Re: [ebxml-iic] Test scenario use case: capturing conversation id andreusing it for subsequent message store queries.

["Monica J. Martin" <Monica.Martin@Sun.COM>]

Tim Sakach wrote:

>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.
>
mm1: One thing to think about in the grander scheme, is that eventually 
these test cases, test results, etc. may be artifacts in a registry. 
Whether they are available in the future during the test is another 
discussion.  However, the reason I bring this up is that we have had 
lengthy discussions about accessing elements, process descriptions, 
fragments, etc. in ebBP. There are already three mechanisms allowed in 
Reg/Rep to accommodate the internal and external identification of 
'objects'.  You may wish to speak with Farrukh Najmi about this: 
external ID, UUID and user defined (simply speaking).  Any decision we 
make here may affect future functionality.  I think the second option 
Tim proposes is more in line with supporting my question. Thanks.

>
>The first option requires that the test driver have some means of passing variables to DOM, which can be very difficult in some cases. It would also require that the variables are passed to DOM each time a message is processed with an xpath query.
>
>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. However, it would enable all the configuration group elements to be available in xpath queries.
>  
>