Mapping XML String in Biztalk Mapper to Destination

Q:

Hello All,

I am facing problem in mapping an element from source to destination.

I am polling data from a database which will trigger my process. In the receved message i have a field which has XML content. Based on the XML content i have to call a WCF service. I have a map that transforms the input message to the WCF request (simply by extracting the content of the XML element). But it seems it is not working.  My sample message is:

<Input><Id>1</Id><Type>Add</Type><Xml>&lt;Add&gt;&lt;A&gt;10&lt;/A&gt;&lt;B&gt;10&lt;/B&gt;&lt;/Add&gt;</Xml></Input>

Here i need to extract the Xml element content in a map and assign that to destination. (Note the XML Content is the complete message for my destination). I have a scripting functoid which replaces the "&lt;" with "<" and "&gt;" with ">" and the output is connected to a another scripting functoid that maps the replaced content to the root node of the destination. But when i test the map in design time, the values are not getting replaced. I am not sure why this happens. Below is the code i used in the maps:

First scripting functoid:

 public string GetXml(string param)
{
param = param.Replace("&lt;","<");
param = param.Replace("&gt;",">");
return param;
}

Output of this is given to an XSLT Template of a scripting functoid:

<xsl:template name="TypedPollingResultSet0">
    <xsl:param name="param1" />
    <xsl:value-of select="$param1" />
  </xsl:template>

Below is my map:

 

Sol:

If you use any Orchestration then Just do this in an expression shape.

Create a variable xmlDoc of type System.Xml.XmlDocument.

varString = xpath(msgPollingResult,"string(/*[local-name()='Input' and namespace-uri()='']/*[local-name()='Xml' and namespace-uri()=''])");

//loads this to the string variable. "&lt;Add&gt;&lt;A&gt;10&lt;/A&gt;&lt;B&gt;10&lt;/B&gt;&lt;/Add&gt;";

varString = varString .Replace("&lt;", "<");

varString = varString .Replace("&gt;", ">");

xmlDoc.LoadXml(varString);

msgAdd = xmlDoc; //msgAdd is your output.

If there are some namespaces that you have to change, use this msg as input to the map and modify it.

 
Else If you are Using a Messaging solution

How about creating a custom C# library and then using tat in the scripting functoid. For this you would need to GAC the assembly and use it in the map.


Note: use the above code in a C# Library Gac it and call the method in Biztalk Mapper


Thanks.

Read more ...

Biztalk Schema versioning

By Vincent Scheel

Different VERSIONS OF A SCHEMA SIDE BY SIDE AND USING THEM IN ORCHESTRATIONS

Schema versioning in BizTalk is always a difficult thing to do. When small changes are done on a schema (for a new solution), but this schema is already in use by a solution which is currently in production, you have to be very careful.

BizTalk defines the schema type of a message by the combination:targetnamespace#rootnode to make a MessageType unique (for example: http://mynamespace.com/#MyRootNode). This will define the type of the message and is also used in subscriptions.

If you deploy two schemas with the same MessageType in different assemblies and you try to receive an instance with this MessageType, BizTalk will give you a routing failure telling you it is not able to determine the exact MessageType (the MessageType is found multiple times in the database).

Suppose you have schema X in DLL Y version 1.0.0.0 and you fix a bug (change a nodes’ default value for example) for a new version of a solution, and increase DLL Ys version to 1.0.1.0. If you deploy this new version of DLL Y side by side with an old version, BizTalk is smart enough to see that it is a newer version and will use this newer version of schema X for received messages with this MessageType. No routing failure! This works excellent in a message-only scenario.

So far, so good. If you use the MessageType in a receive shape in an orchestration, this orchestration has a subscription on this MessageType. That is what you expect and see in the ‘View subscriptions’ panel of the Administration Console:

As you can see, there is no assembly version shown here! But since the orchestration is developed with a certain version of a schema, the actual orchestration code does expect a certain version of the schema for the received instance. Meaning that the subscription will work, but the orchestration can’t use the message, because it was typed as the 1.0.1.0 version and the orchestrations expects the 1.0.0.0 version. This will generate an error in the Administration Console as follows:

Uncaught exception (see the 'inner exception' below) has suspended an instance of service 'VersioningTestBTProjOrchv1000.BizTalk_Orchestrationv0100(e0f5b7e2-7e31-550e-1022-af218b9002bc)'.
The service instance will remain suspended until administratively resumed or terminated.
If resumed the instance will continue from its last persisted state and may re-throw the same unexpected exception.
InstanceId: 8b5f3dd1-42b6-4bb0-b7a4-ecd87ced4813
Shape name: Receive_1
ShapeId: 4747131a-9c71-46e6-a99a-319053adcfe7
Exception thrown from: segment 1, progress 3
Inner exception: Received unexpected message type 'VersioningTestProject.Schemas.SchemaIncoming_v0100, VersioningTestProject, Version=1.0.1.0, Culture=neutral, PublicKeyToken=b5c9ca1ed57903d0' does not match expected type 'VersioningTestProject.Schemas.SchemaIncoming_v0100, VersioningTestProject, Version=1.0.0.0, Culture=neutral, PublicKeyToken=b5c9ca1ed57903d0'.
       
Exception type: UnexpectedMessageTypeException
Source: Microsoft.XLANGs.Engine

BizTalk does not automatically know for which orchestration to use the old version and for which the new version. You could say that BizTalk should be smart enough to see that an orchestration obviously expects the older version and cast the message to the correct version before feeding it to the orchestration. But this might lead to unforeseen behaviour and probably is not done this way to avoid errors.

There is an easy fix for this problem. You probably have a different receive location for the newer version of the schema, since the old version is running side by side. You can tell BizTalk to cast a received message to a certain version of the schema. This way it will not automatically cast the message to the latest version, but it will cast it to your specified version. This can be done on the XMLReceive pipeline as follows:

1 – Open the XMLReceive pipeline properties:

2 – Enter the fully qualified name of the type you are going to receive as the DocumentSpecNames property.

The name should look like: ‘FullSchemaTypeName, FullAssemblyName’ (for example: VersioningTestProject.Schemas.SchemaIncoming_v0100, VersioningTestProject, Version=1.0.0.0, Culture=neutral, PublicKeyToken=b5c9ca1ed57903d0). This information can be found by double clicking the deployed schema in the BizTalk Administration Console.

Voila, now BizTalk will cast your message to the specified version and your old orchestration will run just fine

Of course this only works if you have separate receive locations for all versions and you can use the XMLReceive pipeline (or any other pipeline containing the XML dissambler component), but it might just help you out. (Only tested in BizTalk Server 2006 R2)

Read more ...