Jump to content

Process failure


Recommended Posts

Hi @Giuseppe Iannacone

Can I also recommend trying the BPM Tool Box feature this can be enabled using the following System setting.

image.png

Once this is enabled, a new icon will be available on the list of BPM Processes...

image.png

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'

image.png

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. 

image.png

Let us know how you get on.

Regards,

James

Link to comment
Share on other sites

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

  • 1 month later...

@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

@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:
image.png.5c2069454f39f37965aee24c5af9c1fe.png

if i try to edit it in the bpm editor:

image.png.10139b76f42fa38af83b99e986fabc03.png

i only see a green automatic task, so what is should do now?

image.thumb.png.475a5229c4964c0ad2cf5195ab1e848d.png

Link to comment
Share on other sites

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

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

@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

@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

@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

@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

@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

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

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...