...
One log line contains standard parameters which can configure in file logback.xml (see documentation Logback lib: http://logback.qos.ch) that is used as logging platform. In addition the following custom logging parameters are used:
- LOG_SESSION_ID: unique HTTP session identifier. Thanks to this parameter can be grouped records from one user (system). This parameter is not filled if process is asynchronous and postponed (processed in the future).
- REQUEST_URI: URI of incoming request to integration platform. This parameter is not filled if process is asynchronous and postponed (processed in the future).
- REQUEST_ID: unique identifier of single request. Thanks to this parameter can grouped records from one request (HTTP request). This parameter is not filled if process is asynchronous and postponed (processed in the future).
- SOURCE_SYSTEM: identifier of source system which send inbound request
- CORRELATION_ID: unique identifier of single asynchronous message. Thanks to this parameter it can search all correlated records in log file for specific message. Note: this parameter is used by Log Viewer in admin gui to show correlated records.
- PROCESS_ID: optional identifier of process which identifies records correlated to one business process e.g. creating new user which is composed by two subprocess: create new user and activate it.
...
Detection | Severity | Recommended action | Description of problem |
Message in FAILED state
| WARN | Using the application log determine the causes of errors. | Asynchronous message ended up in the final status FAILED, which means that during the processing occurred an error (business or technical error). |
Message is a long time in the state WAITING_FOR_RES | WARN | Using the application log to make sure that we sent a message to the external system properly and correctly and, if necessary, we even received an acknowledgment of receipt of our report from external system.
| Asynchronous message is waiting to response from external system. If there are messages in this status for long time (normal response is received during a few of milliseconds) it means that the problem is on external system side. |
Message is a long time in the state PROCESSING | WARN | Checks whether repair mechanisms works as expected and why messages are still in PROCESSING status.
| Asynchronous message is in PROCESSING state. If some error occurs during processing a message and the message remains in this status, OpenHub has corrigible mechanism which changes after configurable time (default value is 300s) status of message to PARTLY_FAILED without changes of failed count (failed_count). |
External call is in FAILED_END status | WARN | Using the application log determine the causes of errors. | Only external call - confirmations can be in this status and it means the problem where OpenHub could not confirm processing of asynchronous message. Confirmation of result of processing asynchronous messages is joined only with some external systems. If the confirmation fails a workflow process is stopped because external system can have some dependencies to next processing of it. |
| Message is a long time in the state POSTPONED | WARN | Check configurable parameters asynch.postponedInterval, which stands for after how long becomes inactive message in processing state (PROCESSING, WAITING, WAITING_FOR_RES) marked as "not processing". | Messages in status POSTPONED are processed with the same mechanism as messages in PARTLY_FAILED status. Only one difference is that postponed messages are processed preferably. Note: if the behavior of this mechanism would be unexpected (around PARTLY_FAILED messages processing) so it will be the same unexpected behaviour during POSTPONED processing. |
| Tip |
|---|
See Operations which change message state for more details about state's workflow. |