Accessing work item output data when/after being checked-in?
In using an observer gateway, you get notification of workitem status changes via announceWorkItemStatusChange. This includes workitem check-ins (status Executing --> Complete).
However, the workitem's data, retrieved via getDataString(), only ever contains the *input* XML, not the output (or at least in all my tests with YAWL 2.0.1). Is this as intended and, if so, how might I get access to the output data? (This would seem to be a fairly 'standard' use case for an observer gateway, but perhaps there are design issues which means that this data isn't associated with the YWorkItem object, or at least at the time of its announcement to the observer gateway....)
Actually, whilst I'm here :-), getDataString() actually gets the underlying _dataList attribute, whereas get_dataString() gets the _dataString one. Comments suggest the latter is a persisted version of the former, but it's seemed to be empty in all my tests (these weren't very extensive however; as soon as I saw it was empty but the other one wasn't, I switched to using that for everything). When should I be using each method? Always getDataString()? I guess this boils down to when data is persisted and how this manifests itself in the YWorkItem object.
Thanks in advance.
Stuart
(aka monsieurrigsby)
Hi Stuart,
You're on the right track: when a work item completes, the engine's completeWorkItem method is passed the item id and an (external) Element containing the output data - that is, the output data is never contained within the YWorkItem object. Less relevant, perhaps, is the fact that it is a "status change" announcement, and not a "data change" announcement, so the only change the work item should be transporting is its status. (Of course, the owner service or gateway of the work item - i.e. the one that completes the work item - would already know the output data, so this only concerns 3rd party listeners, if i can put it that way).
The 'right' way to get at a work item's output data is through the process logs. An observer gateway would do it something like this:
YlogServer logServer = YLogServer.getInstance();
String itemEvents = logServer.getEventsForTaskInstance(itemid);
The itemEvents String is an XML'ed version of all the events that occurred for the work item with the itemid passed. Two of those events are called 'DataValueChange'; the later one (via its timestamp) is the output data items. Get the (long) key value for that DataValueChange event, then pass it to:
String dataItems = logServer.getDataForEvent(key);
The dataItems String will be an XML'ed version of all the output data variables names, types and values.
Re: get_dataString vs getDataString(), always use the latter. The former is only there for hibernate's use.
Cheers, Michael.
OK, many thanks (again!). Yes, sorry, I forgot to add in my original post that I'd had a look at the YAWL source. (I think it's always good forum etiquette to show that you've actually tried to find a solution and/or understand the code, rather than the all-too-common "Give me the answer to [insert problem statement here, cut and pasted from the requirements document without any attempt to interpret it for the framework it is to be solved via using manuals and examples provided]"...)
I saw that the check-in flow didn't appear to touch the workitem's data string: the output data just gets passed through to YNetRunner to be used in updating the workflow state.
I'll have a think about whether to go the process log parsing route, or look for an alternative design which means I don't need to do this.
Cheers, Stuart
Oops: "or at least at the time of its announcement to the observer gateway" in the first paragraph should be "or at least not at the time of its announcement to the observer gateway".