Oracle Cloud Integration Generation 2 Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Integration

1. Introduction

Oracle Cloud Integration Generation 2 is Oracle’s managed Integration Platform as a Service (iPaaS) for building, running, and operating integrations between SaaS applications, on-premises systems, and custom services—without needing to manage servers, middleware runtimes, or scaling manually.

In simple terms: you provision an Oracle Integration Generation 2 instance in Oracle Cloud, then use a browser-based designer to connect systems (ERP, HCM, databases, REST APIs, files), map and transform data, orchestrate flows, and monitor message processing end-to-end.

Technically, Integration Generation 2 provides a managed runtime for integration flows (often called “integrations”), plus a catalog of adapters/connectors, data mapping, orchestration, scheduling, error handling, and tracking/monitoring. It is designed for enterprise integration patterns such as request/response APIs, event-like flows, file exchanges, and application-to-application synchronization.

The problem it solves: most organizations struggle with spaghetti integrations (custom scripts, point-to-point APIs, brittle ETL jobs). Integration Generation 2 centralizes connectivity, governance, observability, and change management so teams can integrate faster with better reliability and security.

Naming note (important): Oracle’s product is commonly referred to as Oracle Integration. In the Oracle Cloud Console, you provision an Oracle Integration instance and select the Generation 2 platform (OCI-native). If you encounter “Classic” in older documentation, that refers to earlier generations; treat that as legacy and verify in official docs for migration guidance.

2. What is Integration Generation 2?

Official purpose

Integration Generation 2 in Oracle Cloud is an OCI-native managed integration service used to: – Connect applications and data sources using built-in adapters – Orchestrate multi-step business and data flows – Expose and consume APIs (commonly via REST) – Transform data between different schemas/formats – Monitor, retry, and govern integration executions

Core capabilities (what you can do)

Build app-driven integrations (API-triggered, request/response)
Build scheduled integrations (polling, batch sync, timed jobs)
Use adapters for common systems (Oracle and non-Oracle) and generic protocols (REST/SOAP/FTP/DB)
Adapter availability varies by service entitlement and region—verify in official docs and your instance’s adapter catalog.
Define connections with credentials and endpoints
Map data with a visual mapper and support common transformations
Track messages with monitoring dashboards, audit/tracking views, and error handling
Use agents for private connectivity to on-premises networks (where applicable)

Major components (conceptual model)

While exact UI terms can evolve, Integration Generation 2 commonly includes:

Integration instance: the provisioned service runtime in an OCI region and compartment.
Connections: reusable endpoint + credential definitions (for example, “Salesforce Connection”, “REST API Connection”, “ATP Connection”).
Integrations: the flows you design and run (trigger, actions, mappings, control structures).
Adapters: connector technology used by connections to talk to systems.
Lookups: mapping tables used for value translation (for example, “US” → “United States”).
Monitoring / Tracking: message-level observability (instances, payloads, errors).
Agents (optional): runtime components deployed in your network for accessing private resources without exposing them publicly.

Service type and scope

Service type: Managed cloud service (iPaaS) running as a provisioned instance.
Scope: An Integration Generation 2 instance is typically:
Regional (deployed into a specific OCI region)
Compartment-scoped for governance, access control, and cost management in OCI
Exposed via a service endpoint (public or private, depending on configuration—verify options in your region)

How it fits into the Oracle Cloud ecosystem

Integration Generation 2 sits in the Integration category and commonly integrates with: – OCI IAM for authentication/authorization (tenancy users, groups, policies) – OCI Networking (VCNs, subnets, security lists/NSGs) when using private access patterns – OCI Observability components (logging/metrics integration may exist depending on service features—verify in official docs) – Oracle SaaS (ERP Cloud, HCM Cloud, SCM Cloud, CX) as first-class integration targets – On-premises Oracle and non-Oracle systems via agents and standard protocols

3. Why use Integration Generation 2?

Business reasons

Faster integrations: reduce custom code and one-off scripts by using a standardized platform.
Lower integration risk: consistent patterns for retries, error handling, tracking, and change management.
Better time-to-value: prebuilt adapters and templates can accelerate SaaS-to-SaaS and SaaS-to-on-prem projects.
Central governance: fewer “shadow integrations” created by individual teams.

Technical reasons

Adapter-driven connectivity reduces boilerplate auth, pagination handling, and protocol specifics.
Visual orchestration helps teams implement multi-step flows (enrich, validate, transform, route).
Schema-aware mapping reduces data transformation errors and supports evolvable integration contracts.
API exposure for internal consumption (app teams can consume an integration endpoint rather than integrate with multiple backends).

Operational reasons

Built-in monitoring for message instances, errors, and throughput.
Managed runtime: patching and platform maintenance are handled by Oracle (within the service’s managed responsibility model).
Environment separation: dev/test/prod can be separated by compartments and separate instances.

Security/compliance reasons

Centralized credential management (within the platform), plus OCI IAM governance.
Options for private network access to reduce public exposure (verify private endpoint capabilities in your region).
Auditability via built-in tracking and OCI-level audit for resource changes.

Scalability/performance reasons

Designed for enterprise integration throughput with managed scaling characteristics (exact scaling behavior and limits are SKU/edition-dependent—verify in official docs).
Supports parallelism patterns (for example, multiple integration instances for isolation, or different integration designs to manage concurrency).

When teams should choose it

Choose Integration Generation 2 when you need: – SaaS-to-SaaS or SaaS-to-on-prem integration with governance and tracking – A standardized iPaaS instead of maintaining custom integration codebases – Fast delivery of data sync, orchestration, and API mediation – Integration operations visibility (tracking, retries, error analysis)

When teams should not choose it

It may not be the best fit when: – You need ultra-low latency stream processing with complex event-time semantics (consider streaming-native solutions) – You require full custom runtime control and prefer code-only integration (consider self-managed frameworks) – You are primarily solving bulk ETL/ELT analytics pipelines (consider data integration/ETL tools) – Your use case is primarily database replication (consider replication tools; verify Oracle offerings like GoldenGate for that specific requirement)

4. Where is Integration Generation 2 used?

Industries

