Guest Paul Alexander Posted August 10, 2022 Share Posted August 10, 2022 I've now got two linked requests which are resolved, but the process isn't progressing: Link to comment Share on other sites More sharing options...
SJEaton Posted August 10, 2022 Author Share Posted August 10, 2022 @Paul Alexander it might work if you have all linked requests in the parallel but if you have (at least) a path in the parallel processing that will not raise a linked request, and 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've hit so many brick walls trying to get the suspend node to work. I really didnt think it would be this difficult! lol Link to comment Share on other sites More sharing options...
Victor Posted August 10, 2022 Share Posted August 10, 2022 @SJEaton @Paul Alexander now I am very curious to see how is the setup where the workflow having a Wait For Resolution (with a linked request ID as input param) will resume at the time when the linked request is resolved... I really cannot see how this would work and I am sure I did look through all the code logic Link to comment Share on other sites More sharing options...
Guest Paul Alexander Posted August 11, 2022 Share Posted August 11, 2022 14 hours ago, Victor said: @SJEaton @Paul Alexander now I am very curious to see how is the setup where the workflow having a Wait For Resolution (with a linked request ID as input param) will resume at the time when the linked request is resolved... I really cannot see how this would work and I am sure I did look through all the code logic @Victor - it doesn't work for me....but a way of triggering a process to continue when ALL of the linked requests are resolved would be handy for us! Link to comment Share on other sites More sharing options...
Victor Posted August 11, 2022 Share Posted August 11, 2022 1 hour ago, Paul Alexander said: but a way of triggering a process to continue when ALL of the linked requests are resolved would be handy for us! @Paul Alexander doable... on top of my head 1. Have the main workflow in a Suspend Wait For Update - it will resume when an update is made on main request 2. From the linked request, when resolved, push an update for a custom field of the main request 3. From the linked request, when resolved, push an update on the main request, e.g. "Linked request 1 was resolved" or anything really, it just needs to be an update 4. Have the main workflow refresh request details and check the value for the custom field At this point 2 - 4 will be looping and 2 will be updating a different custom field for each linked request and step 4 would be configured to check values for all these custom fields. If not all values are set, loop back to Suspend Wait For Update. When all values are set, meaning all linked request resolved and updated their correspondent custom field in main request, continue the main workflow. Just an idea, might not be the best, and it would more or less work for a fixed number of linked requests. It also needs available custom fields in main request. One could possibly explore the option to update one custom field only by adding content to this field each time a linked request is resolved then perhaps check for this value in the main request, e.g. how many characters or similar are in the string... Link to comment Share on other sites More sharing options...
Guest Paul Alexander Posted August 11, 2022 Share Posted August 11, 2022 @Victor 9 minutes ago, Victor said: it would more or less work for a fixed number of linked requests. This is part of the problem - we have up to 15 separate 'things' which COULD happen in the parallel process, so we'd need 15 spare custom fields (we don't have that), and we'd need a way of knowing how many of the possible 15 'things' have been triggered. I could revert to updating just one custom field with a '1' for instance and doing a check for 15 x 1's, while having the linked requests ensure that they update that custom field once the call is resolved. If the custom field DOESN'T = 15 x 1's, then loop back waiting for an update. I'll give it a go....maybe.... Link to comment Share on other sites More sharing options...
Victor Posted August 11, 2022 Share Posted August 11, 2022 9 minutes ago, Paul Alexander said: I could revert to updating just one custom field with a '1' for instance and doing a check for 15 x 1's, while having the linked requests ensure that they update that custom field once the call is resolved. If the custom field DOESN'T = 15 x 1's, then loop back waiting for an update. Yep, definitely worth exploring. Ideally one would just use a simple built-in node "Wait For All Linked Requests Resolution". If we only had one... Link to comment Share on other sites More sharing options...
Guest Paul Alexander Posted August 11, 2022 Share Posted August 11, 2022 38 minutes ago, Victor said: Yep, definitely worth exploring. Ideally one would just use a simple built-in node "Wait For All Linked Requests Resolution". If we only had one... I'm not sure the developers would class this as 'simple' would they? If it was, surely it'd have happened by now! Link to comment Share on other sites More sharing options...
Victor Posted August 11, 2022 Share Posted August 11, 2022 @Paul Alexander they can class it as simple.. it's all about perspective... usability, setup and functionality, user perspective? Simple... design and code, development perspective? Well... : Link to comment Share on other sites More sharing options...
Guest Paul Alexander Posted August 11, 2022 Share Posted August 11, 2022 OK...I've done this with only 2 linked requests and it's worked...but ooh it's a lot of work! In the PARENT request: 1 = Log a linked request 2 = Update a custom field in Request 1 with the PARENT request ID 3 = log a linked request 4 = Update a custom field in Request 2 with the PARENT request ID 5 = once all parallel options are complete, suspend the parent request and wait for updates. 6 = In the LINKED REQUEST, after resolution, update a custom field and PARENT REQUEST (whose ID can be found in the custom field updated in operation 2 or 4) with a 1 7 = Update the PARENT REQUEST timeline, as an update to a custom field doesn't register as something that the 'Suspend - Wait for Update' node in item 5 recognises) 8 = PARENT REQUEST is unsuspended and a check is done on the custom field. If only one of the two linked requests is resolved, then the request will go back to being suspended until such time that operations 6 and 7 in the OTHER Linked request are carried out. When that happens, the request will come off hold and the decision will be 'true' so the request will move on. I'm glad I've got that working, but I've now got to see if I can get it working for 15 options.....either way, hopefully that's helpful to someone/somewhere?! Link to comment Share on other sites More sharing options...
SJEaton Posted August 11, 2022 Author Share Posted August 11, 2022 On 8/10/2022 at 10:49 AM, SJEaton said: Hi @DanielRi, following up to our discussion on Monday, I'm still having trouble getting my linked requests to raise correctly. I've checked the workflows attached to the catalog items and the spelling, but they still are raising another New Joiner request rather than the catalog items that I want them to raise e.g New Joiner Equipment Order or New Joiner Existing Equipment. Both myself and Adrian are baffled as all looks ok in the config - see screenshots below. Any other ideas would be greatly appreciated. Thanks Hi @DanielRi @Victor, can either of you assist with this? I think it got lost in amongst the other stuff, thanks Link to comment Share on other sites More sharing options...
Guest Paul Alexander Posted August 11, 2022 Share Posted August 11, 2022 (sorry....I seem to have hijacked your thread!) Link to comment Share on other sites More sharing options...
Victor Posted August 11, 2022 Share Posted August 11, 2022 1 hour ago, SJEaton said: see screenshots below @SJEaton the screenshots seem to be quite small unfortunately... any chance you can repost? Link to comment Share on other sites More sharing options...
SJEaton Posted August 12, 2022 Author Share Posted August 12, 2022 17 hours ago, Paul Alexander said: I'm glad I've got that working, but I've now got to see if I can get it working for 15 options.....either way, hopefully that's helpful to someone/somewhere?! Hi Paul, I'm in the exact situation as you with a huge amount of linked request options so yes this may be helpful for me too! I won't be having a go at this until next week but do let me know how you get on. Thanks Link to comment Share on other sites More sharing options...
SJEaton Posted August 12, 2022 Author Share Posted August 12, 2022 15 hours ago, Victor said: @SJEaton the screenshots seem to be quite small unfortunately... any chance you can repost? @Victor I can't even see the screen shots anymore so I'll raise a new request and re-attach them Link to comment Share on other sites More sharing options...
SJEaton Posted August 15, 2022 Author Share Posted August 15, 2022 On 8/11/2022 at 9:22 AM, Victor said: Yep, definitely worth exploring. Ideally one would just use a simple built-in node "Wait For All Linked Requests Resolution". If we only had one... On 8/11/2022 at 10:02 AM, Paul Alexander said: I'm not sure the developers would class this as 'simple' would they? If it was, surely it'd have happened by now! I'd definitely put our vote to this please!!! Link to comment Share on other sites More sharing options...
SJEaton Posted August 15, 2022 Author Share Posted August 15, 2022 On 8/11/2022 at 1:54 PM, Paul Alexander said: I'm glad I've got that working, but I've now got to see if I can get it working for 15 options.....either way, hopefully that's helpful to someone/somewhere?! Hi @Paul Alexander, how are you getting on? Do you have screenshots of node configurations themselves please so I can see how you've set them up? Thanks Link to comment Share on other sites More sharing options...
SJEaton Posted August 15, 2022 Author Share Posted August 15, 2022 To be honest, I'm not sure your solution will be suitable for us though as we may well have say 15 linked requests but we may not. The linked requests I'm configuring won't always raise, l have varying decisions based on what system access or equipment is requested in the IC and then the BPM raises the relevant one's so it could be any number of linked requests between 0 and 15. Link to comment Share on other sites More sharing options...
Steve Giller Posted August 15, 2022 Share Posted August 15, 2022 @SJEaton That's fairly straightforward. When you decide whether to raise the linked request or not you either: Raise the Linked Request and continue, or Do not raise the Linked Request and add the "finished" value to the Custom Field. In the latter case the value is prepopulated ready for when the BPM tests the Custom Field, and in the former the value will only be populated when the Linked Request is completed. Link to comment Share on other sites More sharing options...
SJEaton Posted August 15, 2022 Author Share Posted August 15, 2022 Hi @Steve Giller, so how will the BPM know when all of the linked requests are complete if this number varies for each parent request raised? Link to comment Share on other sites More sharing options...
Steve Giller Posted August 15, 2022 Share Posted August 15, 2022 9 minutes ago, SJEaton said: if this number varies for each parent request raised Doing it that way, it will never vary. If we take two simplified examples: Request A: Linked Request A1 is not needed so we append "1" to Custom Field A Linked Request A2 is needed so we create it. Linked Request A3 is needed so we create it. Linked Request A3 completes and appends "1" to Custom Field A in Request A Linked Request A2 completes and appends "1" to Custom Field A in Request A Request B: Linked Request A1 is needed so we create it. Linked Request A2 is not needed so we append "1" to Custom Field A Linked Request A3 is not needed so we append "1" to Custom Field A Linked Request A1 completes and appends "1" to Custom Field A in Request A As you can see: Request A adds "1" in steps 1, 4, and 5 Request B adds "1" in steps 2, 3, and 4 Both have different numbers of Linked Requests created but both have "111" in Custom Field A which we can test against. before moving on. 1 Link to comment Share on other sites More sharing options...
SJEaton Posted August 16, 2022 Author Share Posted August 16, 2022 Thanks @Steve Giller, sounds like a plan! If you can provide examples of what needs to be configured in the nodes to append "1" to Custom Field A and then to wait for "111" in Custom Field A before moving on that would be great, thanks Link to comment Share on other sites More sharing options...
Guest Paul Alexander Posted August 16, 2022 Share Posted August 16, 2022 Hi all Just a note - in mine, for some reason when I update the PARENT request custom field (I just add a "1" and set the node to 'Append text', I end up with a 1 1 (with a space in the middle). I'm not sure why this is happening, but I suppose as long as I know that it IS happening then I can work around it. Just thought I'd mention it in case it's messing anyone else up Link to comment Share on other sites More sharing options...
SJEaton Posted August 16, 2022 Author Share Posted August 16, 2022 Hi @Paul Alexander, so does there need to be an additional 1 and a space between each one in the Gotoif expression then? Link to comment Share on other sites More sharing options...
Guest Paul Alexander Posted August 16, 2022 Share Posted August 16, 2022 @SJEaton in mine, I do a check looking for "1 1 1" if I have 3 possible linked requests 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