June 22, 2005 /Comments Off on Sorting XML Nodes with the BizTalk Mapper
I didn’t Know it was this easy…. This is a little story about sorting nodes in a XML Document. Let’s say we have a schema that looks like the one below
To see the actual XML file I used click here. Let’s say you want to sort the ‘AdresGegevens’ node on ‘Adres’ and then on ‘Postcode’. How do we do that with BizTalk ? As usual, once you know the trick with BizTalk it’s easy…..
Ok we start the BizTalk Mapper and we create a map that looks like this….
I use the mass copy functoid because there is no logic at all and all the nodes are the same. I only want to sort the ‘ZakelijkAdres’ node. Then we start to edit the Scripting Functoid parameters, for this sample the screen looks like the one below
And we are done with it. If you select ‘Validate Map’ and click on the produced output you will see the generated XSL for the complete map and you can see that this little piece of XSL is included in the complete map.
Ok, I am not the most experienced programmer around, But this weekend I started with VS2005. I started with converting my old VB.NET project and converted it to VS2005.
No problem whatsoever. everything seemed fine……
But then I hit the F5 Button to run my project. I was a bit disappointed. I got all kind of CLS compliency errors. I never bothered about CLS compliency but now I have to. So I started reading about it……
CLS-compliant language compilers must follow the rules of Annex 7 of Technical Report 15 of the Unicode Standard 3.0, which governs the set of characters that can start and be included in identifiers. This standard is available at www.unicode.org/unicode/reports/tr15/tr15-18.html.
For two identifiers to be considered distinct, they must differ by more than just their case.
Does this mean that VB got it right all the time ?. In VB it was impossible to have two variables that would differ only in ther casing.
June 2, 2005 /Comments Off on Failed message routing in BizTalk 2006 REALLY NICE !!!!
Failed Message Routing
By default, when a message fails (validation, transformation, routing failure, etc…) within a receive pipeline, the message is automatically placed into the message box as suspended. Suspended messages can be viewed using HAT and notification of the offending message can be sent using MOM (Microsoft Operations Manager). By default failed messages cannot be subscribed to by end points such as an orchestration or send port. This was the default operation of failed messages in BizTalk Server 2004.
BizTalk Server 2006 introduces new functionality which provides additional flexibility in dealing with failed messages. When a new receive port is created there is a property that can be set called “Generate error report for failed message” (see Figure 3).
Figure 3: Receive Port Settings
When this property is checked failed messages will not be suspended. Instead they will be sent to the message box and the following additional properties will be set.
Of these all will be promoted properties with the exception of Description and RoutingFailureReportID. By taking advantage of these additional context properties you can now create end-point filters, on an orchestration or sent port, that subscribe to these failed messages. When used appropriately, failed message routing can be used for notifying users of failed messages or building rich error handling or message repair capabilities.
Sometimes you just have the need to validate a xml document in BizTalk. A while ago I found a piece of code on the internet. You feed the component the just created message and the schemanameit should comply to, and it will be validated by BizTalk.