OIC - How to import prebuilt integrations from oracle market place | Oracle Utility CCS

Usecase: 

Here, we will see thw steps how to dwonload prebuilt integrations from oracle market place and import to OIC.

Steps to follow:

All integration points are shipped as part of single project (.car) file.

To import a pre-built integration from Oracle Cloud Marketplace:

1.Launch the Oracle Cloud Marketplace portal.

https://cloudmarketplace.oracle.com/marketplace/en_US/homePage.jspx

2.Click Applications.

3.Search for “Oracle Utilities Customer Cloud Service”.

4.Browse through the list of applications and select the pre-built integration project to import.

5.Click GetApp.

6.Review and accept “Oracle Standard Terms and Restrictions”.

7.Click Next. MyOracle Support portal opens.

8.Download the integration project from MyOracle Support.

9.When prompted, select the server where the pre-built integration file should be uploaded.

The pre-built integration is imported as a project file that is visible on the Project page in Oracle Integration Cloud.

10.On the Integrations page, the individual integrations of the imported project file that are designated with a BUILT BY ORACLE message are displayed.

Important! This note is applicable only for existing customers. Make sure to take a backup of the existing project and lookups, and perform the clean up before proceeding with the new project import. The clean up includes deactivating the existing flows in this package and deleting the project, connections, lookups and libraries used in the integration.

To import a project in Oracle Integration Cloud:

1.Login to Oracle Integration Cloud.

2.Navigate to Projects.

3.Click Import.

4.Select the .car file downloaded from Oracle Cloud Marketplace.

5.Verify if the project is imported is successfully.

References:

Prebuilt integrations main page:

https://docs.oracle.com/en/industries/energy-water/cloud-integrations/index.html

steps to download and import:

https://docs.oracle.com/en/industries/energy-water/cloud-integrations/24b/ccs-erp-configuration-guide/index.html#page/CCS-ERP-CONFIGURATION-GUIDE/CCS-ERP_Import-Configure-Test_Connections.07.2.html#ww1025695

Oracle Cloud Marketplace: 

https://cloudmarketplace.oracle.com/marketplace/en_US/homePage.jspx

OIC Gen3 - Oracle Integrations 3 Editions

OIC Gen3 - Understanding of OIC Service roles

In Oracle Cloud Infrastructure (OCI) Gen 3, service roles are specialized permissions that allow users to perform specific operations within the Oracle Integration Cloud (OIC) service. These roles help manage user access at a granular level, ensuring only authorized users can perform certain tasks within OIC. Here’s an overview of the key service roles:

1. Service Administrator

• This role grants full access to the OIC service.
• Users with this role can configure, monitor, and manage integrations, processes, and visual applications.
• They have permissions to access and modify all aspects of the OIC environment, including integration flows, settings, connections, and monitoring tools.
• Ideal for IT administrators or DevOps personnel responsible for end-to-end management of the integration platform.

2. Service Developer

• Designed for users who need to create and manage integrations, process flows, and visual applications.
• Developers can create connections, build integrations, set up orchestrations, and configure REST/SOAP services.
• However, they typically lack permissions for high-level administrative tasks that alter the environment or user access.

3. Service Monitor

• This role is focused on monitoring and viewing capabilities.
• Service Monitors can track the status of integrations, view performance metrics, and analyze logs.
• They cannot make changes to the configurations or deploy new integrations.
• Ideal for support staff or business analysts who need insights into integration performance without administrative rights.

4. Service User(service viewer + service invoker)

• This is the most limited role, often given to end-users who interact with OIC applications or APIs.
• Users with this role may only access integrations that are exposed to them but do not have permissions to modify or configure services.
• Useful for business users or consumers of APIs who need to access OIC features without any administrative control.

5. Service Viewer (OCI Role)

