Joins and IBM BPM – Diving Deeper

Next Post
Previous Post

[Editor’s note: This is another guest-post from Andrew Paier, our Director of BP Labs at BP3.  In this post he’s examining how Joins work in IBM BPM.  There’s quite a bit of material available online about how Joins should work in the BPMN spec – but there are subtle differences in how they might behave in a specific BPM engine based on the software developer’s choices for implementing the spec and the areas that aren’t specifically defined in the spec]

 

In answering some questions on the IBM BPM Developer Works forum, I realize that not everyone has fully grokked the join options available in IBM BPM. I hope in this post to clarify that for some of you.

 

(Caveat – what I’m writing below is based off of my experiences delivering BPM solutions using Lombardi Teamworks and IBM BPM.  There are items here that may not be true when this subject is approached as an academic exercise in attempting to understand the BPMN spec.  I can’t help that.  I’ve not memorized the spec.)

 

Joins Defined

 

Joins are any place in your BPMN flow where multiple lines point to the same box.  In a more rational world this is always done with a Join icon (usually a diamond), but it turns out you can also do it by drawing multiple lines to any activity, which just creates an implied join (see end of post).

 

Whenever you have a join, it tells your business process “You cannot move forward from this point until the join rules are met.”  This typically follows a split where you decided to allow multiple activities run in parallel.

 

Join Types

 

In IBM BPM there are 2 basic join types, although they have had different names over the years.  There is an “AND” join (now called “Parallel Gateway”) and an “OR” join (now called “Inclusive Gateway”).  I have no idea which is the technically correct definition, but I will continue to think of them as “AND” and “OR” since that is how I learned them.

 

It is important to understand the difference between these 2 joins or you will likely get confused in your more complex BPM flows.  Here is my basic guideline.  If not fully correct, it seems to cover the vast majority of cases I’ve encountered.

  • AND Join – this join essentially means “There is a token on every in bound line.”  So if I have 5 lines pointed at me, I need a token on each of the 5 lines before I move forward.  Until that happens, the token is going to wait here.
  • OR Join – This one is more subtle.  The rule here is “Every Token that can reach me, has reached me.”

 

What’s the big deal?

 

Well, if you use the wrong join, your process won’t do what you expect and you will wind up with problem.  Lets first look at an AND join. This is pretty easy –

Screen Shot 2013 09 03 at 5 01 54 PM

After this process starts A, B, and C activities will all be sent out, and D won’t happen until A, B, and C are all complete.  If you are looking in the inspector, as each activity completes you will see a token move to the Join.  When there is a token on each line, then they will “Collapse” to a single token and a single instance of Activity D will be sent out.

 

Now, here is an example for an OR join –

Screen Shot 2013 09 03 at 5 05 08 PM

This process starts out the same, and, yes, the token won’t move until A,B, and C are all complete.  But there are some differences here.  Compared to the AND join, this allows all of the following to be true.

 

  • When C is complete, depending on the data, we can immediately issue E no matter what the status is of A or B.
  • If C completes and flows to the Join, D will still wait for A and B (like in the AND scenario).
  • If A and B are complete and C routes to E, D will be issued in Parallel to E

 

That last scenario is why we need the OR (inclusive) join.  If we didn’t do that, if we used an AND join, if we followed the path to E, the A and B tokens would be stuck on the AND join forever as the line from C would never get a token.

 

Why Ever Use AND Joins?

 

If you are following along you might ask the question above.  And you are correct an OR join will act as an AND join if dropped into the first diagram.  However OR joins are computationally expensive, especially in complex real world processes.  (The computation is easy in simple education exercises.)  The AND join is a very simple computation “Hey, is there a token on every line?  Cool, move on.”  The OR Join requires walking backwards through the diagram to each split (which may have occurred in a higher level diagram) and determining if there are any tokens on the lines that could reach you.  And by the way, don’t forget to check for loop backs, which will make your computation go into an infinite loop if you don’t do it right.

 

So you could use OR joins everywhere and likely be safe, however this will cause your system to work harder than it needs to.

 

Did you say “implied joins”?

 

Yes.  It is important to realize that just because you didn’t drag a join in from the pallet doesn’t mean you aren’t joining.  In our first diagram, if you were to remove the join and reconnect its inbound lines to the activity “D” box, in my experience you won’t wind up with 3 D’s issues as each item completes, you get 1 “D” issued when A, B, and C are complete.  Functionally you wind up with the same behavior as in the AND join, but without the clarity of the join for users who don’t know that is going to happen.

 

Correction on September 9th, 2013 –  Based on some user feedback I just went and tested the above and on IBM BPM 8.0.1 this is not an implied AND, you do wind up with 3 D activities issued as A, B, and C complete.  I’m pretty sure this behavior has changed over time though, so I would not count on it.  I don’t think it would be the right way to model the process, and could potentially have migration impacts if you did model it this way.

 

More Complex Scenarios

 

There are ways to handle more complex scenarios in IBM BPM, but I will cover those on another post.  They usually call for a different approach than AND/OR joins can handle.

 

[ original post is available here. ]

 

  • Noe Banda

    Andrew said:
    OR Join – This one is more subtle. The rule here is “Every Token that can reach me, has reached me.”

    =================

    The success I’ve had in explaining the difference in the two joins is when I tell my audience that the conditional join is also referred to as a “smart” join. By that, it looks downstream and is expecting the possibility of X amount of tokens. When the condition is met, then there is no more expectation, only the reality of how many tokens will reach the join. The parallel join is not a smart join, it expects every token that is channeled to arrive at the gateway to reach it before it allows a token to spawn and go on to the next task after the join.

    • subtle difference on the AND join – it waits for a token on each incoming line – once that condition is met, it proceeds. Corner cases – what if more than one token shows up on the same line? It doesn’t count them – one is enough, and more than one counts the same. What if a second set of tokens are produced that would converge on the AND join? will it reactivate or is it one-and-done? (it reactivates)… the corner cases are really interesting.

  • Andrew, I think it just shows we’ve been doing this for too long – I remember it as always activating the Activity on each arrival – but we’ve been doing this so long you can’t trust our memory of what Teamworks 5 used to do!