Skip to Content

BPM with Patterns explained Part-2

This weblog is in continuation of the Part 1 .

BPM with Patterns explained Part-1

In this part remaining patterns are presented.

 

5) Pattern Name: BpmPatternCollectTime

Business Case:

This Pattern is to collect the multiple messages from the Source system for a specified interval of time.

Graphical definition of the scenario:

Pattern5

Process Overview: 

  •  Receive as many as business messages in an infinite loop. Messages received will start the process and activates the correlation. Each Subsequent Message will use the correlation. All the messages with unique correlation are collected in a separate integration process at runtime. The Infinite Loop is defined in a branch within a BLOCK Step. A deadline is defined for the block with a deadline of specified interval of time. When deadline is reached (TimeOut); the process routes to deadline branch where in a control step is defined. This control step then triggers an exception (TimeOut) in this branch. The exception branch does not contain any step and just passes the control out of the block.
  •  After receiving the messages, they are collected in a ‘CollectMessageList’ (Multiline) by using the container with the operation as ‘Append’.
  •  Transformation step is used for transforming the messages collected into a single message (New Message) resembling the target structure.
  •  This message is sent to the target system through send step.

 

6) Pattern Name: BpmPatternMulticastParallel

Business Case:

This is Multicast-Multiple receiver’s pattern in which we have the option of sending a message to multiple receivers and waiting for a response message from each of the receivers.

The procedure of sending a message to multiple receivers and waiting for a response message is also known as ‘multicast’.   

The receivers are determined at runtime from the receiver determination that are configured in the Integration Directory. The number of receivers therefore does not need to be known at design time. The messages are sent in parallel to the target system.

Graphical definition of the scenario:

Pattern6

Process Overview:

  •  The first receive step receives a message into a ‘Message’ Abstract interface.
  •  A subsequent receiver determination calls the receiver determination that is configured in the Integration Directory and gets the receiver list in the multiline receiver ‘Receivers’.
  •  In a dynamic block, the messages are sent to the receivers in parallel. Where the mode of the block is defined as ParForEach (send simultaneously).

Pattern6-correlation

  •  Through send step defined in the dynamic parallel processing block, the receivers one by one are determined into container variable ‘Receiver’ obtained from ‘Receivers List’.
  •  The receiver step in dynamic parallel processing block receives response message from each receiver.
  •  A receiver step uses this correlation and receives the response message from this receiver.

NOTE:The block is complete once all block instances (configured receivers determined from integration directory) that were generated in parallel are complete.

 

 7) Pattern Name: BpmPatternMulticastSequential

Business Case:

This is Multicast-Multiple receiver’s pattern in which we have the option of sending a message to multiple receivers sequentially and waiting for a response message from each of the receivers.

The procedure of sending a message to multiple receivers and waiting for a response message is also known as ‘multicast’.   

The receivers are determined at runtime from the receiver determination that are configured in the Integration Directory. The number of receivers therefore does not need to be known at design time. The messages are sent one after the other to the target system.

Graphical definition of the scenario:

Pattern7

Process Overview: 

  •  The first receive step receives a message into a ‘Message’ Abstract interface.
  •  A subsequent receiver determination calls the receiver determination that is configured in the Integration Directory and gets the receiver list in the multiline receiver ‘Receivers’.
  •  In a dynamic block, the messages are sent to the receiver list one after the other. Here the mode of the block is defined as ForEach (send one after the other). Within the block, a send step sends the message to the first receiver in the receiver list and creates the correlation ‘Correlation’. A receive step uses Correlation and receives the response message from the first receiver. If this receive step is complete, the message is sent to the next receiver in the receive list. The whole process will be repeated for all the receivers in the Recieverslist.    

       Note:A separate instance of the correlation can be processed for each receiver, the Correlation is         defined as a local correlation.A receiver step uses this correlation and receives the response message from this receiver.

 

8) Pattern Name: BpmPatternReqRespAlert

Business Case:

This pattern is to send a request message from the source system and wait for the response from the target system. For example we can consider a Purchase Order and Purchase order response. To monitor whether a particular response message is received by a predefined deadline, hence forth we define an integration process for message exchange. In this process we define a deadline branch to monitor the deadline. If the deadline is missed, an alert is triggered and the process continues to wait for the response message to be received.

Graphical definition of the scenario:

Pattern8

Process Overview:       

  •  The first receive step will receive the Request message, starts the process and activates the correlation Correlation.
  •  The subsequent send step sends the message according to the receiver determination configured in the Integration Directory.
  •  The receive step and send step for Response are defined within the BLOCK with deadline branch. The receive step which receives the response message uses the Correlation. A subsequent send step sends the response message according to the receiver determination configured in the Integration Directory.
  •  The deadline branch is executed for say 24 hours after the correlation that has a unique message id is created and the block is still not processed .The control step triggers an ALERT in the deadline branch. Hence corrective action can be taken.
  •  The receive step waits for the response to be received.

 

