Changes in data model from B2Bi 1.x to 2.x

If you have migrated a B2Bi installation from 1.x to 2.x, the first time you log on to the user interface you will notice a significant set of changes in the way B2Bi exchanges are configured.

In the B2Bi 2.x UI, you can see Communities, Partners and many of the other objects that are available in B2Bi 1.x. However in B2Bi 2.x, certain objects have disappeared, others have been added, and the overall logic of how you configure flows has been re-engineered to enable a more supple way to handle the flow of messages between multiple endpoints of different types.

Many things have changed between B2Bi 1.x and 2.x. If you were familiar with how to configure exchanges between back-end application and trading partner endpoints in 1.x, probably the most significant changes that you will notice in 2.x are the following:

  • The message flows that you configured between a Community and a Partner through Messaging Profiles in B2Bi 1.x, are now configured between a community and partner through Agreements.
  • B2Bi 1.x Community Messaging Profile Routing IDs have been converted to Community Messaging IDs.
  • B2Bi 1.x Partner Messaging Profiles have been converted to Partner Messaging IDs and Agreements.
  • B2Bi 1.x Document Profiles have been converted to document Agreements in 2.x.
  • B2Bi 1.x Document Services have been renamed "Services" in 2.x.
  • B2Bi 1.x Processing Steps have been renamed to Components in 2.x.
  • B2Bi 1.x Processing Connections have been renamed to Connections in 2.x

The information that you stored in 1.x Messaging Profiles and 1.x Document Profiles is now stored in the new 2.x objects:

  • Agreements (Inbound / Outbound)
  • Document Agreements
  • Partner and Community Messaging IDs

This topic describes some of the important changes in the 2.x object model, and directs you to where to locate the configuration fields that you used in B2Bi 1.x.

Learning about the B2Bi 2.x UI data model

For a general presentation of how B2Bi 2.x consumes, processes and delivers messages between exchange endpoints, see the B2Bi Administrator Guide chapter "How B2Bi handles message exchanges".

For a general description of how to use B2Bi 2.x to organize and automate the flow of electronic documents between endpoints located both inside and outside your enterprise network, see the B2Bi Administrator Guide chapter "Organizing your B2Bi exchanges".

For a list of the objects that you can configure in the B2Bi 2.x interface, and for links to detailed descriptions of how to work with these objects, see the B2Bi Administrator Guide chapter "Objects and features for configuring message exchanges".

How B2Bi 1.x objects have changed

The following table summarizes the evolution of the B2Bi object structure for configuring message flows between endpoints.

Object B2Bi 1.x B2Bi 2.x
Community
  • Represents your local way of grouping trading partners.
  • Represents a partner on the business document exchange level.
  • Defines how your organization expects to receive messages from, and send messages to, back-end applications and remote partner exchange points.
  • Has a Messaging Profile Routing ID
  • Represents your local way of grouping trading partners.
  • Does not represent a partner on the business document exchange level.
  • Defines your organization’s internal processes for handling messages.
  • Defines how your organization expects to receive messages from, and send messages to, back-end applications and remote partner exchange points.
  • Has a Routing ID
  • Can have one or more valid Messaging IDs
Partner
  • Specifies the characteristics of the remote trading partner in an exchange.
  • Can exist without being associated with a community, however a Partner must belong to a Community for trading to occur.

  • Has to have a trading delivery.
  • Represents a local or remote partner in an Agreement.
  • Can be a sender or receiver.
  • Can exist without being associated with a community, however a Partners must belong to a Community for trading to occur.
  • Has to have at least one valid Messaging ID
  • Does not have to have a trading delivery
Community Messaging Profile Routing ID Specifies identifiers for the Community when exchanging messages with Partners. Not in this version.

See 2.x Partner and Community Messaging IDs.

 

Partner Messaging Profile

Specifies processing:

  • Messaging standard/version
  • Inbound handling
  • Enveloping
  • Document mapping
  • Transformation

Not in this version.

See 2.x Agreement.

Agreement Not in this version.

Specifies how B2Bi processes the information that is exchanged between two or more endpoints.

