Axway B2Bi Training

Basics
Message Processing Part 1
Message Processing part 1 – Overview
Items

Communication model vs agreement model

Basic processing of EDI messages

Services and Components

Introduction of UI

© 2017 Axway | CONFIDENTIAL 2

Module Objectives

• After completing this module you will have a conceptual understanding of the
message processing logic in B2Bi and you will be familiar with the various
terminology and objects being used to configure those message processing
flows.
• To complete this module, it is a prerequisite that you completed module 14 –
Message Exchange Part 1 – first

© 2017 Axway | CONFIDENTIAL 3

Communication model
vs
Agreement model

4
Communication model vs Agreement model
• As explained in the Product Introduction section, B2Bi provides two Message
Processing modes:
• “Limited” mode: Transport only
• B2Bi uses communication / transport related identifiers and configuration to recognize and route
the message
• “Standard” mode: Transport & Message processing
• B2Bi uses communication / transport and/or message related identifier and configuration to
recognize and process the message
Application / Partner
Communication

Integration / Translation

© 2017 Axway | CONFIDENTIAL 5

Limited versus Standard Processing
Pickup
• Limited mode – Communication only. Limited
Message Handler routing through Message Handler and Delivery
Metadata
Settings. Packaging instructions for delivery
matching
through Collaboration settings
Metadata
Profile

Service

Detection
Matching

Inbound
• Standard mode – Communication and message
Agreement
processing. Context and/or content based routing /
Document
Agreement
translation. Ability to use additional Integration
Engine hosted exchange types (SAP ALE, ..)
Service

Outbound
Agreement

Delivery Collaboration
Settings Settings

Delivery

© 2017 Axway | CONFIDENTIAL 6

Standard Message Processing
Pickup
• Metadata (context) based routing / processing
Message Handler
• Metadata Profiles
Metadata
matching
• Partner / Content based routing / processing
Metadata
Profile
• Agreements
Service

Detection
• Direct Integration
Matching

Inbound
• Services connected to pickups
Agreement

Document
Agreement

Service

Outbound
Agreement

Delivery Collaboration
Settings Settings

Delivery

© 2017 Axway | CONFIDENTIAL 7

Communication model vs Agreement model
• Transport only (Communication Model)
• Routing IDs
• Transport & Message processing (Agreement Model)
• Messaging IDs / Routing IDs
• Agreements

Application / Partner
Communication

Integration / Translation

© 2017 Axway | CONFIDENTIAL 8

Communication Model
B2Bi

Application / Partner
Communication

• The B2Bi communication processing node (known as the “trading engine”) performs all message
consumption and delivery including protocol and security packaging
• For trading partner exchanges (remotely, to/from secure partner connectors)
• For customer application integration exchanges (locally, to/from backend applications)
• Communication processing may include protocol or transport level acknowledgments

9
Communication Model
What is needed

Routing ID
• a unique identifier that the trading engine uses as the “to” and “from” address for e-commerce
messages exchanged over the Internet.
• Although a community or partner can have many routing IDs, the user interface designates one per
community or partner as the default.
• Default routing IDs are used by default for message protocol headers when packaging messages.

© 2017 Axway | CONFIDENTIAL 10

Communication Model
What is needed

Routing ID
• a unique identifier that the trading engine uses as the “to” and “from” address for e-commerce
messages exchanged over the Internet.
• Although a community or partner can have many routing IDs, the user interface designates one per
community or partner as the default.
• Default routing IDs are used by default for message protocol headers when packaging messages.

Trading Pickup and Delivery

• Trading pickups are located in community objects. A trading pickup specifies how you want the
community to pick up or receive documents over the Internet from a remote partner.
• Partner deliveries are located in partner objects. A partner delivery specifies how a community sends
documents to a remote partner.

© 2017 Axway | CONFIDENTIAL 11

Communication Model
What is needed

Application Pickup and Delivery

• An application pickup is a B2Bi object that specifies the way the product consumes messages and files
from back-end applications.
• An application delivery is a B2Bi object that specifies the way the product sends messages and files to
back-end application.
• There may be multiple application pickups and deliveries which are set up within the trading
configuration.

© 2017 Axway | CONFIDENTIAL 12

Communication Model
What is needed

Collaboration settings
• specifies how B2Bi packages the messages that a community sends to its partners. You can use default
collaboration settings which apply to all messages sent by all communities to all partners, or you can
customize collaboration settings at progressively more specific levels.

