Specifies when the service generates audit data

Indicate that the service should never generate audit data. Select this option if you do not want to be able to audit this service.

Indicate that the service should generate audit data only when it is invoked by a client request or a trigger. The service does not generate audit data when it is invoked by another service (that is, when it is a nested service).

Indicate that the service should generate audit data every time it executes. Select this option if the service is a critical service that you want to be able to audit every time it executes.

Specifies the execution points at which the service generates audit data.

Indicate that the service should generate audit data only when the service fails. If the service executes successfully, it will not generate audit data.

Performance Impact: This option impacts performance only when the service fails. When a service executes successfully, this option does not impact performance. This option offers the smallest performance impact of all the options under Log on.

Indicate that the service should generate audit data when the service finishes executing. The service will generate audit data regardless of whether it ends because of success or failure. The service log will contain an entry for every time the service finishes processing.

Performance Impact: This option impacts performance every time the service executes, whether it ends because of error or success. If you are concerned only with services that fail, consider using the Error only option instead.

Indicate that the service should generate audit data when it begins executing and when it finishes executing. The service will generate audit data twice every time it executes (once when it begins processing and once when it finishes processing).

Generally, most services execute fairly quickly. By the time an administrator views the service log using webMethods Monitor, the service log would probably contain entries for the start and end of service execution. Situations where you might want the service to generate audit data at the start and end of service execution include:

In both situations, if service execution began but did not complete, the service log contains an entry for the start of the service, but no entry for the end of the service.

Performance Impact: Of all the options under Log on, this option provides the most verbose and expensive type of audit logging. Every time it executes, the service generates audit data at two points: the beginning and the end. Integration Server must write the audit data to the service log twice per service execution. This requires significantly more disk utilization than the Error only and Error and success options. At most, the Error only and Error and success options require Integration Server to write audit data once per service execution.

Specifies when Integration Server should include a copy of the input pipeline in the service log.

Indicate that the input pipeline should never be included in the service log. Select this option if you are using a flat file for the service log or if you do not want to be able to resubmit the service to Integration Server.

Performance Impact: This option requires minimal network bandwidth because Integration Server needs to send only the audit data generated by the service to the service log.

Indicate that the input pipeline should be included in the service log only when the service ends because of errors. Select this option if you want to use the resubmission capabilities of webMethods Monitor to reinvoke a failed service. For more information about webMethods Monitor, see the webMethods Monitor documentation.

Performance Impact: For successful service invocations, the On errors only option requires minimal network bandwidth. Service invocations that end in failure require more network bandwidth because the Integration Server must save the audit data and the input pipeline. The actual network bandwidth needed depends on the size of the initial input pipeline. A large pipeline can degrade performance because it may negatively impact the rate at which the data is saved to the service log.

Indicate that Integration Server saves a copy of the input pipeline to the service log every time the service generates audit data. If the service generates data at the start and end of execution (Log on is set to Error, success, and start), the input pipeline is saved with the service log entry for the start of service execution. If a service does not generate audit data, Integration Server does not include a copy of the input pipeline.

Select the Always option if you want to be able to use the resubmission capabilities of the webMethods Monitor to reinvoke the service, regardless of whether the original service invocation succeeded or failed. Including the pipeline can be useful if a resource experiences a fatal failure (such as hard disk failure). To restore the resource to its pre-failure state, you could resubmit all the service invocations that occurred since the last time the resource was backed up. This is sometimes called a full audit for recovery.

Performance Impact: The Always option is the most expensive option under Include pipeline. This option places the greatest demand on network bandwidth because Integration Server must write a copy of the input pipeline to the service log every time a service executes. The actual network bandwidth needed depends on the size of the initial input pipeline. A large input pipeline can negatively impact the rate at which the data is saved to the service log.