Finance and insurance (customer onboarding, payment status updates, KYC workflow integrations)
Healthcare (claims, eligibility checks, EHR system integration—ensure compliance requirements are met)
Retail and e-commerce (orders, inventory, fulfillment updates)
Manufacturing (supply chain integration, EDI-like exchanges via B2B capabilities if enabled)
Public sector (case systems, citizen services portals, secure data exchange)

Team types

Integration/Center-of-Excellence (CoE) teams standardizing patterns
Platform engineering teams providing integration as a shared service
Application teams building APIs and syncing SaaS data
DevOps/SRE teams operating integration runtimes with monitoring and incident response
Security teams establishing guardrails and private connectivity

Workloads and architectures

Hub-and-spoke integration: Integration Generation 2 as a central integration hub
API mediation: consolidating backend calls and exposing a single REST endpoint
Data synchronization: scheduled syncing between CRM and ERP
File-based integration: ingest/export via SFTP/FTP patterns (capabilities depend on configuration and adapters)
Hybrid integration: on-prem systems accessed through an agent rather than inbound firewall openings

Real-world deployment contexts

Production: strict change management, private endpoints, compartment isolation, least-privilege policies, monitoring/alerting, and DR strategy aligned to service capabilities.
Dev/Test: smaller instances, public endpoints for quick iteration (with caution), limited credentials, and short retention.

5. Top Use Cases and Scenarios

Below are realistic scenarios where Integration Generation 2 is commonly applied.

1) ERP ↔ CRM customer sync

Problem: Customer accounts exist in both ERP and CRM with mismatched identifiers.
Why this fits: Adapters + mapping + scheduled orchestration provide repeatable sync with tracking.
Scenario: Nightly job pulls CRM updates, transforms fields, upserts into ERP, and logs exceptions.

2) Expose a unified “Customer 360” API

Problem: Frontend apps need customer data from multiple systems.
Why this fits: App-driven integration can orchestrate calls, aggregate data, and return one response.
Scenario: REST endpoint calls CRM + billing API, merges payload, returns a consolidated JSON object.

3) Order-to-cash status notifications

Problem: Customers need real-time-ish order status updates from ERP and shipping providers.
Why this fits: Integration can consume status events or poll, enrich, and push notifications.
Scenario: Scheduled integration checks shipment updates and posts status to a customer portal API.

4) On-prem database to SaaS integration (hybrid)

Problem: SaaS apps require reference data stored in an on-prem database.
Why this fits: Connectivity agent enables secure access to private endpoints; mapping handles schema differences.
Scenario: Sales territories stored on-prem are synced to a SaaS CRM weekly.

5) File ingestion from partners (SFTP/FTP patterns)

Problem: Partners deliver nightly files; you must validate, transform, and load them.
Why this fits: File-based triggers/actions with transformation and error handling (capability depends on enabled features/adapters).
Scenario: CSV file from a supplier is mapped to ERP import format and pushed to a target API.

6) SOAP-to-REST modernization façade

Problem: Legacy systems expose SOAP services; modern apps want REST/JSON.
Why this fits: Integration can accept REST, call SOAP, map XML↔JSON, and return a REST response.
Scenario: Mobile app calls REST /customers/{id}; integration invokes SOAP backend and returns JSON.

7) HR onboarding automation across systems

Problem: New hire data must propagate to ITSM, directory, payroll, and provisioning.
Why this fits: Orchestration supports multi-step flows with conditional logic and retries.
Scenario: New hire created in HCM triggers downstream account creation and ticket creation.

8) API-based data validation service

Problem: Multiple apps need consistent validation rules (address validation, tax ID verification).
Why this fits: Integration exposes a shared API and centralizes outbound calls to validation providers.
Scenario: REST endpoint calls third-party validation API and returns standardized results.

9) Event-like integration using polling + idempotency

Problem: Source system doesn’t publish events; you still need near-real-time processing.
Why this fits: Scheduled integrations can poll, dedupe, and process incremental changes.
Scenario: Every 5 minutes, integration polls “updated since timestamp,” processes new records, stores last watermark.

10) Controlled outbound integrations with security review

Problem: Direct outbound calls from many apps are hard to secure and audit.
Why this fits: Central integration endpoints, consistent credentials handling, and monitoring.
Scenario: Only Integration Generation 2 is allowed to call payment provider APIs; apps call integration internally.

11) Multi-tenant partner routing

Problem: Same message must go to different endpoints based on partner/customer.
Why this fits: Lookups + routing logic enable manageable partner configurations.
Scenario: Incoming order routes to different fulfillment API based on region code.

12) Disaster recovery-friendly decoupling layer (pattern)

Problem: Downstream system outages break upstream apps.
Why this fits: Integrations can implement retries and compensations; combined with queueing patterns (where supported) improves resilience.
Scenario: Integration retries transient failures and emits error notifications; upstream receives stable API responses.

6. Core Features

Feature availability can vary by entitlement/edition and by what capabilities are enabled on your Integration instance. Always confirm in your instance UI and the official docs.

1) Visual integration designer (orchestration)

What it does: Lets you model integration flows with triggers, invokes, mappings, and control logic.
Why it matters: Accelerates delivery and makes flows easier to review and maintain.
Practical benefit: Faster changes, easier onboarding for new engineers.
Caveats: Complex logic can become difficult to manage without standards (naming, modularity, consistent error handling).

2) Adapters and connections (connector model)

What it does: Provides connectors to SaaS apps, databases, and protocols; connections store endpoint and security configuration.
Why it matters: Avoids reimplementing auth/protocol details in every integration.
Practical benefit: Consistent security configuration and faster connectivity.
Caveats: Not all adapters are available in all regions/editions. Some adapters have specific limitations (API limits, object support)—verify per adapter.

3) REST and SOAP integration patterns

What it does: Build integrations that can expose REST endpoints and/or call REST/SOAP services.
Why it matters: Common enterprise requirement for API mediation and legacy compatibility.
Practical benefit: Incremental modernization without rewriting backends.
Caveats: For high-scale public API management, you may still want a dedicated API gateway in front (rate limiting, WAF, developer portal).

4) Scheduled runs and polling patterns

What it does: Run integrations on a schedule (cron-like) and poll source systems.
Why it matters: Many enterprise systems don’t reliably push events.
Practical benefit: Enables incremental sync, nightly batches, and periodic reconciliation.
Caveats: Polling must be designed with idempotency and watermarking to avoid duplicates.

