Wait for Linked Request Resolution

[SJEaton]

Hi

I'm trying to configure raising a linked request and suspending to await its resolution in a BPM but I'm a bit rusty and what I've configured isn't waiting.  Can someone put me right as to what I need to configure in this node please?  Thanks, Sam

  

[Steve Giller]

Hi @SJEaton

That's not a "Wait for Linked Request Resolution" node, it's a "Wait for a Request to be Linked" node. It won't wait, because there is already a Linked Request.

If the variable in the Request ID is the Reference of the Linked Request, you should be using a "Wait for Request Resolution" node, however please bear in mind that forcing a Request ID (rather than allowing the Workflow to pick up the ID of its related Request automatically) is not guaranteed to work.

[SJEaton]

Aha!  thanks @Steve Giller

[SJEaton]

Hi @Steve Giller, and when you raise the new linked request, please remind me, how does it know what BPM to use for the linked request?

Thanks, Sam

[Steve Giller]

@SJEaton That would depend on the parameters of the node, but if you're populating the Service and Catalog Item parameters it'll take the BPM from there.

[SJEaton]

Hi @Steve Giller, got linked request working now, thanks.  I have messaged you re some further assistance though.

Sam

[SJEaton]

Hi, I'm still struggling to configure what I need.  I need to run multiple flows concurrently in a parallel process, depending on what systems are selected in a custom field and what team therefore grants the system access.  This is the current BPM config...

If I select a system for 1st Line team only I get the following error.  I also get this error if I select systems for both teams.  

decision ("stage-f15d6516"/"decision-77543c75") execute: at 2/61: "Uncaught TypeError: Cannot read property 'newRequestId' of undefined" return [((global["flowcoderefs"]["logRequestServiceRequest"]["newRequestId"]!=undefined && global["flowcoderefs"]["logRequestServiceRequest"]["newRequestId"]!=nul...

If I select system for Lorenzo team only, it raises the linked request, and then updates the parent request timeline when the linked request is resolved, but it doesn't move onto the 'system access granted' checkpoint or the next stage of the process.

This is what I've got configured in the suspend node, is it correct?  

Any additional assistance much appreciated.

Sam

[Victor]

2 hours ago, SJEaton said:

If I select a system for 1st Line team only I get the following error.  I also get this error if I select systems for both teams.

You have an custom expression (likely the "Yes" branch on the decision node after the parallel processing) that has criteria for linked request(s). You have (at least) a path in the parallel processing that will not raise a linked request. If your workflow goes through this (or these) paths then there is no linked request thus you will have an invalid criteria for the expression.

2 hours ago, SJEaton said:

it doesn't move onto the 'system access granted' checkpoint or the next stage of the process

You have a node named "Wait For Linked Request Resolution" but the node configuration is set to wait for the current request resolution, not the linked one. You can resolve the linked request but the current workflow is not waiting for that in it's current configuration. Therefore it will remain suspended and resume when the current request is resolved.

2 hours ago, SJEaton said:

This is what I've got configured in the suspend node, is it correct?  

If that is intended for the linked request then no, it's not correct. You need to pass/put the value of the linked request reference in the Request ID param.

[SJEaton]

Thanks @Victor, I'll see if I can fix based on your advice above.  Once I have this field I intend adding further flows within the parallel process which will raise linked requests also. How will I cater for these in the suspend node if I want to wait for them all to resolve?  thanks     

Sam

[Victor]

5 minutes ago, SJEaton said:

How will I cater for these in the suspend node if I want to wait for them all to resolve?

If you want to wait for more than one request to be resolved this can only be done with multiple wait nodes. One node per each request you need to wait for. Assuming this is what you meant.

However it seems to me at some point we are moving away from current capabilities of what a process can do. I mean theoretically it could be possible to build something to the complexity that it seems there is but perhaps an idea would be to see if the business requirement can be implemented using multiple workflows.

In other words, what you are doing in that workflow might become too complicated and possibly plain not possible (at times) so perhaps think of using separate workflows?

[SJEaton]

2 hours ago, Victor said:

4 hours ago, SJEaton said:

If I select a system for 1st Line team only I get the following error.  I also get this error if I select systems for both teams.

You have an custom expression (likely the "Yes" branch on the decision node after the parallel processing) that has criteria for linked request(s). You have (at least) a path in the parallel processing that will not raise a linked request. If your workflow goes through this (or these) paths then there is no linked request thus you will have an invalid criteria for the expression.

I changed the variable in the decision and this part now works, thank you 

[SJEaton]

The suspend node also now works, thank you.  all I need to fathom out now is how I would replicate this for other teams/linked requests raised but note that as you said, may require multiple suspend nodes however this may not be within current capabilities.  I'll see what happens

Sam

[Victor]

7 minutes ago, SJEaton said:

this may not be within current capabilities

Just to clarify, without knowing in more details the business objective, I cannot say with certainty if the product can do it or not. While I do not specifically see a reason why your configuration cannot be implemented; if that becomes too complex it might be that at that point the capability is reached. For example, in the above sequence, you might find that you actually do need that "Wait For Resolution" node inside parallel sequence and there is no alternative where that node can be taken out. In this scenario the capability is reached since you cannot have an automated suspend node inside parallel processing sequence(*)

(*) this is just a theoretical example to demonstrate a possible scenario where complexity can make the desired outcome unachievable in a workflow