In some real-life scenarios, deploying several BizTalk schemas on the same box, as a schema versioning solution or not, can cause multiple identical message types with the same namespace and root element name. Due to same exact message schema deployed twice (or more) or different schemas for different messages, but with the same root element and namespace.
The known error that pops out when naively executing the scenario described is as followed:
Event Type: Error
Event Source: BizTalk Server 2006
Event Category: BizTalk Server 2006
Event ID: 5804
Date: 31/02/2010
Time: 13:31:30
User: N/A
Computer: MyComputer
Description:
An error occurred while processing the message, refer to the details section for more information
Message ID: {0B9ACC4F-229E-4DED-B954-84D3A226A0F6}
Instance ID: {11AD3CA1-0822-4B0A-BFF5-14CDA801A094}
Error Description: There was a failure executing the response(receive) pipeline: "Microsoft.BizTalk.DefaultPipelines.XMLReceive, Microsoft.BizTalk.DefaultPipelines, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Source: "XML disassembler" Send Port: "MySendPort" URI: "http://localhost/MyService.asmx" Reason: Cannot locate document specification because multiple schemas matched the message type "<namespace>#<root name".
The use of "DocumentSpecName" attribute in the configuration section of the pipelines (e.g. XmlReceivePipeline) is there to direct the pipeline to validate the message against a specific schema in the given assembly.This should solve the above error.
The issue is a bit complex when multi-part schemas are involved. After doing the DocumentSpecName magic, when dealing with multi part schema the validation section still can't resolve the unique schema to act with. The error in such case is:
Event Type: Error
Event Source: BizTalk Server 2006
Event Category: BizTalk Server 2006
Event ID: 1001
Date: 31/02/2010
Time: 13:41:56
User: N/A
Computer: MyComputer
Description:
There was a failure executing the response(receive) pipeline: "Microsoft.BizTalk.DefaultPipelines.XMLReceive, Microsoft.BizTalk.DefaultPipelines, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Source: "XML disassembler" Send Port: " MySendPort " URI: " http://localhost/MyService.asmx" Reason: No Disassemble stage components can recognize the data ".
What BizTalk want to tell us is that at this stage, given the specific configuration of DocumentSpecName Attribute, in the well known syntax of "<schema type> ,<schema assembly full name>" is not enough for multipart schemas.
So after some research, I found that a little mending is needed to my DocumentSpecName configuration. The above value syntax is not enough, because it will direct the pipeline to the desired schema in the assembly, but still which root in the multipart schema to validate against.
So the fixed syntax is as followe:
"<schema type>+<root name> ,<schema assembly full name>"
After providing the above configuration all works great.
Hope this will help someone in the globe.
Ariel
Hi all. One of the latest issues on BizTalk advanced usage I encountered was to activate several BizTalk orchestrations with the same published message, where one promoted field is distinguishing which orchestrations are activated.
Instantly, I suggested solving the issue by designating a special numeric (e.g. integer) field in the published message, which represents a binary value of orchestration activation state. E.g. value of "3" (101) in the field, means that orchestration 1 & 3 need to be activated, and orchestration 2 will not. After that stage I planned on using a filter expression in the orchestration activating receive shape, that will use the bitwise-and (&) predicate, between the numeric field and the orchestration "numeric value".
I was so sure the above scenario will work as planned! This is of a great experience in dealing with bitwise-and predicate with filtering in send ports that works really fine.
So after checking it in all direction I sadly found out it is not working. Visual Studio let us creating the above filter expression, but the compilation stage is failing with the following error: "illegal 'activate' predicate". Checking dipper we found that the Microsoft.XLANGs.Core.PredicateBase.Operators enumeration definition, responsible of the runtime aspects of the orchestration predicates, is no including the bitwise-and predicate.
We found that Microsoft explicitly documents that this predicate is not supported (by not including it in the supported predicates table in http://technet.microsoft.com/en-us/library/aa560178.aspx).
Alternatively, we resolved the issue in runtime. We implemented all the above steps with another predicate (e.g. NotEqual predicate), compiled and deployed the orchestrations. Now, after enlisting the orchestration (only after that), a new records are inserted for us in the [BizTalkMsgBoxDb].[dbo].[NotEqualsPredicates] table, for each orchestration filter expression definition. At this stage, we moved the records to [BizTalkMsgBoxDb].[dbo].[BitwiseANDPredicates] table. We started all the application components and …. All worked as designed!!!!!
This resolved the issue but is not supported by Microsoft.
Most "hello world" sample of generating & consuming Web-Services starts with simple method that passes string parameters between the service provider & consumer.Somehow, the approach for the very same sample get complex in BizTalk world. Our aim is to consume the "hello world" web service method that as I mentioned before has a string input parameter.The real question is what message formation we should send to the SOAP send port so that the SOAP adapter comprehend that we want to send our data in the string parameter.
It's really not a problem. I think that BizTalk guys are so schema oriented that when they encounter a simple issue they got staled and confused, like in our scenario. Usually this issue is follows with serialization errors.
So here is the simple solution, the message sent through the SOAP adapter should be formed like this:
<string> the string to pass </string> When the above message is passed through the SOAP adapter, the adapter generates the proper SOAP message (considering the WSDL) with the proper parameter xml node.
Hope this post saved time for you ...
Latly I encantered an issue with the FTP adapter in BizTalk Server 2006 R2 on 64 bit platform (the issue in not the platform).
I configured a send port using the adapter to transmit a file to a remote ftp server.
As described at http://support.microsoft.com/kb/898106, the FTP adapter throttling is keeping the connection to the server open,
gaining the connection reusability.
That's greate! BUT! what about some ftp servers that do not support persistant connections (or the organization security policies don't permit it).
Well, we didn't find any working solution for that, although there are some sagestions about registry entries.
We are currently running with a walkaround of setting the the "after put" value to "QUIT". This terminates the connection, from the server point of view,
but couses abnormal behavior from the adapter side, generating transmission error.
As I counting on the ACK message of the delivery, the walkaround is note answering all my needs. :(
I hope to post an happy ending for this one.
== Update 09/07/2008
I had some sessions about the issue with internal Microsoft stuff and they told me the following:
-
This issue is well known and recorded as a bug.
-
There is no hotfix for that issue at the moment and maybe avalible in future release.
-
Using dynamic ports could be a walkaround.
Hope this helped anyone.
It's been a while I'm trying to understand how to perform a Delivery Notification on a BizTalk Direct Logical Send Port. All the samples and the posts around the issue never mentioned sending the message directly into the MsgBox. They all talked about the guidance of performing the ACK/NACK on a Specify Later, Specify Now or Dynamic port configuration - not Direct.
Well here is how I did it on a Direct style:
1. Assuming the message I'm trying to send (and check for delivery) is called msgDeliver, On a Message Assignment Shape before the Direct Send Shape, write the following:
//Restore the original message using XmlDocument
msgDeliver = xDoc;
//Set the Acknowlegment Flag to true
msgDeliver(BTS.AckRequired) = true;
//Generate a correlation token
msgDeliver(BTS.CorrelationToken) = System.Convert.ToString(System.Guid.NewGuid());
//Set a routing value like the SPTransport
msgDeliver(BTS.SPTransportID)="{4504D95B-5E81-42CF-912D-17A7362E2024}";
2. Add a Send Shape to send the msgDeliver message and link it to a logical Direct Send Port.
3. Create three separate Correlation Sets for BTS.AckRequired, BTS.CorrelationToken and BTS.SPTransportID.
4. Configure the Send Shape to Init the three above correlation sets.
5. Create a new message and call it msgAckNack of type - System.Xml.XmlDocument.
6. Under the send shape add two Direct Receive Shapes, config them to follow the correlation for BTS.CorrelationToken (the first is a dummy subscription for the message sent and the second is for the SOAP NACK message, or the kind of empty ACK message).
7. Configure the two receive shapes to get the msgAckNack message, and link the two receive shapes to a logical direct receive port.
8. Now you can analyze the msgAckNack and see if the message was deivered safely (no need of a Scope shape to get the DeliveryNotification exception because there the NACK is not interprated here as an exception).
9. On a succesful delivery the msgAckNack will contain something like:
<String/>
and on a failing delivery it will contain a SOAP message like that:
<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/" SOAP:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><SOAP:Body><SOAP:Fault><faultcode>Microsoft BizTalk Server Negative Acknowledgment </faultcode><faultstring>An error occurred while processing the message, refer to the details section for more information </faultstring><faultactor>C:\TestSendListen\Send1\%MessageID%.xml</faultactor><detail><ns0:NACK Type="NACK" xmlns:ns0="http://schema.microsoft.com/BizTalk/2003/NACKMessage.xsd"><NAckID>{0BC59C8E-45A2-4292-B1FA-05D1ABA00D27}</NAckID><ErrorCode>0xc0c01c10</ErrorCode><ErrorCategory>0</ErrorCategory><ErrorDescription>The FILE send adapter cannot open file C:\TestSendListen\Send1\{846067E1-5C29-4EAE-9308-401B7F913B4F}.xml for writing.
Details: The system cannot find the path specified.
</ErrorDescription></ns0:NACK></detail></SOAP:Fault></SOAP:Body></SOAP:Envelope>