5) Data mapping and transformation

What it does: Visual mapper for transforming payloads (JSON/XML), enriching, and reshaping data.
Why it matters: Data transformation is a large part of integration effort.
Practical benefit: Reduced mapping bugs and quicker iterations.
Caveats: Extremely large payload transformations can be slow; design for payload size limits and streaming where possible (verify official service limits).

6) Error handling and retries

What it does: Supports handling faults, reprocessing patterns, and operational error visibility.
Why it matters: Production integrations fail; controlled failure is mandatory.
Practical benefit: Faster incident resolution and reduced data loss.
Caveats: Retry behavior depends on adapter and integration design; ensure idempotency to avoid duplicate writes.

7) Tracking, monitoring, and operational dashboards

What it does: Provides message tracking, instance status, and error views.
Why it matters: Integrations are operationally critical; you need auditability.
Practical benefit: Faster troubleshooting and better SLA management.
Caveats: Payload visibility may be limited or must be configured carefully for privacy/compliance. Retention periods vary—verify and adjust where possible.

8) Lookups and configuration artifacts

What it does: Use lookup tables for value translations and routing.
Why it matters: Keeps partner mappings and code tables out of hardcoded logic.
Practical benefit: Faster non-code changes.
Caveats: Govern lookup changes like code (review, testing) to avoid production incidents.

9) Hybrid connectivity (agent-based)

What it does: Allows Integration to securely reach on-prem systems without inbound network exposure (typical outbound agent model).
Why it matters: Hybrid integration is common; security teams often forbid inbound openings.
Practical benefit: Faster security approvals and safer deployments.
Caveats: Agent lifecycle (patching, HA, placement) becomes your responsibility.

10) Environment isolation and lifecycle management

What it does: Separate dev/test/prod instances; manage activation/deactivation of integrations.
Why it matters: Production stability depends on controlled changes.
Practical benefit: Reduced blast radius.
Caveats: Costs scale with number of instances; plan environment strategy intentionally.

7. Architecture and How It Works

High-level service architecture

At a high level, an Integration Generation 2 instance provides: – A managed integration runtime – A design-time UI (browser-based) – A catalog of adapters and connection configurations – An execution engine for integrations – Monitoring and tracking tools

Integrations are typically defined as: 1. Trigger: how the integration starts (REST call, schedule, file event, etc.) 2. Actions: calls to target systems, transformations, branching, assignments 3. End: returns a response (for synchronous flows) or completes processing (for async)

Request/data/control flow (common patterns)

Synchronous API flow: Client → Integration REST endpoint → Adapter invokes downstream APIs → returns response.
Scheduled sync flow: Scheduler → query/poll source → transform → write to target → log summary.
Hybrid flow: Integration → agent → on-prem service/database → return results.

Integrations with related OCI services (typical)

IAM: Who can create/manage integration instances and artifacts.
Networking: Optional private networking and access control.
Observability: OCI-level resource audit; service-level monitoring in the Integration console.
Exporting logs/metrics to OCI services may be available—verify in official docs for your version.

Dependency services

OCI tenancy, compartment structure, IAM policies
Optionally VCN/subnets/NSGs for private endpoint patterns
Optionally on-prem connectivity (VPN/FastConnect) and/or agent hosts

Security/authentication model (practical view)

OCI IAM controls who can create and manage the Integration instance in OCI.
Integration console roles (within the instance) control who can design/activate/monitor integrations.
Connection credentials secure access to downstream systems.
Inbound authentication for REST triggers can be configured (for example, basic auth/OAuth depending on capabilities). Avoid “no auth” in production.

Networking model (practical view)

Most teams start with a public endpoint for dev/test.
For production, consider a private endpoint model so the Integration endpoint is only reachable within your network boundary (capability depends on service options and region—verify).
On-prem access can be provided via an agent and/or private networking patterns.

Monitoring/logging/governance considerations

Decide what to log and how long to retain it.
Avoid storing sensitive fields in tracking/payload logs unless required and approved.
Use consistent naming and tagging across instances and artifacts.
Establish runbooks for common failures (timeouts, auth errors, API limits).

Simple architecture diagram (learning view)

flowchart LR
  A[Client / App] -->|HTTPS REST| B[Integration Generation 2 Instance]
  B --> C[REST/SOAP API Target]
  B --> D[(Database Target)]
  B --> E[Monitoring & Tracking]

Production-style architecture diagram (enterprise view)

flowchart TB
  subgraph OCI["Oracle Cloud (OCI)"]
    subgraph COMP["Compartment: prod-integration"]
      OIC["Integration Generation 2 Instance\n(Private or Public Endpoint)"]
      MON["Instance Monitoring / Tracking"]
    end

    subgraph NET["VCN (if using private endpoint)"]
      SUB["Private Subnet"]
      NSG["NSGs / Security Lists"]
    end
  end

  subgraph SAAS["SaaS Applications"]
    ERP["Oracle ERP Cloud (example)"]
    CRM["CRM (example)"]
  end

  subgraph ONPREM["On-Premises / Private Network"]
    AGENT["Connectivity Agent Host(s)"]
    LEGACY["Legacy Apps / DBs"]
  end

  USER["Developers / Operators"] -->|IAM + Console Access| OIC
  OIC --> MON

  OIC -->|Outbound HTTPS| ERP
  OIC -->|Outbound HTTPS| CRM

  OIC -->|Secure outbound via Agent| AGENT
  AGENT --> LEGACY

  OIC -.->|If private endpoint| NET
  SUB --> NSG

8. Prerequisites

Tenancy/account requirements

An active Oracle Cloud tenancy with billing enabled (paid or trial credits).
Ability to use the Integration service in your tenancy.
Some tenancies require explicit subscription/entitlement for Oracle Integration—verify with your Oracle Cloud account and service limits.

Permissions / IAM

You typically need: – Permission to manage Integration instances in the target compartment. – Permission to read/manage networking if creating a private endpoint configuration.

Example OCI IAM policy (adjust group/compartment names to your environment):

Allow group IntegrationAdmins to manage integration-instance-family in compartment my-integration-compartment

If you plan private networking, you may also need policies to manage VCN resources (exact policy set depends on your org model—verify with OCI networking requirements).

