Q & A - How to Configure Parties in BizTalk 101

Monday, December 30, 2013

Q: You are developing an EDI solition, and you need to configure a new trading partner.

Trading partner management is the most significant new functionality presented in BizTalk Server 2010. The new mapper has some nice features, but it doesn't bring new functionality to the product. The trading partner configuration, on the other hand, allows for the development of EDI solutions that could not be done before. This solution outlines how to create a trading partner in BizTalk Server.

Open the BizTalk Administration Console, and click Parties (see Figure 1).

Figure 1. The Parties folder in BizTalk

Right-click any area in the Parties and Business Profiles area and select New => Party.

In the Party Properties dialogue box, give the party an appropriate name. This should be the name of the trading partner you will be exchanging documents with.

Enable the option for the Local BizTalk processing (see Figure 2). This setting is used to indicate that BizTalk Server will be used to process messages to or from the party (rather than being the default party itself).

Figure 2. Configuring the base party object

Click the "Send ports" tab. This is where ports are associated with a party, and it is used in instances where all outbound EDI documents on this port should have envelope information configured as specified in the EDI properties of the party being configured. Add any relevant send ports, and click OK.
            Now that the party object has been created, a new business profile must be created. A business profile contains all of the EDI configurations for a given business of a trading partner. For example, a trading partner may be a single company with multiple departments or divisions. Each department has its own integrations with internal and external vendors, and each uses its own X12 or EDIFACT settings. One business profile for each department must be created in order to ensure that the envelopes on the EDI documents being exchanged are set properly, and that all other EDI specific configurations are accurate for that department.

            Right-click the party that was created, and select New => Business Profile (see Figure 3).

            Figure 3. Creating a business profile on a party

            Give the business profile a name representative of the business unit or department being set up. In many cases, a party will only have a single business profile.

            On the identities screen, set the trading partner ID(s) and qualifier(s) (see Figure 4). These values are given to you directly by the trading partner, and are the way trading partners are uniquely identified.

            Figure 4. Setting the Business Profile's identities

            Once the business profile is fully configured, click OK.
            With the business profile and core party configured, an agreement can be made. However, to create an agreement, you must have two parties configured. One party represents the recipient, and one is the sender. In many cases, BizTalk is going to be one of the parties. However, in the cases where BizTalk is acting as a value added network (VAN)—essentially, as a router of documents between parties—there may be many parties sending and receiving documents to many other parties. All of the configurations representing document communication between parties are known as agreements.

            To create an agreement, right-click the business profile, and select New => Agreement.

            Initially, there will be only a single tab to configure. You must specify the party being interacted with and the protocol being used. To do so, set the Protocol property to (for example) X12, and the Party and Business properties to an available party. Once these have been set, two new tabs will appear (see Figure 5). 
            These tabs are where all of the EDI specific information is configured for the given agreement.

            Figure 5. Setting the general properties of the Agreement

            Click each of the tabs to set the EDI-specific values based on the trading partner configuration specifications. An example of the Identifiers screen is shown in Figure 6. Once you are finished, click OK to save the trading partner configuration.

            Figure 6. Setting values within the agreement

            How It Works

            This recipe outlined how to configure the different components that make up a trading partner, but without the full story, understanding all of the settings is difficult.
                          Read more ...

                          Connecting Cloud to On premises - A cloudburst session by sam vanhoutte

                          Monday, November 4, 2013
                          post by sam vanhoutte 

                          This post contains cloud burst session video
                          In new scenarios, in which cloud is getting used, integration becomes very important. The Windows Azure platform provides a lot of different capabilities and services to make a secure link between your local systems and the Windows Azure services or machines. During this session, you will discover what the different technologies are and in what these are best applicable. You will learn more about the following technologies:
                          • Connectivity on messaging level: Service Bus Messaging
                          • Connectivity on service level: Service Bus Relay
                          • Connectivity on data level: SQL Data Sync 
                          • Connectivity on network level: Windows Azure Virtual Networking 
                          • Connectivity on security level: Active Directory integration

                          Read more ...

                          Publish WCF Service Endpoint to Azure Service Bus Relay | BizTalk 2013 / 2010

                          Monday, July 22, 2013
                          This post will focus on a feature that is technically present in BizTalk Server 2010, but was not installed by default. This feature was a subtle enhancement to the BizTalk WCF Service Publishing Wizard – namely the ability to publish a Windows Azure Service Bus Relay Endpoint without leaving the wizard (and also without using one of the new adapters that has Relay in its title).
                          Even if you didn’t know that this feature existed, you will find it the first time that you attempt to publish any BizTalk artifact (schema/orchestration) as a WCF service in BizTalk Server 2013. It takes the form of the following screen within the BizTalk WCF Service Publishing Wizard, which appears immediately after choosing to publish a service (rather than simply a metadata description):
                          If you check this box and proceed through the wizard (regardless of adapter selected on the first screen), you will see the following screen at the end of the typical wizard:
                          The wizard assumes that you have already gone to the Windows Azure Management Portal and created a Service Bus namespace (effectively reserving yourself a sub-domain of servicebus.windows.net, and setting up an access control namespace for claims resolution and authorization purposes). If you’ve never done that before, it can be done through the New menu as shown below:
                          The next page of the wizard will require information necessary for BizTalk to authenticate with Windows Azure and prove that it is indeed the destination endpoint for the relay. This information is also obtainable only from the Windows Azure Management Portal. In order to access this information, you will need to click on your newly created namespace in the list of Service Bus namespaces, and then click theConnection Information button at the bottom of the page:
                          This will bring up the following listing, of which you really only need to worry about theDefault Issuer (Issuer Name in the wizard), and Default Key (Issuer Key in the wizard):
                          Once you gather this information, you’re ready to have a copy/paste party and fill out the last page of the wizard (unless you really want to live life in hard mode, don’t enable client authentication for metadata exchange – if you feel the need to do that, you may as well pass around the raw WSDL to whomever needs it and just forget about a MEX endpoint):
                          Once you’re up to this point, you can sprint to the finish by clicking NextCreate(after reviewing the wonderful WSDL and making sure it’s something that you can be proud of), and then finally Finish.

                          TACKLING COMMON ISSUES

                          Outside of the typical issues one might encounter hosting a WCF Service in a BizTalk Isolated Host (e.g., App Pool Identity needs permissions to Message Box database, correct .NET Framework version needs to be selected for App Pool, Receive Location must be started), you may also encounter a new one:
                          Again, for those using Google-fu in attempt to resolve an error, the error message reads:
                          Invalid element in configuration. The extension name ‘transportClientEndpointBehavior’ is not registered in the collection at system.serviceModel/extensions/behaviorExtensions
                          And it’s highlighting the portion of the configuration file that includes the key for Service Bus authentication.
                          Before getting right to the resolution, let’s recap what we’re looking at. Going through the wizard, I had selected to host a WCF-WSHttp endpoint internally in a BizTalk Isolated Host (i.e., running in an IIS App Pool rather than a BizTalk Host Instance process). I then indicated that I wanted to also expose the service through a NetTcp relay endpoint hosted externally (on Windows Azure).
                          My local IIS instance has been provided all the configuration information that it needs to coordinate with Windows Azure and make the relay live, but it currently doesn’t know what to do with it – which is why I have the error, and why my relay won’t be alive yet.
                          In reality, this all could have been avoided by reading. Specifically reading the last page of the BizTalk WCF Service Publishing Wizard, which should tell you that you need to install the AppFabric 1.0 SDK before any of the relays will work. Again, this is functionality that was technically available in the previous generation, hence the older SDK version number.

                          HOW TO KNOW THAT IT’S WORKING

                          If you have made it this far successfully, hitting the local service endpoint should give you a page that looks something like this:
                          If you go to the Windows Azure Management Portal and dig into the namespace you created, you should see something like this:

                          IT’S NOT REAL UNTIL I CAN CONSUME IT

                          If you’re anything like me, this is an unsatisfactory ending point – the service doesn’t really exist until I can consume it from some client. To make it as fair as possible, I am hosting the service inside a fairly locked down Windows Azure Virtual Machine, and I will be consuming it from my laptop connected ultimately via a microwave connection somewhere in the shadow of Mt. Pilchuk.
                          To consume this beast, we need to know our namespace (e.g., unique-name.servicebus.windows.net), and the mex endpoint exposed via relay (seen in the screenshot above). From there I can construct the address I would use in the Add Service Reference dialog in Visual Studio. In this case, that URL will be:https://unique-name.servicebus.windows.net/GetItemServiceDescription/GetItemService.svc_mex
                          Upon consuming the service, you may notice that the WSDL importer chokes hard on the WSDL it’s finding. It tries to build up a custom binding to make the call, and it’s finding that it doesn’t really know anything about some of the binding elements required:
                          Again for those searching for this specific error, the message reads:
                          WsdlImporter encountered unrecognized policy assertions in ServiceDescription ‘YOUR NAMESPACE HERE’
                          In reality, we don’t need to build a custom binding to make this all happen. Instead, we can use the netTcpRelayBinding to make the connection. An easy way to make that happen is to install the Windows Azure Service Bus NuGet package to our project. We can start out by using the Manage NuGet Packages context menu item in Solution Explorer:
                          Then search for the Windows Azure Service Bus package, and click the Installbutton:
                          This should update the App.config file of your application to include the following WCF extensions:
                          From there, you will want to update your endpoint to reference thenetTcpRelayBinding (instead of the custom binding that the WSDL importer failed to generate properly):
                              behaviorConfiguration="sharedSecretClientCredentials" binding="netTcpRelayBinding"
                              contract="RelayedItemService.ItemService" name="RelayEndpoint" />
                          You will also notice above that we have assigned a behaviorConfiguration — one that currently does not yet exist. So next, we will need to add an endpoint behavior (inside the system.serviceModel section of the App.config) to perform client authentication (if you don’t want to re-use the same credentials as before, make that visit over to the ACS Management Portal that the Connection Information page is begging you to do):
                              <behavior name="sharedSecretClientCredentials">
                                    <sharedSecret issuerName="owner" issuerSecret="YOUR SHARED SECRET VALUE HERE" />
                          This is something that has changed more recently. In fact, I couldn’t find a single place documenting what this behavior should actually look like right now. Hopefully that will change.

                          INVOKING THE SERVICE

                          Once we get through all the configuration craziness, we’re ready to make quick work of calling the service with two lines of code (backed by a billion lines of configuration):
                          YourServiceDotNetNamespace.YourServiceClient client = new YourServiceDotNetNamespace.YourServiceClient("RelayEndpoint");
                          client.GetItem(new YourServiceRequest() { Id = "test" });
                          That’s all it takes.

                          Read more ...