CONFIG AREA

SETTING

PURPOSE

Fusion Embedding

VBCS app URL registered as Fusion Sandbox / Page Composer extension

Enables VBCS screens to be rendered natively within Fusion SaaS navigation pages as iFrame-hosted extensions

Identity Configuration

Enterprise identity provider (e.g., Azure Active Directory) federated to OCI IAM Identity Domains

Fusion and VBCS share a common enterprise identity provider for authentication. Users can access embedded VBCS screens without a secondary login gesture when federation/session policies are aligned.

OIC Connectivity

OAuth 2.0 client credentials or User Assertion

VBCS invokes OIC using the appropriate authentication pattern — client credentials for service calls or user assertion for transactional operations requiring user attribution.

Fusion GET Calls

OAuth 2.0 preferred; Basic Auth only for tightly controlled legacy patterns

Read-only lookups (employees, suppliers, GL accounts, cost centres) can be fetched directly from Fusion for low latency, but many programs route reads through governed integration layers for consistent policy and logging.

ORDS Access — Identity Propagation Pattern

Custom user-context propagation (for example ORDS pre-hook + database context)

VBCS propagates user context to ORDS through an explicit implementation pattern. Row-level security (VPD) and context-sensitive policies then apply based on mapped database context.

ORDS Access — Basic Auth

Custom Backend Service with Basic Auth credentials

VBCS routes ORDS calls through a server-side Custom Backend service configuration where Basic Auth credentials are stored centrally — credentials are never exposed to the browser client

TABLE

PURPOSE

KEY COLUMNS

EXT_REQUESTS

Staging table for VBCS-submitted requests before OPA approval

REQUEST_ID, FUSION_REF_ID, REQUESTED_BY, STATUS, CREATED_TS, OPA_INSTANCE_ID

EXT_AUDIT_LOG

Immutable audit trail of all system actions

LOG_ID, REQUEST_ID, ACTION, ACTOR, ACTOR_TYPE, TIMESTAMP, PAYLOAD_CLOB

EXT_INTEGRATION_MAP

Maps ATP records to Fusion Object IDs after write-back

ATP_ID, FUSION_OBJECT_TYPE, FUSION_OBJECT_ID, SYNC_STATUS, LAST_SYNC_TS

EXT_CONFIG

Runtime configuration values (thresholds, routing rules)

CONFIG_KEY, CONFIG_VALUE, EFFECTIVE_FROM, EFFECTIVE_TO

AREA

IMPLEMENTATION

REASON

Schema Ownership

Single schema only (no multi-schema split)

Consistent grants, easier CI/CD migration, and clean ownership boundaries

API Grouping

Multiple ORDS modules and templates in the same schema

Predictable endpoint layout and easier lifecycle management

VBCS Access — Identity Propagation Pattern

Custom user-context propagation (for example ORDS pre-hook + database context)

VBCS can propagate user context to ORDS through an explicit implementation pattern. Row-level security (VPD) and context-sensitive policies then apply based on mapped database context.

VBCS Access — Backend Basic Auth

VBCS Custom Backend Service with Basic Auth credentials

An alternative access path where VBCS routes ORDS calls through a server-side custom backend configuration — credentials are stored and managed centrally, never surfaced to the browser

OIC Access Path

OIC REST connection invokes the same ORDS endpoints with Basic Auth (service account)

Single canonical API contract for both orchestration and UI retrieval; OIC holds service-account credentials as a managed connection property

OPA Access Path

OPA calls ORDS endpoints directly for in-workflow data reads and status updates

Keeps OPA self-sufficient for data operations within the approval lifecycle — avoiding a round-trip through OIC for simple database interactions

①

REST Trigger (Inbound from VBCS)

VBCS invokes OIC's REST trigger endpoint using the configured authentication pattern. OIC validates the request and captures the originating user's identity — preserving it for downstream attribution throughout the entire integration flow.

②

Data Enrichment & Routing Logic

OIC's mapper transforms the VBCS JSON payload into a canonical internal format. A Decision model or configuration lookup in OIC (EXT_CONFIG) determines routing rules — which OPA process to launch, which Fusion object to invoke, and what approval threshold applies.

③

ATP Write via ORDS (Staging Record)

OIC calls the ORDS POST /requests/submit endpoint using the managed ATP ORDS connection (Basic Auth service account). The requestedBy field carries the original username extracted from the VBCS token. On success, OIC captures the new REQUEST_ID for correlation throughout the workflow lifecycle.

④

Secure Integration → OPA

OIC invokes Oracle Process Automation using an explicitly configured OAuth 2.0 client (or equivalent supported credential pattern), and propagates the originating user's business context in the process initiation payload. OIC then calls the process instantiation API to launch a workflow instance with consistent business-user attribution for task routing and audit traceability.

⑤

Fusion Object API Call

