----- Original Message -----
Sent: Monday, July 21, 2003 7:15 PM
Subject: [ebxml-iic] more on message
correlation
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.
[MIKE] - That is how the Test Framework describes CPAId, MessageId,
ConversationId and RefToMessageId...
either explicitly declared or automatically generated by the Test
Driver
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.
[MIKE] - Yes. I explicitly defined CPAId in the Abstract
Test Suite.. although I could have left it out,
and
whatever CPAId is in the ConfigurationGroup content would be used by default.
I felt that having CPAId defined
explicitly added to the understanding of the test.
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):
[MIKE] - I describe that in section 3.5.5.. maybe I should move it back
to section 3.5.2 ( it is a more logical place for it ).
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 ).
[MIKE] - If you're talking about the executable test suite.. the Test
Driver automatically assigns the ConversationId when it constructs
the
message from the
<MessageDeclaration>....</MessageDeclaration> . There
is no need to "assign" it in the MessageDeclaration.
If
you are talking about the Abstract Test Cases.. we can do whatever we want if
it makes the tests clearer to someone who is going
to write it. As you see in the Abstract Test Suite.. I already
have 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).
[MIKE] - I just left MessageId out because I felt that it added more
complexity than someone who was examining the test needed.
It
would be easy to add them into the Abstract Test Suite. But they are not
in the Executable Test Suite.. because they are not
needed.
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.
[MIKE] - It would be good to add a caveat in table 4 ( section 3.5.2 )
stating that RefToMessage, while automatically generated
by
the test driver, is not used for message declaration... HOWEVER, it is used
for message filtering ( my next comment below ).
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).
[MIKE] - Why not just state ( in a caveat in table 4 ) that
RefToMessageId is used by the Test Driver for message filtering, not
message generation?
If I
am "filtering" returned messages, and I want only those messages that refer to
my previous sent message, then I MUST know the
"RefToMessageId" of the message I receive. I know what it is..
because it is the MessageId of the message I sent with the last Test
Step.
RefToMessageId is critical for <GetMessage> .
RefToMessageId is irrelevant for <PutMessage>.
Furthermore, could we use something like: eb:MessageData/RefToMessageId=nil
To make it clear the
element should be absent?
[MIKE] - I would just
leave that declaration out entirely.. since RefToMessageId is an optional
element in a message to begin with.
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]]
[MIKE] - As I stated above, $RefToMessageId is equal to
$MessageId from the previous <PutMessage>. That is how we
can
correlate and filter messages and look at what we want to look at. So
the Test Driver "knows" what the RefToMessageId will be,
and
if
the Test Service is functioning like it should.. it should send back the
correct 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..
[MIKE] - That is what the Test Driver does
.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:
[MIKE] - And normally, 99 out of 100 times.. that is what we do with
this Test Suite
How
do we remember a parameter (MessageId ) generated by the Test Driver in a
previous step?
[MIKE] - We have a <SetParameter> function that can pull a value
out of a message using an XPath expression, and
assign it to some arbitrary Parameter name.. whatever we want to call
it.
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
[MIKE] - Yes we
can do that, and eliminate the RefToMessageId element.. I just had it in the
Test Suite so that it was a little
clearer what we were
doing.
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.
[MIKE] - That is something to consider for the next
version.
Regards,
Jacques
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