Geeks With Blogs
Bill Osuch - Random geek notes

BizTalk parties are external entities that BizTalk communicates with. You create parties in the admin console to determine how (or where) messages are routed, as well as controlling various pieces of envelope information for EDI messages. Today I'm going to walk through a very simple method of routing a message through an orchestration to any location based just on the party name.

Begin by creating a new BizTalk solution. Add a schema called PurchaseOrder that looks like this:

Promote the customer name by right-clicking the Name element and choosing Show Promotions. On the Distinguished Fields tab, click Add to promote Name.

Go ahead and generate an instance of the schema so you'll have a file to test with.

Add an orchestration called Processer, and create a message (msgPurchaseOrder) that uses the schema you just created. Add a Receive Port on the left-hand Port Surface, then add three shapes to the orchestration: Receive, Expression, and Send. Next, drag a Role Link to the right-hand port surface and configure it as follows:

Name: PartnerRoleLink
Create a new Role Link Type
Consumer Role: I will be sending the first message

Your Role Link will be created with a Provider (that can contain Receive Ports) and a Consumer (that can contain Send Ports). Go ahead and delete the provider role (since we won't be receiving anything), and rename the Consumer role to Partner (this isn't absolutely necessary, but I think it makes things more clear).

Next, drag a Send Port into the Partner Role. Wire up the Receive Port to the Receive shape, and the Role Link to the Send shape.

Finally, we're going to create the Expression that will actually assign the destination party to the message. Add the following to your Expression:

PartnerRoleLink(Microsoft.XLANGs.BaseTypes.DestinationParty) = new Microsoft.XLANGs.BaseTypes.Party(msgPurchaseOrder.Customer.Name, "OrganizationName");

When complete, your orchestration should look like this:

Build and deploy the solution.

Now we'll create the ports needed. First, create a Receive Port and a Receive Location pointing to the directory where you'll drop input files.

Your file mask should be *.xml, and you need to use the XMLReceive pipeline. Next, create two send ports (since we'll be testing this with two different parties). Each should be linked to a different directory so that you can clearly see how the messages are being routed. Leave the default file name mask (%MessageID%.xml), and use PassThruTransmit for the Send pipeline.

Next we'll create the two parties that we'll be sending to. You can name them anything you want; I happened to go with our old friends Contoso and Fabrikam. On the Send ports page for each party, connect it to one of the send ports you just created.

Now to configure the application. Right-click on the application name and select Configure. You'll configure the orchestration the same way as always - select the Host and Receive Port - but now you should see a new section titled Role Links. Click on it, then click Enlist. In the Enlist Parties window that pops up, select the two parties you just created and click OK. Then on each party click Bind, and select the send port you're associating with that party. Click OK and start the application.

You'll need a couple test files to work with, so take the xml instance you generated earlier and make two copies, naming them ContosoPurchaseOrder.xml and FabrikamPurchaseOrder.xml. Edit each one with whatever data you'd like, but be sure that the Name element is either Contoso or Fabrikam. Remember, we pick the destination party name from the promoted property msgPurchaseOrder.Customer.Name, so they have to match exactly.

Save these two files and drop them to the input directory. If all goes well, you should see a new file generated in each output directory that exactly matches the input file for that particular party. Granted, just passing the file straight through isn't a very realistic scenario, but my point here was to show you how to match a promoted property to party name and have the message routed properly. We simply dropped the files to different directories, but since you've got a send port associated with each party, you could route the message to a web service, WCF endpoint, email message, etc.

You'll notice we didn't create a party to represent "us", and there are no agreements between parties. These come into play when you're dealing with EDI trading partners; I'll talk about that in a future post.
 

Technorati Tags:

Posted on Monday, October 17, 2011 1:29 PM BizTalk | Back to top


Comments on this post: Basic Party Resolution in BizTalk 2010

# re: Basic Party Resolution in BizTalk 2010
Requesting Gravatar...
its really good one with easy steps to understand the party configuration.hoping more posts like this from you soon...
Left by bala on Dec 20, 2011 1:20 AM

# re: Basic Party Resolution in BizTalk 2010
Requesting Gravatar...
Thank you for sharing this great info, it helped me very much with my current work.
Left by itransition on Jan 04, 2012 3:48 PM

# re: Basic Party Resolution in BizTalk 2010
Requesting Gravatar...
Thank you, this is a clear example. I always used parties with Agreements defined for EDI documents, and your example clearly illustrates how to route messages based on parties only. Great work.
Left by Mamdoh Ashir on Jan 26, 2018 4:04 PM

Your comment:
 (will show your gravatar)


Copyright © Bill Osuch | Powered by: GeeksWithBlogs.net