Get the name of received file in Biztalk

Thursday, June 30, 2011

Get the name of received file in Biz talk and Map it to any Element

Use the following Property in Custom pipeline to read the File Name Property

PropertyValue = pInMsg.Context.Read("ReceivedFileName","http://schemas.microsoft.com/BizTalk/2003/file-properties")

There are more than a couple to achieve this thee above description is for accesing filename in pipeline
what if you want to access else where in biztalk

lets see:

How to access the received file name at port level : Use %SourceFileName% macro at port level to access

How to access at orchestration : Use " File.ReceivedFileName " .Net Property

I’m always forgetting the list of macros that I use, which leads me to always be looking for them, so here’s a list of send macros that you can use:

Macro name	Substitute value
%datetime%	Coordinated Universal Time (UTC) date time in the format YYYY-MM-DDThhmmss (for example, 1997-07-12T103508).
%datetime_bts2000%	UTC date time in the format YYYYMMDDhhmmsss, where sss means seconds and milliseconds (for example, 199707121035234 means 1997/07/12, 10:35:23 and 400 milliseconds).
%datetime.tz%	Local date time plus time zone from GMT in the format YYYY-MM-DDThhmmssTZD, (for example, 1997-07-12T103508+800).
%DestinationParty%	Name of the destination party. The value comes from the message context property BTS.DestinationParty.
%DestinationPartyQualifier%	Qualifier of the destination party. The value comes from the message context property BTS.DestinationPartyQualifier.
%MessageID%	Globally unique identifier (GUID) of the message in BizTalk Server. The value comes directly from the message context property BTS.MessageID.
%SourceFileName%	Name of the file from which the File adapter read the message. The file name includes the extension and excludes the file path, for example, Sample.xml. When substituting this property, the File adapter extracts the file name from the absolute file path stored in the FILE.ReceivedFileName context property. If the context property does not have a value—for example, if a message was received on an adapter other than the File adapter—the macro will not be substituted and will remain in the file name as is (for example, C:\Drop\%SourceFileName%). Note: Correct implementation of this macro requires that the output message is the same message as the received message.
%SourceParty%	Name of the source party from which the File adapter received the message. Note: Correct implementation of this macro requires that the output message is the same message as the received message.
%SourcePartyQualifier%	Qualifier of the source party from which the File adapter received the message. Note: Correct implementation of this macro requires that the output message is the same message as the received message.
%time%	UTC time in the format hhmmss.
%time.tz%	Local time plus time zone from GMT in the format hhmmssTZD (for example, 124525+530).

Biztalk Schema versioning

Thursday, June 30, 2011

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)

Biztalk 2010 GAC Issue

Thursday, June 30, 2011

VS 2010 uses .Net 4.0 and Net 4.0 gac's the dlls into the new GAC location (C:\Windows\Microsoft.NET\assembly\GAC_MSIL\ProjectName\v4.0_\*.dll)

wheras Biztalk uses GAC loc as C:\Windows\assembly folder for all the dlls and all the default and esb Biztalk dlls are located here. When i create a Biztalk project it deploys fine in Biztalk DB wheras the dlls are Gac'd in the new GAC loc.

At runtime Biztalk is looking for the dlls in GAC and does not find it (looks under C:\Windows\assembly folder) and it fails.

Ans:

f you are getting a specific error about a file not being in c:\windows\assembly, you could try copying them there using the command-line. Although you cannot see the files in gac_msil through Windows explorer, you can see these on the command-line. So for example, open a command prompt, cd to c:\windows\assembly\gac_msil. Then you can copy files from there to c:\windows\assembly.

Biztalk 2010 GAC Issue

Thursday, June 30, 2011

VS 2010 uses .Net 4.0 and Net 4.0 gac's the dlls into the new GAC location (C:\Windows\Microsoft.NET\assembly\GAC_MSIL\ProjectName\v4.0_\*.dll)

At runtime Biztalk is looking for the dlls in GAC and does not find it (looks under C:\Windows\assembly folder) and it fails.

Ans:

Using FOR XML queries with the WCF-SQL Adapter

