Auditing

injection of audit into event processing

Introduction

The goal is to inject an external auditor into the event processing cycle so all event and node invocations can be monitored by the auditor.

When the SEP is generated there is an option to add an Auditor. The auditor will be invoked by the SEP automatically as the execution path progresses. An auditor receives callback about events, lifecycle and node invocations. The auditor can use this information for a variety of purposes such as monitoring performance of processing or tracing execution paths for later review.

Audit capabilities

The user develops or re-uses a class that implements the Auditor interface and registers this via the SEPConfig method addAuditor(name, Auditor). The auditor indicates whether it wants to track individual node invocations or just event tracking by responding true/false in the auditInvocations method:

  • true - receive all lifecycle callbacks from the auditor interface

  • false - receive all lifecycle callbacks from the auditor interface

    except nodeInvoked

The Auditor can monitor the following SEP invocations:

  • nodes registered - type and node name

  • event received - event instance

  • individual node invocations - node instance, nodeName, methodName of node, event instance

  • post processing complete

In the Auditor callbacks the name of the node in code and the method invoked are supplied as strings. This is consistent with the names used in the generated SEP, graphml and png.

Example

The example below demonstrates an auditor that tracks all node processing. The code for the example is located here.

Auditor

SEPConfig

The auditor is imperatively added to the graph using the addAuditor method on line 10.

Generated SEP

The generated SEP shows each stage of event processing from node registration to individual node invocations are tracked by the auditor

Generated png

Last updated

Was this helpful?