Webcast recording available - Custom Pipeline Component development

For anyone interested in my talk about BizTalk Pipeline Component development, please see this link: http://www.livemeeting.com/cc/microsoft/view?id=BTSBAG-62&pw=35DKTQ

Feedback is appreciated!

Webcast Sample - Disassembler component for 401k requests

In the Webcast I did yesterday, I explained Disassembler functionality, promoting properties from a deployed schema, writing distinguished properties, disassembling a binary Pdf Form into an Xml message which can be used in conjunction with e.g. Party resolution, etc. If you're interested in reviewing the sample material, the component and sample solution, pipelines, etc. can be downloaded here

new version of the XmlCompleteValidator (v1.1) pipeline component

I've updated the XmlCompleteValidator component, it had some minor issues resulting is less readable errors being generated. It's available here.

Upcoming webcast

I'm doing a webcast this coming Friday regarding pipeline components in general, the use of the Pipeline Component Wizard to enable rapid development of pipeline components, etc. I've got demos lined up involving creating a simple pipeline component from scratch, building the same component using the wizard to show productivity increasement, building a Disassembler pipeline component, using IProbeMessage, etc. Here's the info:

Title: BizTalk Pipeline Components - abstracting external document types from your business
URL: https://www.livemeeting.com/cc/microsoft/join?id=BTSBAG&role=attend&pw=35DKTQ
Time: Friday, May 27, 2005 21:45-23:30 (GMT+1) (1-2:30pm PST)

Pipeline Component Wizard - v1.34

Yet another update. This time it's to fix an anomaly in the Disassembler implementation. It's code was incorrectly generated, resulting in a compilable unit, but to not much affect. It now uses a Queue implementation in order to allow easy implementation of the Splitter Pattern.

Pipeline Component Wizard - v1.33 released

An e-mail from Boudewijn vd Zwan (thanks!) got me started on re-testing the Pipeline Component Wizard and I found a few bugs, which are fixed in the 1.33 release just posted on GotDotNet:

[BUG] AssemblingSerializer generated code has wrong member reference
[BUG] Unsupported CATID values removed
[BUG] Solution always named after latest added project
[BUG] SchemaWithNone with stored incorrectly in the PropertyBag

Sourcecode is included ofcourse, and the documentation part of it is getting better (not quite there yet though..)

Enjoy, and please let me know of any issues...

"a multi-rooted schema may not define a message part; reference the roots directly"

Using the "Add Generated Items" to add an "Adapter" for use with SQL Server in order to send data from BizTalk to e.g. a Stored Procedure, you might end up with a so-called multi-rooted schema.

This kind of schema is generated to enable a response coming back from SQL Server to be used in the Orchestration you need the message (using a Request-Response send port).

However, within the schema, you end up with 2 rootnodes. 1 for the Request message structure and 1 for the Response message structure.

If you want to promote a property within one of those structure, you could end up with the compiler telling you "a multi-rooted schema may not define a message part; reference the roots directly". This would occur e.g. if you would use a Message Assignment shape to set the promoted property to some value within your Business Process.

In order to resolve this error, make sure a "Root Reference" is selected in the generated schema pointing to the element containing the promoted property. This setting can be found on the "Schema" toplevel element in the Schema Editor view.

As I Walk Along I Wonder...

Having an Orchestration where I perform a mapping and try to set a promoted property to some value for either correlation or business use, I sometimes encounter this error:

A failure occurred while evaluating the property MacawSchemas.PropertySchema.SomeField against the message part data. The message part data does not contain at least one of the nodes specified by the XPath expression (listed below) that corresponds to the property.

It ofcourse means BizTalk cannot find the property I'm refering to by using the XPath originally specified when the property was promoted (in the annotation within the document schema). However, I was certain I had the XPath setup correctly.

After some testing, it turned out I made the mistake of assuming the field would be available, while in fact, the mapper didn't produce the field in creating the message, as it had neither an inbound link (naturally), nor a default value.

Setting a "space" character to be it's default value in the mapping target is all I needed to get an empty element generated and for the Orchestration to work......

Can't win 'em all :-o

Note to self: cleanup xml schemas after removing promoted properties

