C Reporting for Case Management Filter Execution

This appendix describes how to extract information about Case Management filter execution in Oracle Enterprise Data Quality.

EDQ includes trigger points that are called at the start and end of each filter execution. Information about the filter execution is passed to the triggers, which can then be sent to a streaming service such as Java Message Service (JMS), Oracle Cloud Infrastructure Streaming service, and Amazon Kinesis Data Streams.

The trigger paths are as follows:

• /casemanagement/filter/start
• /casemanagement/filter/end

Run functions in triggers accepting these paths are defined as shown below:

function run(path, id, env, json) {
 ...
}

The json argument is a stringified JSON object containing the following attributes:

Attribute	Description
id	Internal filter execution ID
filter	String representation of the filter
type	Possible values are search_filter, report, bulk_update, bulk_delete and export
xaxis	String representation of the report X axis (present for reports only)
yaxis	String representation of the report Y axis (present for reports only)
server	Name of the server where the filter was executed
userid	Internal numeric ID of the user running the filter
user	Name of the user running the filter
userdisplay	Display name of the user running the filter
start	Timestamp of filter start
duration	Filter execution time in milliseconds (present for end calls only)
status	Indicates the reason if the filter did not complete successfully
sql	SQL statement used for the filter (SQL execution mode only)
args	Array of SQL bind arguments

The args attribute in a report for a SQL execution contains the bind values which replace the '?' placeholders in the SQL text. Each entry in the array contains the following:

type	string, number or date
value	argument value

Example

Suppose a trigger sends filter execution end reports to JMS, an OCI notification service topic, an OCI stream and a Kafka topic.

addLibrary("oci");
addLibrary("jms");
addLibrary("kafka");
 
var oci    = OCI.create("OCI 1")
var topic  = oci.topic("ocid1.onstopic.oc1.phx.aaaaaaaa....")
var stream = oci.stream("ocid1.stream.oc1.phx.aaaaaaaa....")
 
var props  = config.loadTriggerProperties("jms", "jms\\.properties");
var jms    = JMS.open(Object.assign({}, props, config.loadCredentials("", props)))
var kprops = config.loadTriggerProperties("kafka", "kafka\\.properties");
var kprod  = KAFKA.producer(kprops.topic, kprops)
 
function getPath() {
  return "/casemanagement/filter/(start|end)";
}
 
function run(path, id, env, json) {
  if (path.endsWith("end")) {
    topic.publish("filter done", json)
    stream.publish(null, json)
    jms.send(json)
    kprod.publish(null, json)
  }
}

Note that the script trigger framework uses one instance for general queries and additional instances for execution. The first instance will never be triggered and thus resources such as JMS connections are not needed. The framework creates a built in variable runnable which is false for the single configuration instance. To optimise resources, this can be used as shown below:

var jms = runnable && JMS.open(Object.assign({}, props, config.loadCredentials("", props)))
...
function run(path, id, env, json) {
  ...
  jms && jms.send(json)
}