Logging to a Central Database

Introduction

Oracle Health Insurance applications and the runtime technology stack provide the following log types:

Security Log
Protected Health Information (PHI) Log
Dynamic Logic Log
Application Log
JVM Garbage Collection (GC) Log
Server Output Logs

The application provides database storage and HTTP API resources for the Security, PHI, Dynamic Logic, and Application logs. The JVM GC and Server Output logs provide runtime diagnostics separately from these database logs.

Log Types

Security Log

The Security log records security-related events, including login attempts, user account creation, and changes to privileges. Use it to audit security-related activity. For file-based logging configuration, see Security Audit Log. For database access and a sample response, see Fetch Security Logs through the API.

Protected Health Information (PHI) Log

The PHI log records access to and updates of monitored resources containing protected health information (PHI) or personally identifiable information (PII). It identifies the user, the resource, and the operation. The monitored resources depend on the application; see Resource Auditing.

The system property ohi.logging.target determines where PHI access audit messages are stored:

database: The application writes the audit entry to log_phi_events while processing the HTTP API request that accesses or updates the monitored resource. Retrieve these entries through generic/logphievents.
log: The application writes PHI access audit messages through a configured Logback appender with the PHI filter. For configuration details, see Protected Health Information (PHI) Log.

For example, when a client sends a GET request to retrieve a monitored resource containing a member’s personal information, the application records that access. With ohi.logging.target=database, it saves the audit entry while handling that GET request. The request refers to the operation on the monitored resource, not a later request to retrieve the audit log.

Dynamic Logic Log

The Dynamic Logic log records messages produced during dynamic logic execution. Each execution has a unique execution ID that links its log messages. Use this log to follow script execution and investigate script behavior. See Logging Dynamic Logic Execution for configuration and Steps to Follow Dynamic Logic Execution for sample messages.

Application Log

The Application log contains informational messages, warnings, and errors from the Oracle Health Insurance application. It excludes messages belonging to the Security, PHI, and Dynamic Logic logs. Use it to investigate application behavior and runtime errors. See Application Log for database appender configuration and Steps to Retrieve Log Messages for query examples.

JVM Garbage Collection (GC) Log

The JVM GC log contains garbage collection statistics for a Java Virtual Machine. Use these statistics to investigate memory usage and garbage collection pauses. See Garbage Collection Statistics for instructions to capture this data.

Server Output Logs

The application server writes technical information about the state of its JVM processes to server output logs. Use these logs to investigate server-level issues, including application startup failures. These logs are managed by the application server and are separate from the application log events available through the HTTP API.

Store and Retrieve Logs in the Database

When each JVM writes to separate log files, it can be difficult to obtain a complete overview. The following table lists the database tables and HTTP API resources for application-managed logs.

Table 1. Database Log Tables and HTTP API Resources
Log	Database Table	HTTP API Resource
Application log	`log_application_events`	`generic/logapplicationevents`
PHI log	`log_phi_events`	`generic/logphievents`
Dynamic Logic log	`log_dylo_events`	`generic/logdynamiclogicevents`
Security log	`LOG_SECURITY_EVENTS`	`generic/logsecurityevents`

Use the HTTP API resources to access or query stored messages. The sections for each log type describe its configuration and access.

The Oracle Health Insurance Logback Database Appender

Oracle Health Insurance applications use the Logback framework, which supports appenders that write log messages to destinations such as files. Adjust the logging level for a specific logger, package, or class to obtain more detailed diagnostic data.

For Application and Dynamic Logic logs, the Oracle Health Insurance Logback Database Appender initially writes events to a file-backed buffer queue. It then persists the queued events to the database. PHI access audit entries use the request-based persistence described in Protected Health Information (PHI) Log.

The Oracle Health Insurance Database Appender expects log messages formatted as JSON documents with a specific structure. It uses the Logstash Logback Encoder for JSON encoding. The Oracle Health Insurance Database Appender applies the following default configuration settings for the encoder:

<encoder class="net.logstash.logback.encoder.LogstashEncoder">
  <providers>
    <mdc/>
    <context/>
    <nestedField>
      <fieldName>markers</fieldName>
      <providers>
        <logstashMarkers/>
      </providers>
    </nestedField>
    <nestedField>
      <fieldName>arguments</fieldName>
      <providers>
        <arguments/>
      </providers>
    </nestedField>
    <pattern>
      { "ohiLevel": "%ohiLevel" }
    </pattern>
    <fieldNames>
      <timestamp>timestamp</timestamp>
    </fieldNames>
  </providers>
