ebxml-iic message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [ebxml-iic] Test scenario use case: capturing conversation id and reusing it for subsequent message store queries.
- From: "Michael Kass" <michael.kass@nist.gov>
- To: "Tim Sakach" <tsakach@certivo.net>, "ebXML IIC - main list \(E-mail\) \(E-mail\)" <ebxml-iic@lists.oasis-open.org>
- Date: Wed, 25 Feb 2004 15:17:45 -0500
Monica and Tim ( & all )
My comments below.
Regards,
Mike
----- Original Message -----
Sent: Tuesday, February 24, 2004 6:09
PM
Subject: [ebxml-iic] Test scenario use case:
capturing conversation id and reusing it for subsequent message store
queries.
Test cases initiated by the solution under test
create a slightly problematic situation where the ConversationId is unknown
until a message is received in a GetMessage step. The solution may generate a
timestamp or GUID value for the ConversationId, and this value must be stored
for later use in the test script. Subsequent test steps that require a
ConversationId to retrieve related messages need a method to include the
ConversationId in the xpath query.
There are a few options for making the
ConversationId available for xpath queries on the message store.
One
option is to define a method of variable binding to DOM so that xpath processors
can reference the data as variables in the xpath expression.
Another
option is to have the test driver generate a unique GUID for each test case
instance, and add data such as configuration group values to the message store
that can be referenced with the GUID.
The first option requires that the test driver
have some means of passing variables to DOM, which can be very difficult in some
cases.
[MIKE] - Agreed that this is not a
typical part of DOM XPath processor packages
It would also require that the variables are
passed to DOM each time a message is processed with an xpath query.
[MIKE] - That would be the case
for XSLT processors, agreed that this is inefficient.
The second
option should be easier to implement in a test driver and allows for variables
to be grouped by instance of a running test case. It is somewhat more cumbersome
to define queries this way when compared to xpath variables.
[MIKE] - It is also
"cleaner" as far as standard XPath notation, so I would favor the second
option, plus it solves the problem of re-introduction of variables to the
processor each time they are run. One thing that is still
an issue is: dynamically received variable content (i.e.
runtime parameters that are not known apriori). The only way to deal with
those (in your case #2) would be to modify the DOM (adding that paramter
name/value pair on the Message Store DOM parameter list on the fly) whenever the
following type of instruction is encountered in the scripting. But this is
less painful than re-introducing variable definitions each time a processor is
invoked. Comments? If approach (2) is the choice, then I will modify
the Configuration Group and Message Store documentation to reflect
this.
<SetParameter>
<Name>MessageId</Name>
<Value>//MessageStore/Message//eb:MessageHeader/eb:MessageData/eb:MessageId</Value>
</SetParameter>
This would mean "appending" a new (
or replacing an existing ) <ConfigurationItem> name/value pair onto the
DOM
However, it would enable all the
configuration group elements to be available in xpath queries.
-----Original Message-----
From: Monica
J. Martin [mailto:Monica.Martin@Sun.COM]
Sent: Tuesday, February 24, 2004
11:41 AM
To: Tim Sakach; ebXML IIC - main list (E-mail) (E-mail)
Subject:
Sakach 2/24/2004: BPSS Test Scenario Example
Could you provide more
details on the example you referenced in
yesterday's call?
Thanks.
To unsubscribe from this mailing list (and be removed from
the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/ebxml-iic/members/leave_workgroup.php.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]