In answering some questions on the IBM BPM Developer Works forum, I realize that not everyone has fully groked 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 –
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 –
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.
