Database Reference
In-Depth Information
Task
Northbound
Southbound
In general, a southbound controller will never act as
an ABO message receiver.
We must bear in mind that a message could come in the form of a con-
tainer with a Message Header object already in place. Although it sim-
plifies the message recognition, we should be careful when putting this
message into a universal container for Agnostic Composition Control-
ler. Service Facade should be implemented to remove nested headers.
From the SCA business flow, we will receive EBM
with all elements in place, but an execution plan will
most probably contain only one task, as SCA will
implement its own master Composition Controller.
Receive
If Message Header is in place, the universal MsgID will be used for
identification. Otherwise, we can use the name of the message root
element. In this case, the trading partner agreement will guarantee that
every ABO will have its own unique root element.
Message iden-
tification
Only the MessageHeader element MsgID is
needed.
If none of that is possible, the Adapter framework must be employed
for message header construction. Application Business Connector
Service ( ABCS ) will be entirely responsible for conversion of ABO
into EBM.
This is the next logical step after message identification. It can be done
by MsgID , senderID , and events name; all of them are the parts of
Standard Business Document Header ( SBDH ). The result of this
operation could be the extraction of an execution plan, but that will be
necessary if EP is not provided in the message container by the ABCS
framework.
Business Pro-
cess Recogni-
tion
In this part of the framework, we only consume an
execution plan provided in the previous steps.
Alternatively, we can delegate the extraction of an execution plan to
the asynchronous Service Broker in SCA. However, if we are really
looking for good performance (and reliability too) of synchronous ser-
vices, we should avoid calling the SCA level excessively. Mes-
sageHeader elements will clearly indicate the process Message Ex-
change Pattern ( MEP ).
Without ABCS, this function shall be performed on the northbound
ESB part. This functionality is standard in the Message Processing
palette.
We should perform message validation on a re-
sponse action pipe.
Validate
Filtering is based on identification of a certain XPath in the message
body and has a purpose to suppress unwanted requests. This must be
configurable in the Request Action pipe.
Similar to northbound, the edge should be configur-
able for the response action pipe.
Filter
Enrichment means service callout, which requests
additional data. Thus, its regular invocation of dy-
namic endpoint, when the endpoint URL is extrac-
ted from the EP in Agnostic Composition Control-
ler, shall be configurable with a bypass option.
This is not applicable for northbound. Enrichment is usually done on
the adapter level. Inbound messages could be transformed, though.
Enrich
The most common task on the southbound side of
SB. The URL to XSLT or XQuery resources shall be
provided in an inbound EP. For better isolation, it
could be realized by the implementation of the
This operation is not really common on the northbound side, but could
be possible if the URL to XSLT or XQuery resources will be provided
in the inbound EP.
Transformation
Search WWH ::




Custom Search