Design patterns : BPM scenario

In order to support the business requirements outlined above, the following design patterns were used:

-Decoupled orchestrations were used to provide mobility and flexibility of business processes.

-Request broker. The solution brokers requests to different processing departments based on requirements.

-Business Process Versioning

Need to be able to version the business process.

-Business Process Splitting
Each business process was split up into separate orchestrations
Because a single monolithic orchestration was not used it is easier to split up and change the business process

-BAM was used in the solution to provide a contiguous view of activities within the system to the business.

-Interruptible long running orchestrations
Pattern for interrupting them when in-flight.

-Error routing with error envelope
To avoid the operational overhead of dealing with suspended messages in BizTalk all suspended messages are routed to a back end system to be manually repaired and eventually reprocessed.

-Exception handling with code retry
Custom code re-try ability is provided because one of the end point application servers used in the solution exposes a .NET remoting interface for all communication. This requires that all communication from BizTalk Server be done via custom code within an orchestration. When doing this, you lose much of the functionality that BizTalk Server provides when communication is done via adapters including retry capabilities and the ability to resume a suspended message on the send side. In order to avoid unnecessary suspended orchestrations, these capabilities need to be recreated in the orchestration and custom code. This enables the solution to handle situations such as when the network is busy and communication is not possible via .NET remoting. In this case, you don’t really want to suspend the orchestration and induce manual intervention as this creates unnecessary operational overhead.

-Inverse Direct Partner Binding
Direct partner binding – binding one orchestration to another direct binding.
Ability to bind partners together in a backwards fashion.

-An Order manager orchestration has been implemented to manage the execution of each order through the various required stages.

-Enterprise Single sign-on (ENTSSO) was used as a centralized data store for all configuration data required by the solution. This approach avoids the need to store configuration individually across all BizTalk Servers. As the number of servers in your group increases so does the number of applications. Managing and versioning configuration for these applications across multiple servers becomes an administrative and operational burden. This burden is compounded by the fact that incorrect configuration data can lead to problems running the solution in production. Therefore, it is highly recommended that you consider using ENTSSO as a central configuration data store in any solutions that you build.