• The Service Viewer role in OCI generally grants view-only access to the resources and configuration of a service.
• In OIC, this type of role would allow users to view configurations, integrations, and monitoring dashboards without the ability to create, edit, or execute integrations.
• However, OIC itself does not explicitly use a “Service Viewer” role; instead, the Service Monitor role serves a similar purpose for monitoring within OIC.
• For broader access at the OCI platform level, Service Viewer can be useful for administrators who need a read-only view into multiple OCI services, including OIC.

6. Service Invoker (OCI Role)

• The Service Invoker role allows users or services to invoke actions within a service, typically through API calls.
• In OIC, this type of role could correspond to allowing a user or a process to invoke integrations or access APIs exposed by OIC.
• Though OIC does not have a dedicated Service Invoker role, permissions for invoking integrations or APIs are often managed through the Service User role or specific policies granting invoke access.
• At the OCI level, Service Invoker can be applied to service principals (e.g., functions, other cloud services) to allow automated interactions with OIC.

Configuring OCI Roles for OIC Access

To grant Service Viewer or Service Invoker-like access to OIC in an OCI tenancy, you can create IAM policies in OCI that assign these roles to specific users or groups.

For example, you could write policies like:

Allow group Viewers to read integration-instances in compartment <compartment_name>

Allow group Invokers to use integration-instances in compartment <compartment_name>

OIC gen3 - using the OCI Object Storage Action | Create bucket | Upload an object to the bucket

Usecase: 

Here, we will create a bucket and upload an object to OS bucket.

In Oracle Integration Cloud (OIC), we can use the OCI Object Storage action to interact with Oracle Cloud Infrastructure (OCI) Object Storage, allowing integration workflows to upload, download, and manage files stored in OCI.

Supported Operations

Under Manage objects:

• Upload Object: Store files in a specified bucket, enabling integration processes to archive data or manage backups.
• Download Object: Retrieve files from a bucket, useful for processing files stored in Object Storage as part of workflows.
• List Objects: Get details on files within a bucket, useful for fetching metadata or initiating further actions based on file availability.
• Delete Object: Remove files from a bucket, which is helpful for cleaning up temporary data or managing lifecycle policies

Under manage buckets:

• Create bucket
• List buckets
• Delete buckets

Bucket creation:

Steps to follow:

1. Create an Application and configure rest trigger to pass the Bucket name as query param or template or body.
2. Drag and drop the OCI object storage and configure
1. Choose manage buckets
2. Choose create.bucket
3. Choose the compartment
3. Map the bucket name to be created.

Screenshots:

Upload an object to the Bucket:

Steps to follow:

1. Create an Application and configure rest trigger to pass the following 
1. the Bucket name and object name as query param
2.  Binary object as request body
2. Drag and drop the OCI object storage and configure
1. Choose manage objects
2. Choose upload objects
3. Map the bucket name, object name and stream reference of the object.

Screenshots:

CCS - About Oracle Utilities Customer Cloud Service

Oracle Utilities Customer Cloud Service is a comprehensive SaaS solution designed to support utilities of all sizes with customer care, service orders, metering, and billing. 

It provides the following features:

• Customer Information and Lifecycle Management: 
• Covers sales and marketing, customer data management,
• service starts and stops, and both inbound and outbound customer interactions.
• Financial Management: Manages rating, billing, payments, and collections.
• Meter Data Management: Includes device and measurement management, data validation and estimation, and usage calculations.
• Service Order Management: Coordinates service order tasks.
• Operational Device Management: Manages assets, including device tracking, configurations, and settings.
• Oracle Utilities Cloud Service Foundation: Supports infrastructure processes, data migration, and batch scheduling.
• Oracle Utilities Analytics Visualization: Offers analytics tools with pre-built models, KPIs, and metrics for data analysis and visualization.

This cloud solution streamlines complex utility processes, enhances customer service, and provides insights for strategic decision-making.

In our project, we will cover the following:

1. Metering
2. Payment and collection
3. Billing
4. Customer interaction

Reference:

https://docs.oracle.com/en/industries/energy-water/customer-cloud-service/24b/ccs-overview-guide/index.html#page/CCS_OVERVIEW_24B/OUCCS_Overview_Guide.2.2.html#ww1035848

