All posts · OIC Integrations

Using the Oracle DB Adapter in OIC

The Database Adapter is one of OIC's most powerful connectors — here's how to use it safely for queries, stored procedures, and batch operations.

Anurag Jangra · February 18, 2026 · 7 min read · ... views

What the DB Adapter does

The Oracle Database Adapter lets OIC interact directly with Oracle and non-Oracle databases — executing SQL queries, calling stored procedures and functions, and performing DML operations. It’s one of the most used adapters in enterprise OIC deployments because so much business logic lives in the database layer.

Connection setup

To connect, you need a JDBC connection string, credentials, and — for on-premise databases — the OIC Connectivity Agent installed on a server that can reach the database. Cloud databases (ATP, ADW) connect directly using wallet-based authentication.

For ATP:

  1. Download the wallet from OCI Console
  2. Upload to OIC as a credential under Settings → Certificates
  3. Create a DB Adapter connection using the ATP service name from the wallet

Adapter operation types

Run a SQL Query — executes a SELECT and returns results as XML. Best for simple lookups.

Invoke a Stored Procedure — calls a PL/SQL procedure or function. The adapter introspects the procedure signature and generates the request/response schemas automatically. This is the preferred pattern for complex data operations.

Perform an Operation — supports INSERT, UPDATE, DELETE via drag-and-drop field mapping. Use for straightforward DML.

Rather than writing raw SQL in the adapter configuration, wrap your logic in a stored procedure and call it from OIC. Benefits:

  • Business logic stays in the database, testable independently
  • Procedure changes don’t require OIC integration changes
  • Better error handling via OUT parameters
PROCEDURE get_order_status (
  p_order_id  IN  NUMBER,
  p_status    OUT VARCHAR2,
  p_error     OUT VARCHAR2
) AS BEGIN
  SELECT status INTO p_status FROM orders WHERE id = p_order_id;
  p_error := NULL;
EXCEPTION
  WHEN NO_DATA_FOUND THEN p_error := 'Order not found';
END;

Pagination for large result sets

Never execute an unbounded SELECT through OIC. Always pass ROWNUM or use OFFSET/FETCH:

SELECT * FROM transactions
WHERE processed_date > :lastRun
ORDER BY id
FETCH FIRST :batchSize ROWS ONLY

Loop in OIC using a While activity until the result set returns fewer rows than the batch size.

Security notes

Use a dedicated read-only DB account for SELECT-based integrations. Write operations should go through stored procedures that enforce business rules. Never store credentials in integration configurations — use OIC’s credential store.

Think Beyond the Implementation

Questions worth sitting with after reading this

01

Why is this architecture appropriate for this specific context — and where would it be the wrong choice?

02

What assumptions did we make that aren't stated explicitly? What happens if those assumptions are wrong?

03

What would break first if the requirements changed — volume doubled, a third system was added, or the deadline halved?

04

What alternatives did we reject, and why? Was the decision made on evidence — or habit?

AJ
Anurag Jangra
Oracle Cloud PaaS Consultant · OIC & VBCS Specialist

4.5+ years delivering enterprise Oracle Cloud integrations and VBCS applications across manufacturing, IT services, and financial sectors. OCI Certified — writes about real-world OIC, VBCS, SQL, and BI Publisher patterns from production experience.

Chat on WhatsApp