RE: [ebxml-iic] about Use Case #1

Jacques,

Here are use cases #2 & 3, based upon discussion, and modification of scripting.

Cheers,

Mike

-----Original Message-----
From: Jacques Durand [mailto:JDurand@us.fujitsu.com]
Sent: Monday, June 07, 2004 7:36 PM
To: ebXML IIC - main list (E-mail) (E-mail)
Subject: [ebxml-iic] about Use Case #1

Mike and all:

Some thoughts following the call today, about scripting of Use Case #1 :

Propose to split the Use Case #1 (see appended to this mail) into:

Use Case #1a: same as former #1, but remove the failure case where both Acceptance and Rejection messages are received.
(so the current scripting of Mike is OK for #1a)

Use Case #1b: extends #1a with the failure case where more than a single Acceptance or Rejection message
is received. In which case we need an improved script, that will illustrate a script design pattern for catching "unexpected" messages:

(1)- main thread does single GetMessage for either Acceptance or Rejection message. Fail the test case if more than one
is received at that point, when executing GetMessage. Otherwise, make sure to "mask" the message received in persistent store.

(2)- spawn concurrently an "exception" thread that will wait (sleep) for the max time (here TImeToPerform) + some buffer time , and then does

GetMessage for additional Acceptance or Rejection messages (previous one has been masked). The thread terminates with an Assertion that fails the test case if any is found (Assertion when_false="exitFail" when_true="continue").

(3) both threads are and-joined at the end. Once the and-joined is executed, we exit on success.

Comments?

Jacques

--------------------------------------
Use Case #1a: Basic Business Transaction,
(e.g. PIP 3A4) with TimeToPerform, and TimeToAcknowledge
--------------------------------------

Test Case: (test driver plays "buyer")
Step 1: Buyer Send a P.O. to Supplier.
Step 2: Receive a receipt ack, correlated with the P.O. based on Conversation ID
Step 3: Receive a P.O. Confirmation or Rejection.
Step 4: Send a signal Ack.

Constraints:
- total time for 1-2-3 is bounded by TimeToPerform.
- total time for 1-2 is bounded by TimeToAcknowledge.

Success:
- within TimeToPerform, receive either a P.O. Confirmation or Rejection.
- TimeToAcknowledge is satisfied.

Failure:
- failure to preform within above timeouts.
- failure to get the expected messages (receipt ack, Confirmation or Rejection message)

Variant:
The correlation is based on a PO reference # that is in the payload.

--------------------------------------
Use Case #1b: Basic Business Transaction,
(e.g. PIP 3A4) with TimeToPerform, and TimeToAcknowledge
--------------------------------------

Same as Use Case #1a, plus:

Additional failure case:
- within TimeToPerform, receiving more than one Confirmation or Rejection message
(e.g. both a Confirmation and a Rejection, or two or more Confirmation messages)

ebxml-iic message