Billing requirements

Integration Generation 2 is generally a paid OCI service (may consume trial credits if available).
Make sure you understand your tenancy’s subscription model (Pay As You Go vs Universal Credits vs BYOL, depending on your contract).

Tools needed

Web browser for OCI Console and Integration instance console
Optional: curl for testing REST endpoints
Optional: OCI CLI (not required for the lab)

Region availability

Integration Generation 2 is regional. Not all OCI regions may support it.
Verify availability in:
OCI Console service list in your region
Official docs/service availability references

Quotas/limits

Service limits apply (number of instances per region/tenancy, message throughput, connection limits, etc.).
Check Service Limits in OCI Console for Integration and request increases if needed.

Prerequisite services (for certain options)

VCN/subnets/NSGs if using private endpoints
On-prem host(s) if using connectivity agents
Target systems (SaaS/API) credentials and allowlists

9. Pricing / Cost

Pricing changes, and exact costs vary by region, contract type, and edition/SKU. Do not rely on unofficial numbers—use Oracle’s official pricing pages and your tenancy’s cost reports.

Current pricing model (how you are billed)

Integration Generation 2 costs typically depend on: – The edition/SKU you provision (capabilities and entitlements can vary) – The instance capacity or sizing model (service-specific; verify for your SKU) – Your usage volume (for example, message throughput/processing units) depending on Oracle’s pricing metric for your subscribed offering – Add-on capabilities enabled on the instance (if applicable)

Because Oracle’s commercial models can differ by contract (Universal Credits, BYOL, or negotiated enterprise agreements), treat pricing as: – Metered (usage-based), or – Provisioned capacity (hourly/monthly instance-based), or – A combination depending on offer

Verify in official pricing for the exact metric used by your tenancy and region.

Official pricing references

Oracle Cloud price list / cloud pricing entry point: https://www.oracle.com/cloud/price-list/
Oracle Pricing Calculator: https://www.oracle.com/cloud/costestimator.html
Oracle Integration product/pricing pages (may vary by country):
https://www.oracle.com/integration/ (navigate to pricing)
If a direct pricing URL is different for your locale, verify in official Oracle pages.

Cost drivers (what increases spend)

Running multiple instances (dev/test/prod) continuously
Higher throughput / heavier mapping and transformation workloads
Large payload sizes and high call rates to downstream systems
Premium/enterprise adapters or add-on features (if required by your SKU)
Network architecture choices (private networking, connectivity design)
Operational choices: retention and monitoring settings can have indirect costs (for example, if exported to other services—verify)

Hidden/indirect costs to plan for

Downstream API costs: third-party SaaS API usage limits, paid API tiers
Network egress: outbound data transfer from OCI to internet or cross-region (OCI pricing rules apply)
On-prem agent hosts: compute/VM costs if you run agents on OCI or on-prem (plus operations)
Environments and DR: additional instances for staging, DR, and isolation

Network/data transfer implications

Inbound to OCI is typically not charged; outbound (egress) and cross-region data transfer can be.
If integrations call internet endpoints, watch egress.
If your instance is in one region and targets are in another, cross-region patterns can add latency and transfer costs.

How to optimize cost (practical)

Use separate small dev instances and shut down/delete when not needed (if your governance allows).
Avoid chatty integration designs (many small calls) when batch patterns are acceptable.
Reduce payload bloat: only request/return required fields.
Implement caching/value lookups carefully to reduce repetitive calls (where applicable).
Prefer private connectivity to reduce security overhead—but understand it doesn’t automatically reduce cost.
Monitor usage and rightsize instance capacity/edition based on actual needs.

Example low-cost starter estimate (how to think about it)

A realistic starter plan for learning: – 1 dev Integration Generation 2 instance – 1–2 simple REST connections – A few integrations with low daily call volume

Because Oracle’s pricing unit (capacity vs usage) may vary by contract, estimate by: 1) Finding your SKU’s hourly/monthly charge in the pricing page/calculator
2) Adding expected network egress (often minimal for small labs)
3) Keeping the instance lifetime short (delete after the lab)

Example production cost considerations (what to model)

For production, build a cost model including: – Number of environments (dev/test/prod + DR if required) – Peak and average message volumes – Required adapters/features – Private endpoint/networking pattern – Operational overhead: agent hosts, monitoring/export integrations – Expected growth and seasonal peaks

10. Step-by-Step Hands-On Tutorial

This lab builds and tests a small but real integration: expose a REST API on Integration Generation 2 that calls a public REST service and returns the result. It’s designed to be low-risk and easy to clean up.

Objective

Provision an Integration Generation 2 instance in Oracle Cloud, then create and activate an integration:

Inbound: REST endpoint GET /todo/{id}
Backend call: GET https://jsonplaceholder.typicode.com/todos/{id}
Outbound: Return the JSON response to the caller
Verify: Use curl and the Integration monitoring/tracking UI
Clean up: Deactivate integrations and delete the instance to stop charges

Lab Overview

You will: 1. Create (or choose) an OCI compartment for the lab 2. Provision an Integration Generation 2 instance 3. Create a REST connection to JSONPlaceholder 4. Create an app-driven integration with REST trigger + REST invoke 5. Activate and test the endpoint 6. Validate tracking and troubleshoot common errors 7. Clean up resources

Step 1: Prepare OCI access and compartment

Sign in to the Oracle Cloud Console.
Select the correct region (top bar).
Make sure Integration is available in that region (verify by checking the “Integration” service in the navigation menu).
Create or select a compartment for this lab, for example: lab-integration.

Expected outcome – You have a compartment to hold the Integration instance and any related resources.

Verification – You can open the compartment and view its OCID and name.

Step 2: Create an Integration Generation 2 instance

In OCI Console, open Integration (service category: Integration).
Choose Create Integration Instance (wording may vary slightly).
Set: – Name: lab-oic-gen2 – Compartment: lab-integration – Generation: Generation 2 (ensure Gen2 is selected) – Shape/Edition/Sizing: choose the smallest suitable option available in your tenancy for learning (naming varies—verify in UI) – Endpoint type: choose Public for easiest lab setup
(Use Private only if you already have VCN/subnet design and want to practice private access.)
Create the instance and wait for provisioning to complete (this may take time).

Expected outcome – The instance status becomes Active/Ready.

