Mirror of Oracle documentation
Converted for search and offline reading. Authoritative source: Oracle. Diagrams and some complex tables are simplified — check the PDF when in doubt.
6 Generic ReST Jobs
This chapter describes how a user can set up ReST Jobs that can be invoked and tracked by POM.
Introduction
As a Job Scheduler, POM provides the ability for applications to invoke and track different types of Jobs. The list of Job Types that are supported in POM by default are defined in the Batch Job section of the Batch Concepts chapter of this guide.
While this list of types meets the needs of Retail Applications that already have their Batch Schedules on POM, it is fixed and lacks extensibility.
To remedy this, POM provides generic interfaces to define and run ReST-based Jobs on external systems that meet certain requirements.
Features of Generic ReST Jobs
To have POM integrate with an external system and to invoke and track Jobs run on that external system, the external system must provide the following capabilities.
| # | Ability / ReST endpoints | Description | Mandatory / Optional |
|---|---|---|---|
| 1 | Start requested Job | Ability to start a Job that was requested and return a unique ID to track its execution. If the Job can’t be started or does not exist, throw an exception | Mandatory |
| 2 | Check status of Job | Ability to accept a unique execution ID and return a status. In case the execution ID is unknown, throw an exception | Mandatory |
| 3 | Restart Job | Ability to restart a Job, given an execution ID of a failed job. Once restarted, a unique execution ID to track the new execution must be returned. | Optional. If the Restart API is not defned, POM uses the Start API (#1) |
| 4 | Kill Job | Ability to stop/abort/kill a running Job. This is not meant to be a graceful stop. It should be a hard-stop and not just a request to the Job to stop when possible. | Optional. If a KILL is requested when it’s not defned, then POM shows an exception popup. |
| 5 | Job Log | Ability to provide runtime logs for the given execution ID. | Optional. |
Implementation Guide G58508-01 Copyright© 2026, Oracle and/or its affiliates.
8. In case the status is still RUNNING , the Agent then goes back to sleep for 5 seconds and thereafter polls the status again. It does so, until a terminal status of ERROR or COMPLETED is received.
Handling Restarts
A restart is handled in almost the same sequence as shown above. Except, instead of invoking the Start endpoint, the Restart endpoint will be used with the previously failed execution ID.
In case the Restart endpoint has not been defined, then the Start endpoint will be used.
Handling Kills
In case of killing/aborting a RUNNING Job, the Kill endpoint is invoked. A successful response from this endpoint will let POM perform its cleanup and also mark the Job with a status of ERROR .
In case the Kill endpoint has not been defined for a Custom Job Type, then invoking the Kill from the POM UI for a running Job of that type will simply show a popup stating the Kill is not defined for the selected Job type.
Applications Notifications
Applications that run their batches through POM are capable of having POM generate a contextual notification upon the completion of a job. The completion can be a success or failure. This is accomplished by the application optionally specifying notification details in the return payload of the Job Status endpoint. For example, an application can upon processing over a million records have the job return a notification object containing the message: ‘Job abcd processed over a million records today’.
See the Job Status API specification in the Generic ReST Jobs section later in this chapter for details.
Defining Custom Job Types
Generic ReST Jobs are defined in POM as Custom Job Types. A class of Generic ReST Jobs is represented in POM as a single Custom Job Type.
All Jobs in POM today have a Job Type attribute. For Generic ReST Jobs, this Job Type will be a Custom Job Type that will encapsulate all the necessary information needed about the destination system.
Batch Schedule Spreadsheet
Custom Job Types can be defined through the Job Types tab of the Batch Schedule spreadsheet. Custom Job Types that are specified on the spreadsheet get seeded into POM when the Batch Schedule is loaded. See Batch Schedule Spreadsheet Template for more information.
POM UI
The Administrator can also maintain Custom Job Types in the Job Types section of the System Configuration screen. Refer to the “Edit Job Type” subsection of the “System Configuration” section of the POM User Guide .
Implementation Guide G58508-01 Copyright© 2026, Oracle and/or its affiliates.
Request Payload The attributes of the JSON payload are as follows : (JSON)
| Attribute | Description |
|---|---|
| cycleName | POM Batch Cycle |
| fowName | POM Batch Flow. |
| processName | POM Batch process name |
| jobName | POM Batch job name |
| parameters | Job Parameters (Double-pipe delimited key-value pairs) as defned in POM |
| agentExecutionId | A unique ID assigned by POM for every job run |
Authentication OAuth System Credentials Grant
Response Payload In case of a successful invocation, a success HTTP code ( 2xx ) is returned (JSON) with a payload like the following:
{
"executionId": "112",
"executionInfo": Job started,
"status": "STARTED"
}
| Attribute | Description |
|---|---|
| executionId | Unique Id returned by the target app to POM for status tracking |
| status | Any status |
| executionInfo (optional) | Any additional info the target app would like to share with POM. |
In case of an issue, an HTTP code other than the success code (that is, not 2xx ) is sent along with an error payload of any format which will be captured as part of the Job failure logs.
Job Status API
HTTP Method
GET
| Query Parameters | |
|---|---|
| (JSON) Attribute | Description |
| processName | POM Batch process name |
| jobName | POM Batch job name |
| executionId | Unique Id returned by the target app to POM for status tracking |
Authentication OAuth System Credentials Grant
Implementation Guide G58508-01 Copyright© 2026, Oracle and/or its affiliates.
Response Payload (JSON)
In case of a successful invocation, a success HTTP code ( 2xx ) is returned with a payload like the following:
{
"status": "COMPLETED",
"executionInfo": null,
"notification": {
"info": "Number of stock counts: 231",
"type": "StockCountErrorNotification",
"severity": 1
}
}
| Attribute | Description |
|---|---|
| executionId | Unique Id returned by the target app to POM for status tracking |
| status | RUNNING / ERROR / COMPLETED. |
| executionInfo (optional) | Any additional info the target app would like to share with POM. |
| notifcation | An optional Notifcation Object containing details regarding an Application’s Notifcation that needs to be generated through POM. |
| notifcation.info | Message to be used for the App Notifcation |
| notifcation.type | Notifcation Type to be used for the App Notifcation. This must be an existing Notifcation Type on the Consuming Application. |
| notifcation.severity | Severity of the App Notifcation generated. Valid values are 1-Critical, 2-Important, 3-Normal |
In case of an issue, an HTTP code other than the success code (that is, not 2xx ) is sent along with an error payload of any format which will be captured as part of the Job failure logs.
Job Restart API
HTTP Method
Request Payload (JSON)
POST
The attributes of the request payload are as follows:
| Attribute | Description |
|---|---|
| cycleName | POM Batch Cycle |
| fowName | POM Batch Flow. |
| processName | POM Batch process name |
| jobName | POM Batch job name |
| parameters | Job Parameters (Double-pipe delimited key-value pairs) as defned in POM |
| agentExecutionId | A unique ID assigned by POM for every job run |
| executionId | Unique Id of the previously failed execution returned by the target app to POM for status tracking |
Implementation Guide G58508-01 Copyright© 2026, Oracle and/or its affiliates.
Authentication OAuth System Credentials Grant Response Payload In case of a successful invocation, a success HTTP code ( 2xx ) is returned (JSON) with a payload like the following:
{
"executionId": "112",
"executionInfo": Job re-started,
"status": "STARTED"
}
| Attribute | Description |
|---|---|
| executionId | Unique Id returned by the target app to POM for status tracking |
| status | Any status |
| executionInfo (optional) | Any additional info the target app would like to share with POM. |
In case of an issue, an HTTP code other than the success code (that is, not 2xx ) is sent along with an error payload of any format which will be captured as part of the Job failure logs.
Job Kill API
HTTP Method
Request Payload (JSON)
POST
The attributes of the request payload are as follows:
| Attribute | Description |
|---|---|
| processName | POM Batch process name |
| jobName | POM Batch job name |
| executionId | Unique Id of the previously failed execution returned by the target app to POM for status tracking |
Authentication
OAuth System Credentials Grant
Implementation Guide G58508-01 Copyright© 2026, Oracle and/or its affiliates.
Response Payload (JSON)
In case of a successful invocation, a success HTTP code ( 2xx ) is returned with a payload like the following:
{
-
"executionId": "112", -
"executionInfo": Job Killed,
"status": "CANCELLED"
}
| Attribute | Description |
|---|---|
| executionId (optional) | Unique Id returned by the target app to POM for status tracking |
| status (optional) | Any status |
| executionInfo (optional) | Any additional info the target app would like to share with POM. |
In case of an issue, an HTTP code other than the success code (that is, not 2xx ) is sent along with an error payload of any format which will be captured as part of the Job failure logs.
Job Log API
HTTP Method GET Query Parameters (JSON)
| Attribute | Description |
|---|---|
| processName | POM Batch process name |
| jobName | POM Batch job name |
| executionId | Unique Id returned by the target app to POM for status tracking |
Authentication OAuth System Credentials Grant Response Payload In case of a successful invocation, the response will contain the log data for (JSON) the execution provided. This log will be viewable in the log downloaded from the POM UI. The logs from the response are also sent in the job log. Any other response while calling this endpoint would be captured as an error while downloading logs.
Job System Check API
HTTP Method GET Authentication OAuth System Credentials Grant Response Payload A success response of 200 or 204 indicates that the system is up and (JSON) running. Any other response while calling this endpoint, should be interpreted as the system being down.
Implementation Guide G58508-01 Copyright© 2026, Oracle and/or its affiliates.
In this guide
- Guide: POM Implementation Guide
- Previous: 5 Customizing Batch Schedules
- Next: Import Configuration