
Problem
I've seen there's a complex gateway available in Appway. How do I use it with custom split and merge logic?

Solution

Furthermore, complex gateways can, in most cases, be replaced by simple types of gateways such as "XOR", "OR" or "AND" gateways. Using simple types of gateway may mean the model ends up containing more elements and connections than otherwise – but such a model is also generally more understandable at a glance.
If you really want to use a complex gateway and define your very own split and merge logic, then here is how it works.
The example of the travel booking process
You want to implement a simple travel booking process. Users are required to select whether they would like to book a plane ticket or a train ticket to their destination. In addition, a hotel stay always needs to be booked, regardless of travel method. While this scenario would usually be modelled using an inclusive OR gateway, you've decided you are going to use a complex gateway.
The model looks like this (and contains no swimlanes, to reduce complexity):

You know that you definitely need to split the initial token into two tokens: one for the hotel connection, and one for either plane or train. You can use the "split" expression to achieve this. The split expression requires an indexed collection of labels (strings) to be the result of the evaluation. That means we could write the following expression:
Note: The connections in your process model need to match the strings you add to the collection returned in the split expression, or you end up with suspended tokens (since the Process Engine wouldn't know where to put the next token).
The Process Engine puts a token on the 'Book hotel' activity, as well as on one of the other two activities ('Book train' or 'book plane'). There are now two simultaneous parallel activities. These activities will, at some point, be completed by one (or multiple) users. In order to send a confirmation message at the end of the process we need to merge these two tokens into one token. Why is this necessary? Because we only want to send one confirmation message, not two. It is therefore important that only one token lands on the 'Send confirmation' activity.
Important: We are not merging in order to avoid the fastest token through the process bringing the process instance to an end; this instance only completes once there is no token left in the process anyway. The second token would therefore still pass through the gateway and be consumed at the end event, but two confirmations would be sent. We are merging in order to prevent triggering multiple confirmation messages.
So how should merging take place? Well, remember the AND gateway's merging logic? An AND gateway waits until every incoming connection has a token ready for the merge. The same happens for an inclusive OR gateway as well, except that the OR is capable of back-
tracing and then waiting for the right connections to provide a token.
When working with a complex gateway, you are responsible for defining the merging logic yourself. In our small process it would be much easier to simply use a merging "AND" gateway - but keeping on topic, let's use a complex gateway.
For this complex gateway, specify the join expression and leave the split expression empty. The join expression has an implicitly defined variable which can be used in the expression (no declaration necessary). The variable automatically contains the tokens.
The join expression can read the implicitly available variable "$workflowTokens" (Indexed WorkflowToken). This is the collection of tokens that eventually merge. If you don't specify a split expression, Appway simply outputs a single token after the merge - exactly what we want, right? So we want to make sure the complex gateway only merges if all tokens have arrived.
We know that there are always two tokens making their way toward this second gateway, so here's how to write the required expression:
Even if one user now finishes their task much earlier than the other, the first token simply waits on the gateway for merging to take place:

The gateway merges the tokens once the second token arrives, and produces a single token. It is this single token that moves onto the 'Send confirmation' activity. The process instance then ends immediately after the execution of this automated task.
To summarize: The logic contained in this process could be modeled using simpler gateways. It is not necessary to define custom merging logic, but you can do it. Splitting logic is the more likely reason why someone would want to use a complex gateway, but even then it's not common. If you can use simpler gateways, you probably should!

Comments (0)