The Incoming Processor Pattern and the BPMS

Scott Francis
Next Post
Previous Post
Anatoly has posted another process pattern: the Incoming Processor Pattern. It is a good pattern – and actually forms the basis for a lot of variants of that pattern (in a sense, it is the base case of a wide variety of patterns). Essentially, Anatoly describes a process that begins with a message start event listener:
credit: Process is the Main Thing
Beyond that, Anatoly points out there is a challenge with respect to having more than one instance of this process:
But here is the question: how would the message from client John Smith find its way into specific process instance associated with him? Let’s not forget that there are about thousand of instances behind the single pool “Credit card issuance” shown in the diagram. […] But when a message is sent into the middle of a process (i.e. to the intermediate event) one must specify the process instance ID. Moreover, the process instance ID is the internal BPMS data so we can’t expect that a message from an external entity (from collapsed pool on a BPMN diagram) would contain it explicitly. In our case it’s just client’s words “hello, I want my card.”
He even diagrams this “incoming processor”:
Credit: Process is the Main Thing
I found his description of this pattern interesting, because the BPMS that I use most often (Lombardi / IBM BPM) wouldn’t require the incoming processor pattern for this use case.  The typical case for BPMS’ is that the event listeners can hear events targeted at their process instance id.  But Lombardi took a different tact that IBM has preserved – events “correlate” on any piece of process instance information – process instance id is certainly one option, but so is a name, or a debit card number.  And the logic to find and message the right process instance is built into the engine. Not only that- a message my correlate with more than one process instance -automatically- based on the various correlations. So this is a case where the BPM engine allows the models to be both more expressive and more concise, and to leave the incoming processor logic as a black box that “just works.” But if your BPMS doesn’t do this for you, or if you need to do additional pre-processing logic before the process instance is triggered, this pattern will do the trick. Once again, a great, thought-provoking post from Anatoly’s blog.
  • Scott

    Thank you for digging it in but there is a bit of misunderstanding I’m afraid.

    How can the event listener hear the voice of a client standing at the counter and asking for his credit card? It’s the Incoming Processor function to transform an unformal message into formal data within BPMS/ESB/CEP.

    I’ve got you point that IBM/Lombardi is flexible in correlation – it can use any attribute, not just process instance id – but it’s a secondary matter. I can’t see how one can live without Incoming Processor process or some analogue implemented outside BPMS – there must be something that would generate the event that credit card process awaits and pass the correlation id to the listener.

    • Anatoly –

      First, apologies, I didn’t quite read your example correctly.  Some of my assumptions from situations with our customers have colored how I interpreted your example.  Re-reading now I can see its obvious I missed a few points. 

      It is the “look up the instance” part that is abstracted in IBM BPM – not the need to interact with the customer and find out who they are :)  (And, of course, deal with possibly not finding their card or their card request).

      Thanks for the correction!

  • Greg Harley

    I really like the Bizagi modeller.

    • yeah it has a nice output format.  I don’t really like drawing in it that much, but I like the output.