Webmethods : Service Auditing

Service Auditing:*Service auditing is a feature in the 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 audit log

*The audit log can contain entries for service start, service end, and service failure.

*The audit log can also contain a copy of the input pipeline used to invoke the service

*At run time,services generate audit data at predefined points. The Integration Server captures the generated audit data and stores it in the audit log. If the audit log is a database, you can reinvoke services using the webMethods Monitor.

Service Auditing Use Casses

Error Auditing
In error auditing, you use the audit log to track and reinvoke failed services. To use the audit log for error auditing:

- services must generate audit data when errors occur,

-and the Integration Server must save a copy of the service’s input pipeline in the audit log.

Service Auditing
When you perform service auditing, you use the audit log to track which services execute successfully and which services fail. You can perform service auditing to analyze the audit log and determine how often a service executes, how many times it succeeds, and
how many times it fails. To use the audit log for service auditing, services need to generate audit data after execution ends.

For this property... Select this option...

Enable auditing When top-level service only
Include pipeline Never
Note: Configure a service to save a copy of the input
pipeline only if you intend to reinvoke the service
using the resubmission capabilities of the
webMethods Monitor.
Log on Error and success

Auditing for Recovery
Auditing for recovery involves using the audit log to track executed services and service input data so that you can reinvoke the services. You might want to audit for recovery in the event that a resource experiences a fatal failure, and you want to restore the resource
to its pre-failure state by resubmitting service invocations.
When auditing for recovery, you want to be able to resubmit failed and successful services. The audit log needs to:

- contain an entry for each service invoked by a client request or a trigger.

-The audit log also needs to contain a copy of each service’s input
pipeline.

Auditing Long-Running Services
If a service takes a long time to process, you might want to use the audit log to verify that service execution started. If the audit log contains a start entry for the service but no end or error entry, then you know that service execution began but did not complete. To enable auditing of long-running services:

- select the Error, success, and start option for the Log on property.