Wednesday, March 27, 2013

Exposing orchestration as WCF service biztalk example

I am going to demonstrate how to expose an Orchestration as WCF service & then consuming this exposed service using a WCF client.

Overall flow of the solution :

1. Creation of a solution
2. Creation of a BizTalk project in the solution which contains an XML schema & an Orchestration.
3. Publishing the Orchestration to IIS using BizTalk WCF publishing wizard.
4. Creation of a C# console project in the same solution.
5. Addition of the service reference of the above exposed orchestration into the C# console application.

Schema :

Created an XML schema with 'Status' field as distinguished field.

Orchestration :

The Orchestration simply receives a message from a folder path & the Status
of the message is changed to 'received' & then this new message is send to a 
output folder location.

There are two messages used in the orchestration one for receive shape & one
for send shape but these two messages uses the same schema as message type.

The message assignment shape simply copies the input message into output &
then assigns the status field as 'received'.

After doing all this I'll build this BizTalk project & deploy this project to 
Admin console.

Exposing the Orchestration :

Our brand new orchestration is ready to be exposed to IIS. We a wizard to
to perform this thing. In visual studio -> tools we have BizTalk WCF publishing 

After clicking next we have two options Service Endpoint & Metadata only endpoint.

We'll choose Service endpoint & also create a receive location in the deployed BizTalk

After that clicking next we see two options of exposing either schema or 
Orchestration.Choose Orchestration & click next.

Then we need to choose our Biztalk project dll. 

After clicking next a receive port is created with the name specified on
the logical port in the Orchestration.

After clicking next Specify the appropriate namespace for our service.

After clicking next we have the option to locate our service. We can use
localhost to deploy the service on local IIS server or we can change host 
to deploy the service on any other machine's IIS server.

On clicking next a WSDL is created for our service.

After clicking next a new receive location is created in the our project 
in the admin console. We need to enable this receive location to browse
our WCF service.

Next step is to browse the service from the IIS.

Our exposed Orchestration service looks like below screenshot.
We need to copy the link in the explorer so that a service reference can be 
added to consume this service.

After that I have created a new C# console application to act as a client 
for our WCF service calling. Now we need to add the service reference of our

Paste the URL copied from the explorer & click go.
Our service will be discovered & change the namespace.
This namespace will be used in our client to call the service.

Sunday, February 3, 2013

Passing a message to BRE using call rules shape in biztalk

Business Rule Engine is a powerful tool in BizTalk stack for creating, testing, publishing, and deploying rule sets for our Business process. I am going to demonstrate how to call a policy from an Orchestration using call rules shape using message as the parameter.

Scenario : Suppose we receive a Customer details message which also contains the CustID. We'll check the CustID and see if the Customer is new or already a member. If the customer is new we'll set the IsNew field to YES. 

First of all we'll start with creating FACTS in BizTalk Rule composer.
Open BizTalk Rule composer and go to Vocabularies and create a new Vocabulary and then create a new definition for XMLSchema and select the schema created in the project. For CustID a get operation is created as follows :

For IsNew a set operation is performed as follows :

After creating the vocabularies publish the vocabularies so that it can be
used to create a Policy.

Next step is to create a Policy and a rule in BRE. It goes like this :

This Policy is created such that any CustID greater than 21 would set the 
IsNew field to YES. This Policy will be called from the Orchestration using call
rule shape.

Input Schema :

The input schema contains Customer details which contains fields CustID and IsNew.

Orchestration view :

The Orchestration contains a receive shape, send shape, logical receive port and send port. A message is created using InputSchema as message type.

Call rules shape :

In call rules shape the policy that we have created is selected and parameters will automatically be populated. In this case Message_2 is shown. This whole message is passed to BRE and in return modified message is received.

Input Message :

<ns0:Root xmlns:ns0="http://BRE_Samples.InputCustomer">

Output message :

<?xml version="1.0" encoding="utf-8"?><ns0:Root xmlns:ns0="http://BRE_Samples.InputCustomer">

Call rule shape not any showing parameters ?? 

This problem is related to BRE facts that we had created. When developing facts we have to specify the DocumentType property of the fact. This property should be same as the fully qualified name of the schema otherwise the call rule shape will not show the any parameters. This issue is of call rule shape not finding the matching message to the schema which is deployed with the rule.

Saturday, January 12, 2013

Parallel Convoy in BizTalk example

What is Parallel convoy ?

Parallel convoy in BizTalk is used to receive messages in any order. The Orchestration process does not start its execution further until all the messages in parallel convoys are received. In Parallel convoy we have a parallel shape as the first shape in the Orchestration and multiple receive shapes for receiving multiple messages.
                        For example if there is a Online shopping portal which sends several messages to BizTalk like ShoppingDetails, CustomerDetails, BillingAddress and they all need to be received in BizTalk and then only process should continue further and these messages can be receied in any order into BizTalk. This situation can be implemented using Parallel convoy :

SourceSchema for ShoppingDetails message:

SourceSchema1 for BillingAddress messages:

SourceSchema2 for CustomerDetails message:

NOTE : CustID is promoted in all the three schema's. Here is Property schema for CustID :

PropertSchema for CustID:

DestinationSchema :

Orchestration :

In Orchestration we have a Parallel shape with three receive branches and three receive ports for receiving three different types of messages. Now for parallel convoy we have to create Correlation set and correlation type which is done on CustID. All three receive shapes initialize the correlation set because any message can arrive at an time. Suppose 2nd parallel branch's message arrives then the 2nd receive shape initializes the correlation set and the other two follows the correlation set. When all the three messages arrives then only further execution of the Orchestration takes place.