Jump to content

Issue with parallel processing and authorisation


Dan Munns

Recommended Posts

Hi, 

I am having an issue with parallel processing a number of authorisations and capturing the reasons for each one.

So (buckle in this is a long one) I first of all update 25 custom fields to hold the text 'None'.

I then start parallel processing and have 25 authorisation nodes, followed by 25 get authorisation detail nodes, followed by 25 update custom field nodes before finally closing the parallel processing. The update custom field nodes each update a single custom field. The first node after the parallel processing finishes is a Get Request Information node so that the responses can be emailed via a template.

If all the authorisation nodes have a reason added then all custom fields are updated correctly and the template is good. If any of the authorisations don't have a reason, then the 'None' text should be left as is, however this is not the case. 

It seems the 'None' nodes are picking up the reasons from other authorisations nodes but I cant see why this is the case. 

The BPM looks like this: 

image.thumb.png.ac79f97760775c48772888728cfad32c.png

In the email template IT Security should say 'IT Sec Stuff' and the others should all say 'None' but they have taken the info from the IT Sec authorisation/custom field:

image.png.8534b47f088046f16adfd5538150fb5a.png

I cant seem to work out why this is happening, as it only happens to the ones that have no reason (if the user selects 'No impact' for which I am using 'accept' then reason is optional, if the user selects 'Impacted' (refuse) then reason is mandatory. I dont want to force a reason for both to just get different variations on 'None'. I need to be able to report on the 'None' replies which is why I am doing it this way)

 

So TL:DR....HELP!! 

Thanks

Dan

Link to comment
Share on other sites

@Dan Munns 

This may be to do with the way that Authorisations work and the reasons are stored - when you select "No Impact" and do not give a reason the previously stored reason has not been cleared - so it could be any reason from any node within the parallel process.

What I would recommend trying is to have a decision node after each Get Authorisation Details node.
At this point you test the outcome and if Refused you can inject the reason into the custom field as above, if Accepted you bypass the update node completely and. If you need to do something with the (optional) reason you can do it on this branch.

Cheers,
Steve.

Link to comment
Share on other sites

@Gerry this is a new BPM that is all fine bar this (Sod’s law I suppose). 
@Steve Giller, so even though there is only 1 authorisation node per lane from the start of the parallel processing, and all the authorisation nodes are different it can still interfere? As I said, if I put a reason into each authorisation they map fine. 
 

I thought that the nodes in a BPM could only ‘see’ the other nodes along the same track so how are these separated nodes seeing other tracks data? 
 

Sorry to be a pain, I’m just trying get my head around how it all works as I am going to have a few of these kind of workflows to do in the coming weeks. 

Link to comment
Share on other sites

@Dan Munns

we would need to look into this, I have a feeling the auth node might return its results to a global value and from what I recall there is not execution context isolation in parallel processing so it could be that same variable storage is being used for all auth nodes, and its just fortuitous its working on the basis that generally only one will be approved at any point in time.  If thats the case, that would explain why the value is is getting reused when its being being explicitly set.  We will look into it and see what we can do to fix it - without breaking the possibly broken) way it works now. 

Gerry

Link to comment
Share on other sites

Thanks @Gerry

I think it does use a global variable looking at it now because the flow code is identical for each one no matter what I do. I guess it is just keeping the last data entered until it is over written by the next note. 

Trying @Steve Giller decision node addition works, but I cant work out how to capture the 'Impacted' notes. And if two of the authorisations nodes are done really close it is hit and miss which notes it takes.

This has definitely been one of the most frustrating BPMs I have had to build so far. I am so close to the end as well :( 

Link to comment
Share on other sites

@Dan Munns

Ok we have had a look at this now and am not sure what you are trying to achieve is actually achievable here.  Each approval node is followed by a Get Auth Details node, you appear to be trying to get the rejection reason correct?  What if you have multiple approvers in one of those nodes and more than one person rejects it and provides a rejection reason? who's rejection text would you put into the custom field. I am trying to understand what you are trying to achieve so I can offer some further assistance. Can you give me any further explanation? 

 

Gerry

Link to comment
Share on other sites

Hi @Gerry

In this instance I am using the authorisation nodes for our Impact Assessment. We have 25 teams/departments who need to respond and each authorisation node is setup for two authorisers at 100% approval each.

So, only 1 person needs to respond with the impact the proposed request will have on the team (and has been agreed who it will normally be, the second is there for redundancy if required). 

I have made some amendments to the workflow and it 'works' almost all the time, with only 1 instance, where me and another authoriser submitted at the exact same time and caused an issue where the data was copied into 2 fields. It is mighty slow moving from the last human task before the parallel processing to the last authorisation node in the parallel processing though (though I did expect that with the amount it is spawning):

image.thumb.png.d6ba2bf815d0867b5bc21a4986c7bf0d.png

So in short, I am happy that this works for what I need, even if it was a pain to build (so much configuration to automate what used to be manual email of a spreadsheet once a week). But it means that a fair few hours per week have been saved for someone when I roll it out for another, larger process.

Link to comment
Share on other sites

@Dan Munns

A further update for you.  Having now reviewed how this works with some of the devs here, there are definitely some issues for you to be aware of.  In BPM, every node is run asynchronously,  so when, for example you start parallel processes what happens is they will run one after the other. each one to a point where it yields, for example waiting for user input etc, so its not strictly parallel as in multi-threading, I suppose you could adopt and old term of pre-emptive multi-tasking.  Anyway, you using a FlowCode called Get Authorization Details that will give you the details of the last authorization that was completed, and that does not unfortunately mean the last authorization in your particular flow. That will mean your workflow is vulnerable to error (namely in your case, picking up the wrong auth reason in one of your custom fields) because of the way it currently functions. 

The short explanation: we implemented authorizations *before* parallel processing, and they do not play nice together.

We are going to look at a way for the auth node to expose its results into a node-specific context, such that a following decision node will always be guaranteed to access the last automrization is in its flow, and this context would give you access to the outcomes, voting weights and other stuff, essentially removing the need for the Get Auth Details node, its on the list and I will post back when its sorted, so you can update, and even simplify that glorious looking approval process of yours :)

Gerry

 

 

Gerry



 

Link to comment
Share on other sites

Oh @Victor

Welcome to my "What SLA does this request need?" phase of one of my BPMs. 

It wont all fit on the screen at 50% zoom and the next step down is waaaaay too small (33%).

I had fun building this /s

image.thumb.png.b441b5f82e0a13f6e64764e7e9cf08c1.png

I built it like this to make it easier to manage going forward. Adding/removing sections isn't too bad. I am sure there is probably a better way doing doing this, but for setting SLA based on category which goes 3 levels deep depending on what the requestor selects from the PC it works ok and is quite quick (the analysts don't see the ticket until all this has been done anyway)

Edit: I think approx 180 nodes here....

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...