</encoder>

When adjusting the settings, retain the defaults that Oracle Health Insurance applications rely on. The following example adds a specific configuration for stack traces:

<encoder class="net.logstash.logback.encoder.LogstashEncoder">
  <providers>
    <mdc/>
    <context/>
    <nestedField>
      <fieldName>markers</fieldName>
      <providers>
        <logstashMarkers/>
      </providers>
    </nestedField>
    <nestedField>
      <fieldName>arguments</fieldName>
      <providers>
        <arguments/>
      </providers>
    </nestedField>
    <pattern>
      { "ohiLevel": "%ohiLevel" }
    </pattern>
    <fieldNames>
      <timestamp>timestamp</timestamp>
    </fieldNames>
    <stackTrace>
      <throwableConverter class="net.logstash.logback.stacktrace.ShortenedThrowableConverter">
        <maxDepthPerThrowable>30</maxDepthPerThrowable>
        <maxLength>2048</maxLength>
        <shortenedClassNameLength>20</shortenedClassNameLength>
        <exclude>^sun\.reflect\..*\.invoke</exclude>
        <exclude>^net\.sf\.cglib\.proxy\.MethodProxy\.invoke</exclude>
        <rootCauseFirst>true</rootCauseFirst>
      </throwableConverter>
    </stackTrace>
  </providers>
</encoder>

The following table lists other configuration options for the Oracle Health Insurance Database Appender:

Table 2. Configuration Options for Database Appender
Parameter	Explanation	Required
`connectionSource`	For the Oracle Health Insurance Database Appender to work, it needs access to a database. Use only a `JNDI Connection Source`. If no connection source is specified, the application does not start. It throws an `IllegalStateException` with the message "OhiAppender cannot function without a connection source".	Yes
`logType`	The supported log types are `application` and `dylo`. If no log type is specified, the application does not start. It throws an `IllegalStateException` with the message "OhiAppender cannot function without a specific log type".	Yes
`bufferDir`	The Database Appender buffers log messages in a file-backed queue or buffer. The system writes the queue files in the specified directory. The application uses the value of system property `java.io.tmpdir` if no value is specified for `bufferDir`. If the application cannot write to the directory, it does not start. It throws an `IllegalStateException` with the message "Cannot write to path <path>".	Yes
`drainInterval`	By default, the file-backed queue drains every five milliseconds. Override this value if needed. The minimum is one millisecond. Specifying a drain interval of less than one millisecond prevents the application from starting. It throws an `IllegalStateException` with the message "Invalid timeout to drain queue specified: <specified_time_interval>".	No
`drainBatchSize`	By default, messages from the file-backed queue are persisted in batches with a maximum size of `2000`. Override this value if needed. The minimum batch size is one, but this value is extremely inefficient. If the specified batch size is smaller than one, the application does not start. It throws an `IllegalStateException` with the message "Invalid batch size for draining queue specified: <specified_time_interval>".	No
`rollCycle`	Files for the file-backed queue roll over periodically. Files that are no longer in use are automatically removed to limit disk space usage. Use this parameter to specify the roll cycle. The default value is `FAST_HOURLY`, which allows storing 256 million entries per hour (disk space permitting). The alternative value is `DAILY` (four billion entries per day). Contact the Oracle Health Insurance development team in an unusual case where the buffer needs to accommodate larger numbers of log entries.	No
`duplicateDuration`	Setting a value for this parameter filters duplicate events with level `ERROR`. This prevents a large volume of repeated messages for the same `ERROR` in a short time. The application considers an `ERROR` event a duplicate if an event for the same logger and raw message was logged within the last `duplicateDuration` milliseconds. This only applies to `ERROR` messages in the Application log. It is disabled by default. Setting this value to `300000` milliseconds logs an error message once per thread and suppresses repeats of that message in that thread for the next five minutes.	No

The log type parameter for the Appender controls:

Proper filtering of log messages. For example, to ensure that PHI log messages do not show up in the Application log.
Storage of log messages in the database.

