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.

OIC : Common Service to Export Project Integration Version Details to SFTP Using Factory APIs

Objective

The objective is to retrieve Oracle Integration Cloud (OIC) Gen3 project details and their integrations, identify the highest integration version or retrieve all versions, and export the results to a configured SFTP folder.

The solution uses three scheduled integrations — SCH, MAIN, and CHILD — to support both scheduled processing of configured projects and ad hoc processing of selected projects.

High-Level Architecture

1. Lookup Configuration

Project names · SFTP paths · Processing configuration

2. SCH — Scheduler Integration

Receives adhoc parameters or starts scheduled processing

3. MAIN — Orchestration Integration

Determines the project list and invokes CHILD for each project

4. CHILD — Project Processing Integration

Calls OIC Factory APIs, processes integration versions, and generates output data

5. SFTP Output Folder

Stores project integration details for review and reporting.

1. SCH — Scheduler Integration

The SCH integration acts as the entry point for both scheduled and ad hoc execution.

Input parameters

• AdhocProjectName: comma separated project names
• ExportVersion: ALL/Highest
• RunType: SCHEDULE/ADHOC
• Status: ALL/ACTIVATED/CONFIGURED/INPROGRESS/FAILEDACTIVATION

Processing steps

• Receive the input parameters.
• For SCHEDULE processing, invoke MAIN with the schedule configuration.
• For ADHOC processing, pass the project names, version selection, and status filter to MAIN.
• MAIN handles project selection and invokes CHILD for processing.

2. MAIN — Project Orchestration Integration

MAIN determines which projects need to be processed.

Processing steps

• Check the processing type received from SCH.
• If the type is SCHEDULE, read the configured project names and corresponding SFTP paths from the lookup.
• If the type is ADHOC, split the comma-separated project names received from SCH.
• For each selected project, invoke the CHILD integration and pass:
• Project name or project identifier
• Version selection: HIGHEST or ALL
• Status filter
• Target SFTP folder path
• Continue processing the remaining projects and handle individual project failures appropriately.

For adhoc - comma separated case

3. CHILD — Integration Details Extraction

CHILD processes one project at a time and retrieves its integration details using OIC Factory APIs.

Processing steps

• Receive the project details and processing parameters from MAIN.
• Invoke the relevant OIC Factory APIs to retrieve integrations belonging to the project, including the available version information.
• Apply the requested version selection:
• HIGHEST: Select the highest available version for each integration.
• ALL: Include all available versions for each integration.
• Apply the requested status filter, if applicable.
• Map the response into the required output structure.
• Write the integration details to a Stage File.
• Write the generated file to the configured SFTP folder.

Conclusion

This three-integration design separates scheduling, orchestration, and project-level processing. It supports both scheduled and ad hoc execution, configurable version selection, and centralized SFTP output, making the solution reusable for OIC Gen3 project inventory and version reporting.

OIC - Update JSON Content Dynamically Using REST Adapter

Introduction

In Oracle Integration Cloud (OIC), JSON request and response payloads may change dynamically when new fields are added. The REST Adapter's Allow Dynamic Json feature helps process additional JSON elements that are not defined in the original sample schema.

This feature supports for:

1. Trigger Request
2. Invoke Response

2. Use Case

Suppose an API initially returns:

{
  "Val1": "v1"
}

Later, it returns additional fields:

{
  "Val2": true
}

We need to process these new fields without depending entirely on the original JSON schema.

3. Implementation Steps

1. Open the REST Adapter configuration for the trigger or invoke.
2. Select JSON as the payload format and enable Allow Dynamic Json.
3. Configure the initial JSON sample and complete the adapter setup.
4. Open the mapper and map the standard fields using the graphical mapper.
5. For additional fields, update the mapper's XSLT code to extract the required elements dynamically.

Example XSLT:

<xsl:value-of
  select="*[local-name()='test2']"/>

Adjust the XPath to match the actual response wrapper and namespace structure in your mapper.

POC screenshots:

4. Benefits

• Supports additional JSON fields at runtime.
• Reduces dependence on the original JSON sample schema.
• Provides flexibility when API payloads change.

5. Reference

https://docs.oracle.com/en/cloud/paas/application-integration/rest-adapter/using-dynamic-json-content-invoke-connection-response-payloads.html

