Clarification of syncReplyMode Attribute

Line 1171 in the 1.0 CPPA spec talks about four possible values for the syncReplyMode attribute: signalsOnly, responseOnly, signalsAndResponse, and none.

Line 1178 is confusing. I think it should say "the sending application expects in a response" rather than "the receiving application expects in a response".

The explanation of signalsOnly is not clear. Depending on the definition of the business transaction (i.e., whether there is a responding activity), the sending application may still expect a business response message separately. This response message in turn will trigger a business level acknowledgement that may or may not be returned synchronously.

The meaning of responseOnly is also unclear. Does it mean that no business signals should be sent at all or are they only to be sent separately and asynchronously? What if non-repudiation of receipt is required?

In the case of signalsAndResponse, I suppose the multiple business level messages have to be packaged into a single message at the MHS level as multiple MIME body parts. I don't think this point is clearly stated. Also, if the responder returns the business signals and business response synchronously, how is the initiator expected to send its business level receipt acknowledgement? Will that have to be sent asynchronously?

The RosettaNet Implementation Framework 2.0 supports synchronous response but makes a number of simplifying assumptions. For a one-action PIP, the responder can return a signal or not at all. For a two-action PIP, the responder can return a business response but no business signal. Thus, there is no non-repudiation of receipt for the request action from the responder. It is also assumed that the initiator is not required to return a receipt acknowledgement for the response action. Therefore, there is no non-repudiation of receipt of the response action from the initiator either. In other words, synchronous response mode can only be used for certain PIPs that don't require response or non-repudiation of receipt.

The ebXML message is more flexible to allow signal(s) and response to be packaged into the same message, so it may be unnecessary to impose any of the above simplifying assumptions. Still, it is useful to clarify how the initiator can achieve non repudiation of receipt for the response message.

ebxml-cppa message