The following paragraphs list the Logback configuration for each of these logs.

The following points apply to the configuration examples:

The following Logback configuration samples omit the encoder, implying the use of the Oracle Health Insurance default settings for it.
The examples use placeholder buffer directory locations: /writable/log/storage/buffer/….. Configure a writable buffer directory. Otherwise, the application logs an IllegalStateException in the managed server log.

Logging Dynamic Logic Execution

The following example configures the Oracle Health Insurance Database Appender for Dynamic Logic execution logging:

<configuration debug="true" scan="true" scanPeriod="60 seconds">
 <contextListener class="ch.qos.logback.classic.jul.LevelChangePropagator"/>

 <conversionRule conversionWord="ohiLevel"
  converterClass="com.oracle.healthinsurance.utils.logging.logback.OhiLogLevelConverter"/>

 <appender name="dyloAppender"
  class="com.oracle.healthinsurance.loggingsupport.appender.impl.OhiAppender">
     <connectionSource class="ch.qos.logback.core.db.JNDIConnectionSource">
         <jndiLocation>jdbc/policiesUserOhiApplicationDS</jndiLocation>
     </connectionSource>
     <logType>dylo</logType>
     <bufferDir>/writable/log/storage/buffer/dylo</bufferDir>
 </appender>

 <root level="info">
     <appender-ref ref="dyloAppender" />
 </root>
</configuration>

All Dynamic Logic scripts are in the package namespace ohi.dynamiclogic.

To enable logging any statement for that package, add the following logger:

<logger name="ohi.dynamiclogic" level="trace"/>

Application Log

The following example configures the Oracle Health Insurance Database Appender for remaining log messages that must not appear in the PHI or Dynamic Logic log:

<configuration debug="true" scan="true" scanPeriod="60 seconds">
 <contextListener class="ch.qos.logback.classic.jul.LevelChangePropagator"/>

 <conversionRule conversionWord="ohiLevel"
  converterClass="com.oracle.healthinsurance.utils.logging.logback.OhiLogLevelConverter"/>

 <appender name="applicationAppender"
  class="com.oracle.healthinsurance.loggingsupport.appender.impl.OhiAppender">
     <connectionSource class="ch.qos.logback.core.db.JNDIConnectionSource">
         <jndiLocation>jdbc/policiesUserOhiApplicationDS</jndiLocation>
     </connectionSource>
     <logType>application</logType>
     <bufferDir>/writable/log/storage/buffer/application</bufferDir>
 </appender>

 <root level="info">
     <appender-ref ref="applicationAppender" />
 </root>
</configuration>

Fetch Security Logs through the API

Security logs are written to the LOG_SECURITY_EVENTS table and can be fetched through the generic/logsecurityevents API.

The following is an example response for logsecurityevents:

[
  {
    "accessTokenId": "a0e079040f6949e4b2659f0914f77406",
    "apiEndpoint": "/api/users",
    "eventCategory": "User provisioning",
    "eventMessage": "User user1 is updated.",
    "eventOutcome": "SUCCESS",
    "eventSeverity": "INFO",
    "eventType": "User updated",
    "httpStatusCode": 200,
    "user": "testuser1",
    "sourceIp": "10.211.3.44",
    "sourcePort": "44670",
    "vcnOcid": "ocid1.vcn.oc1.ap-zzz-1.amaaaaaa5vehu5ya4rln6nqcok6xov7r6g77w6753qwzy3ta3ucwi7acyrqa"
  },
  {
    "sessionID": "f76e4272ce994a79b6c303d9174cb0f4:f400e3",
    "apiEndpoint": "/api/generic/persons",
    "eventCategory": "Intrusion detection",
    "eventMessage": "Possible intrusion detected in domainattribute Person.name with arguments: null",
    "eventOutcome": "FAILURE",
    "eventSeverity": "ERROR",
    "eventType": "Intrusion detected",
    "failureReason": "Intrusion detected",
    "httpStatusCode": 400,
    "user": "testuser1",
    "sourceIp": "10.211.3.44",
    "sourcePort": "44670",
    "vcnOcid": "ocid1.vcn.oc1.ap-zzz-1.amaaaaaa5vehu5ya4rln6nqcok6xov7r6g77w6753qwzy3ta3ucwi7acyrqa"
  }
]