More details on the “Limited” processing mode can be found later on when we address Message Exchange

© 2017 Axway | CONFIDENTIAL 13

Agreement Model
Application / Partner
Communication

Integration / Translation
• The B2Bi message processing node (known as the “integration engine”) performs all content (payload)
based message processing
• Content based processing resolves the correct profile or agreement to process each business
document inside a received message and apply the correct configured mapping, enveloping and
delivery routing rules
• Partner agreement defined and format specific functional acknowledgements (X12/EDIFact) may be
generated (back to remote partners) or timers may be set (to wait for their response from partners)
14
“Standard Mode” configuration
• Partner initiated (inbound) scenario
1. Community definition
1
2. Partner definition
3. Pickup protocols
4. Delivery protocols
5. Message Processing Configuration

4 5 3 2

© 2017 Axway | CONFIDENTIAL 15

Configuration objects for “standard” processing
Company 1 Company 2 Who is involved in the incoming exchange?

Messaging ID 1 Messaging ID 2 What identities are they using?

Inbound Agreement(s) What document format is it?

Document Agreement(s) What document type?

Service Delivery Processing logic to be applied to this document

Component(s) Building blocks providing processing logic

Optional Enveloping required before sending to partner ?

Outbound Agreement(s)

Messaging ID X Messaging ID Y Who is involved in the outgoing exchange and

What identities are they using?
Company 1 Company 2

This diagram shows an overview of the various objects that maybe involved in the
configuration of a “standard” processing flow (including mapping) between 2 partners

© 2017 Axway | CONFIDENTIAL 16

Community / Partner Configuration
• To prepare a B2Bi for exchanging business messages including processing a
number of additional things need to be configured. One of these things is the
specification of the identities of communities and partner(s) as they relate to the
messages that will be exchanged. These identities are stored in an object known
as a Messaging ID.

© 2017 Axway | CONFIDENTIAL 17

Messaging IDs
What is a Messaging ID

• a child object of a community or a partner that identifies the community or partner as the sender or
receiver of a specific message standard.
• When a community or partner has a messaging ID, it can participate as a sender or receiver in a
message-trading agreement.
• If a community or partner needs to act as the sender or receiver of multiple formats, it must also have
multiple messaging IDs.
• To be able to trade messages of a given standard with other participants, each partner or community
must have at least one messaging ID for each message standard it wants to trade.
• A partner or community can have as many messaging IDs as required for the messages exchanged
(EDI, X12, IDoc, ...).

© 2017 Axway | CONFIDENTIAL 18

Messaging IDs
• X12 Message Structure

ISA*00*9922567822*ZZ*0012345600*ZZ*001111110001*ZZ*991111110001*100807*0946*U*00401*100000461*0*P*>
GS*PO*001111110001*0012345600*20100807*0946*200000461*X*004010
ST*850*300000461
...
… • Messaging IDs
SE*30*300000461
GE*1*200000461
• Sender Messaging ID
IEA*1*100000461 • Interchange ID Qualifier: 00
• Interchange ID: 9922567822
• Application ID: 001111110001
• Recipient Messaging ID
• Interchange ID Qualifier: ZZ
• Interchange ID: 0012345600
• Application ID: 0012345600

19
Community Messaging IDs

© 2017 Axway | CONFIDENTIAL 20

Partner Messaging IDs

© 2017 Axway | CONFIDENTIAL 21

Pickups – Standard Message Processing Mode
• For messages to be processed in “standard” mode (including message
processing), this mode must be selected in the advanced tab of pickup
definitions. Standard is the default for new defined pickups

© 2017 Axway | CONFIDENTIAL 22

Trading Pickup – Standard Message Processing Mode

X
In Standard mode, messages are affected
by the Message Processing
Configuration (in the Integration Engine)
in addition to the Message Handler. The
Delivery Settings are not evaluated –
although 1 default delivery setting must
be created

© 2017 Axway | CONFIDENTIAL 23

Application Pickup – Standard Message Processing Mode

In Standard mode, messages are affected

by the Message Processing
Configuration (in the Integration Engine)
in addition to the Message Handler and
the Collaboration Settings

© 2017 Axway | CONFIDENTIAL 24

Agreements
• In an agreement you define the parameters that need to match the incoming message
structure / envelope structure. When there is a match, the document will be processed
according the service definition that is connected this agreement.