Each agreement is based on a standards-based type of processing for X12, EDIFACT, etc.,

Exists in two types, inbound and outbound:

  • Inbound Agreements specify inbound handling.
  • Outbound Agreements specify enveloping.
  • Inbound Agreements include Document Agreements.
Document Agreement

Not in this version.

See 1.x Document Profile.

Defined within the context of an Inbound agreement.

Specifies how a document type (within a messaging standard and with a specific version) is handled in an inbound agreement.

Document Service Used within the context of a Document Profile or Metadata Profile to execute sequences of processing steps

Not in this version.

See 2.x Service.

Service Not in this version.

See 1.x Document Service

Specifies the processing sequence for handling a message exchanged between two or more endpoints. In 2.x there are two types of services:

  • Metadata services – for metadata profiles
  • Partner services – for agreements
Document Profile In a Messaging Profile, specifies how each document type is processed.

Not in this version.

See 2.x Document Agreement.

Partner and Community Messaging IDs

Not in this version.

See 1.x Messaging Profile

Every Partner must have at least one Messaging ID in order to be able to trade messages with other partners.

Communities may also have Messaging IDs to act as trading endpoints.

The Messaging ID specifies a standard that the Partner or Community can use for trading (X12, EDIFACT, VDA, ...).

Processing Step Building block for a Document Service. Various processing step types can be identified.

Not in this version.

See 2.x Component.

Component Not in this version.

See 1.x Messaging Profile

Building block for a Service. Various component types can be identified.

Example configuration migration

The following sections provide an example of a B2Bi message-flow configuration that is migrated from a B2Bi 1.x environment to a B2Bi 2.x environment. This example flow is configured to:

  1. Consume an EDIFACT D96A ORDERS document (coming from partner A, for partner B).
  2. Transform the document format to XML (EBM XML D96A).
  3. Envelop the transformed document.
  4. Send to a destination.

B2Bi 1.x object configuration

In B2Bi 1.x, the flow that we want to migrate requires the following object configuration:

  • Sharable objects attached to the Community:
    • Application delivery
    • Application pickup
  • Community (representing Partner B):
    • Community Pickup
    • Routing ID
    • Messaging Profile Routing ID
    • Trading Partner Pickup/Delivery
    • Document Service
  • Partner (the sender, Partner A):
    • Delivery Exchange
    • Messaging Profile for consumed format (EDIFACT D96A)
    • Document Profile within the EDIFACT Messaging Profile (ORDERS)
    • Messaging Profile for delivered format (EBM XML D96A)
    • Membership in the Community

Example B2Bi 1.5 object configuration before migration to 2.x.

B2Bi 2.x object configuration

In B2Bi 2.x the migrated configuration for the flow requires the following object configuration:

  • Community
    • Messaging IDs (EDIFACT and XML)
    • Trading Pickup
  • Partner (sender or receiver)
    • Messaging IDs (EDIFACT and XML)
    • Partner Delivery
  • B2Bi objects
    • Agreement
      • Inbound EDIFACT
        • Document ORDERS D96A
      • Outbound (EBMXL)
    • Service
    • Component (Map - converts from EDIFACT to XML)

Example configuration of  B2Bi 2.x objects after to 1.x.

Migration procedure: 1.x to 2.x (automatically applied as part of the upgrade)

  1. Convert the 1.x Community Messaging Profile Routing IDs to 2.x Community Messaging IDs.
  2. Convert the 1.x Partner Messaging Profiles (for both EDIFACT and XML) to 2.x Partner Messaging IDs, and the following agreements:
    • Inbound: Partner-to-ANY EDIFACT Inbound Agreement and Partner_A-to-ANY XML Inbound Agreement.
    • Outbound: ANY-to-Partner EDIFACT Outbound and ANY-to-Partner XML Outbound (configuring the outbound and envelope tabs).
  3. If ACK generation has been turned on, add a link to:
    • ANY-to- Partner EDIFACT agreement Outbound (to envelope the outgoing acknowledgement)
  4. If any 1.x output references another Messaging Profile for enveloping, for 2.x create a reference to the converted 2.x outbound Agreement for that Messaging Profile.

Related Links