RE: [ebxml-dev] ebXML wrap over Business Protocol(X12, EDIFACT etcc)

["Dale Moberg" <dmoberg@cyclonecommerce.com>]

Some comments in-line. Thanks for sending in this problem. I am also
copying some OASIS TCs for their possible consideration.

Some comments pertain to BPSS, others to CPPA, and others to ebMS.
Overall the questions point out that batching payloads is a somewhat
underspecified area in ebXML and raises the question whether we want to
try to provide more explicit support for this kind of complexity or let
other people go there at their own risk!

Dale Moberg

-----Original Message-----
From: samba pedapalli [mailto:sambas@gmail.com] 
Sent: Wednesday, January 12, 2005 5:09 PM
To: ebxml-dev@lists.ebxml.org
Subject: [ebxml-dev] ebXML wrap over Business Protocol(X12, EDIFACT
etcc)

Hi everyone,

While brain storming on how ebXML would carry multiple payloads of
business protocol(the name I use for protocols defining business data
such as X12, EDIFACT, CIDX etc), I ran into a scenario where was
wondering how reliable messaging could be accomplished for both, the
ebXML and the Business Protocol.

DaleMoberg> "Reliable messaging" really pertains to the ebMS transfer of
data and only deals with resending the exact same message (with its
Message-Id value unchanged) until it gets acknowledged or until a
timeout occurs.




UseCase:
ebXML message has 3 payloads which are X12 ISA batches and ebXML as
well as each ISA expect an Ack back.

Scenario:
 - The ebXML receives its Ack back and hence the ebXML loop is complete.
 - One ISA batch receives its Ack and hence the loop for this is
complete.

DaleMoberg> Is this a "997" (the functional acknowledgement) or
something else.


 - The other two ISA batch donot receive an Ack(lets assume the time
out takes place). 

DaleMoberg> Same question I guess. If it occurs at the business layer of
handshaking (that is the 997 layer), then it is a business application
problem to do the right thing. New messages would then be sent with new
message-IDs to get the data exchanged.



So how do we react to such a scenario where we need
to send only two payloads while Action has 3 MIME parts configured.

DaleMoberg>> Hmmh. We normally think of ebXML messages with one payload
and maybe a bunch of attachments related to that one business unit of
work.
If you are really bundling up separate business units of work in one
message, you need to think of this as yet another new business unit of
work for that composite I suppose. This is because old-style batching
was not part of ebXML requirements. 

The available options I could think of were:

1. Recognize the two ISA batch which need to be resent, wait for the
next ISA batch, package the three for the same Action. - But how long
are you going to wait for the third ISA batch???


DaleMoberg>> If you stuck to the existing way that ebXML works (and you
were using ebMS plus the supporting CPPA and BPSS components), you could
think of the 3 part Action as Action1, and the possible 2 part Actions
(3 types of them) as distinct actions. Then a failure on Action1 could
be specified as leading to a transition in your business process to a
new Action that had one of those 2 part Actions, call it Action2. (You
would only see the MIME parts as aspects of the CPPA binding, probably
but the logical distinctions could be documented in BPSS it seems to
me). The trick would be in knowing that the failure worked the right
way. You would need to have a ReceiptException signal indicate the type
of failure you encountered using the current BPSS 2.0 state
synchronization semantics. I am going to send a copy of this message to
the OASIS BPSS group so the signal experts and synchronization gurus can
consider whether we have enough apparatus available for this use case.
It would definitely be near the corner, if not definitely in the corner
case area.


2. Have an Action configured to carry 2 payloads - At this rate when
you have 10 payloads to be carried how many can you configure???

DaleMoberg>> It would get wordy to specify all these combinations. Maybe
that is why we lean toward full support for non-batching scenarios and
are sketchy for batching...

3. Resend all the initial set of 3 payloads again - in which case you
are creating a duplicate at X12 level.

DaleMoberg>> Right, X12 users often check transaction IDs even if
message duplication elimination is in force. 

I am not sure what would be the right way of ensuring reliable delivery.


DaleMoberg>> I don't think ebMS would handle this in terms of RM, which
is for the message as a whole (with its unique Message-ID). It would
have to happen up the stack somewhere as part of business or application
logic.


My understanding is ebXML action is too tied to the no of MIME parts
it carries. 

DaleMoberg> I believe the CPPA can be configured to allow repetition of
variable numbers as part of the MIME packaging. In that way, variable
number of MIME bodyparts can be assembled in the same
Service/Action/Role combination. But that won't help you recover from
your exception. 

Can this be configured to say some payloads can be
optional in which case the above scenario can be satisfied using the
same Action name.

Samba Pedapalli