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!
Filed an issue
same problem here. I filed issue number 505 here:
http://code.google.com/p/yawl/issues/
Solved
Michael Adams says:
Why not add it as an attribute?
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:
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:
XES logs and YAWL log predicates
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.
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!
Hen and Egg Problem?
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.
Retrieving Logs from the YAWL engine
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.
Tool to access the log api / Download log files
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.
With YAWL Version 4.5 log…
With YAWL Version 4.5 log entries are now displayed in the XES logs.