Error 0xC0C01B4C on Debatching Envelope in Simple Orchestration - biztalk

We have a simple Envelope XML that I am trying to debatch using a custom pipeline on the receive side of a HTTP Send/Receive port . BizTalk will pass through the first set in the envelope but we get the error 0xC0C01B4C (Zombie) for all that follow. For testing purposes I am sending the results of the receive out to a folder in file format. I am hoping someone out there has seen this before as I have been trying many different ways to resolve this issue.
this is the Envelope Message
<?xml version="1.0" encoding="utf-16" ?>
<xs:schema xmlns="http://CC.Schemas.ADDR.ADDR_IDs_Envelope" xmlns:b="http://schemas.microsoft.com/BizTalk/2003" xmlns:ids="http://CC.Schemas.ADDR.ADDR_IDs" targetNamespace="http://CC.Schemas.ADDR.ADDR_IDs_Envelope" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:import schemaLocation=".\ADDR_IDs.xsd" namespace="http://CC.Schemas.ADDR.ADDR_IDs" />
<xs:annotation>
<xs:appinfo>
<b:schemaInfo is_envelope="yes" xmlns:b="http://schemas.microsoft.com/BizTalk/2003" />
<b:references>
<b:reference targetNamespace="http://CC.Schemas.ADDR.ADDR_IDs" />
</b:references>
</xs:appinfo>
</xs:annotation>
<xs:element name="ADDR_IDs_Envelope">
<xs:annotation>
<xs:appinfo>
<b:recordInfo body_xpath="/*[local-name()='ADDR_IDs_Envelope' and namespace-uri()='http://CC.Schemas.ADDR.ADDR_IDs_Envelope']/*[local-name()='Messages' and namespace-uri()='']" />
</xs:appinfo>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="Messages">
<xs:complexType>
<xs:sequence>
<xs:element maxOccurs="unbounded" ref="ids:ADDR_IDs" />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
Details ID's Schema
<?xml version="1.0" encoding="utf-16" ?>
<xs:schema xmlns="http://CC.Schemas.ADDR.ADDR_IDs" xmlns:b="http://schemas.microsoft.com/BizTalk/2003" targetNamespace="http://CC.Schemas.ADDR.ADDR_IDs" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="ADDR_IDs">
<xs:complexType>
<xs:sequence>
<xs:element name="TransactionID" type="xs:string" />
<xs:element name="JWID" type="xs:positiveInteger" />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>

Quite simply your Orchestration is missing a loop where it listens for the next message for the same Correlation. So after processing the first message it will just exit leaving the others unprocessed.
The concept you need is called a sequential convoy. You need to have another Receive Shape (which has the Following Correlation Sets you initialised on the first Receive Shape as an Initializing Correlation Sets) inside a loop as well as a way of exiting the loop, e.g. below is where there is a time limit to wait for exiting the loop. You need to get this exit condition correct otherwise there is still the chance of a zombie.

Just wanted to post an update on this problem I had as I decided to use the Orchestration Pipeline Method and had schema issues. To fix this I had to
1 - Change my receive message and port to System.Xml.XmlDocument message type instead of setting this to my schema. You also have to set the receive pipeline to PassTrhuReceive instead of XML Transmit. Since XML Transmit pipeline will debatch automatically. This allows my loop to process the debatching in the Orchestration as I wanted. I was using a Send/Recieve http port and was able to get this working
One Gotcha on this is you have to use a Scope with the Orchestration Pipeline method so it will not send the message out as I intended one at a time in order.
In one of my orchestrations I had to also use the sequential convoy so that I could process the Envelope message in order one at a time not all of them needed this so the first method worked great at fixing the Zombie message problem I had. Since I already had this operation split in two I ended up saving the Envelope to a folder then picking it up and processing it through sequential convoy.
Everything is working as intended now

Related

WSO2AM Mediator with conditional properties

We are trying to add an API to WSO2AM which has the problem, that we need to add (invisible for users) an Authorization Key.
We are able to add it using Mediator with that configuration:
<sequence xmlns="http://ws.apache.org/ns/synapse" name="Add_Fahrplan_AuthKey">
<property name="REST_URL_POSTFIX"
expression="fn:concat(get-property('axis2','REST_URL_POSTFIX'),
'&authKey=**HERE_IS_THE_SECRET**')"
scope="axis2"
type="STRING"/>
</sequence>
We have 4 get methods
/location
/departure
/arrival
/journeyDetails <-- needs an different AuthKey
But for the fourth get method journeyDetails we need to add the AuthKey in a different way with different characters.
Is it possible to do that in a Mediator configuration? And in case of yes, how can we do it?
Please keep in mind that we are not very familiar with synapse configuration syntax. We tried
value="/location"
but it resulted in an AM-error while invoking the API and we tried
<filter> with <then> and <else>
which resulted again in an AM error.
Thanks for any help