While fetching, it is recommended to use pagination based on eventDate and/or using PHI_LOG_SECURITY_EVENTS_BV, along with the data transfer feature.

To fetch logsecurityevents using pagination, send a POST request to the following endpoint with the JSON payload shown below:

http://[hostName]:[portNumber]/[api-context-root]/generic/logsecurityevents/search

{
  "resource": {
    "orderBy": "eventDate:desc",
    "q": "eventDate.gt('2025-11-25').and.eventDate.lt('2025-11-27')",
    "limit": 200
  },
  "resourceRepresentation": {
    "fields": "id|eventMessage|sourceIp|sourcePort|vcnOcid|user|eventDate|eventCategory|eventType|eventSeverity|eventOutcome|apiEndpoint|accessTokenId|sessionId|httpStatusCode"
  }
}

To transfer logs in bulk and avoid multiple POST search requests, send a POST request to the following endpoint with the JSON payload shown below:

http://[hostName]:[portNumber]/[api-context-root]/datatransfer

{
  "columns": [
    {
      "expr": "lse.virtual_access_token_id"
    },
    {
      "expr": "lse.virtual_api_endpoint"
    },
    {
      "expr": "lse.virtual_event_category"
    },
    {
      "expr": "lse.virtual_event_date"
    },
    {
      "expr": "lse.virtual_event_message"
    },
    {
      "expr": "lse.virtual_event_outcome"
    },
    {
      "expr": "lse.virtual_event_severity"
    },
    {
      "expr": "lse.virtual_event_type"
    },
    {
      "expr": "lse.virtual_failure_reason"
    },
    {
      "expr": "lse.virtual_hostname"
    },
    {
      "expr": "lse.virtual_http_status_code"
    },
    {
      "expr": "lse.virtual_session_id"
    },
    {
      "expr": "lse.virtual_sourceip"
    },
    {
      "expr": "lse.virtual_sourceport"
    },
    {
      "expr": "lse.virtual_user"
    },
    {
      "expr": "lse.virtual_vcnocid"
    }
  ],
  "from": "PHI_LOG_SECURITY_EVENTS_BV lse",
  "where": "lse.virtual_event_date > TO_DATE('2025-11-25', 'YYYY-MM-DD') and lse.virtual_event_date < TO_DATE('2025-11-27', 'YYYY-MM-DD')",
  "dataTransferFormat": "JSON",
  "description": "Security events generated between 25th to 27th November 2025"
}

The sourceIp, sourcePort, and vcnOcid attributes are available in SaaS (software-as-a-service) deployments.

For on-premises deployments, add the Mapped Diagnostic Context (MDC) field to the Logback pattern to include the user attribute.

The following example shows a Logback pattern that includes the user attribute from the MDC:

<appender name="securityAppender" class="ch.qos.logback.core.rolling.RollingFileAppender">
	<encoder>
		<pattern>%d{ISO8601} [ %t ] %marker %c - %m [user:%X{user:-N/A}]%n</pattern>
	</encoder>
	<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
		<!-- rollover daily -->
		<fileNamePattern>/ohi/logBase/${APPLICATION}/security/ohiSecurity-${SERVER_NAME}-%d{yyyy-MM-dd}.%i.log</fileNamePattern>
		<!-- or whenever a certain file size is reached -->
		<timeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFileNamingAndTriggeringPolicy">
			<maxFileSize>200MB</maxFileSize>
		</timeBasedFileNamingAndTriggeringPolicy>
		<maxHistory>30</maxHistory>
	</rollingPolicy>
	<filter class="com.oracle.healthinsurance.utils.logging.logback.OhiSecurityLevelFilter" />
	<filter class="com.oracle.healthinsurance.utils.logging.logback.OhiPHILevelFilter" >
		<inclusive>false</inclusive>
	</filter>
</appender>

The following table lists examples of logged security events:

Table 3. Example Security Events
Event	Description
Failed login	Authentication succeeds in IDCS, but the user is not present or not active in Oracle Health Insurance.
User provisioning	Create new users or update existing users.
Role provisioning	Add new roles or update existing roles.
Access restrictions	Create or update an access restriction.
Operational reports access	View, download, or access operational reports that contain PHI.
Extract IP	Extract any resource that contains PHI.
Credentials IP	Create or reset credentials.
Keystore IP	Create or update keystores or keys.
Malicious files	Upload malicious files.
Data file set IP	Download data files.
OAuth client secret configuration	Create or reset OAuth client credentials.

