How to convert outbound message from Xml to Json in BizTalk
Solution:
You can convert xml message to JSon format using custom pipeline (send pipeline)
Following are the steps:
1) Create a custom Pipeline (send pipeline) to convert xml message to JSON. Add JSON encoder in custom receive pipeline as shown in below screen shot:
Note: you can leave JSon encoder component’s properties to its default values (unless you explicitly want to configure or change/overwrite default setting)
2) Now build & deploy custom send pipeline (e.g name = XmlToJsonSendPipeline) to BizTalk server and use it inside the send port as shown in below screenshot:
Note: In order to send out JSON messages, you can leverage ‘WCF-WebHttp’ adapter based send port in BizTalk.
BizTalk server send port generated error message ‘Cannot send a content-body with this verb-type’
Problem Scenario:
Getting error while trying to invoke REST API using BizTalk Send Port (“WCF-WebHttp” adapter enabled send port).
REST call is an inquiry call and hence GET type http verb is being used to invoke service. Exact error message that is appearing in Application Logs is as shown in below screenshot:
Resolution:
This error is generated by BizTalk when you try to send content body in message for GET verb type REST API call. In order to trigger BizTalk send port, you need to send message to send port and the send port, by default, will send same message (as content body) to REST API via WCF-WebHttp adapter, but at the same time it is not allowed to send message as content body to GET verb type REST API calls so you end up getting above mentioned error in BizTalk
To fix this issue in BizTalk, you need to suppress message body for GET or DELETE verb type at send port level and that you can do as following:
Double click send port in BizTalk to open send port properties
Click “Configure” button in front of “WCF-WebHttp” adapter type (in send port properties)
Now go to “Messages” tab and enter specify “GET” verb under “Suppress Body for Verbs” option as shown in below screenshot (Yellow highlighted)
Save changes to BizTalk send port and restart BizTalk host instance(s)
Above mentioned steps should fix this particular issue in BizTalk as it will suppress content body for GET verb type.
How to configure biztalk to create only one instance of an orchestration to process multiple incoming messages
Scenario Details:
Normally biztalk creates a new instance of an orchestration upon receiving message subscribed by that orchestration. However there are situations where we might need to restrict the number of instances that are created for a given orchestration in Biztalk. In that scenario, singleton orchestrations come to rescue
Suppose a scenario, where you want only one instance of biztalk orchestration to get created for processing all messages coming through a particular receive port. In this case, the very first message received through that particular port will activate the first (and only) instance of the orchestration in question and all subsequent messages coming from same receive port will get processed by same already created instance of the orchestration
Implementation:
1) Create an orchestration
2) Create a new correlation type and set correlation properties to “BTS.ReceivePortName” as shown in below screenshot
3) Create a new correlation set based upon newly created correlation type
4) Go the properties of the very first receive shape in orchestration and set Activate = “True” and then initialize it with newly created correlation set as shown in below screenshot
5) Now place another Receive shape inside a loop in orchestration. The loop condition can be set according to the requirements for example, you can set fix number of iterations in loop condition or may be some true/false expression
6) Go to the properties of the second receive shape (that is inside the loop) and set Activate = “False” and then follow the same correlation set that was initialized by the first receive shape of the orchestration
7) Make sure both receive ports (first & second one) are bound to same logical receive port
Now first received message will activate orchestration instance and subsequent messages will be received and processed by the second Receive shape (that is inside the loop)
Conclusion:
Using above defined implementation and configuration, we can enable biztalk to create only one instance for processing all message that satisfy same specific correlation properties/conditions (such as ReceivePortName or any other valid correlation set(s) )
BizTalk sequential convoy is an example/implementation of singleton pattern
BizTalk FlatFile Disassembler creating multiple messages or files while parsing input Flat File
Scenario Details:
You have implemented custom biztalk pipeline (with Flat File Disassembler in it) to receive flat file input and process it inside an orchestration
You want to receive multiple records (that are in flat file) as a collection of xml records inside one single message in your orchestration but you when you process input flat file you see that custom pipeline is creating one xml message for each record (in flat file) instead and if open BizTalk Group Hub have a look at Tracked Service instances then you will realize that actually multiple instances of same orchestrations ran (i.e. one orchestration instance against each flat file input record).
Solution:
You can fix this issue by setting “Group Max Occurs” property value to “unbounded” for the root node in your FlatFileSchema.xsd file
For example:
Suppose you have an input flat file with following structure where each record ends with {CR}{LF}:
And you have defined FF schema as shown below:
And you have defined a mapping between FF schema and destination xml schema as following:
Now you can fix this particular issue by right clicking “Root” node in FF schema and set “Group Max Occurs” property value to “unbounded” (Assuming you have configured “Root” element as Delimited structure and its child record “Record” as positional structure in your FF schema)
By making above suggested change, your FF disassembler will create one xml message with multiple records (from FF file) and final transformation from FF to xml message will be as shown in below sample:
MessageContextPropertyBase type field is written to the message context but it is not promoted
Scenario Details:
For demo purpose, suppose we have a field “Salary” added to Biztalk PropertySchema where its Property Schema Base is set to MessageContextPropertyBase as shown in below screenshot:
We want salary calculated and assigned inside and orchestration and then have Salary added to the message context of the final output message so that we can later do routing (at send port level) based upon salary value.
However when we are calculating employee salary and assigning it to “Salary” field inside an orchestration and when orchestration finally sends out final message (via send port in it) then we can see “Salary” field appearing in message context but it is showing as “Not Promoted” in message context as shown in below in screenshot:
Since this salary field is “Not Promoted” in message context so our salary based filter at the other send port(s) is not working as intended and hence the solution doesn’t work correctly
Resolution:
It is important to understand that when a value is assigned to a field/element which is added to some PropertySchema and whose Property Schema Base = MessageContextPropertyBase then the value of that field is “written” to the message context (and it surely becomes part of the message context) however that field is NOT promoted inside message context by default and hence, down the line, we can’t do any routing based upon value of this field.
In order to get this field “Promoted” inside message context we need to do following:
Create a new CorrelationType and select desired field of the PropertySchema under Correlation Properties (yellow highlighted in below screenshot):
2. Now create a new Correlation Set based upon the Correlation Type created in previous step
3. Now, inside the orchestration, go to the properties of the send port (whose output message should have desired field in its message context) and initialize newly created correlation set at send port level as shown in below screenshot:
4. Now re-deploy modified/updated orchestration and restart biztalk host instance(s)
5. Execute/invoke newly deployed orchestration and inspect the message context of final output message and this time you will be able to see “Salary” field as a “Promoted” field inside the message context (as shown in below screenshot) and now you will be able to successfully perform send port level routing/filtering using value of the Salary field
Getting BizTalk error message The message was not found in the message box or the tracking database.
Scenario Details:
Getting following error message in BizTalk server when trying to open a message under Tracked Message Events list of messages:
Resolution:
Following should solve/fix this issue:
1) Make sure tracking is enabled at orchestration and port level 2) Make sure SQL server agent is running on the SQL server which is hosting BizTalk databases 3) Go to SQL Server jobs and make sure following job is running successfully:
You can even run it manually to verify if this sql job can execute successfully or not.
BizTalk server offers different options to store configurations, each with its own pros & cons. Lets have a quick look at some of the commonly used approaches:
1. BizTalk configuration file
BtsNTSvc.exe.config
BtsNTSvc64.exe.config
Pros: Easy & familiar way of storing configurations (similar to web.config file)
Cons: Has to be updated on each BizTalk server Host restart required No Application level segregation of configurations is possible No Security
2. Database
Pros: Comprehensive security (authentication & authorization) Possible to store application wise configurations Host restart not required
Cons: DB fetch/call is relatively slow & resource hungry SQL scripts or skill required for add/update DB access is required
3. BizTalk Rule Engine
Pros: Host restart not required Application wise configuration storage possible Access control possible
Pros: Supports Distributed model Secure (authentication, authorization & encryption) Supports separate application containers with own configurations Supports separate application containers with own access control Accessible to BizTalk orchestration and other components via .Net API
Cons: Specialized skillset/tools required to add/update configurations in SSO Might require SSO service restart after update/changes
While adding a “Start Orchestration” shape in an already developed & deployed BizTalk orchestration, I started getting error message “part ‘part’ of message <MessageName> contains zero bytes of data” whenever orchestration hit that start shape during execution
This resulted in exception thrown by start shape and as a result neither inner orchestration was executing successfully nor parent orchestration.
Scenario Details:
We had to add Start Orchestration shape in a BizTalk orchestration as part of some modifications to the process. Start orchestration shape was invoking another orchestration and had multiple input parameters (one message type parameter and others variable parameters)
The parent orchestration (being modified) was running fine previously but since the start orchestration shape was added, the parent orchestration broke at start shape and started throwing above mentioned error
Solution:
Upon detailed debugging & troubleshooting we observed a line of code in parent orchestration that was initializing a schema message with a an XmlDocument type using “new” keyword inside message assignment shape. For example:
Message1 = new System.XmlDocument();
Where Message1 was actually a schema based message (i.e. Type set to a referenced schema).
Initializing a message type with “new System.XmlDocument()” was the actual culprit in our case. So when we removed above mentioned line of code and initialized Message1 using Transform shape in the orchestration then the error message part contains zero bytes of data got fixed immediately.
Conclusion:
If you are getting error “part ‘part’ of message <MessageName> contains zero bytes of data” in BizTalk orchestration then go through whole orchestration code and try to find out how the message (whose name is being mentioned in error message) was initialized in that orchestration?
If anywhere in that orchestration it is initialized using “new XmlDocument()” then replace that type of initialization with proper message initialization using either Transform shape or Message Assignment shape.
In BizTalk world, the term “LOB applications” is generally used to refer to various external systems (such Oracle, Siebel, SAP, SQL Server, Peoplesoft, TIBCO and various other ERP or relational database etc)
“LOB Adapters” in BizTalk system are the adapters that facilitate communication between BizTalk Server and underlying LOB application/system.
“WCF LOB Adapters” are the adapters built using WCF LOB Adapter SDK. Adapters built using WCF LOB Adapter SDK has an edge over old style COM based adapters in a way that these adapters can not only be consumed by BizTalk server based applications/services but can also be consumed by any other WCF capable application/service. WCF LOB adapters has the capability to expose underlying LOB application/system as a WCF consumable service
“WCF LOB Adapter SDK” offers features, UI tools and components that provide unified framework for adapter development & consumption. It is a comprehensive framework that provides guidelines for adapter development which facilitates consumers with runtime metadata query and artifact generation depending upon type of the application that is consuming adapter.
Problem:
Transform shape in a previously (and successfully) built BizTalk orchestration reported ‘map file not found’ error when we tried to build it again after small change, despite the fact that the particular map file was already added and available to the project and could be seen as part of the project in solution explorer window.
Resolution:
Apparently everything was fine. Map file was available & added in the project. There was no discrepancy/error. Type name, filename and fully qualified name and other properties of the map file were correct and unchanged since last successful build.
Finally we were able to solve this issue as following:
1) Exclude the particular map file from BizTalk project
2) Include the particular map file in same BizTalk project again
Mubarik Ahmed - Integration Blog 