more on message correlation

[Jacques Durand <JDurand@fsw.fujitsu.com>]

Title: some late feedback...(on MS conf)

Mike and all:

 

a follow-up on my issue #5 below, that I 'd like to reword:

I still believe we have an issue with message correlation:

 

- unlike in interop testing where it is behaving like an application, the Test Driver crafts all elements of the message

when used in a conformance test harness (including elements that are usually determined by the MSH,

and not decided by the application, like Messagge IDs.)

So now the MessageID has to be put in by the Test Driver:

(a)- either explictly (in the message content field of the test case,like done for CPAid)

(b)- or generated automatically, as suggested in parameters of table in 3.5.2.

 

If it were (a), the Message ID would be defined in the test case data, like CPAid value.

But it is more like (b) in our suite.

 

So, questions/comments arise:

 

1. As mentioned in TestFramework, (4.2.1.2) COnversationID and MessageID are automatically generated by

Test Driver. It would be good to remind the way this is done (somewhere after table in MS conf doc 3.5.2):

This semantics seems to be described in TestFramework spec  (7.1.4), which states that the conv ID changes for each test case,

and the MessageId for each step.

So this parameter ($conversationId) is generated by the Test Driver for each TCase, but we still need to "assign" it to

the header of the message to be sent, it seems:  (eb:ConversationId=$ConversationId ).

I don't have a problem with that, but then why don't we do the same for MessageID? (e.g. eb:MessageData/MessageId=$MessageId),

which we know will change for each sending step).

 

2. The RefToMessageId element typically should be absent, for the first message of a conversation (which is,

for each request messge of each test case.)

".... If there is no earlier related message, the element MUST NOT be present."

Although we rightly ignore RefToMessageId in message content for sent messages, it is not clear that

the way we specify this in table in 3.5.2, the Test Driver will make sure to NOT insert a RefToMessageId element.

If I look at the table in 3.5.2, I have the feeling that RefToMessageId is treated the same as MessageID: the

Test Driver will generate one, and even give it a value... I would remove RefToMessageId from this table

(this element should always be set by the app, or Test Service, in responses. And if it needs be set by the Test Driver, that

should be after the MessageId of a previous response. So cannot be automatically generated).

Furthermore, could we use something like: eb:MessageData/RefToMessageId=nil

To make it clear the element should be absent?

 

3. Now, we still need to correlate a response with the message sent.

We will first assume that the Test Service (behaving like an app) will be in charge of setting

the RefToMessageId. So the test case script / Test Driver does not have to do this (at least for regular test cases.)

But in the test cases, the correlation statement is confusing. We correlate first on ConvID, which is OK. But in addition, we do:

eb:MessageData/RefToMessageId=$RefToMessageId]]

 

Which is not correct, as again RefToMessageId should be set by the receiving party (unless the

Test Driver sets it up to previous sent MessageId...but that built-in behavior is unflexible, and error prone)

Normally, the RefToMessageId of the received message should be same as the MessageId of a previously sent message.

Assuming we always need to compare only with the last sent message:

How do we remember a parameter (MessageId ) generated by the Test Driver in a previous step?

We could assume that $MessageId will only change for each "sending" step, so we can still use it

to compare with, in the following "receive" step.

So one way to fix this, is to use:

eb:MessageData/RefToMessageId=$MessageId

 

In which case again, the semantics of when/how a parameter like $MessageId is changed by TestDriver, should be reminded in the spec.

In a next verison of TesFramework, we should be able to refer to parameters set in arbitrary steps, by refering to step#,

e.g. like ($1)MessageId  for $MessageId  set in Step #1.

 

Regards,

 

Jacques

 

-----Original Message-----
From: Jacques Durand [mailto:JDurand@fsw.fujitsu.com]
Sent: Monday, July 21, 2003 11:00 AM
To: 'ebxml-iic@lists.oasis-open.org'
Subject: [ebxml-iic] some late feedback...(on MS conf)

Mike and all:

Quick feedback on MS conf spec (will send more later):

1. need more names in "reviewers" section

2. Profiles section need more exposure (a full section, not header 3), and we'll need a
conforming profile document pointing to the right reqs. We may need to re-discuss a bit the
profile defs (ping/pong/status svc place, syncReply options)

3. Test cases for multi-hop still use the "concrete" syntax (GetMessage...)

4. The wording of some test reqs is not concrete enough, in terms of testable assertion
(see reqs 6, 7: "the MSH accepts the message", we need to say something more concrete,
like: passes to application without generating an error.)

5. In Test Cases: would correlation based on Conv ID be sufficient, for associating req-resp?
(instead of MesgID / RefToMesgID)
(not sure we can always assume the Test Driver can know, as an app, the MesgID that are generated by its MSH)

Regards,

Jacques