Verification – The instance details page shows a console link such as “Open Oracle Integration” (wording varies).

Step 3: Open the Integration instance console

From the instance details page, click Open / Service Console (name varies).
Sign in if prompted (may use SSO depending on tenant setup).
Confirm you can see the design home page where you can create Integrations and Connections.

Expected outcome – You can access the Oracle Integration design console.

Verification – You can navigate to Connections and Integrations sections.

Step 4: Create a REST connection for the backend API (JSONPlaceholder)

You will create a reusable connection that points to the public REST service.

Go to Connections → Create.
Choose the REST Adapter (name may appear as “REST”).
Enter: – Name: JSONPlaceholder_REST – Role: Invoke (since we will call it as a backend)
Configure the connection: – Base URI: https://jsonplaceholder.typicode.com – Security policy: choose No Security (this endpoint is public)
Test the connection.
Save.

Expected outcome – Connection test succeeds.

Verification – Connection shows status as configured and tested.

Common error – “Test failed / cannot connect”: confirm your network allows outbound HTTPS, and that the base URI is correct.

Step 5: Create an app-driven integration with REST trigger

Now you’ll build the integration flow.

Go to Integrations → Create.
Select an App Driven Orchestration (or similarly named) integration pattern.
Enter: – Name: GetTodo – Version: keep default (for example, 01.00.0000—exact format varies)
For the Trigger, choose REST Adapter. – If the UI requires a REST Connection for the trigger:
- Create a second REST connection named REST_Trigger with role Trigger
- Use appropriate security for a lab:
- If available, prefer a basic auth or OAuth option
- If you must choose No Security, do so only for learning and do not use this pattern for production
Configure the REST trigger: – Operation: GET – Resource path: /todo/{id} – Define path parameter:
- id as a string or integer (choose what the UI supports cleanly)
- Response payload:
- If the wizard lets you “sample” a response, you can paste a sample JSON like: json { "userId": 1, "id": 1, "title": "delectus aut autem", "completed": false }
- Otherwise, allow the system to infer or use a generic JSON schema option if provided.

Expected outcome – A new integration canvas opens with a REST trigger at the start.

Verification – The trigger shows method GET and the /todo/{id} path.

Step 6: Add a REST invoke to call the backend API

Add an Invoke action after the trigger.
Select the connection JSONPlaceholder_REST.
Configure the invoke: – Method: GET – Endpoint path: /todos/{id} – Map the {id} from the trigger path parameter.
Configure response handling: – The invoke should produce a response object you can return.

Expected outcome – The integration now calls the backend API using the provided id.

Verification – You can see the invoke step and that it references the JSONPlaceholder connection.

Step 7: Map the backend response to the REST response

Add a Map step (or configure the return mapping depending on UI).
Map fields from the invoke response to the integration response.

If you used the sample JSON schema, map fields like: – id – userId – title – completed

Expected outcome – The integration returns JSONPlaceholder data through your Integration Generation 2 endpoint.

Verification – Mapping shows source fields connected to target fields.

Step 8: Activate the integration

Click Activate.
Review activation settings: – Tracking: enable basic tracking for learning – Security: if your trigger uses no security, the platform may warn you—acknowledge for lab only
Confirm activation.

Expected outcome – Integration status becomes Active.

Verification – The activation dialog shows the Endpoint URL for the REST service. Copy it.

Use the endpoint URL shown in your console. Do not guess the URL format; it can vary by environment and settings.

Step 9: Test with curl

On your terminal, call the endpoint URL you copied.

Example (illustrative only—use your real URL):

curl -sS "<YOUR_INTEGRATION_ENDPOINT_URL_WITH_ID_1>"

If your endpoint requires credentials (recommended), use the auth method you configured. For example, with basic auth:

curl -sS -u "username:password" "<YOUR_ENDPOINT_URL>"

Expected outcome – You receive a JSON response similar to:

{
  "userId": 1,
  "id": 1,
  "title": "delectus aut autem",
  "completed": false
}

Verification – The response matches what JSONPlaceholder returns for /todos/1.

Validation

Perform these checks in the Integration console:

Open Monitoring / Tracking (wording varies).
Find the latest instance execution for GetTodo.
Confirm: – Status is Completed – Duration is reasonable (seconds) – No faults occurred
If payload viewing is enabled, confirm the payload looks correct.

Troubleshooting

Issue: Activation fails due to endpoint/security configuration

Cause: Trigger security policy conflicts with environment rules or missing required settings.
Fix: Revisit the REST trigger configuration and pick a supported security method. If your org mandates auth, configure it accordingly.

Issue: `401 Unauthorized` when calling the endpoint

Cause: REST trigger is secured, but curl is missing credentials/token.
Fix: Use the correct curl auth flags or generate a token per the configured policy.

Issue: `404 Not Found`

Cause: Wrong endpoint URL, wrong path, or missing path parameter.
Fix: Copy the endpoint URL from the activation dialog again. Ensure you include /todo/1 (or the required parameter format).

Issue: Invoke step fails (cannot reach `jsonplaceholder.typicode.com`)

Cause: Outbound internet is restricted by policy/network.
Fix: Test from a network that allows outbound HTTPS, or switch to an internal test API endpoint that your environment can reach.

Issue: Backend returns `429 Too Many Requests`

Cause: Public API rate-limited.
Fix: Reduce test frequency, add retry/backoff logic if available, or use a different test endpoint.

Cleanup

To avoid ongoing charges:

In the Integration console: – Deactivate the GetTodo integration. – Delete test connections if no longer needed (optional).
In OCI Console: – Delete the Integration Generation 2 instance lab-oic-gen2.
Wait until deletion completes.

Verification – Instance no longer appears in the compartment (or shows deleted state). – Cost reports stop accumulating new charges for that instance.

11. Best Practices

Architecture best practices

Use Integration Generation 2 as an integration hub, not as a dumping ground:
Define ownership per domain (CRM, ERP, billing)
Avoid giant “do everything” integrations; prefer smaller, composable flows
Standardize patterns:
Naming conventions for connections and integrations
Error handling pattern (fault handlers, retries, dead-letter-like processes if applicable)
Idempotency strategy (especially for scheduled polling)

IAM/security best practices

