Blogging BizTalk

Lets Discuss BizTalk

Dynamic Endpoint Resolver Using BRE and ESB Itineraries

In this example I will demo how we can use BRE engine in conjugation of ESB itinerary to achieve dynamic routing.

Create a receive port which is going to look like the below screen shot.
The pipeline component being used is ItinerarySelectReceive. Or otherwise you can create you own custom pipeline which in a way mimics ItinerarySelectReceive, see below.
Create a business rule which will contain the information for routing.In this example we are toting a message based on the message type. For simplicity sake I have used FILE type adapter at both send and receive side.
Create a dynamic send port, picture below. Apply the filter as shown in the picture
Lets get down to creating the itinerary which will be  attached from the receive port.
Drag an on ramp shape and under the properties set the receive port name to the one we just created.oNrAMP
Drag a messaging extender shape and set the service name to “Microsoft.Practices.ESB.Services.Routing”.
Add a new resolver in the messaging extender and set that to BRE Resolver Extention.
Pick the BRE policy we created for send port properties.
At this stage we need to an off ramp and  extender for off ramp. Set the different propertied as below.
Once it is done set the Model Exporter to Database Itinerary exporter and right click >> Export Model.
Start the RL and send port. Drop the message of  message type http://ItinRouting#Request, the RL will invoke receive pipeline which in turn will invoke the itinerary which further will call the BRE to get the routing information for dynamic send ports.
Please let me know if you have any questions.

