2.2 Auditing and Exception Handling

In a component architecture it is paramount that interaction between systems can be tracked and audited. The following is a list of system behaviors and features that support auditing and exception handling in OHI Components:

• Messages that indicate any kind of failure are always logged. Messages that confirm a successful result within the context of synchronous interaction are not logged. The overhead for logging these would impact the performance of these relatively lightweight operations. Messages that indicate failure are logged together with data that can help to determine the cause.
• If an OHI Components application cannot deliver a message, it will not retry that operation instantly. This behavior is based on the underlying assumption that a network failure that prevents successful interaction is not going to be resolved instantly. Instead, a task is raised for delivering the message at a later moment in time, to be triggered by a system operator as soon as the network is restored. 
• For SOAP services, OHI Components applications can validate if message payloads adhere to the XSD specification. This feature is configurable on a per web service basis and is disabled by default for performance reasons.
• The logging subsystem can be configured to gather message payloads in log files. Specific measures can be taken for logging message payloads that may contain protected health information. Additional details for checking interfaced messages and results of processing these are documented elsewhere in this guide.