Hi all,

I have been unable to find the logging that occurs as a result of the 'Log Entry' ('Log Predicates' for editor 2.3.5) settings for a Task Decomposition.

I found a forum post from 2012 asking the same question. http://www.yaug.org/node/58

The suggestions are: 1) Log API, and 2) Clicking 'Download Log' for the Case in the Engine view.

1) Using the API is not what I want to do right now. Seems I should have to dig this deep to get those log results.

2) Clicking Download Log produces an xes file, but it does not reflect any of the log settings I have made.

I have tested this on cases uploaded from v2.3.5 editor as well as v3.0. I have tested it with Log Entry being plain text, as well as using Log Predicates such as ${task:name}. I have set the Log Entry on human-resourced tasks as well as tasks automated by a Codelet.

These log entries are also nowhere to be found in my Apache logs directory on my Enterprise installation.

on OS X, editor 2.3.5 and 3.0a. Engine on Windows XP Engine build 3.0.1239 (2013/12/09 16:27) | Resource Service build 3.0.3765 (2013/12/13 00:22).

Does anybody have any suggestions where I can find these logs and why they're not there on the xes log from the engine? Many thanks!

Michael Adams says:

XES is a very specific format designed for process mining tools. There is no scope to fit log predicates into logs that adhere to the XES standard (it also disallows a sizeable number of workflow states that that are recorded in the YAWL logs). 

Log predicates are included in the logs retrieved via the YAWL log API (interface E).

fmannhardt

Fri, 02/21/2014 - 09:53

From what I understand of YAWL and XES it would be possible to achieve this. In XES each event can have attributes attached to it. There is no restriction on the amount of these attributes according to the standard:

http://www.xes-standard.org/xesstandarddefinition

The simplest thing would be to log log predicates into attributes of the type String. For example like this:

<trace>
  <string key="concept:name" value="1"/>
  <event>
   <string key="concept:name" value="Task A"/>
   <date key="time:timestamp" value="1970-01-01T01:00:00+01:00"/>
   <string key="org:resource" value="Resource Name"/>
   <string key="logPredicates" value="whatever the log predicate generates as output"/>
  </event>
</trace>

Or did I get something wrong about log predicates?

Also regarding the lifecycle of a task, the XES attribute  lifecycle:transition, there is no restriction built into the XES format.  According to the XES standard there is a well-defined "standard" model of the lifecycle that consists out of a fixed number of states (such as schedule, assign, withdraw, reassign, start, suspend, resume, ..., complete), but that does not mean that we are restricted to these states. The standard even mentionts an log level attribute lifecycle:model that defines the lifecycle transactional model:

This attribute refers to the lifecycle transactional model
used for all events in the log. If this attribute has a value
of “standard”, the standard lifecycle transactional model
of this extension is assumed.
 
So YAWL could use something else than "standard" to indicate that there are more than the standard states. Or just write unkown on the non-standard states.
 
Actually YAWL already makes nice use of the lifecycle:transition attribute, but most of the process mining tools ignore different states of a work item and just assume one event per task execution, that is usually the complete event. 
 
It would be nice to have YAWL generating useful XES logs with log predicates, as from my point of view this would be quite powerful for data aware process mining. :)
 

Michael Adams

Sun, 02/23/2014 - 23:59

Let me rephrase what I said to Andreas above:

XES is a format for the interchange of event log data between tools and application domains. That is, it provides systems such as YAWL with a format to output archived log data in such a way that it can be interpreted by log mining tools. Note that YAWL archives its process logs in a number of database tables, and queries them on demand to produce both XES formatted output, and other outputs such as XML and CSV formats.

While XES provides a standard way of formatting log data, it also allows extensions to that standard. Indeed, YAWL XES logs contain extended attributes for data taken from the logs that describe the resourcing and data perspectives in addition to control-flow. We (the YAWL team) also developed an 'official' XES extension for cost. The key point to these extensions is that whenever they are included in an output XES log it should be because there are known tools (e.g. plugins explicitly developed for ProM) that expect to find those extended attributes in the log and know how to interpret them. Without such tools, the extended attributes and their data would simply represent ‘noise’ that the tool would, at best, process and ignore (with overheads) and at worst cause the tool to produce errors.

For this reason, we are keen to prevent bloat in XES output, and in particular are averse to the inclusion of any data that will not be of use to any known mining tool. If a mining tool is developed that can meaningfully interpret the free text of a log predicate field, then that will be an argument for the inclusion of log predicate data in the XES formatted output produced by YAWL.

There are, of course, many other ways to format archived log data. For YAWL, formats besides XES are provided via its log interface, and these formats produce logs that do include log predicate values.

Thankyou for the replies. This of course answers my question and I can see the logic for the YAWL system. Now onto connecting with the API!

Michael said: "If a mining tool is developed that can meaningfully interpret the free text of a log predicate field, then that will be an argument for the inclusion of log predicate data in the XES formatted output produced by YAWL."

I would think that is relatively easy to extract information from an XML file. So if I know that the log predicates that I include in my workflow end up in the XES log, I can extract them using XQUERY, XSLT or even just read the log file. So to some extent, there exists a mining tool that can meaningfully interpret free text.

I would definitely like to have the feature that Felix proposed. It would be the last 5 percent of something that is already there 95 percent: an easy and configurable logging solution ready for the end user.

After a long silence....

This is a code snippet proposed by Michael and tested by me that shows how to extract the log data discussed above can be extracted:

********************

class LogTest {

    public static String testLogGateway() throws IOException {
        YLogGatewayClient logClient
                = new YLogGatewayClient("http://localhost:8080/yawl/logGateway");
        String handle = logClient.connect("admin", "YAWL");

        YSpecificationID id = new YSpecificationID("UID_f3553de7-ca9b-455b-adb6-3cd897001bf8", "0.1", "logtest");

        String caseLogXML = logClient.getCompleteCaseLog("12", handle);
        return caseLogXML;
    }
}

*********************

The test workflow is attached.

 

logtest.yawl (3.05 KB)

Hi! For everyone who stumbles upon this thread, looking for a way to get log files out of YAWL:
With the help of ahense, I made a small tool that allows you to access the YAWL Log API and download log files from Engine and Resource Service. It runs from the command line and is written in Java. Start it using the command:
java -jar YawlLogExtractor.jar

For more information on how to use the tool, please check the README.txt.
Please note, that this tool might contain bugs and is by no means complete or perfect. Please let me know if you have any issues using the tool.

README.txt (5.29 KB)