OIC - Common Service - Streamlining OIC Schedule Management Through REST API Automation

 Working...

Introduction

In Oracle Integration Cloud (OIC), managing scheduled integrations involves operations such as Stop, Start, Pause, Resume, Add Schedule, and Update Schedule. Performing these operations manually across multiple integrations can be time-consuming.

To simplify this process, we can develop an automated Scheduling Management Service using OIC Factory REST APIs. The solution follows a lookup-driven approach to identify the integrations, execute the required scheduling operations, and generate a consolidated execution report.

Solution Approach

1. Lookup Configuration

Maintain all required details in an OIC lookup, including:

• Project name
• Integration identifier
• Schedule name
• Operation type (Stop/Start/Pause/Resume/Add/Update)
• Required schedule configuration for Add or Update operations.

2. Main Integration – Scheduling Service

• Fetch all configuration records from the lookup.
• Read the project, integration, schedule, and operation details.
• Pass the required configuration details to the Child Integration.
• Invoke the Child Integration to process the scheduling operations.

3. Child Integration – Schedule Operations

• Receive configuration details from the Main Integration.
• For each record, call the OIC Factory API to retrieve the existing schedule details.
• Append the retrieved schedule information to a file for processing.
• Iterate through each schedule entry.
• Use a Switch action to identify the requested operation.
• Based on the operation type, invoke the corresponding OIC Factory REST API.

Supported Operations:

• Stop: Stop an active schedule.
• Start: Start a stopped schedule.
• Pause: Temporarily pause schedule execution.
• Resume: Resume a paused schedule.
• Add Schedule: Create a new schedule.
• Update Schedule: Modify an existing schedule.

4. Consolidated Execution Report

After processing all records:

• Capture the API response for each operation.
• Maintain success and failure status for every record.
• Capture error details wherever an operation fails.
• Generate a consolidated execution report.
• Send the report through email to the configured recipients.

Benefits

• Automates bulk scheduling operations across multiple OIC integrations.
• Eliminates repetitive manual schedule management.
• Lookup-driven configuration makes the solution reusable and easy to maintain.
• Supports multiple scheduling operations through a single service.
• Provides centralized execution tracking and failure details.
• Improves operational efficiency and reduces manual errors.

Conclusion

By leveraging OIC Factory REST APIs and lookup-driven configurations, we can build a reusable Scheduling Management Service that automates multiple scheduling operations from a single integration. This approach simplifies OIC operational management and provides a consolidated view of all scheduling activities through email reporting.

OIC - Automated OIC Project Export and Backup Using Factory APIs

1. Introduction

To simplify OIC project backup, we developed a reusable integration solution using OIC Factory APIs to export projects as CAR files and save them to the OIC embedded SFTP server. The exported files can then be manually downloaded and uploaded to SharePoint or any other backup location.

2. Solution Overview

The solution consists of two integrations: Main and Child.

Lookup Configuration

An OIC lookup maintains the following project details:

• Project Code
• Project Type (Developed / XBA)
• Version (for Accelerator projects)

3. Integration Flow

Main Integration:

1. Fetch all project details from the configured lookup.
2. Iterate through the lookup records.
3. Pass project code, project type, and version one by one to the child integration.
4. Invoke the child integration for each project.

Get Export lookup data:

GET /ic/api/integration/v1/projects/{projectId}/lookups/{name}

Trigger:

Run from Lookup for all projects:

Adhoc projects run:

Child Integration:

1. Receive project details from the main integration.
2. Prepare the export request based on the project type and version.
3. Invoke the OIC Factory API to export the respective project.
4. Retrieve the generated CAR file.
5. Save the CAR file to the configured OIC SFTP directory.
6. Return the export status to the main integration.

API used: https://<OIC-HOST>/ic/api/integration/v1/projects/{id}/archive?integrationInstance=<service-instance-name>

Request payload:

{

  "code": "TEST_PROJECT",

  "type": "DEVELOPED",

  "label": "01.00.0000"

}

