Hornbill Automation Node problem

[Stuart Torres-Catmur]

We think this issue started after we updated to Service Manager 1667 on 10th September. 

When we go into our Business Processes to any Hornbill Automation node set up to do Requests > Get Request Information > (any option chosen), the Output Params / Context Reference section is not editable.  See attached example on the BPM Data Proection Data Breach v3.0

If another Requests 'type' is chosen (e.g. Update Request) normal update options are available.

Please advise what the issue is and how it can be resolved.

[Steve Giller]

They are output paramters, not inputs - they are not editable.
Before the update they were not visible, now you can prefix the values with the Result Reference they are displayed so you can see exactly what values to use when referencing the results from that node.

[Victor]

@Stuart Torres-Catmur not everything that is new or changed is a Service Manager update!  ... just defending the SM dev team here  

What you see there is actually something introduced in: 

 

Specifically this -> "Workflow - bpm editor: add support for result reference outputs per hornbill automation call (flowcode) i.e. mycall.someoutput, myothercall.someoutput"

So, every node that provides output results/parameters to variables that can be used in the workflow, can now have their own reference. Before this, all output parameters (such as the parameters or values for the variables returned by "Get Request Details" node) were available globally and they were unique. This means that once a node initialised a certain output parameter (e.g request ID, flowcode variables) it will only associate one only variable for that output parameter. An example will explain this better: let's say one has a "Get Request Details" node because it will be using the request status somewhere in the process. When this node runs, one of the variables that would have become available (among others) is: &[global["flowcode"]["status"]. This variable would store the value for the request status at the time the "Get Request Details" ran. Now, in the workflow there could be more (further) "Get Request Details" nodes. When these node run, all they used to do is to refresh the value for the flowcode variables. "Get Request Details" nodes runs when the request is raised, &[global["flowcode"]["status"] gets the value of "status.open", then later the request is resolved then "Get Request Details" nodes runs again at which point the &[global["flowcode"]["status"] value is refreshed with "status.resolved"... You get the idea I hope.

With the latest change in BPE functionality, each node that has output parameters (such as "Get Request Details") can have a set of its own flowcode variables, a set of private variables as opposed to global variables as before. This means that in a workflow one can use variables for various nodes which output parameters of the same type. Like multiple "Get Request Details" nodes. Back to the above example,  let's say one has a "Get Request Details" node because it will be using the request status throughout the process. "Get Request Details A" nodes runs when the request is raised and this will initialise the flowcode variable set. Now, one can make use of the new "Result Reference" option/field in node configuration to create a sort of "private" instance for the flowcode variables returned by node A. Let's say one sets the value for Result Reference to "Details_A". One would notice that the output parameters, the variables now have a different syntax, for example: &[global["flowcoderefs"]["Details_A"]["status"]]. You see the syntax is different than the one before, we no longer have just ["flowcode"], we now have ["flowcoderefs"]["Details_A"]. So, the request was raised, we are using a Result Reference for "Get Request Details A" node which means  &[global["flowcoderefs"]["Details_A"]["status"]] gets the value of "status.open". Later the request is resolved then there is another "Get Request Details B" node (we named it differently but is doing the same thing). For this node one sets the value for Result Reference to "Details_B". You will then notice we have different variables available such as &[global["flowcoderefs"]["Details_B"]["status"]]. This variable will have the value of "status.resolved" (because the request was resolved when "Get Request Details B" node ran). So, instead of refreshing a unique set of global variables, one can now have a different set of variables for the same type of node if the workflow is using the same node multiple times. Useful for example if one needs to keep track of request details values throughout request/workflow lifetime and needs to reference back a previous variable value (such as knowing the initial request owner, when the request was raised and before it was reassigned, and use this somewhere in the process). Hope this helps, happy to clarify further if needed.

[Stuart Torres-Catmur]

@Victor

OK, I get the bit about this being an update to the design of the node rather than it being a fault.

Sorry, I don't understand your explanation at all.  Can we have it in 'before and after' pictures please? Or is there a video that demonstrates this new thing, what it does and what we need to do to our existing Hornbill Automation Nodes in terms of updating them? 

The last point is the priority.  We want to update our Automation Nodes (such as the one shown in our screenshot), but we don't know what to do to enable this.

[Victor]

@Stuart Torres-Catmur

29 minutes ago, Stuart Torres-Catmur said:

Sorry, I don't understand your explanation at all.

I knew it won't be a very easy to understand concept but .. I am not sure how else I can explain this as a whole...

Before: Everything below "Output Params/Context Reference" + the "Result Reference" field did not exist.

After: "Output Params/Context Reference" + the "Result Reference" now exist.

 

 

4 hours ago, Stuart Torres-Catmur said:

Requests > Get Request Information > (any option chosen), the Output Params / Context Reference section is not editable.

Why would you want to edit output for a "Get Request Details" node? Or any output parameters for any node?