OIC - How to Download a Used Schema from an OIC Integration

Introduction

While working on an Oracle Integration (OIC) integration, there may be situations where we need to retrieve the XSD schema that is already being used by an adapter or action.

Instead of creating the schema again, OIC provides an easy way to view and copy the schema directly from the integration configuration.

Use Case

Suppose an existing OIC integration is using an XSD through an adapter or an action, and we need the same schema for:

• Reference or documentation
• Creating another integration
• Troubleshooting
• Mapping or validation
• Reusing the schema in another integration

Solution

We can retrieve the schema directly from the Adapter Configuration – Summary page.

Steps

Step 1: Open the OIC Integration

Open the required integration and click Edit.

Step 2: Open the required Adapter/Action

Navigate to the adapter or action where the schema is being used.

For example:

• REST Adapter
• SOAP Adapter
• Stage File action
• Other actions where an XSD/schema is configured

Step 3: Navigate to the last configuration page

Complete/navigate through the adapter configuration until you reach the Summary page.

Step 4: Open the Schema field

On the Summary page, locate the Schema field.

Click on the schema name/field.

OIC opens a pop-up displaying the XSD content used by that configuration.

Step 5: Copy the XSD

From the pop-up, select and copy the complete XSD code.

You can then save it as an .xsd file or reuse the schema wherever required.

Example

For a Stage File action, navigate to the schema configuration and proceed to the final Summary page.

Click the Schema field.

OIC displays the XSD definition in a pop-up window.

Simply copy the complete XSD content and save it as:

Employee.xsd

Key Point

You do not need to recreate or upload the schema just to obtain the XSD being used by an existing OIC configuration.

Adapter/Action → Configuration → Summary → Schema → View XSD → Copy

Conclusion

This is a simple way to recover or reuse an XSD that is already configured in an OIC integration, especially when the original schema file is no longer available.

ERP- Generate PGP Key Pair in Oracle Fusion Using Advanced Create

Introduction

In Oracle Fusion, a PGP key pair can be generated from Manage Transmission Configuration using the Advanced Create option.

The generated key pair consists of:

• Private Key – securely maintained in Oracle Fusion.
• Public Key – generated by Fusion and made available in UCM.

The public key can be downloaded from UCM and subsequently used in Oracle Integration Cloud (OIC) for PGP-based encryption or other applicable security requirements.

This blog explains the complete process using Advanced Create.

Use Case

The objective is to generate a PGP key pair in Oracle Fusion and make the public key available in OIC.

High-Level Flow

Oracle Fusion

     |

Manage Transmission Configuration

     |

Advanced Create

     |

Generate PGP Key pair( private & Public)                   |   

Export to UCM

     |

 Download  keys to use in oic.

                         

Step 1: Go to Manage Transmission Configurations

Log in to the Oracle Fusion application >> Navigate to My Enterprise >> Setup and Maintenance >> Search >> Search with Manage Transmission Configurations >> click to open Manage Transmission Configuration

Step 2: Create PGP Key pair.

Select "Secure File Transfer protocol for static file names >> add a configuration name >> Provide PGP Private key password >>click on the dropdown list for PGP private Signing Key field >> select Advanced create option >>Select the PGP Key attributes as per required.

A typical configuration can include:

Key Type       : RSA

Key Size       : 2048 / 3072 / 4096

Expiration Date   : As per project requirement

Encryption Algorithm     : AES128/AES192/AES256

Hash Algorithm : SHA256/SHA384

Compression    : BZIP2/ZIP/ZLIB

Step 3: Export the PGP key pair.

Step4: Download keys from UCM

Go to fusion UCM : https://<fusion hostname>/cs > search with key name prefix and click actions >> info > click to download the file.

Step 5: Configure the Public Key in OIC

The downloaded Fusion public key can now be configured in OIC according to the integration requirement.

Public Key vs Private Key

Understanding the purpose of each key is important.

Public Key : The public key can be distributed to the system that needs to encrypt information for the private-key owner.

Private Key: The private key must be protected and should not be distributed unnecessarily.

It is used for operations such as:

• Decryption
• Digital signing

Conclusion

Using Advanced Create in Oracle Fusion's Manage Transmission Configuration provides a controlled way to generate a PGP key pair with the required cryptographic parameters.