For conditional Fusion data operations — supplier validation, GL account checks, or any lookup required for routing — OIC calls the appropriate Fusion REST endpoint using dedicated service credentials. The Fusion identity domain enforces Fusion-specific data roles, row-level security, and business rule validation. OIC adds requestedBy or equivalent audit metadata to preserve business-user attribution.

⑥

Response to VBCS

OIC returns a structured JSON response containing the ATP REQUEST_ID, the OPA processInstanceId, and a status polling URL. VBCS stores these correlation identifiers for real-time status tracking within the embedded Fusion screen.

CONNECTION

ADAPTER

AUTH METHOD

NOTES

Inbound from VBCS

REST Trigger

OAuth 2.0 / User Assertion / Basic Auth

Authentication pattern is configured per deployment model. OIC captures the originating user's identity and propagates it as an audit attribute through all downstream calls.

OPA REST API

REST

OAuth 2.0 service client + propagated business context

Base URL: OPA instance domain + /process/api/v1; process instances are launched with user attribution fields for task traceability and audit compliance.

ATP via ORDS

REST

Basic Auth (service account)

Managed OIC connection; uses ORDS module/template endpoints from the single application schema; base URL: /ords/<schema>/

Fusion Cloud REST APIs

Oracle ERP Cloud / REST

OAuth 2.0 (service credentials)

Service credentials registered in OCI IAM Identity Domains carry Fusion-specific data roles and row-level security context. OIC enriches all calls with requestedBy attributes to preserve business-user traceability in integration and business logs.

▶

OPA → ORDS: In-Workflow Database Operations

OPA calls ORDS REST endpoints directly for all database read and write operations that occur within the workflow lifecycle — fetching task context data, updating request status fields (e.g., EXT_REQUESTS.STATUS = 'PENDING_L2'), writing interim approval decisions to EXT_AUDIT_LOG, and reading configuration thresholds from EXT_CONFIG to drive conditional routing logic. This direct OPA-to-ORDS path keeps database interactions fast and self-contained within the process engine.

▶

OPA → OIC: Actionable Item Delegation

For operations that transcend data persistence — sending structured notifications, triggering Fusion write-backs, invoking external system calls, or executing complex multi-system orchestration — OPA delegates to OIC integration flows via REST callback invocations. This preserves the architectural principle that OIC is the sole authorised orchestration agent for cross-system mutations, while allowing OPA to remain the authoritative owner of workflow state and human-task management.

✅  Sequential Approval

L1 → L2 → FINANCE

Standard pattern for purchase requests. Each approver receives a human task in their embedded Fusion task list. OPA routes to the next stage on approval, or terminates on rejection — triggering an OIC callback to update the ATP staging record and push a real-time notification to the originating VBCS user.

⚡  Parallel Approval

SIMULTANEOUS REVIEWS

Legal and Compliance review in parallel. OPA waits for both branches to resolve before proceeding via a gateway join condition. Reduces approval cycle time compared to sequential chains while maintaining full auditability of each parallel decision.

⏱️  SLA Escalation

TIMER BOUNDARY EVENTS

If an approver fails to act within the configured SLA window, OPA automatically escalates to their manager — resolved in real time from the Fusion HCM supervisor hierarchy via an OIC integration call — and dispatches a reminder notification, maintaining governance compliance without manual intervention.

A

Update ATP Record via ORDS

OIC calls ORDS to update EXT_REQUESTS.STATUS to APPROVED or REJECTED, writing the complete approver chain and decision timestamps into EXT_AUDIT_LOG for an immutable, regulatorily compliant audit trail.

B

Write-back to Fusion Objects (Approved Transactions Only)

On APPROVED status, OIC invokes the relevant Fusion Object REST API using dedicated service credentials to create or update the authoritative ERP record: a Purchase Order in Fusion Procurement, an invoice in Fusion Payables, a supplier qualification update in Fusion SCM.

C

Notify the Originating VBCS User

OIC dispatches a structured notification — via Oracle Notification Service or a VBCS application webhook endpoint — updating the embedded Fusion screen in real time so the originating user is immediately informed of the approval outcome without needing to poll or navigate away.

DOMAIN

OBJECT

ENDPOINT FRAGMENT

OIC OPERATION

 Procurement  

Purchase Orders

/purchaseOrders

POST (create PO after approval)

 Procurement  

Suppliers

/suppliers

GET (validate supplier)

 HCM  

Workers

/workers

GET (resolve manager for escalation)

 HCM  

Assignments

/emps/{id}/child/assignments

GET (cost center / grade)

 Financials  

GL Accounts

/ledgerAccounts

GET (validate account combination)

 Financials  

Invoices

/invoices

POST (create payable invoice)

SCM

Items

/items

GET/PATCH (item master updates)

 Projects  

Projects

/projects

