OIC - Versioning in Oracle Integration Cloud (OIC) - Generation 3

Versioning in Oracle Integration Cloud (OIC) - Generation 3

In OIC Generation 3, versioning follows a three-part format:

1. Major Version:

Indicates significant changes or new functionality that may introduce breaking changes.

Example: Moving from 01.x.x to 02.x.x.

Two major versions can be active simultaneously, allowing phased rollouts or parallel use.

 2. Minor Version:

Represents backward-compatible updates or new features.

Example: Moving from 01.00.x to 01.01.x.

Only one minor version can be active at a time within a major version.

3. Patch Version:

Used for small fixes or non-breaking changes.

Example: Moving from 01.00.0000 to 01.00.0001.

Only one patch version can be active at a time within a minor version.

Key Features

Multiple Active Versions: Two major versions can be active simultaneously, but only one minor or patch version is allowed per major version.

Draft and Active States: Draft versions are used for testing and updates, while active versions are used in production.

Version History: Previous versions are retained for rollback if needed.

Testing and Deployment: Draft versions are isolated for testing without affecting active versions.

This flexible versioning approach ensures seamless updates, backward compatibility, and controlled multi-version management.

OIC - Using REST API vs ERP Cloud Adapter in FBDI Import

REST API vs ERP Cloud Adapter in FBDI Import

1. Definition: REST API allows direct interaction with Oracle ERP Cloud using HTTP methods, while ERP Cloud Adapter is a prebuilt integration adapter in Oracle Integration Cloud (OIC).
2. Ease of Use: REST API requires development knowledge like JSON payloads and endpoint management, whereas ERP Cloud Adapter simplifies integration through configuration with minimal coding.
3. Integration Approach: REST API involves custom coding and manual endpoint management, while ERP Cloud Adapter provides pre-configured mechanisms for FBDI import.
4. Automation: REST API requires manual setup for automation, but ERP Cloud Adapter offers built-in automation for FBDI imports.
5. Error Handling: REST API requires custom error handling, while ERP Cloud Adapter includes built-in error tracking and handling features.
6. Performance: REST API is better for lightweight integrations, while ERP Cloud Adapter is optimized for complex or large-scale processes.
7. Learning Curve: REST API requires knowledge of REST frameworks, while ERP Cloud Adapter is easier for functional users familiar with OIC.
8. Scalability: REST API scalability depends on custom logic, whereas ERP Cloud Adapter scales seamlessly with OIC.
9. Cost: REST API has minimal licensing costs but higher development effort, while ERP Cloud Adapter requires OIC licensing, increasing overall cost.

Conclusion

While both REST API and ERP Cloud Adapter can facilitate FBDI imports, the choice depends on your requirements. REST API is ideal for lightweight, custom integrations with lower upfront costs but requires significant development effort. On the other hand, ERP Cloud Adapter simplifies integration with prebuilt automation and error handling, making it more suitable for complex, large-scale processes, though it requires an OIC license.

OIC - Oracle Integration-Bulk load into Oracle ATP OR Oracle ADW

Oracle Integration enhances its database adapters, including Oracle Autonomous Transaction Processing (ATP) and Autonomous Data Warehouse (ADW) Adapters, to support native bulk load operations. Leveraging Oracle Autonomous database and OCI features, these enhancements significantly boost performance.

A typical use case involves importing bulk data by retrieving a file (e.g., from an FTP server or HCM system), placing it in object storage, and loading its contents into an ATP-S database. Oracle Integration can also reformat files (e.g., XML or JSON) into the database's required format, such as CSV.

To implement the integration flow:

1. Create an App Driven Orchestration or Schedule Based Orchestration based on the requirement.
2. Download the file from the FTP location to the staging area.
3. Use the Oracle Autonomous Transaction Processing Adapter or Autonomous Data Warehouse Adapter as per your database instance.
4. In the adapter wizard:
1. Select Perform bulk data import operation.
2. Choose the OCI Bucket and enable Delete file from object storage after operation completion.
3. Edit Copy data format options, select the file format, schema, table, and columns. Ensure the columns align with the incoming data order.

Reference:

https://blogs.oracle.com/integration/post/oracle-integration-bulk-load-into-oracle-atp-or-oracle-adw

OIC - Convert a package to a project

To convert a user-developed package into a project in Oracle Integration:

1. Navigate to Design > Packages.
2. Hover over the package to convert (accelerator and recipe packages are not eligible).
3. Click the Actions icon and select Create Project.
4. Enter a name, keywords, and an optional description.
5. Choose whether to allow anyone to edit, view, and monitor resources by selecting or leaving the corresponding checkbox unchecked.
6. Click Create. A message confirms the project creation and provides a link to access it.

The newly created project includes all resources (integrations, connections, lookups, and JavaScript libraries) from the package, leaving the original package unchanged.

Screenshots:

OIC - Restrictions on Using Stage File Action Operations with the File/Attachment Features of the Connectivity Agent

Restrictions on Using Stage File Action Operations with the File/Attachment Features of the Connectivity Agent

When configuring the stage file action in the Configure Stage File Action wizard, note that there are restrictions on using some operations with the connectivity agent.

• List File operation: Files uploaded through the connectivity agent are not available with the List File operation.
• Read Entire File and Read File in Segments operations: Files uploaded through the connectivity agent can only be read with a file reference.
• Zip File operation: Files uploaded through the connectivity agent are not available with the Zip File operation.
• Unzip File operation: Files uploaded through the connectivity agent can only be unzipped using a file reference.

Reference:

https://docs.oracle.com/en/cloud/paas/integration-cloud/integrations-user/add-actions-app-driven-orchestration-integration.html#GUID-63CCAB23-A32C-4655-9490-191A011E9EEA

OIC - "Dynamically Configuring Relative URLs for REST API Invocations in Oracle Integration Cloud" | Dynamically invoke local integration

Use Case:

In Oracle Integration Cloud (OIC), there is often a need to dynamically determine the Relative URI while invoking REST APIs. This is particularly useful in scenarios where integration flows must interact with multiple endpoints or services based on dynamic parameters, such as job names, document IDs, or other runtime variables.

Example Scenario:

A bulk data export integration requires a lookup of specific job names and their corresponding endpoint URIs dynamically during runtime. The target REST API expects the Relative URI to change based on the job being processed, ensuring the correct endpoint is invoked.

Solution:

To achieve this, you can use the lookupValue function within the OIC mapper to resolve the required Relative URI dynamically. Here's how:

1. Setup a Lookup Table in OIC:

Create a lookup table in OIC with columns for "Job Name" and "Integration URL". Populate the lookup with key-value pairs for job names and their corresponding relative URIs.

2. Configure the Mapper:

In the mapper, map the required source variable (e.g., Var_JobName) to the target Relative URI field.

Use the lookupValue function to fetch the URI dynamically based on the job name.

Syntax:

lookupValue("Lookup_Name", "JobName", Var_JobName, "IntegrationURL", "Default_Value")

The dynamic uri which we will be passing from lookup , is as below format:

/ic/api/integration/v1/flows/rest/<integrationIdentifier>/1.0/

Limitation:

All the REST APIs being invoked dynamically must have the same request and response payload structures to ensure seamless mapping and processing in the integration.

Invoke local Integration

The same functionality can be achieved using the "Invoke Local Integration" action when calling multiple local integrations. However, this requires all the local integrations to share the same request and response payload structures for consistent processing.

We have to pass integration code(identifier)and version dynamically from the lookup.

Note: if you are using the local integration call within a project, then as per new release, we have to mention project name as project code along with thw code and version.

OIC - How to add days to date YYYY-MM-DD using prebuilt functions

Use Case: 

Adding a Specific Number of Days to a Database Fetched Date in the Format YYYY-MM-DD

Logic Steps:

1. Convert the input date (in YYYY-MM-DD format) to a date object using the date() function.
2. Add the required number of days using the dayTimeDuration("P10D") function (e.g., for 100 days, use "P100D").
3. Finally, convert the result back to a string using the string() function.

Solution :

string((xsd:date(/nstrgmpr:execute/ns20:request-wrapper/ns20:inputDate) + xsd:dayTimeDuration("P10D")))