About Service Auditing

Service auditing is a feature in Integration Server that you can use to track which services executed, when services started and completed, and whether services succeeded or failed. You perform service auditing by analyzing the data stored in the service log. The service log can contain entries for service start, service end, and service failure. The service log can also contain a copy of the input pipeline used to invoke the service as well as select fields from input and output service signatures. At run time, services generate audit data at predefined points. Integration Server captures the generated audit data and stores it in the service log. If the service log is a database, you can re-invoke services using the webMethods Monitor.

Note:

When Integration Server logs an entry for a service, the log entry contains the identify of the server that executed the service. The server ID in the log entry always uses the Integration Server primary port, even if a service is executed using another (non-primary) Integration Server port.

Each service has a set of auditing properties located in the Audit category on the service’s Properties view. These properties determine when a service generates audit data and what data is stored in the service log. For each service, you can decide:

Whether the service should generate audit data during execution. That is, do you want the service to generate audit data to be captured in the service log? If so, you must decide whether the service will generate audit data every time it executes or only when it is invoked directly by a client request (HTTP, FTP, SMTP, etc.) or a trigger.

The points during service execution when the service should generate audit data to be saved in the service log. You might want a service to produce audit data when it starts, when it ends successfully, when it fails, or a combination of these.

Whether to include a copy of the service input pipeline in the service log. If the service log contains a copy of the input pipeline, you can use the webMethods Monitor to perform more extensive failure analysis, examine the service’s input data, or re-invoke the service.

Keep in mind that generating audit data can impact performance. Integration Server uses the network to send the audit data to the service log and uses memory to actually save the data in the service log. If a large amount of data is saved, performance can be impacted. When you configure audit data generation for services, you should balance the need for audit data against the potential performance impact.

Note:

The service log can be a flat file or a database. If you use a database, the database must support JDBC. You can use Integration Server to view the service log whether it is a flat file or a database. If the service log is a database, you can also use the webMethods Monitor to view audit data and re-invoke the service. Before you configure service auditing, check with your Integration Server Administrator to learn what kind of service log exists. For more information about the service log, see the webMethods Audit Logging Guide.