DEV Community

Rajesh Vohra
Rajesh Vohra

Posted on

Bringing OIC Execution Logs into APEX‑Driven Logging Tables

As integrations proliferate and complexity grows, having the ability to see what's happening behind the scenes is no longer a luxury - it's a necessity. By combining Oracle Integration Cloud's powerful capabilities with a custom logging platform in Oracle APEX (and your database), you gain control, transparency, and actionable insight.
If you're working in the Oracle ecosystem and you haven't implemented a structured logging strategy for your integrations, this repo is a strong starting point. I welcome your feedback, forks or suggestions - let's make logging smarter and integrations more traceable.
As a technical developer working with integrations, one of the core necessities is visibility - being able to inspect what your integration platform executed, when, and with what outcomes. That's especially true when working with Oracle Integration Cloud (OIC).
In many environments the default logging might live in OIC's monitoring dashboard, but often you'll want a custom, centralized store - one you can query, report on, correlate with other events, or bring into your own applications. That's where leveraging Oracle APEX + a relational table structure comes in.
My repository "OIC‑Logs‑in‑APEX" provides an end‑to‑end reference implementation: from table definition → to APEX process → to OIC REST call payload. I've outlined the solution below, and you can dig into the code and adapt it for your own projects.
Overview
At a high level, the solution consists of:
A dedicated database table (in an Oracle schema) for storing each log entry from OIC.
An Oracle APEX page or process (PL/SQL) which receives log details (for example via a REST request or manual entry) and inserts into the table.
A "REST‑source" design so that OIC can send JSON payloads to the APEX endpoint.
Documentation (README) and directory structure so you can deploy or adapt quickly.

Here's the directory structure of the repository:
oracle‑apex‑oic‑logging/
├── db/
│ └── logging_table.sql
├── apex/
│ └── insert_log_example.sql
├── rest/
│ └── oic_log_sample.json
└── README.md
As noted in the README:
db/logging_table.sql – defines the logging table. GitHub
apex/insert_log_example.sql – example PL/SQL to insert a log entry (can be used as part of an APEX page/process). GitHub
rest/oic_log_sample.json – an example JSON payload that OIC could send to the APEX REST endpoint. GitHub

Step‑by‑Step Breakdown

  1. Database setup (table definition)  You begin by creating a logging table in your Oracle database. The table stores information such as Integration ID, Log Level, Log Message, timestamp, etc. The idea is to have a structure that can capture each invocation or event from OIC for visibility and traceability.  In the repo you'll find the logging_table.sql under db/. You can run this from SQL*Developer or via APEX's SQL Workshop to create the table.
  2. APEX setup (PL/SQL process)  Next, you build an APEX page (or you could leverage ORDS directly) to receive the log details. In APEX your page might have form items for: "Integration ID", "Log Level", "Log Message", and any custom metadata you consider important (e.g., user, timestamp, correlation id).  Then you have a process (on submit or triggered via REST) which executes the PL/SQL logic in insert_log_example.sql (found in apex/). That PL/SQL will insert the values into the logging table.
  3. REST / OIC integration  To automate logging from OIC, you configure a REST call in OIC (or in APEX using ORDS) such that when an integration executes, it sends a JSON payload to the APEX endpoint. The example payload is in rest/oic_log_sample.json. OIC's monitoring or fault‑handling flows may trigger this. The repository README mentions: "OIC can call your APEX REST endpoint with a JSON payload like rest/oic_log_sample.json." GitHub  The APEX endpoint then uses the process to insert into the table.
  4. Viewing and reporting the logs  Once data flows into the logging table, you now have a custom viewable data set. You can query OIC_LOGS (or whatever your table is named) from SQL Developer or APEX SQL Workshop. You can also build an APEX report page to allow your team to search/filter logs by integration id, log level, date, etc. The README mentions: "Query the OIC_LOGS table … or make a report page in APEX to view logged entries." GitHub

Advantages of this Approach
– Enhanced visibility: Instead of piecing together logs from disparate sources, you have integration logs stored in your database.
 - Custom analytics & dashboards: Because the logs live in a table you control, you can build your own reports, dashboards, trends (e.g., error rates over time, integration durations, user impact).
 - Correlations: You might join integration log data with other business tables (for example, orders, shipments, user actions) - this enables richer root‑cause and impact analysis.
 - Centralised support: For support teams, having a queryable log table is a game‑changer for troubleshooting.
 - Reuse & standardisation: You define a pattern (table + APEX endpoint + OIC call) which you can replicate across multiple integrations, leading to consistent logging practice.


How You Can Use/Adapt the Repo
Here are some suggestions:
Fork the repo and adapt logging_table.sql to include additional columns your organisation needs (e.g., user_id, correlation_token, source_system, execution_time_ms).
Use the APEX PL/SQL example as a template; extend it by adding error‑handling (e.g., if insert fails, write to fallback table), add logging severity categories, or link to parent/child integrations.
Expose your APEX app (or ORDS service) via HTTPS and secure it (OAuth, API Key) so that OIC can post logs securely.
In OIC, integrate this log posting at key points: on successful completion, on fault, or even on intermediate steps if you want granular insight.
Build an APEX report/dashboard: e.g., a region filtered by log level = ERROR, show details, sort by timestamp, drill into integration id, link back to the business transaction.
Consider retention/purging strategy: since logs may grow large over time, you might include a job to archive older logs or summarise them.

GitHub Link & Usage
GitHub repository: https://github.com/rajeshvohra/OIC-Logs-in-APEX

Top comments (0)