Archive for the ‘BizTalk Exception-Cause-Resolutions’ Category

Reason: Name cannot begin with the ‘.’ character, hexadecimal value 0x00. Line 1, position 2.

August 30, 2012 Leave a comment

Issue :

Pipeline execution throws “Reason: Name cannot begin with the ‘.’ character, hexadecimal value 0x00. Line 1, position 2.”

Cause :

The default encoding for a BizTalk schema is UTF-16. When a stream is read from the bodyPart of the message in a pipeline component using a different encoding ( like UTF-8), then this error occurs.


The resolution is to use “Encoding.Unicode” which represent UTF-16 while reading the stream using a Stream reader.


Logical ReceivePort Operation Name as an extra XML element:Publishing Orchestration as a Service

April 24, 2012 Leave a comment

Issue :

While Publishing an Orchestration as a service using WebServices wizard, the xml input expected by the generated service operation is wrapped within an extra xml element, which is the name of the logical receive port of the published orchestration

    <Operation_1 xmlns=”hhtp://MyTestNameSpace”>

Cause :

The Orchestration that is published as a service creates 2 types of subscriptions behind the scenes(logically a single subscription as they are seperated by an OR).

1.For the requests coming from the generated SOAP receive port,  the subsciption is as follows. == {47E7FAA7-D285-4C69-A591-510F8074AEEC} And == Operation_1

2.The second subscription is based on regular messagetypes which are not from the SOAP transport types. {47E7FAA7-D285-4C69-A591-510F8074AEEC} And http://OrchFiltertest.In#Root And != SOAP

 So when a message arrives  through the SOAP recieve  port, an extra xml  element that matches the name of the logical recieve port is added in order to match the subscription.This extra element header will be automatically ripped off by the engine when it hands over the message to the orchestration


No manual action is required in this scenario and it is a built in behavior. The message will reach the orchestration as it has to.

FlatFile xs:Date field with an empty value

June 8, 2011 Leave a comment

I have seen this issue a couple of times and thought of recording this.


After generating a flat file schema with optional elements(minoccurs =0) of type date,int,decimal etc., which does not accept a ‘ ‘  value, we might endup with an error as follows.

error BEC2004: The ‘JoinDate’ element is invalid – The value ” is invalid according to its datatype ‘; – The string ” is not a valid XsdDateTime value.


This exception is perfectly valid from the compiler’s perspective. Here comes the example.

Suppose my flatfile schema is generated using the following imput and is demilited by ‘|’ .


As the date field(highnlighted in red) is optional in our scenario, the following input is also valid.


But when BizTalk validates this instance against the schema, it just picks the value between the two ‘|’ symbols for the date field which is ”. Thus it throws the error when it checks if the value ” is valid for a date field. This will occur for any datatype which does not accept ” value.


The Solution is to logically let BizTalk  know priorly that the datefield is optional and it has to ignore if any blank values occur.

This can be done by setting the “Suppress Empy Nodes” Property to “No” at the Schema Level(By Clicking on the word “Schema” above the root node of the flatfile).


This will ensure that BizTalk knows that the field might have empty value and it should ignore it. This will get your validation successful.

Please post your suggestions or comments.

Cannot locate document specification because multiple schemas matched the message type

March 24, 2011 2 comments


Cannot locate document specification because multiple schemas matched the message type “RootName#Namespace”.


This happens when multiple schemas of the messagetype deployed.

MessageType is an important property that is used for evaluating subscriptions by BizTalk to identify where an incoming message has to be routed to.A MessageType(RootName#NameSpace) is a combination of a schema’s rootname and namespace.

If 2 schemas with the same MessageType(RootName#NameSpace) has been deployed, the XMLDisassembler will not understand which schematype the received message is of.So the exception “Cannot locate document specification because multiple schemas matched the message type “RootName#NameSpace” will be thrown.

Run the following Query against the BizTalkManagement Database. If it returns more than 1 row, then that should be the problem.

SELECT  msgtype
FROM bt_DocumentSpec
Where msgtype = ‘;

Note:Replace “; by “YourSchemasNameSpace#YourSchemasRootName”.


1.If you are using the same schema in different projects seperately, then

Move this schema to a common project and deploy it. Refer this common project in all other projects that you want this schema to be used in.This will resolve the issue.

2.If both the schemas are different and the namespace can be modified, then

Modify the namespace for any one of the schemas and deploy it.This will resolve the issue.

3.If both the schemas are different and the namespace cannot be changed, then

  • Create a custom receive pipeline and add an XmlDisassembler to it.
  • Set the “Document schemas” property of the XMLDisassembler by picking the schema(one among the 2 schemas with the same messagetype deployed) which you want to receive on this receive pipeline.
  • Use this receivepipeline on the receive location. This way we are forcing the XMLDisassembler to use the schema we have provided rather then it trying to match one in the DocumentSpec table.

Please post your comments or questions.


The POP3 adapter could not establish a connection with the POP3 server

March 23, 2011 Leave a comment

Exception :

The adapter “POP3” raised an error message. Details “The POP3 adapter could not establish a connection with the POP3 server. This could be due to the following reasons:
1) The POP3 server host and port information is incorrect.
2) The POP3 server is not running or is not reachable due to network issues.
URL: POP3://<server name>#<user name>
Error: No connection could be made because the target machine actively refused it “.

Cause :

This exception occurs when your firewall blocks the ports used by BizTalk Server to connect to the POP3 server.

Resolution :

There are certain ports that has to be opened on the firewall to allow BizTalk to communicate with the POP3 server.The list of ports to be opened on the firewall  for each adapter can be found at the following link:

Remember to mention the port number as 995 if a Secure connection is used.

To know more about other POP3 Adapter Configurations check

Please post any of your comments or questions.