BizTalk.Unexpected data found while looking for: 'Request Information\r\n'

I have a flat file schema which parse a file with multiple lines
I made delimiters to get the needed data after a sentence 'Request Information[CR][LF]'.
When I tried to test the project with a file(.txt) it works correctly.
But when I tried to test by POP data from email
I got this error:
An output message of the component "Flat file disassembler" in receive pipeline "InqueryCardDemo.EmailParserPipleline, InqueryCardDemo, Version=1.0.0.0, Culture=neutral, PublicKeyToken=f0522d81e74b224f" is suspended due to the following error:
Unexpected data found while looking for:
'Request Information\r\n'
The current definition being parsed is Root. The stream offset where the error occured is 0. The line number where the error occured is 1. The column where the error occured is 0. .
The sequence number of the suspended message is 1.
<xs:element name="Root">`
<xs:annotation>`
<xs:appinfo>`
<b:recordInfo structure="delimited" child_delimiter_type="hex" child_delimiter="0x52 0x65 0x71 0x75 0x65 0x73 0x74 0x20 0x49 0x6E 0x66 0x6F 0x72 0x6D 0x61 0x74 0x69 0x6F 0x6E 0xD 0xA" child_order="infix" sequence_number="1" preserve_delimiter_for_empty_data="true" suppress_trailing_delimiters="false" />
</xs:appinfo>
I would recommend replacing the EmailParserPipeline for the PassThru pipeline and hooking up a send port to dump the message to a file location (filter on receive port name as the message is untyped). Then, inspect the file - does it looks as expected? Try using a hex editor and check for any byte order marks that appear before your 'Request Information'. This might help you diagnose what the problem is; I am not suggesting that it is a solution.
I suspect the POP adapter is adding something to the start of the message, before the token that you are looking for. Once you have identified what that is, you can either: update your flat file schema to consume those tokens, or add a custom pipeline component before the flat file disassembler to manipulate the incoming message so it conforms to the schema.
If the encoding of the message if not utf-8, BizTalk needs to be told what encoding it is, using a byte order mark (BOM). Also see this MSDN question for more information: http://blogs.msdn.com/b/atinag/archive/2009/03/18/utf-encoded-message-failing-in-biztalk-2006.aspx
Check the message being received either from HAT for BizTalk 2006R2 or from the BizTalk Admin Console if BizTalk 2009 or above. You may find that it is a Multipart message that you have to accept, and then get the part you want from that and run that through a Pipeline in your Orcherstration to dissasemble.
POP3 Adapter
The POP3 receive adapter retrieves e-mail from a specified mailbox on a specified POP3 server. By default, the POP3 receive adapter applies MIME processing to the e-mail messages that it downloads and submits these messages to BizTalk Server as multipart BizTalk messages. The POP3 receive adapter can receive and process e-mail in the following formats:
Plain text
* MIME encoded
* MIME encrypted
* MIME encoded and signed
* MIME encrypted and signed
At my work we avoid using the POP adapter due to it's security issues, we prefer to have an SMTP service running on the BizTalk server that e-mails are forwarded too, and it is configured to write them the .eml files which we then pick up and process via a MIME pipeline and iterate through all the attachments.

How to add a masked password property to a BizTalk custom file adapter?

I've built a custom file adapter using the sample found in the BTS 2009 SDK, but I need to receive files via this adapter using credentials other than what the host instance is running under. I'd like to add 2 properties to the properties window of the adapter for username and password (this I know how to do), but I want to hide the password text on the password property. Does anyone know how to go about this? Is there something I can set in the ReceiveLocation.xsd on the property to let it know it's for a password, similar to TextBox.PasswordChar property?
I needed to use the Biztalk Adapter Framework PasswordUITypeEditor and PasswordTypeConverter components in the ReceiveLocation.xsd like so:
<xs:element name="Password">
<xs:simpleType>
<xs:annotation>
<xs:appinfo>
<baf:designer>
<baf:displayname _locID="passwordName">Password</baf:displayname>
<baf:description _locID="passwordDesc">Enter username for authentication to directory</baf:description>
<baf:editor assembly="%BTSROOT%\\Developer Tools\\Microsoft.BizTalk.Adapter.Framework.dll">Microsoft.BizTalk.Adapter.Framework.ComponentModel.PasswordUITypeEditor</baf:editor>
<baf:converter assembly="%BTSROOT%\\Developer Tools\\Microsoft.BizTalk.Adapter.Framework.dll">Microsoft.BizTalk.Adapter.Framework.ComponentModel.PasswordTypeConverter</baf:converter>
<baf:category _locID="authenticationCategory">Endpoint Directory Authentication</baf:category>
</baf:designer>
</xs:appinfo>
</xs:annotation>
<xs:restriction base="xs:string">
<xs:maxLength value="22" />
</xs:restriction>
</xs:simpleType>
</xs:element>

What is the most descriptive way to define HTTP basic authentication header in a WADL?

I would like to describe HTTP basic authentication within a WADL, what is the most descriptive way to achieve this?
Since basic authentication is implemented as a header, simply use a param within your request.
<method name="GET">
<request>
<param name="Authorization" style="header" type="xs:string" required="true" />
<!-- other headers... -->
</request>
<response>
<!-- repsonse.. -->
</response>
</method>

ASP.NET WebService without Complex Types

I'm trying to build a webservice with ASP that will be given three parameters: a string, a date/time and another string. After making the method, the wsdl contains this:
<s:element name="TimesheetAudit">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="employeeNumber" type="s:string"/>
<s:element minOccurs="1" maxOccurs="1" name="periodEndDate" type="s:dateTime"/>
<s:element minOccurs="0" maxOccurs="1" name="timesheet" type="s:string"/>
</s:sequence>
</s:complexType>
</s:element>
The black box calling my web service is complaining that there is a mismatch in the number of parameters. I am assuming this is because my webmethod is technically taking 1 parameter, a complex type, instead of three.
Is this the problem? If so, what can I do to overcome it?
Edit: The consumer is the black box in this case, I must mold my web service to match the caller.
Adding [SoapDocumentMethod(ParameterStyle = SoapParameterStyle.Bare)] to my method signature gives the following error: ' does not conform to WS-I Basic Profile v1.1. Please examine each of the normative statement violations below. To turn off conformance check set the ConformanceClaims property on corresponding WebServiceBinding attribute to WsiClaims.None.
R2204: A document-literal binding in a DESCRIPTION MUST refer, in each of its soapbind:body element(s), only to wsdl:part element(s) that have been defined using the element attribute.
- Part 'input' of message 'TimesheetAuditSoapIn' from service description with targetNamespace='http://www.netdes.com/'.
- Part 'TimesheetAuditResult' of message 'TimesheetAuditSoapOut' from service description with targetNamespace='http://www.netdes.com/'.
It is difficult to be sure without more information about what exactly the client is expecting, but it could be a parameter style issue.
By default, an ASP.NET web service uses the "Wrapped" parameter style, which means that all of the parameters get wrapped in a single element that is sent inside the SOAP body.
You can change the method declaration to use the "Bare" parameter style, which puts all the parameters directly inside the SOAP body, without a wrapper element. This is achieved via the ParameterStyle property on the SoapDocumentMethodAttribute on the web method.
See this MSDN entry for details.
In response to conformance error: You can disable WS-I conformance checking by putting the following in your web.config:
<configuration>
<system.web>
<webServices>
<conformanceWarnings>
<remove name='BasicProfile1_1'/>
</conformanceWarnings>
</webServices>
</system.web>
</configuration>
Conformance is normally a good thing, but it's not required. Since you aren't in control of the definition in this case, you don't have much of a choice.
It is also possible that the client is expecting an RPC-style web service instead of a document-style web service. (This would be controlled with a SoapRpcMethodAttribute instead of a SoapDocumentMethodAttribute.) If you still have no luck after turning off the conformance warning you might try changing to RPC-style and see if that works.
And if there's any way you can get a definition (either source or, better yet, a WSDL used to produce the source) for the client so that you can tell what exactly it's expecting, it would help. If you can get a WSDL you can have .NET generate the web service method for you in the correct format.
It sounds like you're the one building the web service host, so you get to run the show, right?
If you can launch Visual Studio, click File, New Website, add a web service to it, use the auto-generated WSDL and successfully connect to it from a test harness, then the consumer of that web service ought to be able to read that same WSDL and connect to it as well as you. The important thing is that you have a test harness that works.
If that's the case, then the black box problem lies on their end of the wire, not yours.

Resources