• There are 3 Agreement types:

• Inbound Agreement – Defines the characteristics of an incoming exchange an at

partner / envelope level and captures the inbound handling

• Document Agreement – Defines the characteristics of an incoming exchange at a

document level. Document agreements are defined as a child object of an Inbound
agreement.

• Outbound Agreement - Defines the enveloping logic required for sending to a remote
partner.

© 2017 Axway | CONFIDENTIAL 25

Agreement Model
• To configure a “business” message to be running through the B2Bi system
following the Agreement Model, the following objects must be defined
Company 1 Company 2

• Partner / Community Messaging ID 1 Messaging ID 2

• Messaging ID Inbound Agreement(s)

• Inbound Agreement
Document Agreement(s)
• Document Agreement
Service
• Service
• Component Component(s) Delivery

• Outbound Agreement (optional)

Outbound Agreement

Messaging ID X Messaging ID Y

Company 1 Company 2

© 2017 Axway | CONFIDENTIAL 26

Agreements
• An Agreement is a B2Bi object that you use to specify how B2Bi processes the
information that is exchanged between two or more trading endpoints.
• B2Bi uses agreements at runtime to match the messages it handles to partners,
communities and processing services. An agreement defines one of two types of
trading exchanges.
• Agreements may define the endpoint participants of exchanges in several ways:
• Explicit sender/receiver relationship
• Implicit sender/receiver relationship
• Semi-anonymous partner
• Fully-anonymous sender and receiver relationship

© 2017 Axway | CONFIDENTIAL 27

Agreement types
• Specialized Agreement: Both the sender and Megastore Megastore

the recipient are fully defined – including the 9922567822:ZZ *

specific (only) message identity this agreement Supply4All

0012345600:ZZ
Supply4All
*

is valid for
EDIFACT / D01B – ORDERS EDIFACT / D01B – ORDERS

• Semi-specialized Agreement: Both the sender X12 / 5010 - 850 X12 / 5010 - 850

and the recipient are defined, but for one or both

Specialized Semi-specialized
the specific message identity this agreement is
agreement agreement
valid for is set to <ANY>
• Semi-anonymous Agreement – Either the
sender or the recipient of the agreement is set *
*
*
*
to be any of the defined entities in the system Supply4All *
0012345600:ZZ *
• Anonymous Agreement – Both the sender and
the recipient of the agreement are set to be any EDIFACT / D01B – ORDERS
X12 / 5010 - 850
EDIFACT / D01B – ORDERS
X12 / 5010 - 850

of the defined entities in the system

Semi-anonymous
Anonymous agreement
agreement

28
Document Agreements
• A document agreement is a B2Bi object that you use to specify how a document
type (within a messaging standard and standard version) is to be handled in an
inbound agreement between exchange participants.

• A document agreement specifies:

• A document standards version with the standard already defined for the
Agreement
• Document type within the specified standard and version
• Service, to specify how the document is processed for this agreement

• You can associate multiple document agreements with a single inbound

Agreement. In this case, each document agreement specifies the handling for a
different document type under a single standard.
© 2017 Axway | CONFIDENTIAL 29
Services and Components

30
Service

A service is a B2Bi object that you use to specify the

processing sequence for handling a message exchanged
between two or more partners. In the current version of
B2Bi there are two types of services:

• Metadata services – used in the context of metadata

profiles
• Partner services – used in the context of agreements

A service contains one or more components.

© 2017 Axway | CONFIDENTIAL 31

 Service

Service - Partner EDIFACT D01B ORDERS

Document
Document Document
Format Version Type
Document Format Inbound
Post Detection
Agreement
EDIFACT
Mapping

Messaging ID Sender Messaging ID Receiver Output Output Output Output Output

001111110001:ZZ 9911111110001:ZZ

Document Agreement
Possible
D01B Document Version components
Service Mapping
ORDERS Document Type Component
Document
(Enveloping)
Post Enveloping

Post Transfer
Success

Post Transfer
Failed

32
 Service

Service - Partner EDIFACT D01B ORDERS

Document
Document Document
Format Version Type
Each output has its own delivery.
Post Detection
Delivery Methods
Mapping
• Deliver to resolved Partner – this services ended with a delivery to a resolved
Output Output Output Output Output
partner
• Deliver to Application – this services ended with a delivery to back-end
application
• Synchronously return output to originating party – this service ended with a
synchronous reply on in the incoming request

