Call Orchestrations And Direct Bound Orchestrations

The interactions among different orchestrations is a very vital decision that needs to be taken at design time. Usually we tend to go for message box driven direct bound orchestrations which enable us to have a modular development and also allows external components to dump the message to message box without caring for the external component to be invoked. This approach has its own cost that the up and down trip to the message box is done for every single orchestration call. Lets consider a scenario that there are two orchestrations orchA and orchB. Both of them needs to be exposed to the external world and hence have message box driven ports. Both of these orchestrations are part of the same biztalk project.

All of a sudden, a need arises that orchA needs call orchB 5 times within a loop. For this type of scenario, if we use the direct bound port of orchB, there are total 5 * 2 = 10 trips to message box in a request response scenario. This in turn becomes highly expensive calls. The number of persistence points becomes very high because of the presence of send - receive shapes within the loop as per the figure given below.


These expensive calls may be avoided by providing another entry point to the internal orchestration by my moving the entire logic in orchB to an internal callable orchestration.
This is in turn is being called from the previous existing orchestrations for serving the purpose of message box driven direct binding and can be internally called by the local orchestrations directly without using direct binding. This also leads to no deviation from the current design and architecture. The above implementation can be changed as the figure given below.

The orchB needs to be changed from FigA to FigB.

Fig A.



Fig B.

Importance of stub services

Todays world of software engineering involves communication with different applications accross different domains. Lots of time is wasted in integrating with the realtime applications in the development environment. The development and testing of our applications is hindered because of the unavailability or issues not related to our application.
The best way to avoid this is to go for the creation of stubs for all the third party services in the beginning of the development cycle. These stubs should be developed by creating a sample response that will be returned by the 3rd party. For eg.
Here is the sample code for a real web service:

[WebMethod]
public response CheckAvailability(request) {
//Actual Business Logic
...
...
...
return response;
}

The above code can be replaced by a stub service as follows:
[WebMethod]
public response CheckAvailability(request)
{return sampleResponse;}

This leads to a heavy reduction in loss of time in fixing of the issues in the actual service. The best usage of this approach is of performance testing of the application. The performance testing can be done using the stubbed services to deterime the actual resource usage by our application without taking into consideration the behaviour of the external services. If a delay of 2 sec. in response from the external service is required, same can be achieved as follows:
[WebMethod]
public response CheckAvailability(request)
{Thread.Sleep(2000);
return sampleResponse;}

This approach can be further extended to test the individual components/layers in our application by stubbing out the other components/layers. The usage of stubbed or actual service can be made configurable by using a config setting. Other way is to host them on different urls and change the urls as per the requirement.

Automate deployment of Business Rules

You must be tired of using biztalk business rules engine deployment wizard to export and import policies and vocabularies. For eg. if you have 40 business rules and 20 vocabs defined in business rule composer, you need to run the wizard again and again to export to an xml and import from an xml. It becomes painful to run the wizard. The code in the images helps you to do the same without using the wizard. All you need to do is to create a batch file and invoke an exe created by putting the following in a console application. The following code shows how to export the policies and vocabs to an xml file.

Once you have exported to an xml file, you will need to import them to another machine or even again on your own machine. The second image shows how to import the policies and vocabs to any machine by running the exe through a batch file. These two code pieces can be used for even deleting the policies and vocabs. They publish the vocabs and deploy the policies too. The following sample shows the contents of the batch file used to run these console applications. The calls can be used in a sequence in a single file.

The below sample is for importing the policies and vocabs from xml:

REM *** Call ApplicationName Policy/VocabularyName FileLocation

REM *** Delete Policies
call ImportBRE " " " " "CustomerPolicy"

REM *** Import Vocabularies
call ImportBRE "CommonField" "..\vocabulary files\CommonField-1.0.xml" "CommonField"

REM *** Import Policies
call ImportBRE "CustomerPolicy" "..\policy files\CustomerPolicy.xml" "1"

The below sample is for exporting the policies and vocabs:

REM *** Call ApplicationName Policy/VocabularyName MajorRevision MinorRevision
REM *** Export Vocabularies
call ExportBRE "CommonField" "1" "0"

REM *** Export Policies
call ExportBRE "CustomerPolicy" "1" "0"