Use least privilege:
Separate groups for instance admins vs integration developers vs operators
Keep production access tightly controlled:
Restrict who can view payloads (PII risk)
Store credentials securely in connections; avoid embedding secrets in mappings.

Cost best practices

Minimize always-on dev instances if cost is a concern.
Right-size capacity/edition to actual use (measure first, then scale).
Avoid unnecessary high-frequency polling.

Performance best practices

Keep payload sizes reasonable; return only needed fields.
Reduce chatty calls by batching when the backend supports it.
Use parallelism carefully; don’t overload downstream SaaS APIs.

Reliability best practices

Design retries with idempotency (unique keys, upsert semantics).
Build clear error handling and escalation:
What errors are retried?
Which errors are routed to manual review?
Plan for downstream outages:
Backoff policies
Circuit-breaker-like behavior via conditional routing (where supported)

Operations best practices

Establish dashboards and runbooks:
Where to check failed instances
How to reprocess
How to rollback an integration change
Use versioning and controlled promotion across environments.
Implement tagging at OCI resource level for cost allocation.

Governance/tagging/naming best practices

OCI tags on instances:
env=dev|test|prod
owner=team-name
cost-center=...
Integration artifact naming:
SRC_to_TGT_Purpose_Version
Connection names that include target system and environment

12. Security Considerations

Identity and access model

OCI IAM governs:
Who can create/manage/delete Integration instances
Which compartments can contain instances
Integration console roles govern:
Who can create/activate integrations
Who can monitor and view payloads

Recommended approach: – Separate duties: – Developers can build but not necessarily administer the instance – Operators can monitor and reprocess but not edit in production

Encryption

Data-in-transit:
Use HTTPS/TLS for inbound and outbound integrations.
Data-at-rest:
Service data is managed by Oracle; verify details in official docs for encryption-at-rest and key management options (including any customer-managed key support, if available for your SKU).

Network exposure

Prefer private endpoint (if available) for production to reduce public surface area.
Restrict inbound access using network controls where applicable.
For public endpoints, enforce strong authentication and consider placing an API gateway/WAF in front (architecture-dependent).

Secrets handling

Use connection credential storage rather than hardcoding secrets in payloads or mappings.
Rotate credentials regularly and update connections with minimal downtime.
Avoid logging sensitive headers/tokens.

Audit/logging

OCI-level audit logs cover instance lifecycle operations (create/update/delete).
Integration console provides message tracking; decide what data is retained.
If you export logs externally, treat them as sensitive data stores and secure accordingly.

Compliance considerations

If processing PII/PHI/PCI:
Restrict payload visibility
Use environment isolation
Apply retention and access policies
Verify Oracle compliance attestations and your contract scope in official Oracle compliance documentation

Common security mistakes

Leaving REST triggers with no authentication in production
Using shared admin accounts
Over-permissive IAM policies (tenancy-wide manage instead of compartment-scoped)
Exposing on-prem systems directly instead of using agent/private connectivity patterns
Logging sensitive data in tracking payloads

Secure deployment recommendations

Make production endpoints private where possible, or strongly authenticated and protected.
Use least-privilege IAM policies and compartment isolation.
Establish a secrets rotation and incident response process.
Maintain a clear integration inventory and ownership registry.

13. Limitations and Gotchas

Limits and behavior can vary by edition/SKU and by region. Always confirm the latest constraints in official docs and your tenancy’s service limits.

Common practical limitations/gotchas: – Service limits: number of instances, connections, integrations, throughput, concurrent executions—check OCI Service Limits. – Adapter differences: not all adapters behave the same (pagination, filtering, object support). – API rate limits: SaaS targets often enforce strict rate limits; integrations can hit 429 errors if not designed carefully. – Payload and tracking retention: message payload retention windows may be limited; don’t use tracking as long-term storage. – Public endpoint risk: easiest for labs, but often not acceptable for production without strong controls. – Polling duplicates: scheduled polling without watermarking/idempotency causes duplicates. – Time zone and scheduling: cron-like schedules can surprise teams during daylight savings changes; define a clear standard. – Promotion between environments: moving integrations dev→test→prod requires disciplined configuration management; avoid manual “click ops” drift. – Hybrid agent operations: agents require patching, HA planning, and host reliability—don’t treat them as set-and-forget.

14. Comparison with Alternatives

Integration Generation 2 is one approach among several. The right choice depends on whether you need a managed iPaaS, code-first workflow orchestration, or data/stream processing.

Comparison table

Option	Best For	Strengths	Weaknesses	When to Choose
Oracle Cloud Integration Generation 2	Enterprise iPaaS, SaaS integration, governed integrations	Managed runtime, adapters, mapping, monitoring	Cost and licensing complexity; adapter/feature availability varies	Standardizing enterprise integrations, especially with Oracle SaaS
OCI API Gateway + OCI Functions	Lightweight API mediation and serverless automation	Code-first flexibility, strong API gateway controls	More engineering/ops effort; you build mapping/monitoring patterns	When you want custom logic and serverless patterns
OCI Streaming + custom consumers	High-throughput event streaming	Strong for event pipelines, decoupling	Not an iPaaS; you must build connectors/mappings	When event-driven architecture and scale are primary
Oracle SOA Suite (self-managed on OCI)	Legacy SOA workloads	Full control of middleware stack	You manage patching, scaling, and operations	When you need compatibility with existing SOA Suite apps
AWS Step Functions / EventBridge / AppFlow	AWS-native orchestration and SaaS movement	Strong ecosystem; event-driven patterns	Different adapter model; AppFlow coverage varies	When primary footprint is on AWS
Azure Logic Apps	Low-code integrations on Azure	Many connectors, strong workflow tooling	Connector costs/limits; platform-specific	When primary footprint is on Azure
Google Workflows + Integration Connectors	GCP-native orchestration	Serverless orchestration	Connector coverage differs; may require more code	When primary footprint is on GCP
MuleSoft / Boomi (commercial iPaaS)	Vendor-neutral enterprise iPaaS	Rich connector ecosystems, governance	Can be expensive; separate platform	When you need multi-cloud/vendor neutrality
Apache Camel / Spring Integration (self-managed)	Code-first integration frameworks	Maximum flexibility, portability	You manage everything; slower to standardize	When you have strong engineering capacity and want portability

