Partilhar via

Step 3: Create Agreements Between Partner Profiles

  • Artigo

 

Important

Microsoft Azure BizTalk Services (MABS) is being retired, and replaced with Azure Logic Apps. If you currently use MABS, then Move from BizTalk Services to Logic Appsprovides some guidance on moving your integration solutions to Logic Apps.

If you're brand new to Logic Apps, then we suggest getting started here:

In this step, you create an agreement between the profiles of the two trading partners, Northwind and Contoso.

To specify the General Settings of an X12 agreement

  1. In the BizTalk Services Portal home page, click Agreements.

  2. On the Agreements page, click the X12 tab if you are not already on that tab. Then click Add.

  3. In the New Agreement page, enter the following details:

    Field

    Description

    Name

    Enter a name for the agreement. For this tutorial, specify the name as NorthwindContosoX12.

    Note

    This is a mandatory field. The name for the agreement must be unique.

    Description

    Enter notes or a description for the agreement.

    Hosted Partner

    Select the hosted partner for the agreement. A hosted partner is a partner managed by the service provider and the pipelines are deployed for that partner during agreement deployment. Typically partners managed by service provider are configured as a hosted partner while the enterprise partners are guest partners.

    For this tutorial, the hosted partner is Northwind. The default profile for Northwind is displayed in the Profile field.

    Guest Partner

    Select the partner for the agreement (who is not a hosted partner). For this tutorial, select Contoso. The default profile for Contoso is displayed in the Profile field.
    **Identities**

    Hosted Partner ID Qualifier

    Select an authenticating qualifier that provides unique business identities to the trading partners. For this tutorial, select ZZ-Mutually Defined.

    Value

    Enter US.

    Guest Partner ID Qualifier

    Select an authenticating qualifier that provides unique business identities to the trading partners. For this tutorial, select ZZ-Mutually Defined.

    Value

    Enter THEM.
    **Tracking**

    Track Send side message properties

    Check this to store the message properties when the EDI message is sent to the partner. Once stored, you can query this data by clicking Tracking on the BizTalk Services Portal home page.

    When enabled, you can also store the message body by checking Archive Send side message.

    Track Receive side message properties

    Check this to store the message properties when the EDI message is received from a partner. Once stored, you can query this data by clicking Tracking on the BizTalk Services Portal home page.

    When enabled, you can also store the message body by checking Archive Receive side message.

    1. Click Continue.

      Clicking Continue adds two new tabs, one for receive settings and the other for send settings. Each tab is for a one-way agreement between the two partners, one for receiving messages and the other for sending messages. The properties in the Receive Settings tab define how the EDI receive bridge is configured. This bridge receives incoming EDI messages that are sent to Northwind. Similarly, the properties in the Send Settings tab define how the EDI send bridge is configured. This bridge sends EDI messages from Northwind to its trading partners like Contoso.

    To specify the receive settings

    1. On the Transport page, set the Transport type to HTTP.

    2. On the Protocol page, specify the following values.

      1. Under Acknowledgements, select TA1 expected and 997 expected to receive acknowledgements from the partner receiving the message.

      2. Under the Schemas section, set the following properties.

        Version

        00401

        Transaction Type (ST1)

        840

        Sender Application (GS2)

        THEM

        Schema

        /X12_00401_840.xsd

        Note

        You do not need to explicitly upload the artifacts (schemas or transforms) to the BizTalk Services Portal. The EAIEDITutorial BizTalk Service project you created earlier already includes the artifacts. So, deploying the project also uploads the artifacts under the BizTalk Services subscription. Because you registered with the BizTalk Services Portal using the same BizTalk Services subscription, the artifacts are also available from the portal. You can view the schemas and transforms from the Resources tab of the BizTalk Services Portal.

    3. On the Transform page, click the plus sign to add a new row. From the drop-down, choose /X12_00401_840.xsd for Schemas and /EDI840ToSalesOrder.trfm for Transform file name.

    4. On the Route page, click Add to add a route destination.

      1. Set the Rule Name to SendToBridge.

      2. Under Route rule, select the Use advanced definitions option and specify the following expression in the text box:

        1=1

        This expression always resolves to true, which means that all the messages are routed to the bridge.

        Note

        Even if you do not select the Use advanced definitions option and do not provide any route rule, by default this option is selected and its value is set to 1=1. This means that the default behavior is to route all the messages to the route destination.

      3. Under Route action, click the plus sign to add a new row and set the following values:

        • Set Target Type to Http Header

        • Set Header Name to Content-Type

        • Set Value Type to Constant

        • Set Constant Value to application/xml

        Note

        This ensures that all the messages that are routed to the bridge include a content-type header with its value set to application/xml. Without this header, the bridge receiving the message treats it as a flat-file message and might result in validation errors.

      4. Under Route destination, set Transport type to Azure BizTalk Bridge and in the text box enter the entity name of the bridge on the message flow surface. For this tutorial, the entity name is the default name, which is XmlRequestReplyBridge1. Using this name the bridge deployment endpoint is built, which is https://mybiztalkservicename.biztalk.windows.net/default/XmlRequestReplyBridge1. With this configuration, all the messages processed by the agreement are routed to the XML Request-Reply Bridge bridge you deployed earlier.

        Click Save.

    5. On the Route page, Under Message Suspension Settings, specify an endpoint where any messages that fail processing are sent to. For example, you can set Transport type to Azure Service Bus, the route destination type to BasicHttpRelay, and then specify a relay endpoint with all the details where a failed message is routed to.

      Note

      This tutorial does not cover the scenario where a failed message is sent to the endpoint you specify in the Message Suspension Settings. However, for successful deployment of the agreement, you must provide a value for this property. You can enter a non-empty value.

    To specify the send settings

    1. On the Send Settings tab, leave the default values for Inbound URL, Transform, and Batching pages.

    2. On the Protocol page, under the Schemas section, specify the following properties.

      Version

      00401

      Transaction Type (ST1)

      840

      Schema

      /X12_00401_840.xsd

    3. On the Transport page, specify the endpoints where the response messages or acknowledgements received from the other partner will be sent to. You must specify an endpoint each for the messages that are processed successfully as well as the messages that get suspended due to a failure in processing.

      For receiving messages that were successfully processed, under Transport Settings specify the following values:

      • Set Transport type to Azure Service Bus.

      • Set the route destination type to BasicHttpRelay,

      • Specify the Service Bus namespace, issuer name, and issuer key for the relay endpoint.

      • Specify the relay endpoint as Success so that the entire URL endpoint is https://servicebus namespace.servicebus.windows.net/Success.

      For receiving messages that failed processing, under Message Suspension Settings specify the following values:

      • Set Transport type to Azure Service Bus.

      • Set the route destination type to BasicHttpRelay,

      • Specify the Service Bus namespace, issuer name, and issuer key for the relay endpoint.

      • Specify the relay endpoint as Failure so that the entire URL endpoint is https://servicebus namespace.servicebus.windows.net/Failure.

    4. Click Deploy to deploy the agreement. The agreement is now deployed at the URL that was displayed in the Transport page of the Receive Settings tab. Typically, the endpoint where the agreement is deployed resembles the following:

      https://mybiztalkservicename.biztalk.windows.net/default/Agreements/<AgreementID>/Receive

    See Also

    Create and Deploy the Trading Partner Agreement