Oracle Integration Cloud (OIC) is the connective tissue between your ERP, SaaS apps, data sources, trading partners, and mobile workflows. It translates, orchestrates, and governs the traffic so your processes run cleanly end to end. Understanding OIC's architecture is essential for anyone designing, implementing, or documenting enterprise integration solutions.
Here's a complete guide to OIC architecture diagrams—what they include, how they work, and how to build them.
Cloud Architecture
Create cloud architecture diagrams for AWS, Azure, GCP, and more. Design scalable infrastructure with professional cloud icons.
Complete guide to OIC architecture diagrams—network domains, Gen3 design-time vs runtime, adapters, connectivity agent, hybrid patterns, best practices, and tools.
Click Cloud Architecture to open AI Line Studio and generate diagrams from natural language in seconds.
Oracle Integration Cloud is Oracle's managed integration platform that lets you connect Oracle ERP/HCM/EPM, third-party SaaS, on-premise systems, files, and APIs with prebuilt adapters and visual flows. It's a cloud-native iPaaS on Oracle Cloud Infrastructure designed to connect SaaS, on-premises apps, data sources, and APIs using a visual development experience and a large library of prebuilt adapters.
What makes OIC different: It's a managed service—your team doesn't need to run servers, patch platforms, or maintain custom runtimes. You define integrations, decide how they're triggered, configure security, and deploy. Oracle handles platform resilience, elasticity, and updates.
At a practical level, OIC handles the "plumbing" of modern enterprise processes:
Oracle Integration runs on Oracle Cloud Infrastructure (OCI). In any OCI region, there are two major network domains:
| Domain | Description |
|---|---|
| IaaS Domain | Where you deploy Virtual Cloud Networks (VCNs) with private IP space from RFC 1918. Virtual Machines have private IPs. |
| Oracle Services Network (OSN) | Where all SaaS and PaaS deployments reside (Autonomous Databases, Oracle Integration, Oracle Analytics, Fusion SaaS). All have Oracle-owned public IPs and public DNS names. |
Key networking note: OCI provides a VCN Gateway called Service Gateway for connectivity from IaaS to OSN. The reverse—OSN to IaaS—is not supported via this gateway.
OIC Generation 3 has introduced significant architectural changes compared to Generation 2. An OIC Instance has two major layers, each with different use cases and network flows.
This is an ingress-only layer used for instance management. It has its own public IP and Oracle-provided DNS name.
URL format: https://design.integration.[region].ocp.oraclecloud.com/?integrationInstance=[instance_name]
Purpose: Integration admins use this URL to connect to the OIC Instance management layer to build, destroy, and manage integration jobs (Flow 1 in the diagram). The URL redirects users to OCI IDCS for authentication and then provides the management interface.
This layer can have both inbound and outbound flows and is strictly used for integration jobs.
URL format: https://[name].integration.[region].ocp.oraclecloud.com/path-to-integration
Key distinction: Opening a browser to the DNS name of the Runtime Layer redirects to the Design Layer. Only by providing the full integration path (obtained after the integration is configured) will the flow reach the Runtime Layer.
Network flows:
OIC architecture follows a layered approach that enables scalable, secure, and maintainable integrations.
This is how integrations start.
| Trigger Type | Description |
|---|---|
| REST Adapter | Event-driven, API-based triggers |
| Scheduler | Batch jobs on a schedule |
| File-Based | SFTP or file system triggers |
This is where developers spend most of their time. Key components include:
Real example: Employee created in HCM → Transform data → Create user in Active Directory
Adapters are the backbone of OIC. Common adapters include:
| Adapter | Use Case |
|---|---|
| REST Adapter | External systems, APIs |
| SOAP Adapter | Web services |
| FTP Adapter | File transfers |
| Oracle ERP Cloud Adapter | Fusion ERP integrations |
| Oracle HCM Cloud Adapter | Fusion HCM integrations |
Real-world insight: In real projects, 70% of integrations use REST Adapter (external systems) and HCM/ERP Adapters (Fusion apps).
Security is built into every layer of OIC. Supported mechanisms include:
This is critical in hybrid architecture. The connectivity agent is a software component that can be installed on a Linux machine and can act as a go-between for private integration sources and the OIC instance.
Key features:
Example: OIC → Connectivity Agent → On-Prem Database
OIC Gen 3 integrates with process automation for human workflows, approval processes, and task management.
Use Case: Invoice approval workflow triggered after integration
This is often underestimated but critical in production. Components include:
OIC supports API-based integrations with capabilities to publish, secure, and monitor APIs.
Example: Expose employee data as an API for external systems
OIC supports two methods for integrating systems that are on-premises and in private networks.
The connectivity agent is deployed in your on-premises environment. OIC initiates outbound connections through the agent, which then communicates with on-premises systems.
When to use: When you need to connect to systems behind firewalls without opening inbound ports.
A private endpoint provides a private IP address for your OIC instance within your VCN.
When to use: When you need private, secure connectivity between OIC and resources in your VCN.
OIC supports four types of integrations:
| Pattern | Description | Use Case |
|---|---|---|
| Point-to-Point | Direct data mapping between source and target | Simple, one-to-one integrations |
| Publish/Subscribe | Publish messages to a topic; subscribers receive them | Event-driven decoupled integrations |
| Content-Based Routing | Route messages based on content | Conditional processing |
| Orchestration | Complex workflows with multiple steps and transformations | Enterprise-grade business processes |
| Type | Description | Best For |
|---|---|---|
| Synchronous | Provides an immediate response | Simple, short-running operations |
| Asynchronous | Runs longer or more complex tasks | Processing hundreds of records, complex operations |
Practical guidance: OIC can run integrations in seconds for simple flows. For longer-running integrations, use asynchronous patterns.
The Oracle Integration Cloud Reference Architecture is a standardized blueprint that defines how integrations should be designed, developed, deployed, and governed within Oracle Cloud environments. It includes:
Oracle Integration 3 can be deployed on an Oracle Self-Service Landing Zone. The architecture includes:
Management groups:
Compartments:
Primary VCN subnets:
Avoid direct system dependencies. Instead of ERP directly calling external APIs, use OIC as an abstraction layer.
Common integrations (e.g., authentication, logging) should be reusable. Use integration patterns and libraries.
Use asynchronous integrations where possible. Avoid long-running synchronous calls.
Implement retry logic and store failed messages for reprocessing.
Use OAuth 2.0 for APIs and certificates for secure communication. Implement role-based access in OIC.
Your diagram should clearly show:
OIC Gen 3 has separate layers for design and runtime. Your diagram should show:
Include the integration patterns being used:
If integrating with on-premises systems, show:
Include:
Oracle provides official icons through the OCI Architecture Diagram Toolkit. Using unofficial icons creates confusion and undermines credibility.
A generic "Integration" label is not enough. Write "Oracle Integration Cloud (OIC) - Runtime Layer" or "Connectivity Agent - On-Premises" to be precise.
Mistake 1: Treating OIC as a point-to-point tool. OIC is an enterprise integration platform. Design for reusability, not one-off integrations.
Mistake 2: Using synchronous patterns for long-running operations. Synchronous integrations should be short-running. Use asynchronous for complex or long-running tasks.
Mistake 3: Not using the connectivity agent for hybrid. OIC cannot directly access on-premises systems behind firewalls. Always use the connectivity agent or private endpoint.
Mistake 4: Ignoring the monitoring layer. Monitoring is critical in production. Include tracking, error handling, and alerts in your architecture.
Mistake 5: Forgetting about security. Security must be embedded in every layer. Include authentication, authorization, and encryption in your diagram.
Mistake 6: Using OIC for everything. If an integration doesn't need orchestration, routing, transformation, or monitoring—OIC is usually the wrong place. Keep OIC focused on flows that genuinely need it.
Oracle provides official icons through the OCI Architecture Diagram Toolkit in multiple formats. Oracle also provides reference architecture diagrams for OIC deployments.
AI Line Studio generates cloud architecture diagrams from natural language descriptions in 15–20 seconds, supporting 3,000+ officially licensed icons across AWS, Azure, GCP, and OCI. The AI cloud diagram generator helps you iterate quickly during design sessions. The AI architecture diagram builder enables collaborative editing and refinement, and the AI system architecture generator creates end-to-end diagrams for complex systems. The cloud architecture diagram tool provides editable templates with official icons.
Oracle Integration Cloud architecture diagrams are the blueprint for how your enterprise connects applications, data, and processes. The platform's two-network-domain architecture (IaaS and OSN), separate Design-Time and Runtime layers, and hybrid integration capabilities demand a careful, layered approach to diagramming.
Start with the network architecture: show the IaaS domain, the Oracle Services Network, and the Service Gateway connecting them. Include the Design-Time and Runtime layers with their separate public IPs and DNS names. Show the connectivity agent for hybrid integrations. Document integration patterns, security controls, and the monitoring layer.
The best OIC architecture diagrams tell a complete story: how data flows from source to target, how it's transformed and orchestrated, how it's secured, and how it's monitored. If your diagram can't tell that story, it's not doing its job.