GET (project code validation)

 OIC as the Primary Write Gateway: In this architecture, POST, PATCH, and DELETE operations against Fusion REST APIs are executed by OIC using dedicated service credentials that carry the requisite Fusion data roles and row-level security context. OIC enriches every call with requestedBy or equivalent metadata so business-user attribution is preserved alongside the authenticated technical principal. Read-only GET calls can be direct from VBCS where allowed, but many implementations prefer governed API/integration paths for centralized policy, throttling, and observability.

📘  Manual Journal Upload Dashboard

VBCS + OPA + OIC + ORACLE FINANCIALS

Finance users upload Excel journal files through VBCS, where file details are validated and routed into an approval workflow in OPA. After approval, OIC transforms the spreadsheet content and integrates the journal entries into Oracle Financials with full status tracking and audit visibility.

🧾  AR Invoice Upload Dashboard

VBCS + OPA + OIC + ORACLE RECEIVABLES

Users upload Excel-based AR invoice data in VBCS, trigger an approval process in OPA, and monitor upload status from a centralized dashboard. Once approved, OIC maps the invoice rows into the target Oracle Receivables interface or API and completes the integration with traceable processing updates.

🪣  OCI Object Storage

STORAGE · DURABLE · S3-COMPATIBLE

Oracle Cloud Infrastructure Object Storage is a highly durable, geo-redundant, infinitely scalable object store — purpose-built for unstructured data at enterprise scale. It natively integrates with OIC via pre-authenticated requests (PARs) and supports lifecycle policies, versioning, and AES-256 encryption at rest. In this architecture, Object Storage acts as the primary staging layer for bulk file operations, making it indispensable for upload-driven customization scenarios.

USAGE IN THIS ARCHITECTURE    • VBCS uploads Excel / CSV files (journal entries, AR invoices, bulk payloads) directly to an Object Storage bucket via pre-authenticated URLs — eliminating the need to route large files through OIC or the API tier.
 • OIC monitors bucket events (via OCI Events Service triggers) or polls for new objects, then reads and processes file content as part of integration flows.
 • Approved and processed files are moved to an archive prefix within the same bucket for a complete, auditable file lifecycle trail.
 • Attachment files associated with OPA workflow tasks are stored in Object Storage and referenced by pre-authenticated URLs rather than as inline database BLOBs — keeping ATP lean.
 • Large data sets are staged in Object Storage and imported into ATP using Oracle Data Pump — enabling bulk data loads without routing large volumes through API tiers.
 • File references are exchanged as lightweight pre-authenticated request URLs across OIC, VBCS, and OPA workflows, avoiding inline binary transfers in integration payloads.

🔀  OCI API Gateway

API MANAGEMENT · SECURITY · RATE LIMITING

OCI API Gateway is a fully managed, serverless API management service that provides a secure, observable, and policy-governed entry point for any HTTP-based backend — whether hosted on OCI Compute, ORDS, or external services. It supports JWT validation, OAuth 2.0 scopes, CORS policies, request transformation, and rate limiting at the edge, without introducing any additional compute infrastructure to manage.

USAGE IN THIS ARCHITECTURE    • Hosts and secures OIC integration endpoints behind a consistent base URL, decoupling consumer-facing addresses from OIC's internal service structure and supporting custom domain configuration.
 • Segregates access between downstream systems by applying route-level policies — different authentication requirements, rate limits, and IP allowlists can be enforced per consumer or per integration endpoint.
 • Enables policy-governed header injection and transformation: correlation IDs or tenant identifiers can be supplemented before requests reach ORDS or OIC backends, without weakening downstream authentication trust chains.
 • Acts as a proxy governance layer with centralised request logging, latency monitoring, and error rate visibility via OCI Logging and Monitoring across all API traffic.

⚖️  OCI Load Balancer

TRAFFIC DISTRIBUTION · RESILIENCE · SCALABILITY

OCI Load Balancer provides Layer 7 HTTP/HTTPS traffic distribution across backend service instances, delivering high availability and horizontal scalability for integration and data access endpoints. It supports SSL termination, session persistence, health-check-driven failover, and backend set management — ensuring consistent service availability under variable load conditions.

USAGE IN THIS ARCHITECTURE    • Distributes traffic across multiple ORDS instances, preventing any single listener from becoming a bottleneck under high-volume data access scenarios and ensuring availability during rolling upgrades.
 • Fronts high-load OIC service endpoints in configurations where integration traffic is routed through on-premises or custom backend services requiring load distribution.
 • Provides resilience and automatic failover for integration middleware hosted on OCI Compute, maintaining uninterrupted service availability during instance maintenance or failure events.
 • Enables blue-green and rolling deployment strategies for ORDS and custom middleware by progressively shifting traffic between backend instance pools without service interruption.

🖥️  OCI Compute (Virtual Machines)

