Partilhar via

How do bridges resolve agreements at runtime?

  • 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:

How bridges resolve to agreements at runtime.

How do bridges resolve to agreements?

Agreement type

How the resolution happens

Any user input required?

EDI receive agreement (X12 and EDIFACT)

The identities (ISA for X12 and UNB for EDIFACT) in the received message are matched with the identities specified in an agreement. If a match happens, that agreement is used for message processing. If the match fails, the message is suspended.

The EDI message sent to the bridge must include the identities (ISA and UNB). The bridge promotes the identity values, which are used for agreement resolution.

EDI send agreement (X12 and EDIFACT)

The resolution happens in the following order:

  1. Agreement ID

  2. Combination of agreement name and partners

  3. The identities in the agreement

The EDI message sent to the bridge must include one of the following as part of the header:

  • “AgreementID”

  • “AgreementName”, “HostPartner”, and “GuestPartner”

  • “SenderIdentifier”, “SenderQualifier”, “ReceiverIdentifier”, and “ReceiverQualifier”

The bridge promotes these values; which are used for agreement resolution.

  • If an incorrect agreement ID is included in the message header and subsequently promoted by the bridge, the agreement resolution fails and the message is suspended.

  • If agreement and partner names are present in the header, they are promoted by the bridge. If the agreement resolution fails because of incorrect agreement and partner names, the message is suspended.

  • If the identities are preset in the header, they are promoted and used for message resolution.

If none of the above values are promoted, agreement resolution fails and the message is suspended.

Note

For bridges that were deployed before the August update, if none of the properties are present as part of the header, the messages will be processed with the agreement with which they were deployed before the August update. However, if the old bridges are redeployed after the August update, the message sent to the bridges must include the properties in the header, or else the message is suspended.

AS2 receive

The resolution happens based on the AS2-To and AS2-From values specified in the agreement.

“AS2-To”, “AS2-From”, and “AS2-MessageID” values must be included as per the standard AS2 protocol. The bridge promotes these values, which are then used to match with the values specified in an AS2 agreement.

AS2 send

The resolution happens based on the AS2-To and AS2-From values specified in the agreement.

“AS2-To” and “AS2-From” must be included in the message header.

The bridge promotes these values, which are then used to match with the values specified in an AS2 agreement.

What happens to agreements created before the August’ 14 refresh?

As part of the August ’14 refresh of Microsoft Azure BizTalk Services, agreement created in BizTalk Services Portal, and the underlying bridges are decoupled. The following table provides information on how this impacts the existing agreements in the BizTalk Services Portal.

Before August’ 14 refresh

After August’ 14 refresh

Agreement

  • Agreement exists in the BizTalk Services Portal with a name and an ID.

  • Agreements have two bridges underneath; one for send and another for receive, dedicated to the agreement.

  • Agreement configuration includes identities, protocol, batch, transform, and transport/route settings.

  • Agreement exists in the BizTalk Services Portal with a name and an ID.

  • Agreement configuration includes identities, protocol, and batch settings.

Bridge

  • Underlying bridges are listed in the Bridges tab of the BizTalk Services Portal.

  • The bridge view is just a listing. You cannot click on a bridge to edit its configuration.

  • The EDI bridges cannot be deleted from the BizTalk Services Portal.

  • The bridges that were earlier associated with an agreement are now listed with their uniquely identifiable URLs. The bridges do not have a name.

  • You can click on a bridge to edit its configuration properties. bridges are still listed as send and receive side, each denoting a separate bridge.

  • EDI bridges can be deleted from the BizTalk Services Portal.

Schemas

Schemas are included as part of agreement configuration.

Schemas continue to be included as part of agreement configuration.

Transforms

Transforms are included as part of agreement configuration

Transform are included as part of bridge configuration.

Tracking and archiving

Tracking and archiving is part of agreement configuration

Tracking and archiving is part of bridge configuration.

Route acks as flat file

The configuration option is included as part of agreement configuration

The configuration option is included as part of bridge configuration.

Community Additions

Creating EDI Bridges in MABS (post August 2014 Update)

Using AS2 Bridges in MABS (post August 2014 Update)

See Also

EDI, AS2, and EDIFACT Messaging (Business to Business)