RE: [tamie-comment] XTemp v0.84

Marius:

See inline <JD>

Also, see in the following package posted recently, the use case #4 that shows the setting of a different virtual present time using the attribute start/@vptset (formerly @datetime) , when starting a scriplet:

http://www.oasis-open.org/committees/document.php?document_id=39650&wg_abbrev=tamie

Other responses inline.

Cheers,

Jacques

From: Marius Plavan [mailto:marius.edtf@gmail.com]
Sent: Saturday, October 02, 2010 12:09 AM
To: tamie-comment@lists.oasis-open.org
Subject: [tamie-comment] XTemp v0.84 - questions

Hi all,

I looked quickly through v0.84. I gathered a few questions based on that version which I would like to raise to the TaMIE TC.
Some of them might question some fundamental concepts in the draft, with the sincere goal of improving the draft -- as I am one of the users of XTemp.

"catch/@datetime: provide a VP-time for the catch that is different from the
VP-time of the embedding scriplet. This makes it possible to query events
that occurred before the scriplet VP-time. After the catch execution, the new
VP-time of the executing scriplet will be set based on the latest of
{scriplet VP-time before executing catch, date/time of the latest event [of
the pattern] matched by the catch ."

I might not see / understand the entire picture regarding the VP Time so clearly. But as little as I see in this moment, if I, as a user of XTemp, have the option of specifying catch/@datetime, that is enough for me to catch one or more events based on the time which was stamped by the engine. Additionally to the "event time" (stamped by the engine), the user might be more inclined on querying for events after their actual "business" time (i.e. when the event actually took place in the service under testing / monitoring, but which of course is something that's dependent on each service implementation).

<JD> We are aware of the difference between event “posting time” (as determined by the Event Board) and event “origination time” (as determined by the business source of this event. These can be very different (yet the posting time always later than origination time). And you are right to remark that XTemp seems to only provide support for the “posting time” as it is the only time looked at for VPT calculations. In short: what you are asking for is still possible, but users have to define their own <match> filters that know about “business time”, because the XTemp engine only “knows” about posting time.

Reasons are:

- issue with “origination time” is that it all depends on the users to set-it up. This means it can be found (or not found at all) in very diverse places of the event, e.g. deep inside a business document.

- Moreover, there might be several “business times” associated with the same event: e.g. for a PurchaseOrder message: creation time of the PO, actual sending time of the PO, etc.

- Also, there are always issues with timezones as not all times are set as UTC, etc. Several event-processing companies such as TIBCO, have warned in the past of the unreliability of origination time.

That means it is hard for XTemp to rely on business time attribute and to trust its content, and therefore we made the choice of having XTemp engine/language NOT be aware of business time (or origination time) and ONLY be aware of the event board posting time. But it is always possible for the user to define his/her own catch filters for selection based on such business time(s). For example: if I want to select all Pos created after January 1^st 2010, I will still select events based on post-time, but add a filter condition that takes care of the business time:

<match><condition>xtemp:content//myapp:PurchaseOrder/myapp:CreationTime gt xsd:dateTime(‘2010-01-01T00:00:00’) </condition></match>

</catch>

The catch above will still look at events that may have a business time earlier than Jan 1^st (because such events may still have a post-time after Jan 1st ) but the filter condition on business time will correct this. </JD>

As I see it, a catch operator might move the scriplet's VP time backwards. What benefits has then the user, by having the concept of scriplet's VP-time, if it can be altered (both forward and backwards) by the three operators? Is it there mostly for assuming a given time for each catch operator (that does not have a @datetime specified by the user)? Is it there also for simulating "@concurrent" scriplet behavior?

<JD> The three operators (catch / sleep / start) only move VP-time forward, by default – which is quite expected. The @vptset attr (formerly @datetime) allow for setting VP-time backward in start and catch, for convenience. E.g. when you catch some type of event, you may want then to check that another kind of event was present some time ago in the log. You need then to set the VP-time to a past date, then resume to Actual present date, etc.

"The first "match" child element will be executed first on the event board". ...

"The X-effect of a catch is the sequence of selected events (or views of these, in case the related match statements have defined a view)."

What I could not deduce from the draft is whether each match (inside a catch) will return the matched event immediately or only when catch execution will finish. For example, one might want perhaps to query in the second match the content of the first event (matched using the first match). This can of course be accomplished by using a second catch, but is it possible / intended to be achieved using more matches inside the same catch?

<JD> Absolutely: the second <match> may use information from the event selected by the first <match>. No need for a second catch: see in Section 3.8.4 an example where the match/@event values are used as variable names ($E1, $E2):

<catch>

<condition

>content/soap/Header/msgData/action = 'PORequest'</condition>

</match>

<condition>(content/soap/Header/msgData/action = "POAccept" or content/soap/Header/msgData/action = "POReject") and content/soap/Header/msgData/property[@name = 'order_ref'] = $E1/content/soap/Header/msgData/property[@name = 'order_ref']</condition>

</match>

<condition

>content/soap/Header/msgData/action = 'Receipt' and content/soap/Header/msgData/property/RefMessageID = $E2/content/soap/Header/msgData/messageID</condition>

</match>

</catch>

We may want to make that clearer in the draft , thanks for noticing. </JD>

Even if some things can be deduced by some of us, do you see a benefit in having also a section about error / exception handling in the draft? I feel that, if not addressed in the standard, this might cause in the future various interpretations by the engine developers.

<JD> Right – you mean exception handling in the sense of conventional programming languages (not using the <exit> xtemp operator). We thought of leaving this for a next version. But you are right that it is critical for a robust test engine to support this. On the XSLT implementation side, we are encouraged by the coming exception handling support in XSLT2.1. </JD>

I target here mostly things that one or more engine implementations might take as granted when handling specific exception cases and which might impact portability of that script on another XTemp engine.

As an example: What happens when catch (or any other extension function used by the engine) is waiting for an event for a large period, but for some reason the event adapter knows already that events are not going to arrive anymore (let's say that the network is done, and perhaps the event adapter - or another "entity" - might want to signal the engine that an environment exception was encountered - no disk space, no avail ram, crash)?
One approach might be to (optionally?!) allow a return from the catch when such exceptions are encountered, and return the "exception event" to the script.
Alternatively / additionally, one can add global "exception handlers" which can be reused in cases when the script-package is interacting with the outside world through the "engine" (and it cannot foresee all the exceptions that might occur).

<JD> These are valid points – frankly this feature has not been high on our priority list. if you have concrete suggestions to submit on this list, we welcome them. Yes we’ll need this.

Is there a place where latest XTemp transformers can be freely accessed?

I would like to use the latest XTemp transformers in edtf, if available. I have the eTSM transformer, but it is a few months old.
No problem if it is a "development" version, as long as it is "workable" :-)

<JD> see the link on top of this email, you should be able to access it even without OASIS account – let me know. It has a more up-to-date transformer (beware the change in namespaces)

Best regards,

Jacques

Kind regards,
Marius

tamie-comment message