Jump to content

Connecting Via to Decison node


HHH
 Share

Recommended Posts

What's the reasoning behind not allowing connecting a Via node to a Decision node if the Via has multiple incoming connections.
I managed to build the BPM by connecting the Via to Decision before adding the second incoming node but don't know if/how this will work when running it.
I need to make multiple checks on the customer and display notices depending on certain customer data.

 

756411894_Annotation2020-08-27155308.thumb.png.27bfcf3a5cb8f8b685cae80412712ebb.png

  • Like 2
Link to comment
Share on other sites

Hey @HHH

I think we're trying to do the same thing. I'm trying to check multiple parts of a BPM process (see screenshot) below. Instead of using via, I'm having to use a hornbill automation (does nothing to the request, all options set to ignore for "Lock/Unlock Actions"), so I can combine the 2 results of the Decision then input to another decision.

What I'm wanting to do is...  "team set?" if Yes go to the "Check Source" Decision, if not set the team to Service Desk and then move to check source. As a decision node doesn't support two inputs, I can't do this without some form of middle man to bring the two different actions back together before moving on to the next decision.

Is this what you are having problems with?

Jonny

 

image.png.18771964e63a400e2435881c06f4a4f4.png

Link to comment
Share on other sites

Update:
The workaround of adding the outgoing node before the second incoming node runs as expected. I hope Hornbill can provide some kind of rationale behind the decision.
We'll start by running this on one of the smaller services just in case there are some bugs

  • Like 1
Link to comment
Share on other sites

39 minutes ago, HHH said:

Update:
The workaround of adding the outgoing node before the second incoming node runs as expected. I hope Hornbill can provide some kind of rationale behind the decision.
We'll start by running this on one of the smaller services just in case there are some bugs

Oh yes that worked, will be good to hornbill's stance on it :-)

image.png.8d32817b8376f1c7cdf079c25ebe2f77.png

Link to comment
Share on other sites

Hi @HHH @LifeOfJonny

Sorry for the delayed response on this one, we have been in discussion with our developers regarding it. 
This is going to be amended this week so that if a via node that has multiple inputs, is connected to a decision node (regardless of the order you add the connectors), you will not recieve an error message like you do currently.

Decision nodes are only really designed to accomodate 1 input typically (hence why when you are selecting the decision criteria, you often see some predefined outcomes/criteria in a dropdown list e.g the task outcomes if the decision is based on a task). To accomodate a decision node receiving multiple inputs however, you will ONLY be presented with the Custom Expresson option (looking at your screenshots above, this appears to be what you are doing anyway - but I just wanted to make it clear!). 

We expect this change to be developed this week and hopefully make it's way to your live instances at some point next week.

Kind Regards

Bob

  • Thanks 1
Link to comment
Share on other sites

I will expand on Bob's explanation above to detail on why a decision node can only have 1 inbound connector. In the (very) early versions of the BP engine (BPE), when SM and all other apps were still in inception phase, the BPE mostly had manual tasks (activities). It was designed as a flow of activities that one can use for a certain process. When a workflow (a BP or business process) has manual tasks with different outcomes, the workflow can be branched to follow different paths based on the task outcome. Branching the workflow is done with decision nodes and the expression for each path would be like "Task->Outcome Name" (for example you can have a task with 2 outcomes like "Approved" and "Not Approved" in which case the options for expression in subsequent decision node branches would be "Tasks->Approved" and "Tasks->Not Approved"). Because the value in expression is simply generic"Tasks", and does not specifically says which task, having multiple inbound connectors from two or more tasks into a decision node would create a problem if two or more tasks had the same outcomes. The BPE would then not know to which of the tasks the outcome belongs to (because the outcome is the same) and would not know how to correctly branch the workflow. Because of this scenario, and because the BPE is actually something that any app (including but not limited to Service Manage app) can use, the decision nodes were designed to allow a single inbound connector. However, since then the apps and the BPE evolved, we now have a myriad of nodes from many apps, we now have outcome parameters (variables) that are widely used in branching the workflow. The variables are unique and can be individually references which means the scenario above no longer occurs and when using variables, the decision node can very well accommodate multiple inbound connectors (or converging paths as I call them). In the next BPE2 there will be a more elegant solution to both scenarios (task outcomes and variables) to accommodate a better design of the workflows but this new BP engine is still being developed.

  • Thanks 2
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
 Share

×
×
  • Create New...