Ofcourse, I'm the only one having trouble with this, but I'll blog it never the less... :-)

I recently (just now :p) encountered some behaviour of the Visual Studio environment for editing xml schemas installed by BizTalk Server 2004 which might lead to trouble in testing and deployment (actually, just in running my Orchestrations in general).

As you probably know, BizTalk adds a nice annotation to your schemas upon promoting a property, like so:

<xs:annotation>
 <xs:appinfo>
  <b:properties>
   <b:property name="ns0:CorrelationToken" xpath="/*[local-name()='Order' and namespace-uri()='http://www.macaw.nl/schemas/OrderProcessing']/@*[local-name()='CorrelationToken' and namespace-uri()='http://Macaw.General.Definitions']" /> 
  </b:properties>
 </xs:appinfo>
</xs:annotation>

I would expect BizTalk to remove this information once the field you actually promoted is removed from the xml schema. However, it doesn't... This causes the BizTalk runtime to try and locate the field given it's XPath in order to promote the field value to the message context. Ofcourse, the field can no longer be located, indicated with an XLANG/s exception:

Uncaught exception terminated service MacawOrchestrations.Axapta.ContactPerson(85ce7703-cea4-61cc-67ed-86bfa9998e7c), instance 652d12a4-ed8e-4bca-aa58-9a065d65ca4d

A failure occurred while evaluating the property MacawSchemas.PropertySchema.CorrelationToken against the message part data.

Resolving this issue proves to be quite simple, just right-click on the rootnode, navigate to the promoted properties, select "Property Fields", and remove the promoted property manually.

Just a reminder...

Deploying from the BizTalk Explorer contextmenu...

Having the option to deploy BizTalk elements from the Visual Studio environment is a very handy thing. However, I made the mistake of using this option to deploy into a test environment I was setting up.

Visual Studio confirmed a successful deployment and I went about configuring the Orchestrations I just deployed (they were nicely visible in the BizTalk Explorer).

When testing the first deployed Orchestration however, it turned out the deployment was successful, but to the end that Visual Studio had deployed the components into the GAC of the local computer while using the remotely configured database for registering the BizTalk components (BizTalkMgmtDb); obviously resulting in failing Orchestrations.

It still means the Deploy option is a good thing, but only to the end of testing the components on the local machine. Reconfiguring the Deployment database doesn't tell Visual Studio to deploy the components to the remote machine GAC (which seems normal, installing to a remote GAC isn't supported to the best of my knowledge)

Microsoft.XLANGs.Core.PersistenceException: Exception occurred when persisting state to the database.

Ever ran in to this kind of exception:

Microsoft.XLANGs.Core.PersistenceException: Exception occurred when persisting state to the database. ---> Microsoft.BizTalk.XLANGs.BTXEngine.PersistenceItemException: A batch item failed persistence
Item-ID b668d473-774c-4fae-979b-90fff5444ff5
OperationType MAIO_CommitBatch
Status -1061151998
ErrorInfo The published message could not be routed because no subscribers were found. Please use the Health and Activity Monitoring (HAT) tool to diagnose this situation.

I just ran into this while testing an Orchestration I have build. I had encountered it before, but didn't document / remember the solution.

f.m.i. (for my info): It turns out this exception will occur if you're calling another Orchestration, which isn't in an Enlisted state... I'll try to remember next time... :-|

There's something about Parties

Trying to implement an Order Fulfillment example BizTalk application for the Northwind database, I ran into some Party resolution issues. It turns out Parties cannot have names with any of the following characters in them:

`~!@#$%^&*()+=[]{}|;"'<>,?
As the Northwind database has a Suppliers table consisting of a default of 29 suppliers with various 'complex' names, e.g.:

• Cooperativa de Quesos 'Las Cabras';
• Forêts d'érables;
• and Heli Süßwaren GmbH & Co. KG;

I wasn't able to create parties to fulfill my orders from the Northwind database based on the Supplier companyname.

BizTalk Performance Charateristics online

Read all about BizTalk Server 2004 performance characteristics at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/BTS_2004WP/html/04d20926-20d2-4098-b701-52238a267eba.asp

It's a great read!