29 minutes ago, Stuart Torres-Catmur said:

We want to update our Automation Nodes (such as the one shown in our screenshot), but we don't know what to do to enable this.

Sorry, update what exactly? Update a node? And update to what? Why?  

 

4 hours ago, Stuart Torres-Catmur said:

If another Requests 'type' is chosen (e.g. Update Request) normal update options are available.

Yes, correct, as you noticed these are Options (update options). Here is a screenshot of the "Update Request -> Details" node:

Options are available on any node that has... options. "Get Request Details" node does not have any options. It can't be configured in any way (*) it is intended to be used to solely retrieve data which can be used throughout the workflow. So I would need to understand why would you want to have options and configure a "Get Request Details" node?

(*) The only field that is now configurable on "Get Request Details" is the new "Result Reference" field

[Stuart Torres-Catmur]

@Victor

I'm sorry, I'm getting confused with the Update Request option.  You are right, this is just the same as before, but showing references underneath now.  The rest of the explanation I will leave to cleverer people to understand.

I think I may have confused this with another issue.  Sorry about that.  I'll try to get more details and, most likely, start a new thread so as not to muddle it with this discussion.

Wibble!

[Guest Paul Alexander]

@Victor

Although our instance is showing as being updated, we don't get these output options when we add a 'get request info' node...it looks like nothing has changed. Am I missing something? 

 

 

thanks

 

 

[Victor]

@Stuart Torres-Catmur

Although your reply about not understanding what I explained kind of implies that you are happy with this but I am not Functionality in Hornbill is not intended for clever people only (and I am sure you are a clever person) so I have given it more thought last night to see how this can be explained. I thought to step away from all the above technical mumbo jumbo with flowcodes, variables, references and all and try and put this in a different perspective. Grab a cup of tea, coffee or stir/shake your favourite cocktail, sit comfortably because is going to be a longer read. 

All done? Good. Let's start.

There is a theory out there claiming we don't live in one infinite universe but a multitude infinite parallel universes much like ours. Let's say that in one of these universes exists a country, let's call it Breat Gritain. People in this universe use Hornbill on their day to day life. Yes, Hornbill is used everywhere and is that good that it transgress the current physics law and is available in all alternate universes. Yes, that good and this is a fact  Breat Gritain is part of a greater union of other countries, they call it Society for Humans Interacting Together. One day the average Gritish person, let's call it Rupert, wakes up, looks at his wife, decides is not interested after 45 years of marriage and decides to do something else. Because Rupert is still fond of the great empire that once Grtitain was, he thinks that the union his country is in, is rather matching its acronym and decides to do something about it. Since Rupert is using Hornbill in day to day life he has the option to raise requests. So he raises a request with the Gritish government asking for a referendum so his county leaves the current union. The request reaches the current leader of that county at that time, let's call him Cavid Dameroon. Cavid receives the request, with the first instinct to cancel it but thinks he can turn this around so he decides to progress the request. This request like all the others has a workflow associated with it so people like Cavid can better manage and progress the requests. So, the first thing the workflow does is to retrieve the request details, information such as request owner, status, date when was raised, priority etc. The workflow does this via a "Get Request Details" node. This node will provide request information for the workflow. The next things the workflow does are various, for example, it creates a task for Cavid to "put together the referendum" and another task to spend a stupid amount of money for no purpose whatsoever. Every request has a spend money for no reason task, Gritish government excel at this. So, the workflow progresses doing a bunch of stuff. While these tasks are active the workflow is suspended, waiting for tasks to be completed. Cavid implements the "put together the referendum" task but he gets a different result than what he expected. The outcome is "leave" something he was not prepared for so he decides he had enough and goes on to write books instead. Before doing this he decides to reassign the request to another user, let's call her Mheresa Tay and completes the "put together the referendum" task with the outcome he got. Because Cavid completed the task and the workflow has now resumed, let's say the next thing it does is to retrieve the request details again for the workflow to have the new information such as request owner, status, date when was raised, priority etc. The workflow also has a bunch of other nodes such, let's say a "negotiate with union leaders" tasks and other nodes. The "negotiate with union leaders" task is assigned to the request owner which at this point is Ms. Tay. She gets on with the task, again, spending a ridiculous amount of money and delaying the task completion. However, same as Cavid, the new request owner tries to implement the task with a desired outcome which was "leave with a deal", but she fails. Therefore at this point, like Cavid before, she also decides that she probably want to write books instead and reassigns the request to another user, let's call him Joris Bhonson. After reassigning the request Ms. Tay also completes the "negotiate with union leaders" with a "not done" outcome. again, Because Ms. Tay completed the task and the workflow has now resumed, let's say the next thing it does is to again, retrieve the request details again for the workflow to have the new information such as request owner, status, date when was raised, priority etc. Getting close to the end of this request saga, let's say that workflow designer, which was the leader of Breat Grittain at that time, Queen Elsebeth, thought that such requests can have a convoluted progress and as a workflow designer she wants the workflow do do different things depending on who was the request owner when "put together the referendum" task existed, who was the request owner when "negotiate with union leaders" existed and who is the owner now because there is a feeling that Joris is special so she might want the workflow to follow a different path if that's the case. So the saga is not over but we will stop here and finally start explaining how the workflow worked before and how it works now based on this.