ESB/BizTalk Installation Error: Check that SSO is configured and that the SSO service is running on that server. (RPC: 0x800706D9: There are no more endpoints available from the endpoint mapper

You can get this error under while configuring BizTalk server or ESB.SSOError

To fix this error we need to go to the windows service

Solution: Go to windows services: Check Enterprise Single Sign On Service is running or not if not start it. Please do the same with Remote Procedure Call (RPC).


Modify An Exiting BRE Policy and Vocabulary

Used Case :

This was an old project having a vocabulary which was used in multiple policies / multiple version of policies.

Need was to add a new definition to be used in an existing policy. One way to do this was to add a new vocabulary and use it. This option was ruled out because it would have added an additional vocabulary collection thus making it look cumbersome.
Reversion the vocabulary and add the new definition in it – This as well was ruled out since the current version of the vocabulary was used in many Policies – implying a need to update the reference of used vocabulary definition in each Policy.
Undeploy all the policies using the vocabulary in question , followed by undeploying the  vocabulary. After that modify the bindings and redeploy vocabulary followed by the policy. – This option was not opted out because of the complex nature of the BRE policies using the same vocabulary version. – Ideally speaking this is the option we should pick for any such needs.
Having said that there was an unconventional route taken to accomplish the need.
Modify a published Vocabulary
The vocabulary state is stored in nStatus filed under the table – re_vocabulary in – BizTalkRuleEngineDb. For each vocabulary there is a separate row.
It has two states 1 and 0. 1 indicates the Vocabulary is in Published state and 0 indicated it can be modified. Hence the corresponding vocabulary row –  nStatus field was edited to 0, making the vocabulary editable. Subsequent to it the new definitions were added using the Business Rules Composer.
Modify a published Policy
Policies state are stored in re_ruleset table column nStatus. It has three states.
0 Saved
1 Published
1 Deployed
Notice the Published and Deployed state value are the same. For a policy it is differentiated by  the entry in the table re_deployment_config. For any policy( nRuleSetID value) which is present in re_deployment_config and re_tracking_id table indicates that should be in deployed state.
For example I have to modify the Rules PKS_DemoPolicy version 1.0 without incrementing the version. First I need to get the nRuleSetID from re_ruleset table, this will be used  in deleting respective entries in re_deployment_config and re_tracking_id . 
Once identified go ahead and undeploy the policy PKS_DemoPolicy .
Subsequent to that change the nStatus Column using following query.
 update [BizTalkRuleEngineDb].[dbo].[re_ruleset] set nStatus= 0 where nRuleSetID = ‘**Your nRuleSetID’
Next delete the entry for your PKS_DemoPolicy  in re_deployment_config
Delete from [BizTalkRuleEngineDb].[dbo].[re_deployment_config] where nRuleSetID=’**Your nRuleSetID’
Delete the entry from re_tracking_id table 
 Delete  FROM [BizTalkRuleEngineDb].[dbo].[re_tracking_id] where nRuleSetID=’**Your nRuleSetID’
Once done go back to Business Rule Composer and refresh. The policy state should be editable. Please leave a comment if you have any questions and I will get back as soon as I can.
Disclaimer – The approach taken here is not recommended by Microsoft and please use it at your own discretion.

The Messaging Engine failed to register the adapter for “WCF-BasicHttp” for the receive location

After publishing a BizTalk artifact, while browsing the service you bumped into this error:
The Messaging Engine failed to register the adapter for “WCF-BasicHttp” for the receive location



Go to the app pool under which the BizTalk service is configured in IIS and check for the Identity, the id used there should be a part of BizTalk admin group.Once that is set(And it is running under the isolated host) the issue should be gone.


Please leave me a comment in case you have any questions.

Find Orchestration Details Using BizTalk Mgmt DB


This topic is intended towards Microsoft BizTalk server users and I have tested it to be working with BizTalk 2006 R2/ BizTalk 2009/ BizTalk 2010/ BizTalk 2013/ BizTalk 2013 R2. The person inteding to use this need to be the BizTalk administrator.

What if you have hundrebs of orchestration deployed in your BizTalk enviroinments and you need to go look up specific information like binidings end point used, sunbscriptions, state etc. It can be a realy painful job to go look this up from BizTalk admin console. This article will provide you and alternate approach and obviously a quick one to get the required detail you need. I am leveraging the BizTalk Mgmt DB to find the information outlined below.

This SQL script is goign to provide you the all the bindings and end point details for BizTalk orchestrations, it can be utilized in SSRS report or web based UI to provide end uder with this information.IT can come realy handly while deployment planing in terms of understanding whihc orchestrationn is dependent on what endpointso

Building the Sample

Run the followinf SQL script on the BizTalkMgmtDB, the only prerequisite is you should be the part of BizTalk adminstrator group? 


DECLARE @SendPortAddress TABLE 
(nID intnvcAddress varchar(256)) 
Insert @SendPortAddress (nIDnvcAddress) 
select nSendPortIDnvcAddress 
From BizTalkMgmtDB.dbo.bts_sendport_transport AS spt WITH (NOLOCK)  
where len(nvcAddress) > 0 
SELECT o.nvcName AS 'Orchestration Name' 
, ao.nVersionMajor 
, hst.Name AS 'Host' 
, op.nvcName AS 'Orchestration Port Name' 
, case when (sp.nvcName is null and rp.nvcName is Nullthen spg.nvcName 
  else sp.nvcName 
  end as 'Send Port' 
, spt.nvcAddress as 'Address' 
, rp.nvcName as 'Receive Port' 
, app.nvcName as 'Application Name' 
, o.nvcFullName 
, ao.nvcName as 'Assembly' 
FROM BizTalkMgmtDB.dbo.bts_orchestration_port_binding AS b WITH (NOLOCKINNER JOIN 
     BizTalkMgmtDB.dbo.bts_orchestration_port AS op WITH (NOLOCKON b.nOrcPortID = op.nID INNER JOIN 
     BizTalkMgmtDB.dbo.bts_orchestration AS o WITH (NOLOCKON o.nID = op.nOrchestrationID INNER JOIN 
     BizTalkMgmtDB.dbo.adm_Host AS hst WITH (NOLOCKON o.nAdminHostID = hst.Id INNER JOIN      
     BizTalkMgmtDB.dbo.bts_assembly AS ao WITH (NOLOCKON o.nAssemblyID = ao.nID LEFT OUTER JOIN 
     BizTalkMgmtDB.dbo.bts_application AS app WITH (NOLOCKON ao.nApplicationID = app.nID LEFT OUTER JOIN 
     BizTalkMgmtDB.dbo.bts_receiveport AS rp WITH (NOLOCKON b.nReceivePortID = rp.nID LEFT OUTER JOIN 
     BizTalkMgmtDB.dbo.bts_sendportgroup AS spg WITH (NOLOCKON b.nSpgID = spg.nID LEFT OUTER JOIN      
     BizTalkMgmtDB.dbo.bts_sendport AS sp WITH (NOLOCKON b.nSendPortID = sp.nID LEFT OUTER JOIN 
     @SendPortAddress AS spt ON sp.nID = spt.nID 
Order by app.nvcNameo.nvcNameao.nVersionMajorop.nID

Publishing Schemas As A Webservice With Exception Handling

Where you need to publish an schema or orchestration as service:
Scenario where the communication has to happen in real time for example someone wants to call an orchestration from an UI or wants to post a request to BizTalk.

How do you Do That:

Develop a schema project as usual. If required you can pick an orchestration as the subscriber or leave it. Since you are publishing the Schema it will be loosely coupled and you can have multiple subscribers to the same message type.

Once done please go ahead and deploy the schema/solution.(In the case of orchestration you will like to have your activate receive  shape directly bound to msgbox) Also please consider having a fault port in your orchestration. That way you will be able to return a custom exception in case of any issues from BizTalk.

Some Unique Errors You May Encounter are:
The Messaging Engine failed to register the adapter for “WCF-BasicHttp” for the receive location : Solution your app pool id has to be part of BizTalk Admin group.
must receive before sending a message whose message type corresponds to a request response operation on an implemented port.You need to move your second send shapes under a condition branch as shown in the picture.

This scenario we are going to design a synchronous BizTalk service which will return a response for each request.
1> Define your request response contracts.For this example I am going to create an orchestration which will consume the request and create a response. Make sure the activate receive shape is directly bound to msgbox.
This is how your solution is going to look like.

2>Once done please go ahead and deploy it.Start the orchestration.

3>Go to BizTalk WCF publishing wizard and follow the following steps( BizTalk WCF publishing Wizard can be found in Visual studio for 2009 or in the Start>>program >> Microsoft BizTalk server >>). I am going to design a HTTP based 2 way communication here. Please follow the following steps as showed in the screenshot below.

note:We can also publish an orchestration as a web service but using schema gives you loosely coupled architecture. In the case of schema you can define multiple subscribers at your convenience.


Once you are done with the Wizard it is going to create one receive port and location + one IIS application.

The app pool for the BizTalk application in IIS has to be a part of Admin group and you will also need to enable directory browsing.




4>Once done this is going to create a two way receive location and port. Please go ahead and start that. The solution is ready to be tested.

How To Test:
1>Go to your IIS and take the WCF endpoint. You can use this endpoint in SOAP UI/Stylus.. to post a request and get the response.

2>Using A Windows Client:


Once the project is created right click on references and pick add service reference


This step will create a service reference for you. Now open the program.cs and make necessary changed to it.


Run it and you will see the BizTalk process invoked.


BizTalk Error “A Correlation Set Can Be initialized Only Once” : An alternative solution

So you bumped into this error while compiling your BizTalk project. The most obvious reason could be : You have a correlation set set initialized on more than one places by mistake.

Now here is the tricky part: What if you have initialized it only once but still you are getting this error. What could be wrong.

Here are the possible reason:
You are using a long running transaction loop (For example in the resume pattern : and have initialized this correlation set in there ONCE :-). You see, even thou it is initialized once at run time it may be called more than one time, thus explaining the error.

You need to define your correlation set in a non long running scope contained within your long running scope and that will fix the problem for you.

Let me know if you have questions.


Error Message Routing Pattern demo In BizTalk

This topic deals with Error Message Routing Pattern Demo.

Where can you use this? One of the examples may be when your send port end point is erroring out or the subscriber to a RP is unavailable for some reason(For example may be a a send port working in a time window) then you will bump into a scenario where in a message comes in on a receive port and doesn’t finds a subscriber which it would have had it come between the defined time window or  where you may see the Zombie message scenario (Let me accept it is not a very ideal solution to handle the Zombies but may fit your need, one never knows).   It is going to leave you unconsumed messages suspended messages in BizTalk, if you choose to terminate them it can lead to data loss scenario . Even if you resume these messages they going to suspend back because there instance subscription is no longer valid(In case the response was to consumed by orchestration). You may want to handle them and this is one of the way on How can you do it.

I am trying to demo how can handle this.

Lets Create The Non Subscribed Orphaned Message Scenario

1>Create a receive port with the “Enable Routing Failure For Failed Message” ticked in.


2>when you drop a message which has the subscriber defined it will be consumed by the respective BizTalk artifact. Now if you drop a message which has no subscriber defined: You will have a suspended message with no subscriber found error. So you have your orphaned message created at this point in time.
Read more of this post

BizTalk Performance : Error: Tracking data in MsgBox db can not be moved to DTA / Reason: 6-DB Size !!

We faced a strange issue on one of our servers recently. There was this orchestration it was taking close to 50 minutes to complete while the same orchestration was completing within 2 seconds on another group of server.
Note: The mgBox DB is present on different instances of SQL server for both of these BizTalk machines.
When I studied the orchestration flow it appeared that each time it tried to publish message into msgBox there was a huge delay. 
Thought of sharing the steps performed to get this resolved.We ran the msgBox viewer tool  diagnostic and it resulted in following errors being reported:
0 (Tracking data in MsgBox db can not be moved to DTA) !!
Reason: 6-DB Size !!
For the error related to Tracking data in MsgBox db can not be moved to DTA  was happening because the hosts did not have the host tracking enabled which was resulting into the tracking data not being moved from msgBix DB to the trackingDB.
What we did : Enabled host tracking on each host and later we created a dedicated tracking host.  You may want to read this Microsoft article to understand why a dedicated tracking host can improve BizTalk performance.

“A BizTalk Host that hosts tracking is responsible for moving the DTA and BAM tracking data from the MessageBox database to the BizTalk Tracking (DTA) and BAM Primary Import databases. This movement of tracking data has an impact on the performance of other BizTalk artifacts running in the same host that is hosting tracking. Thus, you should use a dedicated host that does nothing but host tracking.

Using a dedicated tracking host also allows you to stop other BizTalk hosts without interfering with BizTalk Server tracking. The movement of tracking data out of the MessageBox database is critical for a healthy BizTalk Server system. If the BizTalk Host responsible for moving tracking data in the BizTalk group is stopped, the Tracking Data Decode service will not run. The impact of this is as follows:

  • HAT tracking data will not be moved from the MessageBox database to the BizTalk Tracking database.
  • BAM tracking data will not be moved from the MessageBox database to the BAM Primary Import database.
  • Because data is not moved, it cannot be deleted from the MessageBox database.
  • When the Tracking Data Decode service is stopped, tracking interceptors will still fire and write tracking data to the MessageBox database. If the data is not moved, this will cause the MessageBox database to become bloated, which will impact performance over time. Even if custom properties are not tracked or BAM profiles are not set up, by default some data is tracked (such as pipeline receive / send events and orchestration events). If you do not want to run the Tracking Data Decode service, turn off all tracking so that no interceptors save data to the database. To disable global tracking, see “How to Turn Off Global Tracking” in BizTalk Server 2006 R2 Help at Use the BizTalk Server Administration console to selectively disable tracking events.”
The Message publishing throttling state was in red for every host instance on the server We went ahead and check for the spool table count and realized there were close to 200000+ messages piled up there. Generally below 500 is considered a normal count for an average traffic. This count was way too high.
Job Status
We went to the BizTalk jobs and identified the DTAPurge and Archive job was disabled and TrackedMessageCopy job had been failing since long. Once this was corrected and jobs were enabled the number of messages in spool table came back to normal.
D Goins Insperience

Technological outformation for this day and age

[INACTIVE BLOG] Connected Thoughts - Thiago Almeida

Connected systems and the occasional picture

Uri Katsir's Blog

BizTalk , BizTalk RFID and .NET


My BizTalk Experiences

BizTalk Server Tutorial

BizTalk Server Concepts and Common Errors

Extremely Talented Monkeys

A Technical Blog by Ed Jones: Azure, .NET, BizTalk, WCF, and SQL Server

On All Things Web

Discussing web development without limits

Vikas Bhardwaj's Blog

All about BizTalk Server, Azure and .NET

Cloud develop

a blog about (cloud) development... because I'm a nerd

Hooking Stuffs Together

My learning logs from day to day work experience about Integration platform using Microsoft technologies.

Connected Pawns

Mainly BizTalk & Little Chess


a blogger in the process.

MS Innovations Blog

Tips, Tricks, and Workarounds for BizTalk and other Microsoft technologies


Katradhu Kaialavu,Kalladhadhu Ulagalavu!

Vijay Microsoft Technical

BizTalk, WCF, ESB ToolKit, Windows Azure

Mind Over Messaging

Musings on BizTalk, Azure, and Enterprise Integration