T2: Need to change Service and Action for Errors,Delivery Receip ts etc.

Arvola

 

I 
agree that the spec is quite specific. However I think that having just one 
value for Service and Action for a Delivery Receipt makes it hard a MSH which 
receives a Delivery Receipt to work out which application to notify. For normal 
messages, Service and Action contain some useful name, e.g 
Service=SupplierOrderManagement, Action=NewPurchase order. This can be used to 
route the message to the application that supports 
OrderManagement.

 

On a Delivery Receipt, Service contains 
"uri:www.ebXML.org/messageService" and Action "DeliveryReceipt" as you quote 
below and the MSH is given no clue on which application to forward the message 
to.

 

This means that the MSH has to look up the original 
message sent to work out where the DR was sent to.

 

There is an IDENTICAL problem with Error Messages as 
the MSH will not know which the application to forward the message to. This time 
though, it is worse as the message may not have been saved if it was sent with 
RM as BestEffort. If we don't change the spec then a Sending 
MSH will have to PERSIST ALL MESSAGES whether sent reliably or not so that they 
can work out which applicatioon to notify if there is an 
error.

 

The better alternative I propose is to make Action hold 
all the information, e.g. 

    Action 
=uri:www.ebXML.org/messageService/MessageError

 

Then Service could contain "BuyerOrderManagement" so 
that the MSH could work out which application to notify of the error. However 
this requires that you know what to put in the Service when an error or other 
similar message is returned to the sender of a message. To solve this you also 
need to specify the Sending "From Service" in the original 
message.

 

Thoughts?

 

David

  
-----Original Message-----
From: Arvola Chan 
  [mailto:]
Sent: Wednesday, August 08, 2001 6:59 
  PM
To: Burdett, David; 'Dr Crawford'; 
  
Subject: Re: T2: Reliable Messaging 
  (point-to-point)

  
Sorry for the delayed response. I was tied up the last 
  couple of days attending to some personal matters.

  
 

  

  
To answer Cait's original question about the Service and Action elements 
  that should be used when a message containing a DeliveryReceipt element is to 
  be sent not in conjunction with any business level reply, the following 
  excerpt from the 1.0 spec clearly states:

  
If there are no errors in the message received and a DeliveryReceipt is being sent on its own, not as part 848

  
of message containing payload data, then the Service and Action 
  MUST be set as follows: 
  849

  
· the 
  Service element MUST be set to uri:www.ebXML.org/messageService/ 
  850

  
· the 
  Action element MUST be set to DeliveryReceipt 851

  
Unfortunately, the above information is located in section 8.4.7.1 
  deliveyReceiptRequested attribute, rather than in section 8.14 DeliveryReceipt 
  element.

  
 

  
I believe the spec is currently quite specific about the Service and 
  Action elements to use when Acknowledgement, DeliveryReceipt, Error, 
  StatusRequest, StatusResponse, and Ping elements are sent on their own (not in 
  conjunction with business payloads).

  
 

  
-Arvola

  
 

  
-----Original Message-----
From: Burdett, 
  David <>
To: 
  'Dr Crawford' <>;  
  <>
Date: 
  Monday, August 06, 2001 6:39 PM
Subject: RE: T2: Reliable Messaging 
  (point-to-point)

  
>I think that this is a bug in the spec.
>

  
 

  
>To solve this problem I think we should include in every message that 
  is
>sent, an identifier for Service that is sending it. You can then use 
  this
>Service when returning a message if there is no business process 
  specific
>one to use instead. You would then use the Action element to 
  identify why
>the message is being sent.
>
>If we make this 
  approach the rule for returning errors, for example, then it
>fixes the 
  problem that a MSH does not know which application it should
>notify if 
  the original message was not persisted (which it shouldn't be if
>it was 
  not sent reliably).
>
>I also think we should follow the same 
  approach for the Message Status and
>Ping transactions for the same 
  reasons.
>
>Thoughts?
>
>David
>
>-----Original 
  Message-----
>From: Dr Crawford [mailto:]
>Sent: 
  Monday, August 06, 2001 8:11 AM
>To: 
>Subject: 
  T2: Reliable Messaging 
  (point-to-point)
>
>
>
>
>I have a 
  comments/questions regarding POINT-TO-POINT reliable 
  messaging
>implementation for ebXML MS 1.0.
>
>First, lets 
  assume that Party A is sending a message reliably -- that 
  the
>deliverySemantics have been set to OnceAndOnlyOnce 
  and
>deliveryReceiptRequested to Unsigned (I don't think that 
  Signed/Unsigned
>makes a difference for the example, actually) in the 
  QualityOfService
>element in the MessageHeader.  I am sending this 
  message w/out
>intermediaries, so I am not making use of the Via or 
  Acknowledgment
>elements, although I am populating the TraceHeader 
  element as appropriate.
>
>Now, Party B receives the 
  message.  Now assume that there is NO REPLY from
>the 
  application.  Party B is required to send an "Acknowledgement 
  Message"
>(section 10.3.2) which at a minimum has a MessageData element 
  with a
>RefToMessageId of the received message.  Since a 
  deliveryReceipt is also
>requested, the MSH must also generate the 
  DeliveryReceipt element in the
>ack message.  My question concerns 
  the service and action elements of this
>ack.  Clearly, as there is 
  no business-level reply, the service and action
>should not reflect any 
  business or application level service & action.  In
>section 
  10.3.3, the spec says that if an Acknowledgment element is being
>sent 
  on its own then service MUST be set 
  to:
>uri:www.ebxml.org/messageService and action MUST be set to 
  Acknowledgment.
>What is the equivalent service/action for a 
  DeliveryReceipt element being
>sent on its own?? (as set in the 
  MessageHeader element for this ack
>message)??  Is this described 
  in the CPP/BPSS since this is one of the
>"signals" that need to be 
  processed by the MSH-application interface??
>
>What would happen 
  if the deliveryReceiptRequested was false, but the
>semantics were set 
  to OnceAndOnlyOnce??  The minimal acknowledgement
>required only a 
  RefToMessageId within the MessageData element -- any
>guidelines as to 
  what should be used in the Service and Action elements in
>the 
  MessageHeader?
>
>In general, I think that the Reliable Messaging 
  section should be expanded
>to include the POINT-TO-POINT option where 
  no Via or Acknowledgment
>elements are used, but 
  deliveryReceiptRequested attributes are turned on.
>(i.e. there is no 
  information about whether the reply is sync or not in the
>message 
  header).
>
>Your guidance is greatly 
  appreciated.
>
>Regards,
>Cait
>
>Cait 
  Crawford
>B2B Integration
>IBM Research
>Hawthorne, 
  NY
>
>
>
>------------------------------------------------------------------
>To 
  unsubscribe from this elist send a message with the single 
  word
>"unsubscribe" in the body to: 
>
>------------------------------------------------------------------
>To 
  unsubscribe from this elist send a message with the single 
  word
>"unsubscribe" in the body to: