Agent - Processing Part

The Agent - Processing Part is responsible for getting the messages from the local buffer and processing them up to the point where they are ready to be sent to the final destination, to the Event Logging Collector Service (via HTTP/HTTPS REST), or to the Server JMS Broker Queue.

Consumer of the local buffer will read existing buffered events from the buffer and start processing it via a synchronous processing and send it via direct: communication (transactional, in the JMS case) to the core processing route which will start a custom processing route, if one is defined for the given event category in the org.talend.eventlogging.agent.cfg file.

Example:

agent.processing.custom.routeid.default=myCustomProcRoute
agent.processing.custom.routeid.audit=myCustomProcRoute
agent.processing.custom.routeid.security=myCustomProcSecurityRoute

In the example above, the myCustomProcSecurityRoute will be called for the security category and the myCustomProcRoute will be called for the audit one and all others (default). By default, no custom processing route will be called.

In the next step, the Event Log message (as stored as plain text in the exchange body) will be signed and a signedLogMessage header property will be created which contains the logMessage in a XML Digital Signature (enveloped). The Camel XML Security component (based on Apache Santuario) is used for the XML DSIG signature creation.

If signing is required, it can be defined by category within the org.talend.eventlogging.agent.cfg file.

Example:

agent.processing.signing.default=false
agent.processing.signing.audit=true
agent.processing.signing.security=true

In the above example, audit events and events in the security category (but which are not marked as audit) will be signed, but all others (with the default definition) will not be signed.

The default is:

agent.processing.signing.default=false
agent.processing.signing.audit=true

The keystore and the certificate configuration used for signing the events are defined by the following within the org.talend.eventlogging.agent.cfg:

agent.signing.keystore.properties=./etc/keystores/trunKeystore.properties

A default local keystore (trun.jks) is provided for the private key which will be used to sign the log message, however it is strongly recommended to use a custom keystore and certificate for production.

After the signing step, the Camel Exchange (Event Structure) is treated as ready and the event is send with the direct component synchronously (transactional in the JMS case) to the sender part of the Agent.

The last part of the processing is a direct-vm: component which gets configured per event category as follows:

agent.sender.destination.default=eventlogsenderrest
agent.sender.destination.audit=eventlogsenderjms

With those two parameters, the event will be sent to the Event Logging Sender according to its related category. Two sender destinations are available:

• eventlogsenderrest

• eventlogsenderjms

Even though these values are just the route IDs where the direct-vm: will send the event to, with this configuration, the customer can easily create custom senders as routes with a Direct-VM Endpoint and by configuring the related route ID of the exposed direct-vm endpoint.

agent.sender.destination.system=eventlogsendermysender

The above parameter would send the event to the route with the eventlogsendermysender route ID. And this route can put the log event wherever it likes.