Configuring outbound mail / notification providers in tools (just like any other configurations) should be easier as you move higher up the application layer (Think configuring sendmail command line program vs...
SOA Suite uses audit trails as a way of tracking messages and actions performed by components within a SOA Composite application. Configuring the audit level correctly is needed for increasing the performance of the infrastructure and to help support managing of application. SOA Suite Audit Levels article covers all the audit level configuration options provided by SOA suite with examples & discusses their implications.
Contents of this article are
- What are Audit Levels
- Audit Level Values
- Inherit and Overrides
- Audit Level Configuration
- General Guidelines
What are Audit Levels?
Audit levels represent the composite instance and payload details which are collected by the messaging infrastructure from different components in the SOA composite which help in tracing the execution of a composite application.
- SOA Infrastructure is a JEE application running on top of a JEE server like web logic server
- SOA Infrastructure understands and executes SOA Composites in SOA Suite
- Each SCA components are handled by different Service Engines
- Binding components will work with external JEE resources (like adapters) as needed
- For SOA Composite to execute, it might require some or all of these different components or engines to work together depending on what the composite is using
Audit levels are the configurations which affect the composite instance tracking and payload messaging details stored when executing a SOA composite. These messaging details are what are referred to as Audit Trails. In this article we will concentrate on configuration settings provided by SOA Suite for capturing audit trails.
Note that Audit levels usually affect the dehydration store which will store information based on audit level setting. Log levels usually affect the log files – to which logging information from the component will be written to. Audit level settings has no impact on Log level setting and vice versa.
Audit Level Values
Audit levels that you can set usually have the following valid values. Note that not all the SOA levels support all of these different values.
No information (like composite instance tracking and payload tracking) is collected. This will be provide the best performance – but harder to support and maintain.
The component (or the engine) with this audit setting will not capture any information, rest of the components in the composite will capture audit trail based on their settings.
Composite instance tracking information is collected. With this value, payload information is not collected for most of the activities (like Mediator or Assign activity in BPEL, etc) except for some key activities in the components (like BPEL Receive activity). This is sufficient for most production requirements.
Allows for composite instance tracking and payload tracking of all activities in the composite. This is useful for development and debugging purposes – but has performance impact.
Inherit the audit level setting from its parent component. See the inherit and override section below for more details.
Inherit and Overrides
As you have seen in the SOA Infrastructure overview above, there are multiple levels of container or engines at play when you are executing a SOA composite. Some of the main players for the execution from SOA Suite perspective are SOA Infrastructure, Service Engine, SOA Composite and Composite Components (SCA components within a composite).
These layers follow the normal Java Object property rules namely:
- Any child level can inherit the configuration information from its parent level. For example, if the SOA Composite audit level is set to inherit, then the messaging framework will look up the audit configuration at the service engine level for understanding what to do. If service engine audit level is set to inherit, then SOA infrastructure level values are taken into consideration.
- At child level you can override the configuration property to use by the messaging framework. For example if the SOA infrastructure audit level is set to Development & the BPEL service engine audit level is set to off, then none of the BPEL component audit trails will be captured.
Note that by default audit level for SOA infrastructure is set to Production and for all other levels, the level is set to inherit.