Object promotion in a BizTalk send/receive pipeline

This blogpost will describe some weird behavior we’ve recently encountered. One of the requirement during our project was that we would promote some values to the context and during development of the pipeline component we discovered the behavior as described below.

The Setup

To promote properties to the context you off course need a property schema. We created following property schema with one property called Customer.

Next to that we have a basic ‘Customer’ class defined that will contain our Customer Object.

Last but not least we have a pipeline component that creates a Customer object and writes that object to the context.

Please note that we’ve intentionally passed the entire customer object as parameter to the Write method. Like the intelligence shows us.

Next to that we have following Receive Location and Send Port created in our BizTalk environment.

Receive Pipeline

When we drop a file in our receive location with above setup and added our CustomerPromotor Pipeline Component to our receive pipeline we noticed following behavior. Our pipeline component executes and our pipeline component return the message successfully.

But the message does not enter the BizTalk MessageBox and the file remains in the drop folder as shown below.

While this message remains in the Inbound folder, the receive location will keep on picking up this message and will keep on trying to process this message unsuccessfully. Important to stress is that this behavior is not triggering any warning or error in the event log. So we were left in the dark when it came to this scenario.

Send Pipeline

So let’s see what kind of behavior will be triggered when we use our pipeline component in a send pipeline scenario.

Again our pipeline component executes and our pipeline component return the message successfully.

But this time we do get a notification that something is wrong and our Message gets suspended with following error:

In the event log we see following error appearing.
A message sent to adapter “FILE” on send port “spCustomerRequestResponse” with URI
“C:UsersgcolpaertDesktopDropOut%MessageID%.xml” is suspended.
Error details: 80004005
MessageId: {6E32D903-E862-4037-9737-FF96D25CDB77}
InstanceID: {EFC3BFEA-8C44-47C5-BE24-4707A76EA1E6}

Conclusion

We discovered this behavior by accident while trying to promote an XML serialized object to the context in an outbound scenario, but we forgot to implement our XML serialization.

The problem with the error we received from BizTalk was not clear and we had to figure it out by debugging our pipeline component. We then took this scenario to our receive location and discovered the problem with the pick-up of the file.

We solved this problem by serializing our customer object to XML string and add that string to the context property, like we planned in the first place. We know not many people will encounter this problem as we mostly promote strings or other base types to the context. The main goal of this blogpost was to intentionally trigger this behavior and get the information out there, because we did not locate any information on this behavior and error.

Hope you enjoyed it!

Cheers,

Glenn Colpaert