Application
Delivery
(A)
Delivery
Service
Partner
Partner
Delivery
(P)

33
Service - UI
Step to be executed before
map (right after detection).
This step can only have 1
output as result
Mapping Step – This is the
only component which can
have more than 1 output.
Each output will drive a new
output tab further down on
this page

Output(s) of the Map

component

Document Components –
one or more post-map
steps – configured per
output

Delivery option – per output.

© 2017 Axway | CONFIDENTIAL 34

Components
Components provide specific types of processing to a
message handling flow.

A component associates a resource (piece of message-

processing code residing on the integration engine) with a set
of specific parameters and message formats.

The processing can then be used in one or more service

objects to specify how a specific message type is handled
between two or more exchange endpoints.

© 2017 Axway | CONFIDENTIAL 35

Components - Resources
Resources are small installable programs that extend the standard set of message handling processes
provided by B2Bi.

Resources can be classified in the following categories:

• Message Builder Component (MBC) resources, built using the Axway-proprietary Message Builder
language
• XSLT component resources for wrapping, transforming and validating the structure of XML files
• Map flows built using Mapping Services
• Datamapper Maps built using Mapping Services
• Maps built using the Axway Business Object Modeler (JTransform and TF-XSLT)

Resources are available as add-ons and must be manually copied to an appropriate directory on the
integration engine. Resources must also be registered on the integration engine before they can be
browsed in Component creation.

© 2017 Axway | CONFIDENTIAL 36

 Service

Components - Mapping EDIFACT D01B ORDERS

Document
Document Document
Format Version Type

A Mapping Component performs message transformation, data Post Detection

mining, routing based on message body, header or metadata content. Mapping
A mapping component could have multiple outputs.
Output Output Output Output Output

Using Mapping Services

• DML Map flows
• Datamapper Maps

Mapping Services is a map development environment in which you

create and test mapping flows. After you create a flow in the map
development environment, you send it a B2Bi runtime environment.
It comprises:
• Mapping Services – A map definition application for creating, Delivery
simulating and deploying maps to runtime instances of B2Bi.
• DML Map Engine – The component responsible for simulating in-
process data maps to transform various documents

© 2017 Axway | CONFIDENTIAL 37

Components - Mapping
To use B2Bi maps (embedded in "flows") that you create or edit in Mapping Services, you deploy the flows
to a B2Bi server. There are two methods for deploying a flow:

• Deploy the flow directly from Mapping Services to a runtime server using UI commands
• Export a flow to a container, and then deploy the container using a command line

The resource appears in the Mapping Services user interface on the Runtime Repository Server tab,
listed under the server name.

The resource is available in the B2Bi user interface for use in message-processing definitions. When you
add components you can view lists of available resources.

© 2017 Axway | CONFIDENTIAL 38

Message monitoring

39
 Trading Engine
Message Tracker Message Tracker

Integration
Engine

© 2017 Axway | CONFIDENTIAL 40

 Trading Engine
Message Log Message Tracker

Use Message Log to view detailed integration engine message-processing related Message Log
information, such transfer status, synchpoints, etc. Integration
Engine
Message Log is for detailed message-processing information. The final processing
status can always be found in the Message Tracker. To view logs of system-related
errors on the integration engine, use the Trace Viewer.

Each message is associated with a unique LogId. A message going through the
integration engine may change its shape (mapping, splitting, enveloping). For each new
form of the message a new LogId is obtained.

© 2017 Axway | CONFIDENTIAL 41

 Trading Engine
Message Log Message Tracker

When you look at the Message Log, Hierarchical view, it is possible to see the Message Log
complete chain of LogIds and log events and how each LogId is related to its child- Integration
LogIds and/or parent-LogIds. Engine

Normal message-related errors are logged in the Message Log. For example:
• Parsing failures
• Classification failures (no matching criteria)
• Send failures
• Retrieve failed polling (ftp server down, or directory missing, POP server down

© 2017 Axway | CONFIDENTIAL 42

 Trading Engine
Message Log Message Tracker

Message Log
Integration
Searches Engine
- Default
- Customized

First Entry

Log Entries

Log Events
Selected Entry

© 2017 Axway | CONFIDENTIAL 43

 End of
Message Processing Part 1
module