[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [Fwd: [ebBP] 6/14/2004: Need for Feedback for ebXML IIC on Use Cases]
Earlier today, I sent the team an email on the ebXML IIC test framework.
As indicated, they are using three use cases (attached). As they extend
the test framework, the team wishes to:
* Anticipate what test framework functionality would be required to
support business process test scenarios.
* See the test framework as a process itself (albeit simplified).
They have identified three initial use cases related to business
processes to assist them in the test framework specification development
(see attached). One of the IIC team's main concerns is accommodating
reoccurring events in a business process. The test driver, mutation
mechanism, and message construction capabilities in the IIC framework
should support the majority of use cases we anticipate. The list
provided this morning is only one of which to start throwing darts.
* retryCount Reiterate sending a message again if the appropriate
response or signal was not received.
* Indirectly check on statuses for time to perform (Related to
monitoring not to specification conformance).
* BSI checks on signal receipts to trigger backend system (same).
* 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 (same).
If you have feedback on any of these, please advise or provide any cases
you can contribute. Thanks.
--- Begin Message ---
- From: "Monica J. Martin" <monica.martin@sun.com>
- To: ebXML BP <ebxml-bp@lists.oasis-open.org>
- Date: Mon, 14 Jun 2004 07:57:10 -0700
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)--- End Message ---
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]