CPA Support
OUTDATED! This document has not been update for a long time.
CPA info to ebMS info structures
In order to not work through the XML elements and attributes of the CPA HefeWeizen created internal structures called ebXML message info structures. Each such structure is for a service/action/from/to instance. A hash (calculated from an incoming ebXML message or from a directive) shall allow for a quick look up to get the right information of the CPA.
There is one gotcha with HTTP sync replys because a sync HTTP error or sync HTTP ack uses the same delivery channel as the origin ebXML message. So it is important in those cases to retrieve the origins ebXML message info structure. All async ebMS signals are using the default delivery channel unless overridden in the CPA of course.
CPA elements/attributes implemented vs not implemented
It is important that the HefeWeizen administrator, the ebXML CPA manager, know which parts of the ebXML CPA are supported by HefeWeizen und which parts are not supported.
Actually this is a bit tricky to document as there are lots of elements and attributes and also because there are further combinations of those elements/attributes.
MessagingCharacteristics
combination of AckRequested and SyncResponse
AckRequested:
- never
- always
- perMessage
SyncMode:
- none
- mshSignalOnly
- responseOnly
- signalsAndResponse
- signalsOnly
SyncMode is only important for Synchronous Transport Protocols. In ebXML messaging 2.0 SyncMode is only of importance if the Transport Protocol is HTTP. SyncMode is not used when the Transport Protocol is SMTP. This causes a question whether a CPA that has a Delivery Channel that uses SyncMode other than none in the MessagingCharacteristics but references an STMTP Transport Protocol element is actually valid. A "business rule" validation would say this does not make sense. Otherwise it could simply be ignored.
So in the HTTP case the request leg is an ebXML message (signal or user message) ... the SyncMode tells about what happens on the response lef ot the HTTP call. For example a acknowledgment can sent back, nothing, the repsone business document (synchronous messaging in that case), or both ack and response business document. it is about synchronous verses asynchronous.
Notes:
- Actually something the ebXML Message Service Handler is unable to tell is which response payload belongs to an open connection.
- Generally synch messaging is tying up systems.
- Closing an HTTP connection with sending neither an ebXML message signal nor an ebXML user message requires to send an HTTP 204 return code.
Extra Note:
- the ackSignatureRequested attribute of the MessagingCharacteristics only applies if the ackRequested element is set to anything but never. If ackRequested set to perMessage or always than ackSignatureRequested has to be looked at. The ackSignatureRequested can have the values never, always, and perMessage.
| SyncMode options | ack if ack | response payload if response payload | comment |
| none | async | async | |
| mshSignalOnly | sync | async | seems to be used most in practice. |
| responseOnly | async | sync | |
| signalsAndResponse | sync | sync | |
| signalsOnly | sync | async |
The values indicate that we are talking about ebXML Message Service Handler signals and other Signals. We know that there are ebXML Business Process Signals ... again the ebXML Message Service Handler would not know about what is another Signal and what is not. Also signalsAndResponse would not be clear as to which signals ... when are there no more signals coming?
About the implemetation (HTTP only).
| implemented | comment | |
| none | yes | |
| mshSignal | yes | includes Error Messages and Acknowledgment, and Pong? |
| responseOnly | no | should be possible in the future ... HTTP connection must be kept open and directive for response must reference connection id. |
| signalsAndResponse | no | not implemented because no way yet to tell how many other signals must be packaged. last signal must have a 'now are all signals' info. |
| signalsOny | no | not implemented because no way yet to tell how many other signals must be packaged. Last signal must have a 'now are all signals' info. |
Combinations of SyncMode and AckRequested
| implemented | |
| syncmode none ackrequested always | no |
| syncmode none ackrequested never | no |
| syncmode mshSignal ackrequested always | no |
| syncmode mshSignal ackrequested never | no |
| syncmode responseOnly ackrequested always | no |
| syncmode responseOnly ackrequested never | no |
| syncmode signalsAndResponse ackrequested always | no |
| syncmode signalsAndResponse ackrequested never | no |
| syncmode signalsOny ackrequested always | no |
| syncmode signalsOny ackrequested never | no |
plus howto package non ascii stuff into mime message.
example ebMS info structure
File Edit Options Buffers Tools Help
{"from"=>"Coronation",
"service"=>"urn:oasis:names:tc:ebxml-msg:service",
"info"=>
{"transport-protocol-version"=>"1.1",
"mc-ackSignatureRequested"=>"never",
"this_party_name"=>"Coronation",
"cpa_id"=>"Coronation::Gnaraloo::UBL 1.0 Invoice Notification",
"ebMS-version"=>"2.0",
"other_party_name"=>"Gnaraloo",
"this_party_ids"=>
[{:type=>"string", :id=>"coronation"},
{:type=>"urn:li.coronation.b2b", :id=>"coronation_test_system"}],
"doc-exchange-sender-digital-envelope"=>"not done yet",
"other_party_ids"=>
[{:type=>"string", :id=>"gnaraloo"},
{:type=>"urn:li.gnaraloo.b2b", :id=>"gnaraloo_test_system"}],
"mc-syncReplyMode"=>"mshSignalsOnly",
"doc-exchange-sender-non-repudiation"=>"not done yet",
"transport-protocol-name"=>"HTTP",
"transport-protocol-endpoint"=>"http://localhost:8888/gnaraloo",
"mc-ackRequested"=>"always",
"mc-duplicateElimination"=>"never"},
"action"=>"Ping",
"hash_value"=>"hash_-13977508001",
"to"=>"Gnaraloo"}