Thursday, June 30, 2011

By Dan Rosanova

The WCF-SQL adapter is the official replacement for the old SQL Adapter in BizTalk and is available across three versions of the product (2006 R2, 2009 and 2010). This adapter greatly increases the capabilities of interacting with SQL Server from BizTalk. It also advertises backwards compatibility with the older adapter. There are a few subtle points to using the approach of the classic SQL adapter that are covered in this article.

Why use FOR XML?
FOR XML is a relatively little known feature of SQL Server that makes reading normalized records vastly easier. The basic concept is that some query keywords will enable SQL Server to output XML as the result of a query, instead of tabular data. This is extremely useful when dealing with parent child records that you need to read from a database.

Let's say we have a database that handle purchase orders. A purchase order has some information of its own and then it has line items that are part of the order. The table structure is shown below.

Using classic T-SQL if we wanted to get all this data out we could join the two tables and then we would get a longer flat record that repeated the data for the order in every record as shown below.

select * from [Order] JOIN OrderLine ON Id = OrderId

With FOR XML we can leverage SQL Server's built in heuristics that will create an XML structure for us that better represents the parent child relationship that is an order and line items. This query turns out to be very easy as seen in the following query.
select * from [Order] JOIN OrderLine ON Id = OrderId FOR XML AUTO,ELEMENTS

The resulting XML is also very simple as shown below.

<Order>
<Id>47</Id>
<OrderNumber>3774632</OrderNumber>
<CustomerName>John Doe</CustomerName>
<CustomerAddress1>123 Fake St</CustomerAddress1>
<CustomerState>IL</CustomerState>
<OrderTotal>247.54</OrderTotal>
<OrderLine>
 <OrderLine>49</OrderLine>
 <OrderId>47</OrderId>
 <ItemNumber>54346</ItemNumber>
 <Quantity>1</Quantity>
 <UnitCost>2.475400000000000e+002</UnitCost>
 <Description>Some Item</Description>
</OrderLine>
<OrderLine>
 <OrderLine>50</OrderLine>
 <OrderId>47</OrderId>
 <ItemNumber>44352</ItemNumber>
 <Quantity>2</Quantity>
 <UnitCost>1.542500000000000e+002</UnitCost>
 <Description>Another Item</Description>
</OrderLine>
</Order>

We can see that this XML is a much better representation of the order construct. There are also other options available with FOR XML including the ability to completely define the resulting XML structure. For our purposes this will work fine.

Generating schemas?
At first this part was extremely frustrating to me. The new wizard does now allow us to generate schemas the way the old wizard did. The approach is much more manual. Although not that difficult to do; BizTalk has made so many other things easy that I just expected this to be easier and wizard based. It turns out that it still is.

We can still use the classic SQL Adapter wizard to generate the schemas that we use just like we used to. Again, like with the classic SQL Adapter we must use the XMLDATA directive on the query in order to run the wizard and have the schema generated for us. For more information on using the classic SQL Adapter see How to Add SQL Adapter Schemas to a BizTalk Project.

Tying it all together
We’re almost done. This last part is the only subtle change between the two adapters. After the schema is generated we must set the Element Form Default on the schema to Unqualified. The classic adapter wizard sets this as Qualified. This setting is set at the schema level in the BizTalk schema editor within Visual Studio.

After this everything works exactly as you would expect and we can continue using a pattern that has been well developed and tested over time.

Using Sql Adapter in Biztalk 2010

Thursday, June 30, 2011

Anyone every actually pull off a successful FORXML polling query using the WCF-SQL Adapter? The documentation on MSDN for this does not seem to show a clear way to do it. Every example is a trivial 'this is so easy with a simple single table not using the classic SQL adpter' and I'm at my wits end with it.

Something that takes 30 seconds with the old adapter is taking all day and not working... and involving notepad according to MSDN.

Ans:

OK, I got the answer to this one!!! It seems the documentation is behind on how AWESOME BizTalk is. So I read that the classic SQL adapter is included in BizTalk 2010, but not supported and I couldn't figure out why it was still there. I was just going to keep the old solution, but since this is for my book I thought I'd try to figure out the right way. I'll be honest, I was really upset earlier if you couldn't tell by my tone after trying to work through this: http://msdn.microsoft.com/en-us/library/dd787898.aspx

So you just run the old wizard, like you used to, then you simply deploy the schema and create a receive location via the admin console. Then you just set the type to XmlPolling and put in "exec MyProcName" and the where clause from your existing FORXML stored procedure in a stripped down query in PolledDataAvailableStatement. Like magic it just all works!

I am writing a blog post about this now, but this deserves to be better documented.

Oh one last thing... have to change the Element Form Default from qualified (as it was in the old SQL Adapter) to unqualified.

So NO we did NOT break this! Now it works better!

Mapping Repeating Sequence Groups in BizTalk

Wednesday, June 29, 2011

Repeating sequence groups can often be seen in real life XML documents. It happens when certain sequence of elements repeats in the instance document. Here's fairly abstract example of schema definition that contains sequence group:

<xs:schema xmlns:b="http://schemas.microsoft.com/BizTalk/2003"

xmlns:xs="http://www.w3.org/2001/XMLSchema"

xmlns="NS-Schema1"

targetNamespace="NS-Schema1" >

<xs:element name="RepeatingSequenceGroups">

<xs:complexType>

<xs:sequence maxOccurs="1" minOccurs="0">

<xs:sequence maxOccurs="unbounded">

<xs:element name="A" type="xs:string" />

<xs:element name="B" type="xs:string" />

<xs:element name="C" type="xs:string" minOccurs="0" />

</xs:sequence>

</xs:complexType>

</xs:element>

</xs:schema>

And here's corresponding XML instance document:

<ns0:RepeatingSequenceGroups xmlns:ns0="NS-Schema1">

B1

B2

B3

</ns0:RepeatingSequenceGroups>

As you can see elements A, B, and C are children of anonymous xs:sequence element which in turn can be repeated N times. Let's say we need do simple mapping to the schema with similar structure but with different element names:

<ns0:Destination xmlns:ns0="NS-Schema2">

</ns0:Destination>

The basic map for such typical task would look pretty straightforward:

If we test this map without any modification it will produce following result:

<ns0:Destination xmlns:ns0="NS-Schema2">

</ns0:Destination>

The original order of the elements inside sequence is lost and that's not what we want. Default behavior of the BizTalk 2009 and 2010 Map Editor is to generate compatible map with older versions that did not have ability to preserve sequence order. To enable this feature simply open map file (*.btm) in text/xml editor and find attribute PreserveSequenceOrder of the root <mapsource> element. Set its value to Yes and re-test the map:

<ns0:Destination xmlns:ns0="NS-Schema2">

</ns0:Destination>

The result is as expected – all corresponding elements are in the same order as in the source document. Under the hood it is achieved by using one common xsl:for-each statement that pulls all elements in original order (rather than using individual for-each statement per element name in default mode) and xsl:if statements to test current element in the loop:

<xsl:template match="/s0:RepeatingSequenceGroups">

<ns0:Destination>

<xsl:for-each select="A|B|C">

<xsl:if test="local-name()='A'">

<Alpha>

<xsl:value-of select="./text()" />

</Alpha>

</xsl:if>

<xsl:if test="local-name()='B'">

<Beta>

<xsl:value-of select="./text()" />

</Beta>

</xsl:if>

<xsl:if test="local-name()='C'">

<Gamma>

<xsl:value-of select="./text()" />

</Gamma>

</xsl:if>

</xsl:for-each>

</ns0:Destination>

</xsl:template>

BizTalk Map editor became smarter so learn and use this lesser known feature of XSLT 2.0 in your maps and XSL stylesheets.

source : paul petrov

BizTalk Guru

Pages

Get the name of received file in Biztalk

Biztalk Schema versioning

By Vincent Scheel

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

Biztalk 2010 GAC Issue

Biztalk 2010 GAC Issue

Using FOR XML queries with the WCF-SQL Adapter

By Dan Rosanova

Using Sql Adapter in Biztalk 2010

Mapping Repeating Sequence Groups in BizTalk