Video
Automic Automation Cloud Integrations: Oracle Fusion Cloud ERP Agent Integration
Broadcom's Oracle Fusion Cloud ERP Automation Agent lets you easily integrate Oracle Fusion Cloud ERP jobs and job sets into Automic Automation and synchronize them with your existing enterprise workload automation solution. This video explains the Automic Automation Oracle Fusion Cloud agent integration and its benefits. It presents its components and demonstrates how to install, configure, and use it.

Video Transcript
Welcome to this video on the Automic Automation Oracle Fusion Cloud ERP integration solution.
In this video, we will explain the Oracle Fusion Cloud ERP integration and what it brings to the Automic Automation user community.
Oracle Fusion Cloud ERP is a comprehensive cloud-based enterprise resource planning (ERP) suite developed by Oracle. It integrates various business processes including financial management, procurement, project management, supply chain management, and human resources into a unified platform.
The Automic Oracle Fusion Cloud ERP agent enables running and monitoring of Oracle Fusion Cloud ERP jobs and job sets, providing visibility and control for any workload across the enterprise. Integrating Automic Automation with Oracle Fusion Cloud ERP allows you to run Oracle Fusion Cloud ERP jobs in your workspace from Automic Automation.
We'll provide some technical insights so that the integration components are clearly identified and the deployment sequence is understood. We'll focus on the configuration of the agent and the design of the two core object templates: connections and jobs. Finally, we'll run through a demo.
Automic Automation plays a central role in orchestrating operations across multiple environments, including the cloud. Automic Automation synchronizes these processes with other non-cloud operations. By integrating Oracle Fusion Cloud ERP, we can configure process automation centrally in Automic Automation and then trigger, monitor, and supervise everything in one place.
Oracle Fusion Cloud ERP processes can then be synchronized with all other environments routinely supported by Automic Automation. Oracle Fusion Cloud ERP's role is reduced to execute the jobs; all other functions, especially those pertaining to automation, are delegated to Automic Automation. This means that we don't have to log into the Oracle Fusion Cloud ERP environment and keep on refreshing it by ourselves. Automic Automation manages all the execution and monitoring aspects.
The Automic Automation integration provides a simplified view of Oracle Fusion Cloud ERP jobs. Automic Automation lets us build configurations with intuitive interfaces like drag-and-drop workflows and supervised processes in simple dashboard tools designed natively for operations. Statuses are color-coded and retrieving logs is done with a basic right-click.
From an operations perspective, Automic Automation highly simplifies the configuration and orchestration of Oracle Fusion Cloud ERP jobs. Externalizing operations to a tool with a high degree of third-party integration means we can synchronize all cloud with non-cloud workload using various agents and job object types. We can build sophisticated configurations involving multiple applications, database packages, system processes like backups and data consolidation, file transfers, web services, and other on-premise workload.
A conventional architecture involves two systems: the Automic Automation host and a dedicated system for the agent. The agent is configured with a simple INI file containing standard values: system, agent name, connection, and TLS. When we start, the agent connects to the engine and it adds two new objects to the repository: a connection object to store the Oracle Fusion Cloud ERP endpoint and login data, and a job template designed to trigger Oracle Fusion Cloud ERP jobs.
Let's assume we're automating for four instances of Oracle Fusion Cloud ERP. We create a connection object in Automic Automation for each instance by duplicating the CON template for each of these instances. Lastly, we create the Oracle Fusion Cloud ERP jobs in Automic Automation for each corresponding process in Oracle Fusion Cloud ERP. The Automic Automation jobs include the connection object based on the target system. When we execute the jobs in Automic Automation, it triggers the corresponding process in Oracle Fusion Cloud ERP. We're able to retrieve the successive statuses and finally generate a job report in Automic Automation. This job can be incorporated in workflows and integrated with other non-cloud processes.
The procedure to deploy the Oracle Fusion Cloud ERP integration is as follows:
- First, we download the integration package from Marketplace. This package contains all the necessary elements.
- We unzip this package, which produces a directory containing the agent, the INI configuration files, and several other items like the start command.
- We use the appropriate INI file for our specific platform.
Oracle Fusion Cloud ERP is a standard Automic agent. It requires at least four values to be updated: agent name, Automic system JCP connection and TLS port, and finally the TLS certificate. When the agent is configured, we start it. New object templates are deployed. We create a connection to every Oracle Fusion Cloud ERP instance we need to support. For this, we use the template CON object, which we duplicate as many times as we need. The CON object references the Oracle Fusion Cloud ERP endpoint.
Finally, we use the Oracle Fusion Cloud ERP template jobs to create the jobs we need. We match these Automic Automation jobs to the Oracle Fusion Cloud ERP jobs, reference the connection object, and run them. We're able to supervise the jobs, generate logs, and retrieve the statuses. The jobs can then be incorporated into non-cloud workflows.
We install, configure, and start an agent to deploy the Oracle Fusion Cloud ERP integration. The agent is included in the Oracle Fusion Cloud ERP package, which we download from Marketplace. We unzip the package, which creates a file system `agents/Oracle_fusion_cloud_ERP/bin` that contains the agent files. Based on the platform, we rename the agent configuration file UCXJCX and set a minimum of four values: the agent name, the AE system name, the host name and port connection to the automation engine's JCP, and finally the directory containing the TLS certificate.
Finally, we start the agent by invoking the JAR file via the Java command. The agent connects to the AE and deploys the object templates needed to support the integration: the CON (connection) object and the Oracle Fusion Cloud ERP job templates.
In our demo, we will create a connection object. Once we have established the connection to the Oracle Fusion Cloud ERP environment, we'll create several jobs. Finally, we'll execute and supervise these jobs.
Let's move on to the Automic system. Here we create a connection object with specific inputs to connect to Oracle Fusion Cloud ERP. The first input is the base URL. Here we need to provide the base URL where the Oracle Fusion Cloud ERP system is running, along with the username and password.
Once the connection object is defined, you can create Oracle Fusion Cloud ERP jobs. There are different types of jobs you can work with. Some are pretty straightforward, like download, import, and upload jobs. Then there are more specialized ones like:
- Submit HCM Data Load Jobs
- Submit Oracle ERP Cloud Jobs
- Submit RunFlow Jobs
- Schedule Report Jobs
- Submit BIC Request Jobs
- Submit ESS Jobs
We will explain some of these in more detail later in our demo.
For now, we will focus on the **download job**. The connection drop-down list lets us select the appropriate connection object. Next, we specify the download options. There are four available options, and we need to select the appropriate one based on our needs:
- Download files from the UCM integration service.
- Download files from UCM.
- Download the BIC ESS job output manifest and associated files.
- Download ERP integration services ESS job execution details.
For this demo, we select the BIC ESS job option. We must provide the request ID, which is the ESS request job ID. There’s an optional checkbox available if you want to download the request ID and save it to the specified download directory—simply enable this option.
Next, we configure the download parameters, which start by specifying the directory where the file will be saved. Then we set the file permissions, which is especially important in a Unix environment. Here, we can define permissions for read, write, and execute access. Additionally, we can specify the file owner, thereby determining who will have ownership of the downloaded file—for example, "root" for Unix or "Automic" for Windows. Similarly, we can assign a file owner group to the downloaded file—for example, "root" or "Automic."
Everything is configured now, so we execute the job. Let's go to the **Executions** view. It shows the list of executions in Automic Automation. As you can see, this is the job we have created and completed successfully. If you go to the **Details**, the details pane shows the status field, which tracks the job status in the target environment. The job has ended normally. The details panel also shows an object variable called `&Download_Job_Status#`, which shows the download file status as "Success."
Let’s have a look at the **Reports**. The report section is empty because this is a download operation and no response data is generated for display. However, if you switch to the **Agent Log**, you see that it includes everything related to the job execution from the Automic Automation perspective. It lists all the connection details, followed by the job inputs and execution logs. Finally, we see that the file was downloaded successfully.
Let's check the file status on the local system. This is the request ID that we have provided. If you go to your Oracle Fusion Cloud ERP system, you can locate the folder with the specific request ID. Open this folder to confirm that the file was downloaded successfully.
Now, let's take a look at the specific parameters of an **Upload File to UCM** job. This job allows you to upload files to the Universal Content Management (UCM) server or UCM with Generic SOAP Service from Automic Automation.
First, we specify the connection object, where the connection drop-down list allows us to select the appropriate connection object.
Next, we have the **Job Type**. The drop-down list offers two options:
- Upload File to UCM
- Upload File to UCM with Generate SOAP Service
For the demo, we select *Upload File to UCM*.
Then, we specify the **File Path**, which indicates the location of the file to be uploaded to UCM. We set the **Content Type** to "document." After that, we define the **Document Account**, which specifies the account under which the file will be uploaded.
Next, we need to provide the **Document Author**, and optionally a **Document Name**. The **Document Security Group** is also an optional parameter—it is a fixed value used for importing and exporting documents through the UCM service.
Finally, we specify the **Document Title** and provide the **File Name** that will be created on the UCM server for this document.
Everything is configured now, so we can execute the job and check the **Execution** section. The job ended OK. The **Details** pane shows the status field, which tracks the job status in the target environment—the job has ended normally. The details panel also shows an object variable called `&UCM_Document_ID#`, which shows the ID of the document that was uploaded.
Let’s have a look at the **Reports**. Again, the report section is empty because we have only uploaded a file. The **Agent Log** lists all the connection details followed by the job inputs. Finally, we see that the file was uploaded to the UCM job successfully.
Now, let's take a look at the specific parameters of a **Submit ESS Job**.
Automic Automation Submit ESS Jobs allow you to run and monitor the Oracle ESS job/job set on your Oracle Fusion Cloud ERP application from Automic Automation.
So, let's define the **Connection Object** and select the appropriate connection from the drop-down list. We specify the **Package Name**, which identifies the package where the job definition is defined. Then, we specify the **Job Definition Name**.
After that, we define the **Parameters Input Type**. There are three options:
- None
- JSON File Path
- JSON
For this demo, we'll use *JSON* and include the entire JSON content.
We then have the **Evaluate Child Statuses** option—check this box if you want to include intermittent child processes in the evaluation to determine whether the job should pass or fail.
Next, we have the **Download Execution Details** option, which also includes a checkbox. Selecting this option allows you to download the execution logs for these jobs. Once the box is checked, we provide the **Download Directory Path**, where the logs will be saved.
Everything is configured now, so let's run the job and check the **Execution** section. The job ended OK.
The **Details** pane shows the **Remote Status** field, which tracks the job status in the target environment—the job has succeeded. The details panel displays three object variables:
- `&Submit_ESS_Job_Request_ID#` (intermediate request ID)
- `&Submit_ESS_Job_Status#` (job status)
- `&Submit_ESS_Job_Download_Dir#` (directory where the logs are downloaded)
Let’s have a look at the **Reports**. The report captures the successful response.
The **Agent Log** includes all the connection details and job inputs. The specified directory could not be created because it already exists; however, the file was successfully downloaded and saved as a ZIP file. By checking the status in the local directory, you can verify that the ZIP file was downloaded successfully.
Finally, we can confirm that the job was submitted successfully.
Let’s look at another job type now: the **Oracle ERP Cloud Job**, which allows you to run and monitor ESS jobs on your Oracle Fusion Cloud ERP application directly from Automic Automation.
First, we specify the **Connection Object**. We do not specify the optional **Process ID** parameter, which would allow us to automatically retrieve the job definition including parameters. For this purpose, you would have to run the job once in the agent, copy the agent process ID, and paste it in this field.
Instead, we provide the **Job Definition Name**—this is the Enterprise Scheduling Service job definition name for the job that must be submitted. This name must exist in the agent for the job/job set to be successfully submitted.
Next, we specify the **Name of the Application** where the job is defined. Then, we provide the **Name of the Package** where the job is defined. We decide not to provide a job description.
Next, we have the **Job Type**—you have two options: *Job* and *Job Set*. For this demo, we select *Job*, which is the default setting. We do not define any download execution details.
Everything is configured now. Let's execute the job.
The **Execution** section shows that the job has ended OK. We go to the **Details** pane, which displays the **Remote Status** field—it shows that the job has succeeded. The details panel displays two object variables:
- `&ESS_Submit_Request_Status#` (job status)
- `&ESS_Submit_Request_ID#` (request ID)
Let’s look at the **Reports**. The report captures the response that the request was successful. The **Agent Log** again captures everything related to job execution from the Automic Automation perspective and informs us that the ESS submit request job completed successfully.
The last job that we will review today is the **Submit BIC Request Job**.
Again, we select the appropriate **Connection Object** from the drop-down list. We specify the **Name of the Application** where the job is defined, then provide the **Name of the Package** where the job is defined.
In the **Job Type** drop-down, we see two options: *Job Set* and *Job Definition*. We use the default setting, *Job Definition*, for this demo.
Then, we specify the **Job Definition Name**. After that, we define the **Parameters Input Type**. From the three options—*None*, *JSON File Path*, and *JSON*—we select *JSON* and include the entire JSON content.
Next, we enable the **Request ID Directory** option. This allows the system to create a directory with the request ID name when downloading the log.
Next, in the **Download File Parameters**, we define the **Download Directory** where the file will be saved, and ignore the other options that are the same as those we've already shown.
Everything is configured now, so we execute the job.
Let’s check the **Execution** section. The job ended OK. We go to the **Details** pane and check the **Remote Status** field—it shows that the job has succeeded. The details panel also shows three object variables:
- `&BIC_Request_Job_Download_Dir#` (directory where the logs are downloaded)
- `&BIC_Submit_Request_Status#` (job status)
- `&BIC_Submit_Request_ID#` (request ID)
Let’s have a look at the **Reports**. The report captures the final response. The **Agent Log** lists all the connection details followed by the job inputs. Finally, we see that the job was submitted successfully.
If you check the download status in the directory, you'll see the file we uploaded and the logs have been successfully downloaded.
That wraps up the demo on how Automic Automation can integrate with Oracle Fusion Cloud ERP to execute and monitor various jobs.
Thank you for watching this video.
![]()
|
Note: This transcript was generated with the assistance of an artificial intelligence language model. While we strive for accuracy and quality, please note that the transcription may not be entirely error-free. We recommend independently verifying the content and consulting with a product expert for specific advice or information. We do not assume any responsibility or liability for the use or interpretation of this content. |