15. Real-World Example

Enterprise example: Oracle ERP Cloud + on-prem finance system integration

Problem: A large enterprise runs Oracle ERP Cloud but still has an on-prem legacy finance system and partner file exchanges. They need reliable sync and a unified monitoring approach.
Proposed architecture
Integration Generation 2 instance in a production compartment
Private connectivity to on-prem via connectivity agent (and/or private networking)
Separate integrations:
- ERP Cloud → on-prem ledger updates (scheduled)
- Partner files → validation → ERP import API (file-based where supported)
Standardized error handling and operations dashboards
Why this service was chosen
Strong fit for Oracle SaaS integration patterns and enterprise governance
Managed runtime with operational visibility
Expected outcomes
Reduced integration development time
Improved auditability and incident response
Fewer brittle scripts and manual reconciliations

Startup/small-team example: SaaS-to-SaaS order processing

Problem: A small team uses an e-commerce platform, a support ticketing system, and an accounting SaaS. They need reliable order sync and customer updates without building/hosting integration code.
Proposed architecture
One smaller Integration Generation 2 instance (initially dev/prod combined if acceptable, later split)
Integrations:
- New order → create invoice in accounting SaaS
- Refund → update accounting and create support ticket
Alerts for failures and reprocessing playbook
Why this service was chosen
Low-code speed, built-in monitoring, and reduced ops burden
Expected outcomes
Faster automation rollout
More reliable order lifecycle processing
Less engineering time spent on glue code

16. FAQ

Is “Integration Generation 2” the same as “Oracle Integration”?
Integration Generation 2 refers to the OCI-native generation/platform for Oracle Integration instances. The product is commonly called Oracle Integration. Always verify naming in the OCI Console and official docs.
Do I need to manage servers or Kubernetes for Integration Generation 2?
No. It’s a managed service where Oracle operates the underlying runtime. You manage integrations, connections, and configuration.
Is Integration Generation 2 regional?
Yes, instances are typically provisioned in a specific OCI region. Check region availability in your tenancy and official docs.
Can I use it for on-premises systems?
Yes, commonly via an agent-based model and/or private connectivity patterns. Exact options depend on your configuration—verify in docs.
Does it support REST APIs?
Yes. You can expose REST endpoints (as triggers) and invoke REST services (as actions), depending on adapter capabilities.
Does it support SOAP?
Commonly yes (SOAP invoke and/or SOAP exposure patterns), but confirm current adapter support in your instance.
How do I secure an inbound REST trigger?
Use the security policy options provided in the REST trigger configuration (for example, basic auth or OAuth options if available). Avoid unauthenticated endpoints in production.
Can I keep integrations private (not internet accessible)?
Many production deployments aim for private endpoint patterns. Availability and setup steps can vary—verify private endpoint support for Integration Generation 2 in your region and edition.
What’s the difference between Connections and Integrations?
Connections define how to reach systems (endpoint + credentials). Integrations are the executable flows that use connections.
How do I promote changes from dev to prod?
Use environment separation (separate instances) and a disciplined promotion process (export/import or platform-supported lifecycle tools). Exact mechanics vary—verify in official docs.
How do I troubleshoot failed messages?
Use Monitoring/Tracking to inspect failed instances, review fault details, and apply reprocessing where appropriate. Also check connection tests and downstream system logs.
Can I do transformations (JSON/XML)?
Yes, via mapping tools. For complex transformations, keep mappings maintainable and test thoroughly.
Is Integration Generation 2 suitable for streaming/event processing at scale?
It can support event-like patterns, but for high-throughput streaming pipelines you may prefer streaming-native services. Use Integration where adapters, mapping, and orchestration are the priority.
How do costs scale?
Costs typically scale with instance capacity/edition and/or usage (message volume), depending on your contract/SKU. Use Oracle’s pricing calculator and monitor usage.
Can I use it with non-Oracle SaaS apps?
Often yes through adapters and generic REST/SOAP connectivity. Adapter availability varies—verify your instance’s adapter catalog.
What are common causes of production incidents?
Rate limits on downstream SaaS APIs, credential expiration, schema changes, unhandled null/formatting differences, and insufficient idempotency on retries.
Does it provide audit trails?
OCI provides audit logs for resource changes; the Integration console provides message tracking. Confirm retention and export options in official docs.

17. Top Online Resources to Learn Integration Generation 2

Links can change by product updates and locale. If a link redirects, navigate from the Oracle Integration documentation hub.

Resource Type	Name	Why It Is Useful
Official documentation	Oracle Integration Documentation (Docs Hub) – https://docs.oracle.com/en/cloud/paas/integration-cloud/	Primary reference for features, adapters, security, and administration
Official docs (OCI)	OCI Documentation portal – https://docs.oracle.com/en-us/iaas/	Context for IAM, networking, compartments, tagging, and governance used with Integration instances
Official pricing	Oracle Cloud Price List – https://www.oracle.com/cloud/price-list/	Authoritative pricing entry point for Oracle Cloud services
Pricing calculator	Oracle Cloud Cost Estimator – https://www.oracle.com/cloud/costestimator.html	Build estimates by region and service SKU (best-effort estimate tool)
Product overview	Oracle Integration product page – https://www.oracle.com/integration/	High-level capabilities, packaging, and links to trials/pricing
Architecture center	Oracle Cloud Architecture Center – https://www.oracle.com/cloud/architecture-center/	Reference architectures and best practices patterns (search for integration and iPaaS patterns)
Tutorials/labs	Oracle Cloud “Get Started” / tutorials – https://docs.oracle.com/en/learn/	Step-by-step labs; search for Oracle Integration/Integration Gen2 content
Release updates	Oracle Cloud “What’s New” – https://docs.oracle.com/en-us/iaas/Content/General/Reference/whatsnew.htm	Track platform updates; verify Integration-specific updates from Oracle Integration release notes
Video learning	Oracle YouTube channel – https://www.youtube.com/@Oracle	Webinars, demos, and product explainers (search within channel for Oracle Integration)
Samples (verify official)	Oracle GitHub – https://github.com/oracle	Some Oracle org repos include integration samples; validate repo relevance and recency before use
Community learning	Oracle Cloud Customer Connect – https://cloudcustomerconnect.oracle.com/	Community Q&A and announcements; useful for practical issues (validate against docs)