9) Pattern Name: BpmPatternReqRespTimeOut

Business Case:

This pattern is to send a request message from the source system and wait for the response from the target system. For example we can consider a Purchase Order and Purchase order response. To monitor whether a particular response message is received by a predefined deadline, hence forth we define an integration process for message exchange. In this process we define a deadline branch to monitor the deadline. An exception is raised if the deadline is missed. An error message is raised and sent in the corresponding exception handler.

Graphical definition of the scenario:

Pattern9

 

Process Overview:        

  •  The first receive step will receive the Request message, starts the process and activates the Correlation.
  •  The subsequent send step sends the message according to the receiver determination configured in the Integration Directory.
  •  The Block step is defined with the exception branch and a deadline branch. The deadline branch is executed for say 24 hours after the correlation is activated with a unique message id is created and the block is still not processed. The exception is triggered by a control step in the dead line branch to pass the control to exception handler.
  •  In the corresponding exception handler the process continues that contains a transformation step to create an error message.
  •  The error message can be identified by an ID from the request message and it is also possible to trap run time values for PI environment such as message id etc from context objects. This helps in taking the corrective action for that message.
  •  A subsequent send step sends the error message according to the receiver determination configured in the Integration Directory.

 

10) Pattern Name: BpmPatternSerializeMultipleTrigger

Business Case:

This pattern is designed to send the messages in defined sequence. And can be specified that the process should wait for the acknowledgement from the receiver each time when it sends the message. In this process different messages can start the process.

Graphical definition of the scenario:

Pattern10

 

Process Overview:

  •  The three receive steps are defined within a FORK step where the corresponding messages are received in the container variables FirstMessage, SecondMessage and ThirdMessage. Any of the three messages can start the process. For this to be achieved start process indicator available in properties has to be set for all the receiver steps.
  •  If one of the message is received it activates the correlation Correlation and also the correlation is used by other receive steps. The FORK will be complete when all the 3 messages are received as the required branches are set to 3.
  •  The messages are sent in a specified sequence as per the sequence in which send steps are defined in the integration process.

 

11) Pattern Name: BpmPatternSerializeOneTrigger

Business Case:

This pattern is designed to send the messages in the reverse order of receiving the messages into integration process. Send steps are defined to wait for the acknowledgement from the receiver each time when they send the messages.

Graphical definition of the scenario:

Pattern11

 

Process Overview:

  •  In this process three receive steps are defined. The corresponding messages are received in the container variables FirstMessage, SecondMessage, or ThirdMessage.
  •  The process starts once the first receive step receives the message as the Start process indicator is set for the first receive step. When the message is received, the receive step activates the Correlation Correlation. This correlation is used by both subsequent receive steps and correlates the messages by means of an ID.
  •  Once the messages are received, the process sends the messages in reverse order.Once the messages are sent it waits for the acknowledgement from the receiver to arrive before sending the next message.

            Note:

                We must ensure that the message of the first receive step – FirstMessage – really is the first    message to arrive. If, for example, SecondMessagearrives first, it cannot be assigned to the process.

 

12) Pattern Name:BpmPatternSyncAsyncBridge

Business Case:

This pattern is designed to communicate between the two business systems in which one is a synchronous Business system and the other is asynchronous business system.For this purpose we define a Sync/Async Bridge.

Graphical definition of the scenario:

Pattern12

 

Process Overview:

  •  In this process receive step (SyncReceive) receives the Request Message from the synchronously calling business system and opens the sync/async bridge.For this in the receive step, the mode in its property has to be set as Opens S/A Bridge. The messages from the business system are received by the synchronous interface BpmPatternBridgeSyncIf and start the process. This synchronous message interface is mapped to an asynchronous, abstract message interface by using the sync/async bridge.
  •  The send step (AsyncSend) sends the received Request message asynchronously to the target business system.
  •  The receive step (AsyncReceive) Receives the Response message from the asynchronously called business system.
  •  The send step (SyncSend) Sends the Response message to source business system which is waiting for the response message as the mode is synchronous. This step also closes the sync/async bridge.
  •  The message type of the message to be sent and that of the message from the synchronous interface in the opening receive step SyncReceive are identical.
  •  The message type of the response message from the system and the response message sent to the source asynchronous system are identical.
1 Comment
You must be Logged on to comment or reply to a post.
  • Hi Sharathchandra,

    Thanks for the illustrative blog.
    I would have thought that the 1:n splits described in scenarios 6 & 7 would be better done using the Receiver Determination as part of the Send step for performance reasons.
    Maybe you could consider adding a comment on this to your blog?

    Sascha