• Print
  • Share

Example Patterns

  • Updated on 01 May 2018
  • 3 minutes to read
  • Contributors

In a typical BizTalk environment, the messages pass through multiple orchestrations within the system. The scenario gets worse to understand the end-to-end message flow structure if you have to diagnose a problem with a particular message. The graphical diagram of the message flow indicates the message path within the system – the message enters the system through the receive ports, goes through orchestrations (if any), and exits through the send ports. In this article, we will see such message flow patterns with scenarios.

  1. One Way Transmit & Receive You have a message from an external application or process that you want to receive into your BizTalk Server and you would like to send to a downstream application, partner or process.The image below depicts the message flow while integrating two systems that can communicate only via flat file messages and provide the mechanisms for receiving and sending the messages to BizTalk Server.

-One_Way_Transmit__Receive.png

  1. One-Way Receive, Orchestration, One-Way Send In this case, the message flow using BizTalk Server orchestration to convert an purchase order into an invoice. BizTalk Server retrieves the XML purchase order message from the receive location folder. The orchestration uses the map file to create an XML invoice from the XML purchase order. BizTalk Server places the resulting XML invoice message into the send adapter.

-One-Way_Receive_Orchestration_One-Way_Send.png

  1. Two-Way Receive, Orchestration, Two-Way Send This message depicts a request/response style receive adapter. BizTalk Server first publishes the request message to the MessageBox database. Next, this message is received by the appropriate subscriber, which is likely an orchestration bound to a receive port. This subscriber formulates a response message and publishes it to the MessageBox, along with properties that cause it to be sent back to the receive port from which the request came. Finally, the response message is picked up by the publisher of the request, the receive adapter that submitted the request, and is returned to the calling application.

-Two-Way_Receive_Orchestration_Two-Way_Send.png

  1. One-Way Receive To Multiple One-Way Send In most business processes, we receive a consolidated group of messages containing multiple messages inside it and we call it as a batch. It is a common task to de-batch every single message from the batch and process it separately. We can then transform or route these messages for further processing.

-One-Way_Receive_To_Multiple_One-Way_Send.png

  1. One-Way Receive, Orchestration, Multiple Send Ports An orchestration receives the consolidated group of messages containing multiple messages inside it (batch). We de-batch each single message from the batch and process it separately. We can then transform or route these messages for further processing.

-Graphical_Message_Flow_Error_In_Orchestration.png

  1. Orchestration Multiple Receive (Parallel/Listen) The image below shows the message flow in a business process where the orchestration receives three messages from different sources correlate the messages and send a request to a web service and on receiving a response, it transmits a message to an external system/process.

-Orchestration_Multiple_Receive_Parallel-Listen (1).png

  1. Orchestration - Scatter and Gather Scatter and Gather Integration pattern is a scenario where a message is sent to the Scatter-Gather Operation and the message is either de-batched or sent to multiple recipients or is sent as it is depending upon the requirements. The recipients process the message request and when the processing is completed a response is sent back to Scatter-Gather where all the responses are collected from all the recipients and then processed and aggregated into a single message.

-Orchestration_-_Scatter_and_Gather (1).png

  1. Orchestration Calling Other Orchestrations (Start Shape) In this scenario, the start Orchestration invokes another BizTalk orchestration asynchronously, thus enabling the calling or parent orchestration to continue processing. The below image depicts a message flow in a business process where messages are received into an orchestration and this starts two different orchestration. Inside these two orchestrations, the message is processed independently and the resulting message is sent to different process/systems.

-Orchestration_Calling_Other_Orchestrations_Start_Shape.png

  1. Orchestration Calling Other Orchestrations (Call Shape) Call orchestration invokes another orchestration. The invocation is done synchronously, meaning that calling or parent orchestration must wait for the invoked orchestration to complete before processing can continue. BizTalk360 Graphical Message Flow viewer cannot visualize message flow due to the absence of message event tracking.

  2. Graphical Message Flow: Error In Receive Port, Orchestration and Send Port At each point along the pathway that a message follows through the BizTalk Server messaging subsystem, failures can occur in the BizTalk Server infrastructure and in custom pipeline components, orchestrations and so forth. A failure in receive port is represented in Graphical message flow viewer as shown below.

-Graphical_Message_Flow_Error_In_Receive_Port.png Error in Receive Port

-Graphical_Message_Flow_Error_In_Orchestration.png Error in Orchestration

-Graphical_Message_Flow_Error_In_send_port.png Error in Send Port

  1. One-Way Receive, Multiple Orchestrations, Multiple Send Ports The following message flow shows a pattern where a message received in an orchestration is split up and processed in separate orchestrations and the processed message is sent to external process/systems.

-One-Way_Receive_Multiple_Orchestrations_Multiple_Send_Ports.png