[ebBP] 5/25/2004: ebXML IIC and ebBP Considerations

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

The OASIS ebXML IIC (Implementation, Interoperability and Conformance) 
TC has been reviewing our progress as they develop the next phases of 
the test framework. They have noted the need for conditions, branching, 
composition of test steps into threads into test cases. They've recently 
looked at three use cases that evidences their need for test case 
control patterns and control flow (with operators) [html/xml, discussion 
attached]. On yesterday's call they discussed exit conditions on test 
steps (similar to what we have been discussing relating to state and 
transition).

I think their work is progressing well. It will continue to evolve but I 
would (and I am sure the IIC team would) welcome your feedback. They 
should have some revised html/xml in the next few weeks that I will 
forward. Feel free to comment on the if-then-else constructs (still 
under discussion). Thanks.

--------------------------------------
  Use Case #1: 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 signal 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, 
but not both.
- TimeToAcknowledge is satisfied.

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

  --------------------------------------
  Use Case #2: Catching unexpected ebXML Error messages (a test case 
"design pattern")
  --------------------------------------
  Test Case: (test driver plays "buyer")

  Step 1: buyer sends a message M1
  Step 2: receive and verify message M2
 
  Correlation M1-M2 based on COnversation ID.
But in case an error is received that correlates with M1 (in addition or 
instead of M2),
at any point in time within 300sec after sending M1, before or after 
receiving M2,
and regardless of the outcome of verifying M2, we want the test case to 
fail.

  --------------------------------------
  Use Case #3: conditional branching
  --------------------------------------
  Test Case: (test driver plays "buyer")

  - buyer sends M1
  - received M2 (e.g. an approval, or rejection)
  ---> if M2 is "approval", we will expect a sequence of:
- receive M3 (e.g. a quotation) 
- send M4 (e.g. approval of quote and payment info)
- receive M5 (final delivery details).
  ---> if M2 is "rejection", we will expect a sequence of:
- receive M6 (proposed alternative)
 
We need to verify all received messages, as the test case would fail if 
they do not comply.
Any error message received, would also fail the test case (see use case #2)

ebxml-iic-bpss-use-cases-may2004.zip