Yes, I see what you are getting at, and in this specific scenario it makes
sense.
Possibly there is something here that might also help with the roll back
rat
holes
related to business ack signals. Need some more thinking.
Regardless, gist of this thread should go into possibly BPS documentation
as
implementation
recommendations.
Thanks for the detailed response, Dick.
Regards,
-Suresh
Sterling Commerce (on loan to RosettaNet)
469 524 2676 (O), 469 323 0234 (Cell)
-----Original Message-----
From: Dick Brooks [mailto:dick@tech-comm.com]
Sent: Thursday, October 23, 2003 3:16 PM
To: Damodaran, Suresh; 'Duane Nickull'; Anthony Ellis
Cc: ebxml-dev@lists.ebxml.org
Subject: RE: [ebxml-dev] MSH vs BSI acknowledgement messages
Suresh,
I agree, it would be superfluous to send a Functional
Acknowledgement if a
business level acknowledgement will be returned immediately. The scenarios
where I've seen the FA used have a non-deterministic response time for
business level response messages. In these cases the FA serves as a
"checkpoint" acknowledgement. Here is an example time sequence showing
the
3 acknowledgements mentioned earlier:
t0___t1_t2_______t3____________________t4
where:
t0=time sender initiates transfer
t1=time first octet received
t2=Delivery Acknowledgement sent
t3=Functional Acknowledgement sent (validation results)
t4=Business Level Response Message sent
In this example the delta between t2 and t3 is influenced by the amount of
data being processed (e.g. a complex XML document of 75MB could take
several
minutes to process). The delta between t3 and t4 is again influenced by
the
amount of data being processed and complexity of processing with backend
applications.
Also noteworthy is the fact that the Functional Acknowledgement at t3 is
sent on a separate session from that used at t0.
The same is true for a Business Level Response Message.
Hope this make the scenario where FA's are used a bit clearer.
Regards,
Dick Brooks
B2B Integration and Cyber Security Consultant
http://www.tech-comm.com/dbc
Mobile:602-684-1484
eFax:240-352-0714
-----Original Message-----
From: Damodaran, Suresh [mailto:Suresh_Damodaran@stercomm.com]
Sent: Thursday, October 23, 2003 1:32 PM
To: 'Dick Brooks'; 'Duane Nickull'; Anthony Ellis
Cc: ebxml-dev@lists.ebxml.org
Subject: RE: [ebxml-dev] MSH vs BSI acknowledgement messages
Interesting, Dick!
I wonder about the business justification for using an extra business
signal.
Non-repudiation is already covered by signals 2/3 (normally, syntax
verification of the envelope is done before 2/3 is sent). It seems
superfluous to me to send an additional business signal just to indicate
payload syntax verification, whereas a business message
with a response can be sent just as quick, saying "Accept" or "Reject."
Possibly, this is a grey area in the spec that needs to be fixed? Just
fell
between the cracks of MS and BPS.
Regards,
-Suresh
Sterling Commerce (on loan to RosettaNet)
469 524 2676 (O), 469 323 0234 (Cell)
-----Original Message-----
From: Dick Brooks [mailto:dick@tech-comm.com]
Sent: Thursday, October 23, 2003 10:58 AM
To: Damodaran, Suresh; 'Duane Nickull'; Anthony Ellis
Cc: ebxml-dev@lists.ebxml.org
Subject: RE: [ebxml-dev] MSH vs BSI acknowledgement messages
Suresh,
Exchange 2 is frequently seen when trading partners utilize X12 to
represent
business data. ERCOT's ebXML implementation (www.ercot.com) follows the
MEP
outlined in Exchanges 1-2-3.
The Ontario Energy Markets, which use XML to represent business data, also
send a Functional Acknowledgement(in XML) following the same MEP.
Regards,
Dick Brooks
B2B Integration and Cyber Security Consultant
http://www.tech-comm.com/dbc
Mobile:602-684-1484
eFax:240-352-0714
-----Original Message-----
From: Damodaran, Suresh [mailto:Suresh_Damodaran@stercomm.com]
Sent: Thursday, October 23, 2003 11:36 AM
To: 'Dick Brooks'; 'Duane Nickull'; Anthony Ellis
Cc: ebxml-dev@lists.ebxml.org
Subject: RE: [ebxml-dev] MSH vs BSI acknowledgement messages
Exchange 2, below, is not something I have seen.
(granted, in theory, it looks very plausible)
Regards,
-Suresh
Sterling Commerce (on loan to RosettaNet)
469 524 2676 (O), 469 323 0234 (Cell)
-----Original Message-----
From: Dick Brooks [mailto:dick@tech-comm.com]
Sent: Thursday, October 23, 2003 6:24 AM
To: Damodaran, Suresh; 'Duane Nickull'; Anthony Ellis
Cc: ebxml-dev@lists.ebxml.org
Subject: RE: [ebxml-dev] MSH vs BSI acknowledgement messages
I've seen 4 used as a "functional acknowledgement" to indicate that
received
data is syntactically good/bad. A typical scenario is as follows:
Exchange 1
{
A sends data (PO) to B.
B sends 1,(2/3) in a single response message to A indicating reliable
delivery complete of (PO).
}
Exchange 2
{
B sends 4 (functional acknowledgement) to A indicating successful
syntax
validation of (PO).
A sends 1,(2/3) in a single response message to B indicating reliable
delivery complete of 4.
}
Exchange 3
{
B sends Business level response indicating the results of processing
(PO)
(e.g. PO accepted - POA) to A.
A sends 1,(2/3) in a single response message to B indicating reliable
delivery complete of (POA).
}
The above scenario can also be completed in a single exchange (classic
RPC),
as follows:
{
A sends data (PO) to B.
B sends 1,(2/3) and a Business level response (e.g. PO accepted - POA)
to
A in a single response message indicating reliable delivery and processing
of (PO) complete.
}
Dick Brooks
B2B Integration and Cyber Security Consultant
http://www.tech-comm.com/dbc
Mobile:602-684-1484
eFax:240-352-0714
-----Original Message-----
From: Damodaran, Suresh [mailto:Suresh_Damodaran@stercomm.com]
Sent: Wednesday, October 22, 2003 11:17 PM
To: 'Duane Nickull'; Anthony Ellis
Cc: ebxml-dev@lists.ebxml.org
Subject: RE: [ebxml-dev] MSH vs BSI acknowledgement messages
yes, 2 and 3 are same, and 4 is not used typically in practice (when
there
is a business response
message, then that serves the same purpose, and when it is only one-way,
i.e., notification, usually nobody cares to send a business ack).
Regards,
-Suresh
Sterling Commerce (on loan to RosettaNet)
469 524 2676 (O), 469 323 0234 (Cell)
-----Original Message-----
From: Duane Nickull [mailto:duane@yellowdragonsoft.com]
Sent: Monday, September 15, 2003 9:41 PM
To: Anthony Ellis
Cc: ebxml-dev@lists.ebxml.org
Subject: Re: [ebxml-dev] MSH vs BSI acknowledgement messages
Yes - 2 and 3 are the same.
Duane
Anthony Ellis wrote:
>Thanks,
>
>I wasn't thinking about the http level ack at first but now I think the
spec
>can have up to 4 messages.
>
>Level 1 - Transport level. HTTP response
>Level 2 - MSH reliable messaging acknowledgement (as defined in the
ebMSS)
>Level 3 - BSI ReceiptAcknowledgement message (as defined in the BPSS)
>Level 4 - BSI (or BPM) AcceptanceAcknowledgement message (as defined in
the
>BPSS)
>
>Although I still think that Level 2 and Level 3 could be sent together as
>they really do the same thing. Although I come from a technical approach,
>not a business approach :)
>
>I know that the MSH and BSI layers should be seperate but I think there
>should be some overlap for simplicity's sake...
>
>
>-----Original Message-----
>From: Duane Nickull [mailto:duane@yellowdragonsoft.com]
>Sent: Tuesday, September 16, 2003 10:23 AM
>To: Anthony Ellis
>Cc: ebxml-dev@lists.ebxml.org
>Subject: Re: [ebxml-dev] MSH vs BSI acknowledgement messages
>
>
>Anthony:
>
>Almost. You are correct in asserting that there may be three levels of
>acks. First one couldbe an http ack (a basic 200 - ok).
>
>Second ack could be a message layer specific ack that says - yes - the
>message content is validated and received. If specifically requested
>within the Message, must be delivered (timneouts etc apply to this).
>
>The third is a potential business level acknowledgement. This is to say
>"Yes - we accept the terms of your business proposition". It would be
>foolhardy to say that any communication received indicates acceptance of
>the business intent without checking it against the business rules
>(credit limits, shipping to constraints etc.).
>
>Want to have some real fun? Try to imagine what happens if the business
>level acknowledgement gets sent back before the http level ack (Actually
>don't - we've been down this rathole before ;-)
>
>Duane
>
>Anthony Ellis wrote:
>
>
>
>>I have a question regarding the link between the ebXML MSH and BSI and
>>regards to acknowledgement messages and was hoping to clear things up
>>a bit.
>>
>>MSH specifies reliable delivery, and this can be performed with ebXML
>>acknowledgment messages.
>>The BPSS spec then specifies another layer of acknowledgement
>>messaging, ie Receipt Acknowledgement and Acceptance Acknowledgement.
>>
>>Does this mean that there can be up to 3 acknowledgement messages sent?
>>
>>Firstly a MSH acknowledgement, which is simply an acknowledgement
>>attribute in the header of a message, sent once the message has been
>>delivered to the receiving application. There is no business document
>>(ie payload) associated with this message (or there doesn't have to be).
>>
>>Then a BSI, ReceiptAcknowledgment if the BSI can determine a message
>>is legible. This is a ebXML message with a payload containing an XML
>>ReceiptAcknowledgement document.
>>
>>Then a BSI, AcceptanceAcknowledgement if the BSI can determine
>>a payload document is legible and is successfully sent to the
>>Application. This is a ebXML message with a payload containing an XML
>>AcceptanceAcknowledgement document.
>>
>>It seems to me that the MSH acknowledgement message and the first BSI
>>ReceiptAcknowledgement message are a little redundant, as they
>>both signal that the original request message was succesfully
>>received. The MSH should not be sending it's acknowledgement if the
>>original message was not legible either.
>>Is this understanding correct?
>>
>>It just seems to me that there is very little coherence between the
>>MSH spec and the BPSS spec - or it could just be my understanding :)
>>
>>Thanks in advance..
>>
>>
>>Anthony Ellis
>>Red Wahoo
>>-----------------------------
>>Tel: +61 438 878 003
>>www.redwahoo.com
>>
>>
>>
>
>
>--
>***************************************************
>Yellow Dragon Software - http://www.yellowdragonsoft.com
>Web Services & ebXML Messaging / Registry Downloads
>UN/CEFACT eBusiness Architecture/ ebXMl Technical Architecture
>Phone: +1 (604) 738-1051 - Canada: Pacific Standard Time
>Direct: +1 (604) 726-3329
>
>
>
>
>
>
>
>
--
***************************************************
Yellow Dragon Software - http://www.yellowdragonsoft.com
Web Services & ebXML Messaging / Registry Downloads
UN/CEFACT eBusiness Architecture/ ebXMl Technical Architecture
Phone: +1 (604) 738-1051 - Canada: Pacific Standard Time
Direct: +1 (604) 726-3329
<<attachment: winmail.dat>>