I have the suspicion that BizTalk’s role links are a fairly misunderstood, and thus avoided, part of the developer’s toolbox. For the longest time,
I myself avoided them like the plague, mainly because I didn’t understand how all this Business Activity Services (BAS) stuff worked. What I’ve learned,
however, is that Role Links can be quite useful even outside of the larger BAS infrastructure. Role Links can actually act like dynamic ports, but for
trading partners or other applications. Below, I walk through the fairly simple steps to set up, and demonstrate the usage of Role Links in BizTalk
What are Role Links? At the end of the day, they are a form of abstraction so that you can dynamically choose which trading partner (or I propose, application)
to transmit (or receive) a message from. You can use the same orchestration to handle countless different partners, and choose at runtime who to send the
output message to. For a nice description of Role Links, check out Todd Uhl’s explanation.
Very first thing is to open the Types pane of the Orchestration View window and expand the Role Link Types section. Create
a new Role Link Type, in my case, this was called Fulfillment. Then right-click and create a Role, which in my case was called
Supplier. Next you right-click the role and Add Port Type. Here you can either point to one you’ve already built, or, create a brand
new port type.
Next, we add the Role Link to the orchestration. You can either drag a shape from the Toolbox, or, right click the the Port Surface and choose
New Role Link. This naturally pops up a wizard which walks you through either creating a Provider or Consumer Role Link. In my case,
I’m a Consumer since I’m sending a message out.
Now on my orchestration, I have a Role Link on my Port Surface which I can connect to a Send shape.
Now how in the heck does this orchestration know where to send this message to? The main step is to set the Destination Party on the Role Link.
In my case, this is a property of my schema. I call a business rule, which fires through criteria to set which supplier to use. The field modified by the
Rules Engine is what I set as the Destination Party in an Expression shape. The “OrganizationName” parameter maps to one of many aliases you can use to select which
party should be used.
Now we can compile and deploy this bad boy. If you use BizTalk Explorer, or the Admin Console, you’ll see that there is no port binding for the Role Link
port. That threw me the first time. Role Link ports are bound differently. Before we can bind however, we have to create the actual Parties that
we will be choosing from. From the BizTalk 2006 Admin Console, click the Parties collection and create a few. In my case, I created a few dummy
supply companies. Notice that each party has (a) alias by which to identify this party, (b) collection of multiple possible send ports, and
(c) certificates for outbound encryption. Powerful stuff.
Now we go to our Role Links collection contained in whichever Application we’ve deployed our solution to. As you can see, it shows you
all the Role Links contained in the Application.
Right now, if you try and start the application, it will bomb out and tell you that the application is not configured. That’s because no Role Links have
had parties enlisted. If you choose Configure for the Application, you’d see the following.
The Supplier Role Link is incomplete, and thus has the error icon. The other orchestration bindings are fine, thus a “complete” icon. As you can
see, no parties have been associated with this Role Link.
So, all you do is click Enlist, select the party or parties to enlist, and then choose which of the send ports you chose for that party you want
to apply to the Role Link. And that’s it.
So why does this matter? If I need to replace a trading partner, or more likely, bring a new one online, the steps are (1) add a party, (2)
Add that party to the Role Link, and (3) modify the business rule to assign the new party for distribution. That’s really easy. Also, it’s very
easy to switch which transmission send port to use for a particular partner without recompiling anything.
Now this function is often talked about for trading partners. But there is no reason this also can’t apply to certain applications. What if, based
on certain business logic, you update either system 1, 2, or 3? Why couldn’t you just set a Destination Party on a Role Link, let the send port
map the schema to the application-specific format, and be good to go? If there’s a new application in the mix, you’d just add a Party for it, change your
business logic, create a new schema/map, and bam, you’re done. Am I crazy, or are Role Links feasible for trading partners AND applications? Obviously not
in every case, but I can envision certain scenarios where this could make you more agile.