Configuration

The following example configures the Oracle Health Insurance Security Appender for security logging:

<configuration debug="true" scan="true" scanPeriod="60 seconds">
	<appender name="securityAppender"
  class="com.oracle.healthinsurance.loggingsupport.appender.impl.OhiSecurityLoggerAppender">
		<connectionSource class="ch.qos.logback.core.db.JNDIConnectionSource">
			<jndiLocation>jdbc/policiesUserOhiApplicationDS</jndiLocation>
		</connectionSource>
		<logType>security</logType>
		<bufferDir>/writable/log/storage/buffer/security</bufferDir>
	</appender>
	<root level="info">
		<appender-ref ref="securityAppender" />
	</root>
</configuration>

How to Track Oracle Health Insurance Appender Status

The Oracle Health Insurance Logback Database Appender can write messages about its state to the Oracle Health Insurance logs. Track the status of the Appender by using Logback status listeners and redirecting messages it writes to Standard Out and Standard Error to the server log.

Enable Logback Status Listeners for the Oracle Health Insurance Database Appender

To enable the Logback status listener:

Set the Logback configuration debug flag to true, as in the samples above.

Attach a status listener as in the following example:

<configuration>
  <statusListener class="ch.qos.logback.core.status.OnConsoleStatusListener" />
  ...
</configuration>

Refer to the Logback documentation for a complete overview of capabilities. The Oracle Health Insurance Logback Database Appender writes Logback status messages during initialization and shutdown.

How to Track the Logger’s Status Using Logback

The Oracle Health Insurance Database Appender uses separate threads to write messages from the file-backed queue to the database. Enable Logback loggers to write diagnostic messages from these threads. Log the messages about the Oracle Health Insurance Database Appender to a different Appender.

The following sample Logback configuration tracks the Oracle Health Insurance Database Appender by writing messages to a specific file Appender:

<conversionRule conversionWord="ohiLevel"
 converterClass="com.oracle.healthinsurance.utils.logging.logback.OhiLogLevelConverter"/>

<appender name="fileAppender" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <encoder>
        <pattern>%d{ISO8601} %ohiLevel %logger{3} - %m%n</pattern>
    </encoder>
    <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
        <fileNamePattern>target/ohiAppenderFile-%d{yyyy-MM-dd}.%i.log</fileNamePattern>
        <timeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFileNamingAndTriggeringPolicy">
            <maxFileSize>100MB</maxFileSize>
        </timeBasedFileNamingAndTriggeringPolicy>
    </rollingPolicy>
</appender>

<logger name="com.oracle.healthinsurance.loggingsupport.appender.impl.QueueFileListener"
 level="debug" additivity="false">
    <appender-ref ref="fileAppender"/>
</logger>
<logger name="com.oracle.healthinsurance.loggingsupport.appender.impl.OhiAppender"
 level="debug" additivity="false">
    <appender-ref ref="fileAppender"/>
</logger>
<logger name="com.oracle.healthinsurance.loggingsupport.appender.impl.LoggingEventBatchPersister"
 level="debug" additivity="false">
    <appender-ref ref="fileAppender"/>
</logger>

Access centrally stored log data using HTTP API resources. The following sections describe these resources and provide examples.

Steps to Retrieve Log Messages

Ensure that users have the appropriate access to the HTTP API resources.

Use the metadata specification to get the default representation for each resource. You can also fetch a sample response when you send the following POST request:

http://[hostName]:[portNumber]/[api-context-root]/generic/logapplicationevents/search

For example, the default representation for application log events looks like this:

{"id": "96558",
 "application": "authorizations",
 "applicationVersion": "3.18.1.0.0",
 "eventLevel": "ERROR",
 "eventLogger": "c.o.h.d.d.i.c.p.DataReplicationTargetSynchronizationTaskTypeProcessor",
 "eventMessage": "Failed to retrieve and / or store events, closing data replication extraction task",
 "eventThread": "[STANDBY] ExecuteThread: \"18\" for queue: \"weblogic.kernel.Default (self-tuning)\"",
 "hostName": "a_host",
 "instanceName": "authorizations_node1",
 "instanceType": "an_instance",
 "links": [
  {"href": "http://localhost:27041/api/generic/logapplicationevents/96558",
   "rel": "self"
  }
 ],
 "eventTimestamp": {
   "value": "2018-01-11T17:42:27.13+01:00"
  },
 "persistedTimestamp": {
   "value": "2018-01-11T17:42:31.304+01:00"
  }
}

