OAG
BODs, etc. To meet this end, we can just borrow business documents
from

the
other standards for our demo. By using the signal messages from a particular
standard,

we
are giving an impression that ebXML services can be layered on top of other
standard's

service, since the signal messages are consumed by
the particular standard's service.

ex. The DocumentLabel field in the ebXML header for
Request Acknowledgement has the value of "Purchase Order Request
Acknowledgement". There is no such document type defined by Rosenttanet.
Rosettanet does not create custom acknowledgement messages
based on the received message.

<PY>This is not a custom acknowledgment. The
label is just a textual description of what is in the ebXML payload. However
the TAPId.Action field should have the correct value from PIP3A4, which is
simply "Receipt Acknowledgement".</PY>

[Patil, Sanjay] The DocumentReference.DocumentLabel should
also be "Receipt Acknowledgement" instead of "Purchase Order Request
Acknowledgement" or

"Purchase Order Acceptance
Acknowledgement"

My point is, we are creating confusing scenario by
mixing the Rosettanet business documents (defined by PIPs) and signal
messages (defined by and scope limited to RNIF).

<PY> I don't understand distinction you are
trying to make. Both business documents and Acks *are* defined by RosetaNet
and are part of the PIP (PIP3A4 in this case). Again without the Acks there is
no PIP.</PY>

[Patil, Sanjay] Agree, without the Acks there is no PIP. But
Acks message type is not

defined by PIP, but it is just used in a PIP. It's
only the business document types which are

defined by the PIP and the Ack type is
defined by RNIF. Again, this is because Rosettanet

PIPs
are tightly coupled with the implementation
framework.

Instead we can live with just ebXMLHeader and no
payload for acknowledgement messages. This will at least keep the
matters clean.

<PY>If you don't need or handle the Acks,
you can simply choose to throw away the payload for the acks. Others need
it.</PY>

[Patil, Sanjay] Acks are useful and ebXML Acks at this point can
simply be defined by

the
header itself. At this point, even if we decide to demonstrate backend
integration,

I
don't understand how one is going to use the the Rosettanet Ack
payload.

Rosettanet Ack payload is also based upon the Service
Header of the the incoming

This was already discussed. We said, the RN acks would simply be payload
as far as ebXML is concerned. The Packaging section of the POC
proposal document also shows <RN-Action-Message> or
<RN-Signal-Message> in the payload. There are no ebXML level
acks.

Regards, Prasad

"Patil, Sanjay" wrote:

> This is about "Receipt Acknowledgement" messages for the demo.
> Are we planning to use any payload for these messages? Since these
> messages are consumed by the service and not passed to the backend,
> we need to have ebXML specific payload, if any. > > I
am not sure if TR&P has identified different signal message types
> as acknowledgement, exception and defined types for them. >
> Of course, we can use RN payload for the demo, but that
demonstrates > no ebXML feature, as the ebXML service is not going to
process the receipt > payload in the receipt messages. >
Instead, maybe we can just use the ebXML header's DocumentLabel field
> to identify the "Receipt Acknowledgement" and not have any payload.
> > Please ignore this message if this topic has already been
discussed and > decision has been made (I would still need to know
the decision though). > > thanks, > Sanjay Patil
>
----------------------------------------------------------------------------
> ------------------------------ > Work Phone: 408 350 9619
> http://www.netfish.com