Geeks With Blogs
Todd Uhl BizTalk/WSE/Indigo

The glossary in the help file describes role links as "The relationship between roles defined by the message and port types used in the interactions in both directions".  Hmmm...that sort of hurts my head.

 

What role links are useful for is to abstract your business process from your trading partner or a disparate system.  For example, let's say that I have a feed that comes out of my backend system, and the business process is the same for 25 vendors.  Some of the vendors need this feed in a flat file, some need it in XML, some FTP, some HTTP...you get the picture.  Now, there are ways to implement this with dynamic mapping, dynamic ports, a bunch of If statements, etc.  But, it is tough to maintain, if a trading partner updates their process and can now receive messages through a web service, there is rework involved in our orchestration.

 

One way we can handle this is through role links.  It is a misconception by some that role links are tied to BAS.  Business Activity Services sort of consists of 2 parts.  For one, it gives a non-technical business user a nice, safe way to manage the interaction with trading partners (configuring ports, transport URI's, etc.).  This works in theory.  It has some limitations, as you can't set any port level maps through the sharepoint interface for instance.  But, anything you need to do for role links, you can implement through BizTalk explorer.  The other part of BAS is the ability to set up service agreements with our partners.  Things like if a purchase order limit is > $1000, we have to send it to a special approval department.  The service agreements would rely on BAS (and therefore Sharepoint) to implement.

 

So, back to our example, how do role links help us?  There are a couple of parts to get role links to work.  Keep in mind there are several orders in which you can do the following, and the following would be for an outbound role link.

 

First we need to create a port type as ultimately we do need to send out a message.  We can create the port type within the orchestration view window, and we need to point the port type to a message.

 

Next we will create a new role link type in the orchestration view, add a role to it, and assign our new port type to the role.  So, let's say we had to send purchase orders out for approval, and different approvers were assigned to specific vendors.  We could have a port type that referenced a PO message.  Our role link type could be "Purchasing" and our role could be "Approver".

 

We now have a role link type that contains a role (Approver) that points to a port type that handles PO messages.  We're part of the way there.  Now we are going to create an actual role link.  Right click on the port surface and choose "New Role Link" to bring up the role link wizard.  Since we have already created our role link type, you can go ahead and select that.  In the next step, select that we will be sending the first message (therefore consuming a service - the Approver can be thought of as a service).

 

We're almost there now.  In BizTalk explorer, you can now create your actual ports, setting the URI, transport types and maps, etc.  We also need to create a party at this point.  The party is the other half of our role link.  For those of us familiar with earlier versions of BizTalk, the party is sort of like the Organization used to be.  We can set up identifiers, like organization name = SupplierA.  We can also specify ports that this party can use.  You will notice in the BizTalk Explorer that we have our role listed under Roles.  Now that we have created a party, we can right click on our role and enlist a new party to allow it to make use of that role.

 

This is the key piece to the whole puzzle.  Within your orchestration, you are going to have a step that will initialize the role link to be associated with the partner.  Basically what is going to happen is based on some value in your message, you will tell BizTalk to figure out who the party is.  Based on the value you pass in, BizTalk will determine the party, and determine the port to use (because you set the port when you created the party), and it will link that port, in essence, to the role link.  So, in some sense it is similar to a dynamic port.

 

I know the details are a little confusing because there are a lot of separate pieces and types pointing to other types, etc.  But, I will post an example showing what I have described above.  I think reading through this, and poking around the example, you will start to see how all the pieces relate to each other.  The definition in the glossary might even make some sense.  Keep in mind that once it's all set up, you can edit a party to use a different port (which could use a different transport method, etc), you can add new parties if you get additional trading partners, or remove some that no longer exist, etc.  Our orchestration is done and doesn't have to be changed, we can manage it all through the physical ports and partners.

 

I will post a link to an example in the next couple of days.  Please let me know if you have any questions.

Posted on Tuesday, September 28, 2004 4:48 AM | Back to top


Comments on this post: Role Links....what are they anyway?

# re: Role Links....what are they anyway?
Requesting Gravatar...
Hi Todd,

The RoleLink works fine in one orchestration but if I use a second orchestration which uses the same RoleLinkType I get an error "Could not load type RoleLink1.BizTalk_Orchestration2 from assembly".

Have you hit this problem or better still found a solution?

Thanks for any advice.

...colin
Left by Colin Munt on Oct 29, 2004 9:51 AM

# re: Role Links....what are they anyway?
Requesting Gravatar...
Colin,
In working with Role Links in the past, I had not tried to share them between orchestrations. However, if you are creating another orchestration in the same assembly, and in the RoleLink Wizard you choose "use an existing role link", rather than creating a new one, it should work. Can you let me know how you created your second role link, and if they were in the same project? Int he meantime I will give it a spin and see if I get the same result.

Todd
Left by Todd Uhl on Oct 29, 2004 3:25 PM

# re: Role Links....what are they anyway?
Requesting Gravatar...
I would like to add receive ports to a Party, but it only allows a send port. What can I do if I want to receive messages from different partyes?
Left by Joe on Jan 12, 2005 1:30 PM

# re: Role Links....what are they anyway?
Requesting Gravatar...
Well, the short answer is that you can't add receive ports, and you don't need to. For one thing, what are you trying to do exactly...perhaps role links are not the way to go. Also, take a look at the PartyResolution example in the SDK under Orchestrations. This will give you an idea of how INBOUND "role links" are used. It is slightly different. The example is a bit bulky, but pay attention to the SupplierProcess orchestration. You will have to run the install.bat file to get the full perspective, but I think it will clear things up for you.
Left by Todd Uhl on Jan 12, 2005 2:18 PM

# re: Role Links....what are they anyway?
Requesting Gravatar...
Hi Todd,

I have many clients, each with their own input message queue! The messages they send for BT do not contain anything about the sender.

I have to create an orchestration which manages orders coming from the partys, and sends responses to them. I wnant to have a single orchestration, where the input and output ports of the client parties can be managed easily. The abstraction layer of role links seem like a good solution, but in this case the Party must be identified by the corresponding message queue.

I have solved tis problem by having one receive port, with many MSMQT receive locations. Knowing the receive location I can decide where (to which party) to send the response.
My problem is that this can not be managed as easy as the output side, where I simply configure the send port to each party (client). (Of course new clients are added, and some are deleted from time to time...)

This is BT2000 migration project, so I cannot change the interfaces or messages :-(.

I am aware of the PartyResolution example, but It seems to me that there is one receive port configured to the Role Link, so it can not manage more parties.

Do you have a suggestion? Am I missing something?

Thank you,

Joe
Left by Joe on Jan 13, 2005 8:51 AM

# re: Role Links....what are they anyway?
Requesting Gravatar...
Can an incomming message be routed to multiple send ports this way?
Left by Jeremy on Jan 25, 2006 3:14 PM

# re: Role Links....what are they anyway?
Requesting Gravatar...
Hello Todd,

Thanks for this great post.

The only thing is that the example link is dead. Is it possible to revieve the link.

Thanks a lot.

regards,
Abhishek.
Left by Abhishek Srivastava on Mar 08, 2006 7:20 AM

# re: Role Links....what are they anyway?
Requesting Gravatar...
I'm not sure I understand. Why would I use this? In my case I just mark the orchestration send ports as "Direct", and then have a messaging send port for each trading partner which is subscribed using the correct promoted property. Am I missing something here? What are the advantages of using Role Links?
Left by The Gremlin on Jul 03, 2006 8:17 PM

# re: Role Links....what are they anyway?
Requesting Gravatar...
Here is a very simple implementation of Role Links.
Left by Eric Stott on Oct 26, 2006 1:21 AM

# re: Role Links....what are they anyway?
Requesting Gravatar...
Hi Todd,
Is it possible to implement the concept of Role Links and party without using any orchestration. We need have to send message to multiple partners only using ports cant use any orchestration. so is it possible? looking forward for your reply. Thanks in advance..

Abhijit Mahato
Left by Abhijit Mahato on Oct 29, 2007 4:24 AM

Your comment:
 (will show your gravatar)


Copyright © Todd Uhl | Powered by: GeeksWithBlogs.net