Many attributes repeat for other logged messages as well.

When querying log messages, make sure to always filter on eventDate as the system indexes this field.
As the number of log messages increases, using eventDate as a filter helps maintain acceptable query performance.
If you are using eventTimestamp to order results, be sure to filter by a specific and narrow time range (for example, 5 minutes). This is especially important when DEBUG level logging is enabled for extended periods, as a narrow time range reduces memory usage and improves efficiency when loading and sorting large datasets.

Example 1: Steps to Check for Warnings and Errors in the Application Log

Use the Query API to find specific log messages. The following POST request returns errors or warnings in a specific hour on a specific day, ordered by the eventTimestamp of the messages:

POST: http://[hostName]:[portNumber]/[api-context-root]/generic/logapplicationevents/search

{
    "resource": {
        "q": "eventLevel.in('WARN','ERROR').and.eventDate.gt('2018-01-11T17:00:00').and.eventDate.lt('2018-01-11T18:00:00')",
        "orderBy": "eventTimestamp:asc"
    },
    "resourceRepresentation": {
        "fields": "eventMessage|eventTimestamp"
    }
}

The following example shows the results in a more concise form than the previous application log event example:

{"id": "96558",
 "eventMessage": "Failed to retrieve and / or store events, closing data replication extraction task",  "links": [
{"href": "http://[hostName]:[portNumber]/[api-context-root]/generic/logapplicationevents/96558",
   "rel": "self"
  }
 ],
 "eventTimestamp": {
   "value": "2018-01-11T17:42:27.13+01:00"
  }
}

Note the difference between eventDate and eventTimestamp:

The precision of eventDate is seconds. The system indexes eventDate specifically for executing such queries efficiently.
The precision of eventTimestamp includes microseconds and time zone information.

Example 2: Steps to Check for Debug Logs in the Dynamic Logic Log

Use the Query API to retrieve DEBUG level messages for a particular time window. The following POST request returns debug messages logged within a 5-minute interval, ordered by the eventTimestamp of the messages:

POST: http://[hostName]:[portNumber]/[api-context-root]/generic/logdynamiclogicevents/search

{
    "resource": {
        "q": "eventLevel.eq('DEBUG').and.eventDate.gt('2018-01-11T17:00:00').and.eventDate.lt('2018-01-11T17:05:00')",
        "orderBy": "eventTimestamp:asc"
    }
}

This approach is particularly beneficial when DEBUG logging is enabled for an extended period and generates a high volume of logs.

How to Check Access to PHI Data

The application writes an entry to the PHI log when a user accesses an Insured Member's Personally Identifiable Information. This can be through a web service or via the application’s user interface.

PHI logs in the SaaS database are retained for 60 days. After that, they are moved to Object Storage. See Move PHI Logs to Object Storage for more details.

Steps to Follow Dynamic Logic Execution

Use the Dynamic Logic log to inspect Dynamic Logic executions.

For every Dynamic Logic execution, the system generates a unique execution ID that all messages logged during that execution carry.

The following sample messages show the execution of a Dynamic Logic script (edited for readability):

{
  "message" : "execution starts",
  "logger_name" : "ohi.dynamiclogic",
  "level" : "TRACE",
  "markers" : {
    "scriptexecutionid" : "da2e6719-e5d2-4112-85b9-4321929aeed9"
  }
}
{
  "message" : "Binding foo set to bar",
  "logger_name" : "ohi.dynamiclogic",
  "level" : "TRACE",
  "markers" : {
    "scriptexecutionid" : "da2e6719-e5d2-4112-85b9-4321929aeed9"
  }
}
{
  "message" : "result: true of type: class java.lang.Boolean",
  "logger_name" : "ohi.dynamiclogic",
  "level" : "TRACE",
  "markers" : {
    "scriptexecutionid" : "da2e6719-e5d2-4112-85b9-4321929aeed9"
  }
}
{
  "message" : "execution completed",
  "logger_name" : "ohi.dynamiclogic",
  "level" : "TRACE",
  "markers" : {
    "scriptexecutionid" : "da2e6719-e5d2-4112-85b9-4321929aeed9"
  }
}