Before: there was no possibility for Queen Elsebeth to later branch the process on different paths based on previous request owners. The reason for this is that every time the retrieve the request details node ran, it actually refreshed the existing information such as request owner, status, date when was raised, priority etc. When retrieve the request details node ran the first time, the value for request owner was Cavid. When retrieve the request details node ran the second time the value for request owner was Mheresa and when retrieve the request details node ran the third time the value for request owner was Joris. Each time the node ran it refreshed the value, overwriting the previous one. Therefore Queen Elsebeth cannot later branch the process on different paths based on previous request owners because this information no longer exists,it was overwritten each time, the only information about the request owner she now has is the one provided by the latest retrieve the request details node, which says the request owner is Joris.

After: there is now a possibility for Queen Elsebeth to later branch the process on different paths based on previous request owners. Now, it is possible that every time the retrieve the request details node ran, it will store the existing information for the request such as request owner, status, date when was raised, priority etc is a separate, dedicated "box". So, when it ran the first time, the value for request owner was Cavid, and this is stored in its own box/place. When it ran the second time the value for request owner was Mheresa and again this is stored in its own box/place and when it ran the third time the value for request owner was Joris and again this is stored in its own box/place. Each time the node ran, instead of refreshing the values, overwriting the previous ones, it created a new set of values that can now be referenced based on the "box" where they are stored. Therefore Queen Elsebeth can branch the process on different paths based on previous request owners because this information exists in their own little boxes.

The term "box" is used to describe the "Result Reference" field.

 

DISCLAIMER: All characters and events depicted above are entirely fictitious. Any similarity to actual events or persons, living or dead, is purely coincidental. Yeah...

[Foley Coker]

Apologies this might have been my fault in explaining the initial issue to @Stuart Torres-Catmur. @Victor from my understanding of the explanation given above, is that each get request info node can have its own unique reference, and at any point it is placed in the bpm and referenced it is drawing from whichever request info is present at that point of that reference? allowing for multiple streams of separate information to be pulled at different times?  

Currently, in the BPM Data Protection Data Breach v3.0 (Draft) The human tasks that appear after the get request info node, when selecting owner for tasks with the unique output reference from the get request information, it still is not loading the human task when the request is made for the analyst. when populating it automatically came with a reference, but when i look at preexisting get request info nodes in other BPMs previously built, the reference is blank. I have tested it with a blank reference also, but still to no avail. the latest is IN00133148 from our service. 

 

[Victor]

3 minutes ago, Foley Coker said:

is that each get request info node can have its own unique reference, and at any point it is placed in the bpm and referenced it is drawing from whichever request info is present at that point of that reference? allowing for multiple streams of separate information to be pulled at different times?

Correct!

4 minutes ago, Foley Coker said:

it still is not loading the human task when the request is made for the analyst. when populating it automatically came with a reference, but when i look at preexisting get request info nodes in other BPMs previously built, the reference is blank. I have tested it with a blank reference also, but still to no avail.

The fact that activities list is empty indicates the process did not actually reach teh creation of the task is either somewhere before this or followed a different path. If the task would have been reached and there was an issue with the variables I woudl expect to see an error for failing to create the task...

[Foley Coker]

Hello @Victor thats what i thought but the nodes before it are request info nodes which essentially require no action 

 

this is the set up. The stage checkpoint is the last thing to seemingly activate and what should happen next is the activity. so thats why the issue was pinpointed to be the nodes, one for get procap information and one for get owner information. any advice on what could be wrong?

 

[Stuart Torres-Catmur]

@Victor

Big thank you sir . I enjoyed your 09:07 update a great deal.  It was a most amusing tale and I think I understand better now.  However, I think I shall bow out now and let you and @Foley Coker continue dialogue on this matter.  I'm off to write some songs instead.  Maybe a book as well.  I wonder how jolly Joris Bhonson is getting on these days? Sigh...

 

 

[Victor]

@Foley Coker hmm... ok, I'll have a look at IN00133148 and see what I can find. I'll get back to you on this.

@Stuart Torres-Catmur happy to hear that my short saga, which is totally hypothetical by the way (haha!), shed some light into how the workflow nodes used to work and how they work now  I'll try and keep you updated on how Joris is doing these days... probably hanging around with his friend Tondald Drump...

[Foley Coker]

@Victor hello Victor please ignore the above, issue has been resolved. It was the wrong catalouge that was updated, so changes being made werent being seen on the right request.

[Victor]

@Foley Coker good news! 

Sorry I wasn't been able to come back with updates, been off sick for a bit and now on annual leave.