Share via

BizTalk: Reusing BizTalk Server’s Context Properties

  • Article

Introduction

This article is not much of a how-to, rather a reminder that sometimes a solution is so obvious, it’s not at all obvious. ;)

Very often in our app, we need to pass around contextual information along with the actual message content… hence Context Properties!

Generally, the guidance is to create our own property Schema, reference that in our apps, and use accordingly.  While we would say this is the ‘correct’ way, it’s certainly not the only ‘correct’ way.

BizTalk Server comes with dozens of individual properties already defined, deployed and ready for use in any application.  In an number of scenarios, the is perfectly legitimate and allows us a degree of simplification.

Considerations

Reasons for reusing existing BizTalk Context Properties:

  • The property will be used across multiple Solutions/Applications.
  • The property name matches your requirement.
  • BizTalk Server itself is not dependent on the property.
  • You are complimenting BizTalk use of that property.

Reasons to avoid reusing a BizTalk Context Property:

  • The property is crucial to BizTalk’s internal operation.
  • The property name is misleading for your actual use.
  • All app teams can’t agree on a property’s use case.
  • You app(s) require many different properties for full functionality.

Possibilities

My Most Common Properties.

BTS.BatchRequired This is useful in situations where the need to batch messages is based on differing factors, usually just receiving Trading Partner.  For example, an Orchestration subscribes to the True cases while a Send Port subscribes to the False cases.
BTS.DestinationParty This one, we keep very self describing.  The value is descriptive of the receive, meaning whatever is on the other side of the protocol.  This can be the Trading Partner Organization, such as Contoso, or the receiving LOB app in or outside your own organization, CRM for instance.
BTS.Operation By far, my favorite and most commonly used.  A huge plus on this one is the BizTalk will automatically set and Promote this property for you.  All you have to do is set the Operation name property on Orchestration Send Ports and…that’s it…it’s ready to use.  You can almost as easily set this on receive operations (Receive Ports and Two Way Send Ports) by deriving the value in a Map, and setting a field promoted to BTS.Operation.
BTS.PartnerPort This one I’ve used when is necessary to route message to different Orchestration processes.  The PartnerPort being the receiving Port of the Orchestration.
BTS.SourceParty SourceParty is useful in cases where the meaningful source is not part of the message itself or is used in downstream decisions and you can avoid reading it from the message every time.
ErrorReport.Description This, along with the other ErrorReport properties is the built in way to communicate with an app owned exception disposition process.  While we should always be writing to the Windows Event Log when the exception is detected, the ErrorReport properties can be set internally when the failing message is routed to a user experience, such as SharePoint, for investigation or remediation.

Finally

For relatively uncomplicated apps, it’s even more important to use a minimalist approach in patterns and artifacts since any unnecessary complexity is a higher relative net negative.  Using built-in properties can save an extra deployment, reduce inter-app dependencies and keep a simplicity focus to you App Dev.

As always, try it first, then if built in properties don’t match your needs, create your own.  Happy BizTalking.