How to Bundle Log Messages in a Data File Set

Use HTTP API resource generic/logfilesetspecifications to specify parameters for bundling multiple messages in a Data File Set.

Bundling log messages is not available for log type phi.

The following table explains the attributes for a log file set specification:

Table 4. How to Bundle Log Messages in a Data File Set
Attribute	Explanation	Required	Sample Value
`logType`	The log type whose messages are bundled into a set.	Yes	One of `application` or `dylo`.
`startDateTime`	The application selects messages with an `eventTimestamp` between the specified `startDateTime` and `endDateTime` (see next row) to include in the data file set.	Yes	`2018-01-12T00:00:00`
`endDateTime`	The time between `startDateTime` and `endDateTime` must not exceed two days by default. Adjust system property `ohi.logging.fileset.max.timespan` to specify larger periods. Configure the database to accommodate the creation of data file sets that span a larger time.	Yes	`2018-01-14T00:00:00`
`logLevel`	The log level filter. The specified value selects messages as follows: `ERROR` results in the selection of messages with level ERROR only. `WARN` results in the selection of messages with levels ERROR and WARN. `INFO` results in the selection of messages with levels ERROR, WARN, and INFO. `DEBUG` results in the selection of messages with levels ERROR, WARN, INFO, and DEBUG. `TRACE` results in the selection of messages with levels ERROR, WARN, INFO, DEBUG, and TRACE.	No	`ERROR`
`logger`	Filter for a specific logger.	No	`healthinsurance.loggingsupport.components`

The resource supports creating a log file set specification only. It is impossible to change or delete existing log file set specifications.

After the application accepts the log file set specification request, it starts the creation of the Data File Set immediately. The application creates data files containing messages in the original JSON format. The application returns the GET requests on the link to retrieve the resource location to the data file set.

Creating the Data File Set may take some time, depending on the number of messages to bundle and the system workload.

The system returns an error message if creation of the Data File Set fails.

Oracle Health Insurance applications keep the log file set specification and the resulting Data File Set for two days. The daily purge routine removes any older Data File Sets and the log file set specifications for these.

How to Add Loggers and Set Log Levels

At startup, the application takes the initial Logback configuration from a configuration file. Make sure that a single copy of that configuration is available for all nodes that execute an instance of an Oracle Health Insurance application. Use HTTP API resource generic/loggers to manage loggers:

Get an overview of custom loggers using the generic/loggers API by executing a GET request to generic/loggers.
Add a logger with a specific log level by executing a POST request to generic/loggers.
Update the level of an existing logger by executing a PUT request to generic/loggers/{id}.
Unset a logger by executing a DELETE request to generic/loggers/{id}. Here, the logger will inherit the log level of its parent.

The application propagates any changes made via the generic/loggers API to all nodes that execute an instance of an Oracle Health Insurance application.

To add a logger for package com.oracle.healthinsurance.datareplication.service at level DEBUG for 120 minutes, send the following JSON payload:

{"logger": "com.oracle.healthinsurance.datareplication.service"
,"logLevel": "DEBUG"
,"duration": 120
}

The application automatically removes the logger after the specified 120 minutes. To create a durable logger that the application cannot remove, set the duration to 0. The default duration for a logger is one hour. Alternatively, if the logger is no longer needed, remove it by sending a DELETE request for it.

The application does not add changes that the generic/loggers API makes to the Logback configuration file. Instead, it reactivates durable loggers after restarting.

At startup, the application initializes the specified loggers in the following order:

Loggers specified in the Logback configuration file.
Loggers defined using the generic/loggers API.

Customer-defined loggers may overwrite settings for loggers that are in the Logback configuration file.

The customer must maintain the customer-defined durable loggers.

Steps to Use the Diagnostic Context

Oracle Health Insurance applications log data in context. For example:

During Claims processing, Claims logs messages of the specific Claim, making it possible to gather all log messages for a specific Claim.
Track log messages that the application writes while processing web service requests using a trace ID provided in the request. If the application does not receive a trace ID, then it generates one and returns that in the response.