Oracle® Retail Process Orchestration and Monitoring Oracle® Retail Process Orchestration and Monitoring Implementation Guide Release 21.0 F42216-02 |
|
![]() Previous |
![]() Next |
This chapter describes the various scenarios which involve configuring & integrating the Process Orchestration and Monitoring (POM) application to connect with external systems.
When POM is first installed for a specific customer, it does not include any application batch schedules out of the box such as Merchandising or Retail Intelligence, and so on. An Oracle administrator or a system integrator need to first configure those schedules before they get loaded with the scheduling data. Configuring a new schedule entails setting up schedule properties such as the schedule name and description, and customer environment information for callbacks. It also entails setting up the location of different components and services with which different POM components need to interact to function properly.
Refer to the section "Configure New Schedule" in the "System Configuration" chapter of the POM User Guide.
Different SaaS customers operate in different models for running batch.
For some, the Oracle support team configures the time and frequency for running the batch cycles in POM on their behalf, based on their requirement.
Others may choose to use the Scheduler feature of the product. Refer to the POM User Guide for documentation on the Scheduler.
For others, the capability exists for them to control the time and frequency of batch executions by invoking the following ReST service.
Some may use a hybrid of all or some of the above methods.
Note: All POM endpoints are protected by the OAuth authorization protocol. To invoke an endpoint in POM, a customer application must use an Access Token that was generated using the OAuth Client Credentials Grant. Refer to "Invoking POM Services Using OAuth" in this guide for further details. |
The specification of the ReST service to start the POM cycle execution is shown below:
HTTP Method | POST |
Path | http://<pom-server-host>/ProcessServices/services/private/executionEngine/schedules/<Schedule_Name>/execution
Note: <pom-server-host> and <Schedule_Name> variables need to be changed according to the target environment and schedule. |
HTTP Headers | Content-Type = application/json
Accept-Version = 16.0 Authorization: Bearer <<OAuth_Token_FROM_IDCS>> |
Request Body |
{ "cycleName": "<Cycle Name>", "flowName": "<Flow Name>", "processName": "<Process Name>", "requestParameters":"<Comma Separated Key Value Pairs>" }Notes:
|
Response Body |
{
"value": "171" -Execution Request ID,
"cycleName": "CycleName",
"flowName": "FlowName",
"processName": "ProcessName",
"jobName": "JobName",
"requestType": "requestType",
"requestParameters": ":"<Comma Separated Key Value Pairs>"
"executionEngineInfo": "STARTED",
"hyperMediaContent": {}
}
|
Invocation | Request Payload |
---|---|
Nightly Cycle invocation |
{ "cycleName" : "Nightly", "flowName" : "Nightly", "requestParameters" : "callerId=XXX,correlationId=123" }Note: The Nightly Cycle contains a single flow hence a single invocation will suffice to start the Nightly Flow. |
Hourly Cycle invocation |
{ "cycleName" : "Hourly_Cycle_<N>", "flowName" : "<FLOW_NAME>", "requestParameters" : "callerId=XXX,correlationId=456" }<N> is the cycle number (1 to 24) <FLOW_NAME> is name of the flow (Process Group) to invoke. For example, SALESPROCESS_CYCLE. { "cycleName" : "Hourly_Cycle_1", "flowName" : "SALESPROCESS_CYCLE", "requestParameters":"callerId=Sys_Name,correlationId=456" } Note: The Hourly Cycles comprise of many distinct flows and for each flow a separate invocation would be required. |
Ad hoc Cycle invocation |
{ "cycleName" : "Adhoc", "flowName" : "Adhoc", "processName" : "<ADHOC_PROCESS_NAME>", "requestParameters" : "callerId=xxx,correlationId=789" }Example: { "cycleName": "Adhoc", "flowName":"Adhoc", "processName":"RPM_NEW_ITEM_LOCATION_PROCESS _ADHOC", "requestParameters":"callerId=Ext_System_Name, correlationId= 789" } Note: Ad hoc Cycles are composed of many discrete individual Processes. For each Process, a separate invocation is required. |
The following endpoints provide the ability to check the status of an execution request in POM:
HTTP Method | GET |
Path | http://<pom-server-host>/ProcessServices/services/private/executionEngine/schedules/<scheduleName>/requests/{executionId}
Note: Replace <pom-server-host> according to the target environment. <scheduleName>: Name of the schedule. For MOM apps, the schedule name is "MERCH". For RDE, the schedule name is "RDE". <executionId>: ID of the execution request returned by POM when execution request was submitted. |
HTTP Headers | Content-Type = application/json
Accept-Version = 16.0 Authorization: Bearer <<OAuth_Token_FROM_IDCS>> |
Response Body |
|
The External Status Update feature provides the ability for external systems to register with POM to receive the Job status notifications as a callback to their ReST interface.
This section details the steps to configure the External Status Updates feature at the schedule level:
Navigate to the System Configuration screen.
Click the Edit icon on the External Configuration Panel to open the External Configuration window.
Enter the configuration values:
External Status URL - External system's URL that needs to be called for status updates.
Note: In addition to this configuration, you must work with Oracle support to get the External Status URL allowlist. |
External Status Update Mode - Choose one of the options below:
ALL - POM will send a status update to the external system for each job's execution in the schedule regardless of success or failure.
FAILED - POM will notify only for failed jobs.
NONE - No status updates will be sent by POM.
Note: The External Status Update Mode defined on this screen applies to all the jobs in a schedule. If status update is desired only for specific jobs then set the mode on the above screen to NONE and follow the steps defined in the Job Configuration section below. |
Click Update Credentials and provide the credentials for the external system.
This section describes the steps to configure the External Status Update Mode at job level.
Navigate to the Batch Administration screen and select the schedule to update with the external status.
Select one of the Cycle - Nightly/Recurring/Standalone
Select the Process/Job combination and click Edit from table action menu to open the popup below.
Set the External Status Update Mode one of the following values:
ALL - POM will send a status update to the external system for each job's execution regardless of success or failure.
FAILED - POM will notify only for when this job fails.
NONE - No status update will be sent by POM for this job.
Attribute | Description |
---|---|
processName | Name of the root process in a given cycle/flow
Note: Process names in the callback response are prefixed with the name of the schedule. For instance, a callback response sent for Process "P1" would have processName attribute as MERCH_P1 on return. |
processExecutionId | Unique identifier generated by POM to track the process executions. |
activityName | Name of the job for which the callback/status update is sent. |
activityExecutionId | Unique identifier generated by POM to track the job run instance. |
callerId | Identifier provided by the caller to POM when submitting the invocation/execution request. POM returns the same ID back to caller. |
correlationId | Identifier provided by the caller to POM when submitting the invocation/execution request. POM returns the same ID back to caller |
callBackServiceDataDetail.<KeyName> | Key value pairs supplied to POM when submitting the invocation/execution request. Those are returned back to the caller |
failedActivity | In the case where the callback is for a failed job, this field is populated with the details of the failed Job. |
status | Status of the job execution -
COMPLETED"SKIPPED, ERROR SKIPPED_ON_ERROR |
activityStatus | Status of the job, and the derived activity state:
|
Below are sample external status update payloads for the MERCH schedule.
Description | Payload |
---|---|
Hourly Job Callback |
{ " callerId " : "XXX", " correlationId " : "37", " processName " : "MERCH_ BATCH_PROCESS _01", " processExecutionId " : "MERCH_ BATCH_PROCESS_01 ~asfasfdasdfas", " activityName " : " MERCH_ BATCH_JOB", " activityExecutionId " : "123456", " status " : "COMPLETED", " activityStatus " : "ACTIVITY_COMPLETED", " failedActivity " : null } |
Nightly Job Callback |
{ " callerId " : "XXX", " correlationId " : "37", " processName " : "MERCH_ START_NIGHT_BATCH_PROCESS ", " processExecutionId " : "MERCH_ START_NIGHT_BATCH_PROCESS ~asfasfdasdfas", " activityName " : " MERCH_ START_NIGHT_BATCH_JOB", " activityExecutionId " : "123456", " status " : "COMPLETED", " activityStatus " : "ACTIVITY_COMPLETED", " failedActivity " : null } |
This feature allows customers to control the execution of a schedule running in POM by defining custom pre-dependencies. POM pauses the schedule execution on encountering these external pre-dependences and resumes the execution once they are released by customer.
This section details the steps involved in setting up the external dependency.
Navigate to the Batch Administration screen and select the schedule to which the external dependency will be added.
Select a Cycle - Nightly/Recurring/Standalone.
Find the Process/Job combination to which dependency needs to be added.
Click on the Job name to open the Batch Job Details panel.
On the External Dependency section of the screen, click the Add button to create the external dependency.
Provide the external job name.
Click Ok to save and exit or Ok and add another to create another dependency.
External systems need to invoke the following POM ReST service to release/fulfill the external dependencies.
HTTP Method | POST |
URL | http://<pom-server-host>/ProcessServices/services/private/schedules/<Schedule_Name>/external/jobs/<Ext_Dependendy_Name>/status/COMPLETED
Note: <pom-server-host>, <Schedule_Name> and <Ext_Dependendy_Name> variables need to be changed according to the target environment and schedule. |
HTTP Headers | Content-Type = application/json
Accept-Version = 16.0 Authorization: Bearer <<OAuth_Token_FROM_IDCS>> |
Request Body | None |
Response Body |
{ "value": "true", "links": [], "hyperMediaContent" : { "linkRDO": []} }The true/false in the value attribute shown above indicates the success/failure of releasing the external dependency respectively. |