KEW provides various options for reporting on and simulation of routing scenarios. There is a GUI for performing these reporting functions as well as an API that you can use to run routing reports against the system.
From the Rice main menu there is a link to the Routing Report screen. From this set of screens you can enter various criteria for running reports against the routing engine. The output of this reporting is a simulated view of the Route Log, displaying the result of the report.
The KEW client API also provides facilities for running reports against the routing engine. At the core of KEW is a Simulation Engine that is responsible for running these types of reports. The method for executing these reports is on the Workflow Info object that is part of the client API. The method is defined:
public DocumentDetailVO routingReport(ReportCriteriaVO reportCriteria) throws WorkflowException;
This method takes the report criteria and returns the results of the routing report.
The routing report operates under two basic modes:
Reports that run against existing Documents
Reports that simulate a Document from a Document Type
In each these cases there are certain properties that you need to set on the ReportCriteriaVO to obtain the desired results.
In the first case, the report runs against a document that has already been created in the system. This document already has a Document Id and may be en route. Using this style of reporting, you can run simulations to determine where the document will go in future route nodes. For example, to run a simulation against an existing document to determine to whom it will route in the future, execute this code:
WorkflowInfo info = new WorkflowInfo(); RoutingReportCriteriaVO criteria = new ReportCriteriaVO(new Long(1234)); DocumentDetailVO results = info.routingReport(criteria); // examine results...
This runs a report against the document with ID 1234, starting at the active nodes of the document and continuing to the terminal nodes of the document. The DocumentDetailVO will contain the Action Requests generated during the report simulation.
You can also stop the report at a particular node or once Rice generates a request for a particular user. For example, to stop the report simulation at a node or when Rice generates a certain user's request, configure the report criteria like this:
WorkflowInfo info = new WorkflowInfo();
RoutingReportCriteriaVO criteria = new ReportCriteriaVO(new Long(1234), "MyNodeName");
criteria.setTargetUsers(new UserIdVO[] { new NetworkIdVO("ewestfal") });
DocumentDetailVO results = info.routingReport(criteria);
This executes the report until it reaches a node named MyNodeName or a request is generated for user ewestfal.
In the second style of reporting, the report is run against an arbitrary Document Type and the simulation engine creates a temporary document against which to run the report. When setting up the report criteria for these scenarios, you usually populate the XML content of the document on the criteria (provided that the routing of that document evaluates the XML). Also, the criteria need to be configured with the valid node names (or rule templates) against which the report should be run. For example, to run a Document Type report, you can invoke the routing report this way:
WorkflowInfo info = new WorkflowInfo();
RouteReportCriteriaVO criteria = new ReportCriteriaVO("MyDocumentType");
criteria.setXmlContent("<accountNumber>1234</accountNumber>");
criteria.setNodeNames(new String[] { "MyNodeName" });
DocumentDetailVO results = info.routingReport(criteria);
The code above simulates the generation of requests for MyDocumentType at the MyNodeName node with the XML given. This sort of reporting is especially useful if you simply need to determine what rules in the rule system will fire and generate action requests under a particular scenario.
As an alternative to specifying the node names, you can also specify rule template names. This is simply another way to target a specific node in the document. It searches the Document Type definition for nodes with the specified rule templates and then runs the report against those nodes. Currently, the rule template must exist on a node in the Document Type definition or an error will be thrown. In the case of our previous example, you could simply change the line that sets the node names on the criteria to:
criteria.setRuleTemplateNames(new String[] { "MyRuleTemplate" });As above, this is primarily useful for determining who will have requests generated to them from the KEW rule system.
As we've seen, the object returned by the Routing Report is an instance of DocumentDetailVO. This object extends RouteHeaderVO and provides three more pieces of data along with it:
An array of ActionRequestVO objects representing the action requests on the document
An array of ActionTakenVO objects representing the actions that have been performed against the document
An array of RouteNodeInstanceVO objects that represent nodes in the document path
For reporting, the most important piece of data here is typically the ActionRequestVO objects. After running a report, this array contains the Action Requests that were generated as the result of the simulation. So, for example, in the example above where we run a document type report against the MyRuleTemplate rule template, this array contains all of the Action Requests that were generated to users or workgroups during the report simulation.