Prebuild integrations:

https://docs.oracle.com/en/industries/energy-water/cloud-integrations/index.html

Oracle Cloud Marketplace: 

 Import the prebuild oracle integration cloud project based accelerator from oracle cloud marketplace.

https://cloudmarketplace.oracle.com/marketplace/en_US/homePage.jspx

Rest apis:

https://docs.oracle.com/en/industries/energy-water/customer-cloud-service/restapi.html

OIC - Use of Fault datatype variable | Define Fault Aggregation in Parallel Processing Scenarios

Define Fault Aggregation in Parallel Processing Scenarios

Oracle Integration includes a predefined fault object for fault aggregation. This object enables you to catch and aggregate faults in the context of parallel processing in schedule integrations and to send these faults to an external service to define more granular error handling. To define a fault object and aggregate the faults, you must use actions that support looping (for example, for-each loops, while loops, and so on).

• append: Adds a new fault to the end of a fault list.
• clear: Removes all entries in a fault list.

Two fault aggregation operations are available for selection in schedule integrations:

These options are available for selection under the following scenarios:

Location	Append Option Allowed?	Clear Option Allowed?
Top level (that is, outside of any looping actions)	Yes	Yes
Inside a for-each action with the Process items in parallel option selected	Yes	No
Inside a for-each action loop and a while action loop	Yes	Yes
Inside a stage file action configured with the Read File in Segments operation	Yes	No
Inside a scope action	Yes	Yes
Inside a global fault or a named fault (that is, inside a scope fault handler)	Yes	Yes

1. Create a schedule integration.

   Note:

   The fault object is only supported with schedule integrations.
2. Create an aggregated fault per the scenarios supported in the above table. For example, create a for-each action, then drag an assign action within the loop.
3. Create an assignment and select faults from the Datatypes list.
   The page is refreshed to display the Operations list with two options.
4. 
   
   

5. Build the fault object mapping.

6. Complete your mapping.

7. Define an invoke connection to send the aggregated faults to an external service.

   Note:

   Changing the name, data type, or both is only allowed during initial creation of the variable while not yet assigned a value.

Reference:

https://docs.oracle.com/en/cloud/paas/application-integration/integrations-user/define-fault-aggregation-parallel-processing-scenarios.html

OIC - "How to Modify an OIC .iar File from the Backend"

Usecase:

In many projects, we often face last-minute requirements to rename database assets or variables to comply with specific customer naming standards. Renaming everything through the front end can be challenging, especially when it results in invalid mappings that require a complete rebuild from scratch. Recently, we encountered similar situations where we needed to adjust several variable names and update the database schema name to meet customer standards.

To address this, we decided to create a script using Groovy (though this could be done in any language) to review each file in the .iar and apply the necessary changes. Before beginning this bulk update, please ensure you have backed up the current code, as there is a risk of the .iar file becoming corrupted during the process.

Solution steps:

Step1: You must first export the iar file from your OIC instance in order to start the procedure. Then rename the extension from iar to zip. Now you should open the zip file using 7zip.

Step2:

I wrote a simple Groovy script that searches for a specified string across the entire icspackage folder and replaces it with a new string. The script goes through each file, finds the target string, and replaces it. For example, I searched for the variable name localVar_before_demo, which appeared in four files (logged for reference), and replaced it with localVar_after_demo. To use this for other variables or package names, simply update the script and run it.

Groovry script used:

def dir = new File("C:/Users/Work/Software/DEMO/icspackage")

println "=============================START================================"

dir.eachFileRecurse (groovy.io.FileType.FILES) { file ->

    def fileText = file.text

    def first = fileText.indexOf("localVar_before_demo")

    if (first != -1) {

        def searchString = "localVar_before_demo"

        def replaceString = "localVar_after_demo"

        fileText = fileText.replace(searchString, replaceString)

        file.write(fileText)

        println "Change File ==> " + file.path

    }

}

println "=============================END=================================="