----- Original Message -----
Sent: Thursday, February 26, 2004 7:05
PM
Subject: [ebxml-iic] edits for
GetMessage() op
Mike:
Some proposed additions in the section below (in
bold). Please update if not correct.
Should
the Filter of a GetMessage() op produce a "Result" element containing the
resulting node-set?
Jacques
Semantics of the GetMessage operation
A fundamental aspect of the GetMessage operation
is its behavior and effect over the Message Store.
The Message Store is an XML document object that contains an XML
representation of all synchronous and asynchronously received ebXML messages
for a Test Case. The received messages for a particular Test Case
MUST persist in the Message Store for the life of the Test Case. Messages in
the Message Store MAY contain all MIME, SOAP and ebXML or other types of
message content, represented as an XML document. The particular XML
representation of a message in the Message Store is based upon an a
"best practice" schema for representing a particular message type. If
the messages being stored are ebXML messages using HTTP transport and a SOAP
envelope, the XML format of the Message Store document MUST validate against
the ebXMLMessageStore.xsd schema in appendix D.
The GetMessage Filter sub-operation queries the
Message Store document object, and retrieves (by default) the XML content that
satisfies the XPath expression specified in its Filter child
element. As the MessageStore is
updated every time a new message comes in, a GetMessage() operation will
automatically execute as often as needed, until either (1) its Filter selects
and returns a non-empty node-set, or (2) the timeout (stepDuration)
expires.
[MIKE] - suggest adding:
A TestPreCondition
and/orTestAssertion sub-operation ( which also contain a single XPath query)
query the resulting document object constructed from the node-list
generated by a GetMessage Filter operation. That document object to be
examined by a TestPreCondition of TestAssertion action MUST have a root
element with a name of test:Result ( as defined in the Result schema in
Appendix XX). If the Test Driver is unable to create a Result
document object because the resulting node-list contains any XML content other
than elements ( such as an attribute list), then the Test Driver MUST generate
an exception, and terminate the Test Case with a result of
"undetermined". (i.e. if the XPath query does not return XML
content that can be built into a document object, then it cannot be
further examined with XPath in the TestPreCondition or TestAssertion
operations)
NOTES:
All
the message items available for querying, are children of the MessageStore
element. The Xpath expression in the Filter will typically select all the
/MessageStore/Message elements that satisfy the filter, and these will be
consolidated as children of a Result element, available for further
querying, e.g. by the TestAssertion operation.
The
messages that have been selected by a GetMessage() operation are (suggest remove the word 'normally'.. sounds ambiguous)
"invisible" to future Getmessage() operations in the same test case, unless
the "mask" attribute is set to "false" (default is "true"). A GetMessage()
operation will execute over all messages in the message store for this test
case, except those messages that have been masked by a previous GetMessage()
operation. [MIKE] - My interpretation of what you are saying here ( and
what will be necessary to implement) is that there will have to be 2
MessageStores ( this would seem the only efficient way to make this
transparent to the test writer ). If I do a <GetMessage
mask="true"> ( the default ) then any messages that contain a node in the
returned nodelist are "moved" to the "masked" MessageStore after the
<GetMessage> operation. This is a bit tricky ( will require the
Test Driver to traverse "back up" the document tree to the root
<MessageStore> element, and copy the <Message>(s) that contain
the matching node-set node(s) and delete them from the "unmasked"
MessageStore. and add them to the "masked" MessageStore. This will be
a bit time-consuming for the Test Driver ( unless the default
is mask="false".. a more likely scenario in testing I think
). Also.. there is the issue of "side-effects".
Since the MessageStore is a "global" data resource, available to
any concurrently running Thread... "masking" (i.e. deleting)
messages that may be needed by a concurrently running GetMessage
operation would introduce problems unless the test writer is aware of
them. Lastly, I would hope that "masking" would not require
"unmasking". If so, then we need to introduce another operation called
<Unmask> to move the messages back to the "unmasked"
MessageStore. Do implementers see this (masking) as a necessary
function? I think that we may be able to satisfy the need to mask by
simply assigning parameter values (e.g. messageCount="5").. and if a
subsequent GetMessage operation returns 10 messages, then a
<TestAssertion>//Message[count() =5] would fail... without the need to
"mask"messages so that our count is set to "0". Comments from
implementers?
NOTES:
Examples of use:
If
one wants to verify that within 300 seconds, exactly 5 messages with
MessageId="123" have been received, then the test case should first wait 300
sec before executing GetMessage(). This is done with a "Sleep" operation.
The Sleep operation (not
step) must be followed by a GetMessage() operation (not step) with a Filter selecting any
message with MessageId="123", and a stepDuration of a few seconds at
most . The TestAssertion Xpath expression will finally verify that the
resulting node-set contains 5 message elements.
If
one wants to verify that within 300 seconds, at least one messages with
DocumentType="PurchaseOrder" has been received, then it is sufficient to use
a GetMessage() test step with a stepDuration of 300 sec, and a Filter
selecting DocumentType=" PurchaseOrder". This would succeed as soon as a
PurchaseOrder message is
received.