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.

20141118_PropertySchema

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

20141118_CustomerClass

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

20141118_PipelineComponent

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

20141118_WriteMethod

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

20141118_ReceiveLocation

20141118_SendPort

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.

20141118_ReceiveBreakPoint

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

20141118_DropFolder

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.

20141118_ReceiveBreakPoint

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

20141118_SuspendError

In the event log we see following error appearing.
A message sent to adapter “FILE” on send port “spCustomerRequestResponse” with URI
“C:\Users\gcolpaert\Desktop\Drop\Out\%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

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s