OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

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.


Monica and Tim ( & all )
 
    My comments below.
 
Regards,
Mike
 
 
----- Original Message -----
From: "Tim Sakach" <tsakach@certivo.net>
To: "ebXML IIC - main list (E-mail) (E-mail)" <ebxml-iic@lists.oasis-open.org>
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]