4. Backup Process

Once all projects are exported successfully, the CAR files are available in the OIC SFTP directory. These files can be manually downloaded and uploaded to SharePoint, OCI Object Storage, or any other enterprise backup location.

Oracle Documentation:

https://docs.oracle.com/en/cloud/paas/application-integration/rest-api/op-ic-api-integration-v1-projects-id-archive-post.html?utm_source=chatgpt.com

https://docs.oracle.com/en/cloud/paas/application-integration/rest-api/op-ic-api-integration-v1-lookups-name-get.html?source=%3Aow%3Alp%3Acpo%3A%3A%3A%3ARC_CORP250721P00028%3ADMO400412486

5. Benefits

• Automates project export using OIC Factory APIs.
• Centralizes project configuration through lookups.
• Supports multiple project types.
• Reuses a common child integration for all projects.
• Reduces manual effort in project backup.
• Provides a centralized location for exported CAR files.

6. Conclusion

This solution provides a reusable and configurable approach to exporting multiple OIC projects and consolidating their CAR files in SFTP. It simplifies project backup activities and makes the exported archives available for storage in external backup locations.

OIC Common Service to Submit CCS Batch Jobs and Monitor Job Status | Extract file from Oracle CCS to Object Storage

Objective

Create a reusable common service in Oracle Integration Cloud (OIC) to submit batch jobs to CCS, monitor their execution status, and retrieve the generated files from the Object Storage bucket.

Proposed Flow

Main Integration → Submit Job → Monitor Job Status → Process Output

1. Submit Batch Job

Invoke the CCS API to submit the batch job.

Capture the Job ID returned by CCS.

2. Check Job Status

Use the Job ID to periodically check the job status.

Continue polling until the job reaches a terminal status, such as Success or Failure.

Implement a timeout and retry mechanism.

3. Handle Successful Execution

Once the job succeeds, identify the output files generated by the batch job.

The files are stored in the configured OCI Object Storage bucket.

Retrieve the required file details or file contents for further processing.

4. Handle Failed Execution

Capture the failure status and available error details.

Log the error and notify the calling integration or trigger the required error-handling process.

Architecture Diagram

       Calling Integration

                |

                v

       OIC Common Service

                |

                v

       Submit Job to CCS

                |

                v

        Capture Job ID

                |

                v

       Check Job Status

                |

          +-----+-----+

          |           |

       Running      Terminal

          |           |

          |      +----+----+

          |      |         |

          |   Success    Failure

          |      |         |

          |      v         v

          |  OCI Object   Log Error

          |  Storage      / Notify

          |      |

          +------+

         Poll Again

         While Running

Key Design Considerations

• Reusability: The common service should accept the required job parameters so multiple integrations can use it.
• Polling: Configure an appropriate polling interval and maximum wait time.
• Job tracking: Maintain the Job ID and execution status for monitoring and troubleshooting.
• Object Storage: Ensure the generated files are available in the expected bucket and location.
• Error handling: Handle submission failures, job failures, timeouts, and Object Storage access errors separately.

Expected Outcome

A centralized OIC common service that submits CCS batch jobs, monitors their execution, and handles the generated files in OCI Object Storage based on the final job status.

OIC Blog: Create a Common Service to Update Tracing Level Across Projects

1. Objective

In Oracle Integration Cloud (OIC), changing the tracing level for integrations individually can be time-consuming, especially when multiple projects are involved.

To simplify this process, we can create a common reusable service that updates the tracing level of all activated integrations across selected OIC projects.

The service supports three modes:

1. AUDIT – Enables audit-level tracing.
2. DEBUG – Enables detailed payload tracing for troubleshooting.
3. PRODUCTION – Disables payload tracing to minimize unnecessary logging.

The solution uses two integrations within an OIC project: Main and Child.

2. High-Level Architecture

