Re: [ebxml-iic] call today...+ comments

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

> Durand: - BPSS requirements: are we OK?
> - looping cases: =recursive split? (conditioned by an Assertion)
>    * Anticipate what test framework functionality would be required to
>      support business process test scenarios.
>    * See the test framework as a process itself (albeit simplified).
>
Jacques,
Here is the looping list ebBP team has thus far:
  * 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).

I may not be able to attend today as I will be flying at 2:55 p.m. PDT 
(I'll try to briefly call). Other brief comments are inline (mm1).

> ---------------
>
> SOme comments on previous mail (use case #2, #3):
>
> [MIKE]  We use 
> <WhenTrue><Split><ThreadRef="thread_02"/></Split</WhenTrue>
> [JD]: that is fine to me.
>
> [MIKE] - I was trying to follow the semantics of workflow, however if 
> you are saying that we can simply have a <Thread> without having to 
> enclose it in a <Split>, that would be fine (i.e. it would be 
> considered a "synchronous" execution of a <Thread> by default.
>
> [JD]: I wouldn't give it any different semantics than the embedded 
> form...
> Synchronous with main (invoking) thread would be achieved by:
> <Split>... threadref= ABC </Split>
> <join> threadref= ABC </join>
> (so main thread will wait end of ABC to proceed further steps)
> But we don't have to "join" right after, in which case main thread 
> would proceed
> concurrently with ABC.
>
mm1: If you look at the most recent post regarding ebBP updated schemas, 
we will have business transaction activities (BTA) within BTA because 
more than one layer of request may occur before a response to the 
original BTA. I believe I forwarded the working draft schema.

> thread_02 needs to wait 300sec before doing the check.
> [MIKE] - Actually, just having a "stepDuration=300 for the 
> <GetMessage> will accomplish what we need, without having to <Sleep>  
> (see updated use case example)
>
> [JD]: Not here Mike: remember that there is a subtle difference 
> between (a) sleep(300) and (b) stepDuration=300. In (a), the error 
> thread will catch everything that will have occurred
>
> within the 300 sec (will make sure no error message occurred). In (b), 
> as soon as the GetMessage
> filter is satisfied (//*[not(eb:ErrorList...), the thread proceeds, 
> and completes on "continue",
> (e.g. after 200sec) ignoring an error message that arrives at 250sec.
>
mm1: This is inline with the timeouts, transitions defined in ebBP.

> [MIKE2] - Actually, we can generate "erroneous" messages using a MIME 
> API as well (supplying erroneous MIME header content).
>
> [JD]: OK, these would be "well-formed" errors. That will be sufficient 
> in many
> cases. But generally, I assume the scripting will
> allow for full manipulation of MIME envelope - sometimes this is 
> useful to avoid MIME-package-dependent idiosyncrasies (correct way to 
> use MIME, but limited)
>
> [MIKE] (example below)
> JD: questions:
> - instead of using a MessageHeader element for each name/value pair:
> can we wrap all pairs in a single element? (e.g. by putting "value" as 
> an attribute of "Name")
> - how do these MessageHeader elements relate to the MessageDeclaration 
> element content?
> - what is the semantics of adding (repeating?) MessageHeader element 
> in the SetPayload element?
> that does not seem to belong to the final message (e.g. ebXML) header, 
> but to some MIME headers.
> <PutMessage>
> <MessageHeader>
> <Name>Content-Id</Name>
> <Value>cid:MessageEnvelope</Value>
> </MessageHeader>
> <MessageHeader>
> <Name>type</Name>
> <Value>text/xml</Value>
> </MessageHeader>
> <MessageDeclaration>
> <soap:Envelope>
> <soap:Header>
> <eb:MessageHeader>.....</ebMessageHeader>
> </soap:Header>
> </soap:Envelope>
> </MessageDeclaration>
> <SetPayload>
> <MessageHeader>
> <Name>Content-Id</Name>
> <Value>cid:PurchaseOrder</Value>
> </MessageHeader>
> <PayloadDeclaration>
> <rn:PurchaseOrder>
> </rn:PurchaseOrder>
> </PayloadDeclaration>
> </SetPayload>
>