Re: [ebBP] 6/14/2004: Need for Feedback for ebXML IIC on Use Cases

["David RR Webber" <david@drrw.info>]

Monica,

OK - got it!

Here's what I'd suggest:

Use Case bp#1 - Invalid payload.

Responder receives a payload that fails to
validate against XSD.
Return "Invalid document" response.

Use Case bp#1a - Invalid payload

Responder recieves a payload that is syntactically
OK - but is not the correct payload type - eg BP
tells you you are going to get a certain type of
BOD - and you get one that is its close cousin
instead.  Return "Invalid document" response.

Use Case bp#2 - Business problem.

Responder receives a payload that is syntactically
OK - but information is wrong - e.g. PurchaseOrder
but the Order quantity = zero, or the Item ID is missing,
etc.  Return "Business problem" response.

Use Case bp#3 - Access failure

Requester system simply cannot reach the responders
system - simulates network failure - or infrastructure
re-configuration - eg - move to new server - change
of port address, etc.  Return - protocolFailure response.

These with the timeout and retry counts examples I
think do cover off a whole chunk of problems.

I guess another area is things like "Addressee not
recognized - etc" - but I suspect they have those
use cases already as part of envelope testing.

Thanks, DW

----- Original Message ----- 
From: "Monica J. Martin" <monica.martin@sun.com>
To: "ebXML BP" <ebxml-bp@lists.oasis-open.org>
Sent: Monday, June 14, 2004 10:57 AM
Subject: [ebBP] 6/14/2004: Need for Feedback for ebXML IIC on Use Cases


> The ebXML IIC continues in improving and updating their test framework.
> They are using three use cases (attached). In thinking about these use
> cases and the process related functions, what other cases would we see
> the use of looping. I have identified:
>
>     * retryCount  Reiteration of sending a message again if the
>       appropriate response or signal was not received
>     * Indirectly for checks on statuses for time to perform
>     * BSI checks on signal receipts to trigger backend system
>     * Business document processing may allow the condition for a
>       response to be sent or the successful handoff from the BSI to the
>       backend systems could also apply for looping usage.
>
> The team is asking for other conditions within ebBP that would help them
> determine if there constructs can meet the majority of use cases. The
> use case would be from the testing party perspective.
>
> Any other usages or cases relevant for ebBP? We can briefly discuss in
> today's call. I've attached the original use cases and a revision below.
> Michael Kass, NIST, has also created the XML for the cases which is also
> attached. Thanks.
>
>
> Jacques Durand wrote:
>
> > 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)
> >
> >
>
>
>


----------------------------------------------------------------------------
----


> Test use cases, representative of test case control patterns.
> They should help focus on the minimal set of operators for control flow.
>
> -------------------------------------- 
>   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)
>
>
>