I posted this problem on the MSDN forums as well. Someone there suggested the following:
You can set the DOCTYPE from the grid properties of a map. I suggest you create a map to construct above message and set the below property in Grid properties.
Doctype System = http://xml.cXML.org/schemas/cXML/1.2.021/cXML.dtd
This was a great suggestion, however I unfortunately had the following issues with the approach:
1) There isn’t a source message to transform in this process
2) I hate the Biztalk mapper because it has unpredictable behavior such as including optional attributes, etc.
In any case it was the best idea I had and in some simple tests with the BizTalk mapper the idea of using the DocType System property worked well. The resulting XML in testing the map does not include the [] brackets in the DOCTYPE declaration. Due to this I decided to take the idea and run with it. Since I knew just using the BizTalk mapper verbatim was going to result in some wacky output XML, I created a custom XSLT transform. My process also requires a call to an external assembly, so I created custom extension XML, so I could call the assembly in my XSLT. The resulting XSLT was as follows:
<?xml version=”1.0″ encoding=”UTF-8″?>
<xsl:stylesheet xmlns:xsl=”http://www.w3.org/1999/XSL/Transform” xmlns:msxsl=”urn:schemas-microsoft-com:xslt” xmlns:var=”http://schemas.microsoft.com/BizTalk/2003/var” exclude-result-prefixes=”msxsl var ScriptNS0 userCSharp” version=”1.0″ xmlns:ScriptNS0=”http://schemas.microsoft.com/BizTalk/2003/ScriptNS0″ xmlns:userCSharp=”http://schemas.microsoft.com/BizTalk/2003/userCSharp”>
<xsl:output omit-xml-declaration=”no” method=”xml” version=”1.0″ doctype-system=”http://xml.cXML.org/schemas/cXML/1.2.021/cXML.dtd” />
<xsl:template match=”/”>
<xsl:variable name=”var:PayLoadID” xmlns:ariba=”http://AribaHelper” select=”ariba:PayloadID("dev.service.fabio-perini.com")” />
<xsl:variable name=”var:DateTime” select=”userCSharp:DateCurrentDateTime()” />
<cXML>
<xsl:attribute name=”payloadID”>
<xsl:value-of select=”$var:PayLoadID” />
</xsl:attribute>
<xsl:attribute name=”timestamp”>
<xsl:value-of select=”$var:DateTime” />
</xsl:attribute>
<xsl:attribute name=”xml:lang”>
<xsl:value-of select=”‘en-us'”/>
</xsl:attribute>
<Response>
<Status>
<xsl:attribute name=”code”>
<xsl:value-of select=”‘200′”/>
</xsl:attribute>
<xsl:attribute name=”text”>
<xsl:value-of select=”‘OK'”/>
</xsl:attribute>
</Status>
</Response>
</cXML>
</xsl:template>
<msxsl:script language=”C#” implements-prefix=”userCSharp”>
<![CDATA[
public string DateCurrentDateTime()
{
DateTime dt = DateTime.Now;
string curdate = dt.ToString(“yyyy-MM-dd”, System.Globalization.CultureInfo.InvariantCulture);
string curtime = dt.ToString(“T”, System.Globalization.CultureInfo.InvariantCulture);
string retval = curdate + “T” + curtime;
return retval;
}
]]></msxsl:script>
</xsl:stylesheet>
When I tested the map, I got the perfect response! Here is what my test ouputted:
<?xml version=”1.0″ encoding=”utf-8″?>
<!DOCTYPE cXML SYSTEM “http://xml.cXML.org/schemas/cXML/1.2.021/cXML.dtd”>
<cXML payloadID=”7162010103415.4808.1633756899@dev.service.fabio-perini.com” timestamp=”2010-07-16T10:34:15″ xml:lang=”en-us”>
<Response>
<Status code=”200″ text=”OK”/>
</Response>
</cXML>
At this point the idea in my mind was a genius and while the approach was a bit unconventional it got the job done and I was happy. Then I tested it in a running application. Keep in mind my BizTalk application uses a HTTP two-way receive port. If a valid document is posted in, the above code is what should be in the GET response. Guess what I got back out in the GET response? This:
<?xml version=”1.0″ encoding=”utf-8″?>
<!DOCTYPE cXML SYSTEM “http://xml.cXML.org/schemas/cXML/1.2.021/cXML.dtd”%5B%5D>
<cXML payloadID=”7162010103737.644.40540607@dev.service.fabio-perini.com” timestamp=”2010-07-16T10:37:37″ xml:lang=”en-us”>
<Response>
<Status code=”200″ text=”OK”/>
</Response>
</cXML>
The double brackets came back! It would appear that somewhere in the BTSHTTPReceive.dll assembly this problem is occurring! So I was targeting the wrong point in the process where the problem was introduced. I have NO idea how to control the behavior of the BTSHTTPReceive.dll assembly at all.
By the way…this problem is with BizTalk 2009 Server.