1. Scheduler / Adhoc Trigger: Input: Execution mode, project names (adhoc), and tracing level
2. Main Integration: Determines the project list based on execution mode
1. Adhoc Uses comma-separated project names from the input
2. Scheduled Fetches project names from the lookup
3. Child Integration: 
1. Retrieves integration details for each project
2. Update Tracing Level: Processes each activated integration using the requested tracing level

3. Lookup Configuration

Maintain the project names in an OIC lookup. No SFTP path is required.

Project Name

Customer_Utilities

Finance_Utilities

HCM_Utilities

The Main integration reads this lookup only during scheduled execution. During adhoc execution, it uses the project names provided as input.

4. Main Integration

The Main integration orchestrates the entire process.

Processing steps:

1. Receive the execution mode and requested tracing level.
2. Check whether the execution is adhoc or scheduled.
3. For adhoc execution, accept comma-separated project names and split them into individual project names.
4. For scheduled execution, retrieve project names from the lookup.
5. Iterate through the project list.
6. Invoke the Child integration for each project, passing the project name and tracing level.

Example adhoc input

Execution Mode : ADHOC

Project Names  : Customer_Utilities,Finance_Utilities

Tracing Level  : DEBUG

For scheduled execution, the project names are obtained directly from the lookup.

5. Child Integration:

The Child integration is responsible for retrieving integration details and updating tracing settings for each project.

Processing steps:

1. Receive the project name and target tracing level from the Main integration.
2. Call the OIC Factory REST APIs to retrieve the integrations belonging to the project.
3. Retrieve integration details, including activation status and available version information.
4. Identify activated integrations.
5. For each activated integration, invoke the appropriate supported API operation to update its tracing configuration.
6. Map the requested tracing level to the corresponding tracing flags.
7. Handle individual failures and continue processing the remaining integrations wherever possible.

Note: you can follow below blog . Here we have shown how to get project lists from lookup and how to get integration list for each project.

https://soalicious.blogspot.com/2026/10/oic-gen3-export-project-integration.html

Tracing-level mapping

The following mapping reflects the approach shown in the provided XSLT screenshot.

The exact flag values should be validated against the API operation and OIC release being used.

API used to update tracing level:

API - /ic/api/integration/v1/integrations/{Integrationld|Version}?enableAsyncActivationMode=true&integrationInstance={ServiceInstanceName}

Security - Oauth2.0

Request Body -

{ "tracingEnabledFlag": true, "payload TracingEnabledFlag": true, "replay": { "canReplay": false }, "payload": {"validate": false }}

Headers - X-HTTP-Method-Override: PATCH

Response -

{ "apiDeploymentInprogress": false, "compatible": false, "links": [], "lockedFlag": false, "payload": { "validate": false }, "payload TracingEnabledFlag": true, "replay": { "canReplay": false }, "scheduleApplicableFlag": false, "scheduleDefinedFlag": false, "tempCopyExists": false, "totalEndPoints": 0, "tracingEnabledFlag": true}

Screnshots for Updating Tracing level:

6. Error Handling and Logging

• For better operational visibility, implement the following:
• Log the project name and integration name being processed.
• Track successful and failed tracing-level updates.
• Handle API errors, authentication failures, and integrations that cannot be updated.
• Continue processing other integrations when an individual update fails.
• Generate a summary with total integrations processed, successful updates, and failed updates.

7. Benefits

1. Centralized management: Update tracing levels across multiple OIC projects from a single service.
2. Reusable design: Support both adhoc and scheduled execution.
3. Reduced manual effort: Avoid changing tracing settings for each integration individually.
4. Flexible configuration: Manage project names through a lookup and pass the target tracing level at runtime.
5. Improved monitoring: Track update results and identify failed operations.

Conclusion

The Main–Child integration pattern provides a reusable way to manage tracing levels across OIC projects. The Main integration determines the projects to process, while the Child integration retrieves their integrations and updates the tracing configuration of activated integrations.

This common service helps OIC teams switch between audit, debug, and production-oriented tracing with minimal manual intervention.