Giuseppe Iannacone Posted January 9, 2019 Share Posted January 9, 2019 we received this error message while processing a request, can you please help us? (the bpm has not been modified in the last days and was working fine) Link to comment Share on other sites More sharing options...
ArmandoDM Posted January 9, 2019 Share Posted January 9, 2019 Hello @Giuseppe Iannacone is the BPM operation triggered after completing a task ? Cheers Armando Link to comment Share on other sites More sharing options...
James Ainsworth Posted January 9, 2019 Share Posted January 9, 2019 Hi @Giuseppe Iannacone Can I also recommend trying the BPM Tool Box feature this can be enabled using the following System setting. Once this is enabled, a new icon will be available on the list of BPM Processes... It will prompt you for a BPM ID. One way to get the BPM ID is to either use the Direct Database to query the request with the broken BPM to find this ID. I'm also sure it may be possible to create a report that shows all of the currently broken BPMs (I'll look into this). SELECT h_pk_reference, h_bpm_id FROM h_itsm_requests where h_pk_reference = 'CH00000006' Once you have the BPM ID for the request, the workflow is displayed and it highlights which node is causing the problem. It can also provide a more detailed error message to help with troubleshooting. Let us know how you get on. Regards, James Link to comment Share on other sites More sharing options...
Giuseppe Iannacone Posted January 9, 2019 Author Share Posted January 9, 2019 3 hours ago, ArmandoDM said: Hello @Giuseppe Iannacone is the BPM operation triggered after completing a task ? Cheers Armando @ArmandoDM after restarting the process on the reload icon on the hud bar the process have restarted but the task were cancelled (?!?) @James Ainsworth this is a good suggestion but very time consuming, I don't know when i will be able to perform this task. Do you suggest to enable this setting only for a limited time for the troubleshooting or leave it turned on anyway? thank you Link to comment Share on other sites More sharing options...
James Ainsworth Posted January 9, 2019 Share Posted January 9, 2019 @Giuseppe Iannacone I would leave this setting on. Link to comment Share on other sites More sharing options...
Giuseppe Iannacone Posted February 20, 2019 Author Share Posted February 20, 2019 @James Ainsworth it seems like the team is randomly finding out some broken requests... can you please help me with the report you were talking about? On 1/9/2019 at 8:01 PM, James Ainsworth said: I'm also sure it may be possible to create a report that shows all of the currently broken BPMs (I'll look into this). Link to comment Share on other sites More sharing options...
James Ainsworth Posted February 20, 2019 Share Posted February 20, 2019 Hi @Giuseppe Iannacone Here is the report that I mentioned. Let me know if you have any questions. failed-workflows.report.txt Link to comment Share on other sites More sharing options...
Giuseppe Iannacone Posted February 20, 2019 Author Share Posted February 20, 2019 @James Ainsworth thank you for the quick reply, i will now use it and let you know Link to comment Share on other sites More sharing options...
Giuseppe Iannacone Posted February 20, 2019 Author Share Posted February 20, 2019 @James Ainsworth thanks to your support i was able to find out some of the failed workflows. the strange thing is it's not finding some requests that are reopened and resolved by the system, some kind of loop. i've found for example this: if i try to edit it in the bpm editor: i only see a green automatic task, so what is should do now? Link to comment Share on other sites More sharing options...
James Ainsworth Posted February 20, 2019 Share Posted February 20, 2019 Hi @Giuseppe Iannacone That report will only show BPMs that have failed (displayed in red). Your BPMs appear to still be active as they are green. I'm wondering if the Suspend and wait for Resolution is causing the problem. It might be looking to see if there is Resolution Text and not just checking the status. So, even if the status is Open, the original resolution text might still be in place, and the suspend is not suspending as a result. Just a thought at the moment. I'll see if I can find out more info on this. Link to comment Share on other sites More sharing options...
Giuseppe Iannacone Posted February 20, 2019 Author Share Posted February 20, 2019 @James Ainsworth thank you James, it will be very useful Link to comment Share on other sites More sharing options...
James Ainsworth Posted February 21, 2019 Share Posted February 21, 2019 Looking at the code behind the Suspend and Wait for Resolution, it is strictly working off the status. So, if a loop is happening it might be that for some reason on the decision node, a resolved request is taking the route of Reopened outcome. Can you paste a screen shot of what you have configured on the Goto If option for the Reopened branch? Link to comment Share on other sites More sharing options...
Giuseppe Iannacone Posted February 21, 2019 Author Share Posted February 21, 2019 @James Ainsworth here is the goto node definition Link to comment Share on other sites More sharing options...
Victor Posted February 21, 2019 Share Posted February 21, 2019 @Giuseppe Iannacone - you're not using the variable from the right flowcode... "Flowcodes -> Request Status" is a variable returned by suspend node... what you need in your decision is "Flowcodes -> Status", a variable returned by "Get Current Status" node... Link to comment Share on other sites More sharing options...
Giuseppe Iannacone Posted February 21, 2019 Author Share Posted February 21, 2019 @Victor & @James Ainsworth thank you for the feedback and support. Consider that this BPM was suggested to us at the very beginning of our "Switch on" so if the flowcode is not the correct one: - why is it working for almost 99% of the other request based on the same BPM? - it is because something has changed in the meanwhile? - do I have to review all the BPM with this flowcode? Thank you Link to comment Share on other sites More sharing options...
James Ainsworth Posted February 21, 2019 Share Posted February 21, 2019 @Giuseppe Iannacone Personally, I think that the outcome should be taken from the suspend node as you want to know what the status changes to. I don't think that the Get Current Status is actually needed in your process as prior to this you already have a Suspend and wait for Resolution and there no opportunity for this status to change between this and the Suspend and Wait for Status Change. You already know that the status will be resolved. I would be interested to know if on the small percentage of situations when this happens, if the person that resolved the request is using a different language from other users. Link to comment Share on other sites More sharing options...
Giuseppe Iannacone Posted February 22, 2019 Author Share Posted February 22, 2019 @James Ainsworth I'm not sure to have fully understood what the outcome must be for a 2 stage closure. So would you be so kind to provide me a definition file as example? Regarding the language, the example i was refferring to was resolved by my self, english is my default language. other analyst that has worked on the request have the italian as default language. Link to comment Share on other sites More sharing options...
Victor Posted February 22, 2019 Share Posted February 22, 2019 @Giuseppe Iannacone @James Ainsworth It seems there is a general misunderstanding of how the suspend node works currently. I'll try and clarify this. The "Suspend Wait For Status Change" node returns a flowcode variable named "Request Status". If you look at the variable syntax when selecting it it will say &[global["flowcode"]["newStatus"]]. This "newStatus" variable is refreshed when the node is processed or executes with the value of the current status of the request and it works fine for the majority of the situations. However there is one particular scenario where this variable ("newStatus") does not refresh and as such, it can cause issues. I'll try to explain with the following example The request is progressed to the autoclosure stage, the request is resolved and the "Suspend Wait for Status Change" node is reached. The request is then reopened (either by customer or by a user). At this point, the "newStatus" variable value is updated with the "status.open" value. The process then will follow through the "reopen" branch then the request is resolved. Now, this is the scenario where things might not go as expected: let's say the request is not actioned and the "Suspend Wait for Status Change" node expires. At this point, the "newStatus" variable value is NOT updated, meaning it will still have its previous value of "status.open". As you can imagine, the workflow now can actually follow two paths: one for the "reopen" and one for "expiry" (both would evaluate to true). I assume it follows the "reopen" path because this is the first path evaluated by the BPE. So you, see, using the &[global[" flowcode"]["newStatus"]] in current functionality might not work as you would need and can make the progress go via an unwanted path. This is the reason why (at least for the time being) I advise using the status variable from the "Get Request Details" node because this will always have the actual value for the request status. @James Ainsworth 11 hours ago, James Ainsworth said: request is using a different language from other users BPE does not care about language, it cares about DB values which are always EN. 11 hours ago, James Ainsworth said: Personally, I think that the outcome should be taken from the suspend node as you want to know what the status changes to If you want this then this behaviour (described above) needs to be looked at by dev team and changed accordingly. Hope this helps. Link to comment Share on other sites More sharing options...
James Ainsworth Posted February 22, 2019 Share Posted February 22, 2019 That is some very interesting insight @Victor. I hadn't considered the order that the outcomes are evaluated. But in this case the previous value is Resolved. So I'm not sure I understand why it would go down the path for "Open''. Link to comment Share on other sites More sharing options...
Giuseppe Iannacone Posted February 22, 2019 Author Share Posted February 22, 2019 @Victor so based on what you have explained before I must adjust all the similar BPM I have with this flowcode, correct? Link to comment Share on other sites More sharing options...
Victor Posted February 22, 2019 Share Posted February 22, 2019 @James Ainsworth 51 minutes ago, James Ainsworth said: But in this case the previous value is Resolved No, the previous value is OPEN. Because after the node "executes", in case there is an expiry, the value for "new status" is not refreshed, meaning it will not update to have the resolved status!let's say the request is not actioned and the "Suspend Wait for Status Change" node expires. At this point, the "newStatus" variable value is NOT updated, meaning it will still have its previous value of "status.open" Link to comment Share on other sites More sharing options...
James Ainsworth Posted February 22, 2019 Share Posted February 22, 2019 @Giuseppe Iannacone Maybe give us some time to look at options with our development team to look at before making any changes. Link to comment Share on other sites More sharing options...
James Ainsworth Posted February 22, 2019 Share Posted February 22, 2019 23 hours ago, Giuseppe Iannacone said: why is it working for almost 99% of the other request based on the same BPM? @Giuseppe Iannacone the reason it works most of the time is that there is only one particular scenario when this occurs. This scenario is when a request has been reopened the first time it passes through the Suspend and Wait for Status Change. As this loops around to the Suspend and Wait for Status Change a second time, if it then Expires before a new status is applied, this is when the issue can occur. Link to comment Share on other sites More sharing options...
Giuseppe Iannacone Posted February 27, 2019 Author Share Posted February 27, 2019 @Victor & @James Ainsworth any news on this topic? Link to comment Share on other sites More sharing options...
Victor Posted February 27, 2019 Share Posted February 27, 2019 @Giuseppe Iannacone - not sure what news I can give you... my previous advice in current functionality remains valid. If the functionality is to change, it is something for James to advise... Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now