I have been asked by a couple of people why Intermediate events are required in BPM and why SAP make such a big deal about having delivered this feature.
The simple answer is that the process world is not always real-time when it interacts with other systems or processes. These means that we need to have intermediate events in our process models that can get “pinged” by the other systems once they have finished doing what ever it is we asked them to do.
This might make some more sense if I give you a couple of examples that could not be implemented without intermediate events.
Scenario 1 – Master Data Creation
In this scenario imagine that I have a process that creates new materials and at the end of the process I have to create that material in SAP and an old Mainframe system that I have. For the SAP system I can make a real-time call and the material is created. For the mainframe I have to drop a file into a location which is then picked up by an integration broker which puts this file into a mainframe file location. Once the file is processed my mainframe creates another file confirming that it has been created. My integration broker then send a message back to my intermediate message to confirm that it has been created. I can then continue my process to confirm that that material has been created in both systems.
Scenario 2 – Long Running Processing
In this scenario I need to bulk process 200,000 materials at a point in the process to validate that they are all material that exist in SAP. Let’s say that the processing time to do this is 60 mins. If I made a call to this webservice as a real-time request response I would have to have a massive time out on my webservice and if the network fails during the call my process would fail....so what I can do with intermediate messages is call a webservice which starts a batch process that once it has completed call my intermediate message to continue the process.
I hope this helps you to understand why Intermediate Events are a key part of any BPM solution.
