Singleton Orchestration in BizTalk Server

Singleton Orchestration in BizTalk Server

Abstract  In this article you will learn how to write Singleton orchestrations using BizTalk Server.
This article has been taken from this site.
Article Contents: Overview What is a Singleton Orchestration? Implementation How does one create a Singleton Orchestration? Scenario: Memo Processing Example Conclusion
Overview
Generally, a singleton pattern is used to restrict the number of instances of a class to only one object. This means there can be only one instance of a class at any time. All the requests for an instance of the class would point to the same object that was created earlier. The singleton pattern is implemented by creating a class with a method that creates a new instance of the object if one does not exist. If an instance already exists, it simply returns a reference to that object. To make sure that the object cannot be instantiated any other way, the constructor is made either private or protected.
What is a Singleton Orchestration?
In Biztalk Orchestrations, a new instance of an Orchestration is created every time a message arrives at the Receive Port. In a Singleton Orchestration, there would always be only one instance of the Orchestration irrespective of the number of messages that arrive at the Receive Port. All the messages that arrive at the Receive Port are processed by the same instance of the Orchestration.
Implementation
The first message that arrives at the Receive port creates a new instance of the Orchestration. All other messages would use the same Orchestration for processing. A BizTalk Correlation would ensure that the messages which arrive into the Orchestration have at least one similar property.  For example, the messages arrive from the same Receive Port or they have the same InstanceID or flag property. For a single Orchestration to exist, all the messages which arrive at the orchestration must have one common property. This common property of the messages must be encapsulated into a Correlation set. The Correlation set created above shall be initialized on the receipt of the first messagewhich creates the Singleton Orchestration, all other subsequent messages would use the same Correlation set and, therefore, the same Orchestration instance. Figure 1 – Receive Shape Properties Dialog box
How does one create a Singleton Orchestration?
1.    Create a correlation type with the property "BTS.ReceivePortName;" this will ensure a single instance of an orchestration, since all the messages come from a single receive location. 2.    Create a correlation set with the correlation type created in the previous step. 3.    In the first Receive Shape (Activate = true), set the property "Initializing Correlation Sets" as the correlation set (created in the previous step) and in the Second receive shape (Activate = false), set the property "Following Correlation Sets" as the correlation type (created in the previous step). NOTE: Any promoted property which would be the same across all the messages can also be used as the correlation type property.
Scenario: Memo Processing Example
In this example a Memo input is sent to the orchestration. The Memo message is of two kinds, "Memo.xml" and an "EndMemo.xml" (Flag is set to STOP). NOTE: The EndMemo signifies the end-of-batch signal. 1.    When the first Memo arrives at the receive location, a new instance of the Orchestration is created with the Correlation Set as the Receive Port name. 2.    All other messages which arrive at the same Receive port would have the same Correlation set and would use the same instance of the Orchestration. 3.    When an "EndMemo.xml" arrives into the Orchestration an exception is thrown by the orchestration and the Orchestration state becomes “Suspended (non-resumable).” All other messages which arrive after the “EndMemo.xml” will not be processed. When this Orchestration instance is terminated it gets into “Completed with Discarded Messages” state. In this case the Orchestration needs to be terminated.  The entire set of messages which were not processed in this case needs to be resubmitted again. 4.    The Logic has to be written in such a way so as to Terminate the Orchestration in the case where a EndMemo arrives. 5.    After the “Suspended Orchestration” is terminated, a new instance of the Orchestration is created once a message arrives at the receive location. This Orchestration will continue to process new messages placed at the receive location until an EndMemo.xml arrives, which again suspends the orchestration. 6.    Thus, in the case of a “Singleton Orchestration” a suspended non-resumable Orchestration needs to be terminated, in order to process all the backlog messages. The messages which were not processed also need to be resubmitted again. Quick Summary: A memo message arrives at the receive location, which creates an instance of the orchestration. The second receive shape picks up the rest of the messages from the receive location, using the same orchestration instance created. Figure 2 - Orchestration Screen Shot Quick Takeaways ·         Observe that the same logical Receive Port is used for both the Receive shapes. ·         Observe the while LOOP which looks for the flag in the messages and terminates the Orchestration once an End Memo is received. ·         The use of Correlation type enables a Singleton Orchestration which requires a property or a set of properties to be common across a set a messages.
Conclusion
The singleton pattern is implemented by creating a class with a method that creates a new instance of the object if one does not exist. If an instance already exists, it simply returns a reference to that object. Hopefully, this article has helped you understand the basics of Singleton Orchestration in a BizTalk Server. --------------