18. Training and Certification Providers

Institute	Suitable Audience	Likely Learning Focus	Mode	Website URL
DevOpsSchool.com	Engineers, DevOps, platform teams	OCI fundamentals, cloud operations, integration-adjacent DevOps practices	Check website	https://www.devopsschool.com/
ScmGalaxy.com	Beginners to intermediate engineers	DevOps, cloud basics, tooling practices that support integration delivery	Check website	https://www.scmgalaxy.com/
CLoudOpsNow.in	Cloud operations teams	Cloud operations, monitoring, governance, cost controls	Check website	https://www.cloudopsnow.in/
SreSchool.com	SREs, ops engineers	Reliability engineering concepts applicable to integration platforms	Check website	https://www.sreschool.com/
AiOpsSchool.com	Ops and monitoring teams	AIOps concepts, observability practices	Check website	https://www.aiopsschool.com/

19. Top Trainers

Platform/Site	Likely Specialization	Suitable Audience	Website URL
RajeshKumar.xyz	DevOps/cloud training content (verify current offerings)	Beginners to intermediate learners	https://rajeshkumar.xyz/
devopstrainer.in	DevOps training resources (verify current courses)	Engineers and students	https://www.devopstrainer.in/
devopsfreelancer.com	Freelance/consulting and training-style content (verify services)	Teams seeking project-based guidance	https://www.devopsfreelancer.com/
devopssupport.in	Support/training resources (verify scope)	Ops and support teams	https://www.devopssupport.in/

20. Top Consulting Companies

Company	Likely Service Area	Where They May Help	Consulting Use Case Examples	Website URL
cotocus.com	Cloud/DevOps/engineering services (verify OCI specialization)	Delivery support, integration adjacent platform work	Environment setup, CI/CD pipelines for integration artifacts, operational playbooks	https://cotocus.com/
DevOpsSchool.com	Training + consulting (verify consulting offerings)	Enablement and delivery acceleration	Skills uplift for teams operating Oracle Cloud integrations; governance standards	https://www.devopsschool.com/
DEVOPSCONSULTING.IN	DevOps consulting services (verify OCI scope)	Cloud ops, automation, reliability	Monitoring strategy, incident response runbooks, automation around integration operations	https://devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before Integration Generation 2

OCI basics:
Compartments, IAM policies, groups
Networking fundamentals (VCN, subnets, security lists/NSGs)
Tagging and cost management
Integration fundamentals:
REST/HTTP basics (methods, headers, status codes)
JSON and XML basics
Authentication concepts (basic auth, OAuth 2.0)
Operational basics:
Logging/monitoring concepts
Incident handling and root cause analysis
Change management fundamentals

What to learn after Integration Generation 2

API management patterns (rate limiting, developer onboarding, WAF)
Event-driven design (queues/streams) for decoupling and resilience
CI/CD for integration artifacts (export/import pipelines, environment promotion)
Advanced security:
Private connectivity patterns
Secrets rotation automation
Compliance controls and audit readiness

Job roles that use it

Integration Engineer / iPaaS Developer
Cloud Solutions Architect
Platform Engineer (integration platform owner)
DevOps Engineer / SRE supporting integration operations
Enterprise Application Integration (EAI) specialist

Certification path (if available)

Oracle’s certification offerings change over time. Check Oracle University and official certification pages for the current roadmap: – Oracle University: https://education.oracle.com/
– Oracle Certifications: https://education.oracle.com/oracle-certification

If there is a specific Oracle Integration certification track, verify in official Oracle University pages.

Project ideas for practice

Build a “CRM to ERP account sync” scheduled integration with watermarking and idempotency
Create a REST façade that aggregates 2–3 backend APIs
Implement a partner routing integration using lookups and per-partner endpoints
Build an error-handling pattern:
transient retry
persistent error notification
manual reprocess procedure
Design a private endpoint deployment (if supported) and document network rules and IAM policies

22. Glossary

Adapter: A connector that knows how to communicate with a specific application or protocol (REST, SOAP, SaaS apps, DB).
App-driven integration: A flow triggered by an inbound request (commonly REST) and often returns a response.
Compartment (OCI): A logical container used for organizing resources and applying IAM policies.
Connection: A reusable configuration in Oracle Integration defining endpoint details and credentials for an adapter.
Connectivity Agent: A runtime component deployed in a private network to allow Integration to access private systems securely.
Endpoint: The URL exposed by an integration (trigger) or called by an integration (invoke).
Idempotency: The property that repeating an operation produces the same result (critical for retries).
Integration (flow): The executable process you design with triggers, actions, mappings, and logic.
Instance: The provisioned Integration Generation 2 environment running in an OCI region.
Invoke: An action step that calls a target system.
Lookup: A mapping table used to translate codes/values and route logic without hardcoding.
Monitoring/Tracking: Operational features that let you inspect integration runs, errors, and performance.
Private endpoint: A deployment model where the service endpoint is reachable only within private networking boundaries (availability varies; verify).
REST trigger: An inbound REST API endpoint that starts an integration.
Watermark: A stored “last processed” marker (timestamp or ID) used in polling to avoid reprocessing.

23. Summary

Integration Generation 2 in Oracle Cloud is a managed iPaaS runtime for designing, executing, and operating integrations using adapters, orchestration, transformation, and built-in monitoring. It matters because it reduces the cost and risk of point-to-point integration sprawl while improving governance, security, and operational visibility.

Architecturally, it fits as an enterprise integration hub—often between Oracle SaaS, non-Oracle SaaS, on-prem systems, and custom APIs—using OCI IAM and compartment governance. Cost depends on the edition/SKU and your capacity/usage model, so you should estimate with Oracle’s pricing pages and calculator rather than assuming a fixed rate. Security success depends on strong IAM, secure inbound authentication, careful payload logging, and (where feasible) private connectivity patterns.

Use Integration Generation 2 when you need governed application integration with visibility and speed. Avoid it for workloads that are primarily streaming-native, ultra-low-latency, or better served by ETL/replication tools.

Next step: follow the hands-on lab again with a secured REST trigger and a second environment (test/prod separation), then build an idempotent scheduled integration with robust error handling and monitoring runbooks.

rajeshkumar

Category