COMPUTE · FLEXIBLE SHAPES · CUSTOM MIDDLEWARE

OCI Compute provides flexible, bare-metal-class virtual machine instances across an extensive library of shapes — from ARM-based Ampere A1 instances for cost-efficient workloads to Intel and AMD high-memory shapes for demanding middleware. With live migration, autoscaling instance pools, and Oracle Linux as the native OS, OCI Compute is the trusted home for custom backend services, middleware adapters, and legacy integration components that have not yet been re-platformed to managed cloud services.

USAGE IN THIS ARCHITECTURE    • Hosts custom middleware components implementing specialised transformation or enrichment logic that exceeds standard OIC mapper capabilities — invoked by OIC as REST endpoints within the integration network.
 • Implements specialised integration logic as a transformation or orchestration layer, particularly in complex derivation or validation scenarios requiring custom code execution.
 • Provides a self-managed ORDS runtime for organisations requiring fine-grained control over ORDS configuration, connection pool tuning, and database wallet management while keeping ATP as the managed database tier.
 • Hosts Oracle Middleware (SOA Suite, OSB) components in hybrid transition architectures where legacy integration flows are being progressively migrated to OIC 3.0.

📨  OCI Events & Notifications

EVENT-DRIVEN · REAL-TIME TRIGGERS

OCI Events Service captures state-change events from any OCI resource — Object Storage objects created, ATP backups completed, Compute instance state changes — and routes them to Notifications topics, Functions, or Streaming. This enables a fully event-driven trigger model for integration flows, replacing costly polling loops with instant, serverless event delivery.

USAGE IN THIS ARCHITECTURE    • Triggers OIC integration flows immediately when a new file lands in an Object Storage bucket (e.g., a newly uploaded Excel journal file), eliminating scheduled polling and reducing processing latency to near-real-time.
 • Sends OCI Notifications (email, SMS, Slack webhook via HTTPS) to operations teams when critical events occur — failed OIC integration runs, ATP storage thresholds, or OPA process instance backlogs.
 • Drives the VBCS notification layer by publishing approval-completion events to an ONS topic that VBCS subscribes to via a webhook service connection.

🔐  OCI Vault (Key Management)

SECRETS · ENCRYPTION KEYS · COMPLIANCE

OCI Vault is the platform's centralised secrets management and key management service — providing HSM-backed encryption key storage, automatic key rotation, and a secrets API that helps eliminate hardcoded credentials across the architecture. Runtime retrieval and non-plaintext handling depend on each service's configured integration pattern.

USAGE IN THIS ARCHITECTURE    • Stores ORDS Basic Auth credentials, Fusion service account secrets, and JWT signing keys as Vault secrets — referenced by OIC through supported secret integration patterns configured per connection/runtime.
 • Manages ATP wallet passphrases and TDE master encryption keys for regulatory compliance (GDPR, SOX) requirements.
 • Provides a central rotation mechanism: when a Fusion service account password is rotated, a single Vault secret update propagates to all OIC connections referencing it — no redeployment required.

 Platform Cohesion: The power of these OCI infrastructure services lies not in their individual capabilities, but in their deep integration with the application-tier services. Object Storage events can trigger OIC processing. API Gateway can validate JWTs issued by OCI IAM Identity Domains. Vault centralizes secret lifecycle management, with OIC integration implemented through configured secret patterns. This interoperability is a hallmark of a mature cloud platform.

The architecture presented in this blueprint is a testament to Oracle's singular vision: a unified cloud platform where every service is purpose-built to work in concert with every other. By leveraging VBCS for governed low-code experiences, OIC as the intelligent integration backbone, OPA for enterprise-grade process discipline, ATP for self-managing data persistence, and ORDS for clean API projection — all atop OCI's hardened infrastructure — organizations unlock a customization model that is simultaneously powerful, maintainable, and architecturally coherent.

What distinguishes this approach from conventional multi-vendor integration patterns is not any single technology choice, but the compounding effect of platform convergence. When identity is federated through OCI IAM Identity Domains, when operational observability flows through a unified OCI Logging stack, when security credentials are managed in one Vault, and when every component carries Oracle's enterprise SLA — the result is an architecture whose operational burden is a fraction of its functional capability. The toil of managing integrations between disparate vendors is replaced by the momentum of building on a platform designed to be extended.

For enterprise architects and integration engineers, the message is clear: Oracle Cloud is not merely a destination for migrating existing workloads — it is a platform for reimagining how enterprise software is built. Every customization built within this ecosystem inherits the security, scalability, and governance standards of Oracle Fusion itself — a standard that no third-party toolchain can replicate.

Whether the next project is a streamlined journal upload dashboard, a multi-tier procurement approval workflow, or a full extension module spanning HCM, ERP, and SCM — this blueprint scales with it. The platform is ready. The architecture is proven. The only remaining question is: what will you build?