This function is complete and can be used. The interfaces will be supported until the function is removed from the project via the deprecation process. There will be ongoing extensions to this function, but it will be done to ensure backward compatibility as far as possible. If there is a need to break backward compatibility, this will be discussed and reviewed in the community, with a documented timeline.
Audit Log Framework (ALF)¶
The audit log framework (ALF) provides interface definitions and classes to enable connectors to support natural language enabled diagnostics such as exception messages and audit log messages.
The audit log framework provides the ability to route audit log records to multiple destinations where they can be stored or processed automatically. This second option is particularly important in today's world of continuous operations.
Figure 1 shows the main parts of the framework.
Figure 1: Components of the Audit Log Framework (ALF)
When processing activity wishes to log a message to the audit log, it selects a message definition from a message set, optionally passing in the values to fill out the placeholders in the message template.
The message definition is passed to the audit log where it calls the message formatter, builds a log record and passes it on to the audit destination.
The audit log destination can be extended to allow routing to different destinations for review and processing.
The Open Metadata Repository Services (OMRS) provide an extension to the audit log destination that supports audit log store connectors. This means that an OMAG Server can be configured to route audit log messages to different destinations.
Details of the supported audit log store connectors and how to set them up are described in configuring the audit log.