1 Introduction

The Process Orchestration and Monitoring (POM) application provides comprehensive batch scheduling and monitoring capabilities for Oracle Retail SaaS Applications.

The key features for POM are

• Customizable Batch Schedule – Customers can tweak the Batch Schedule to suit their needs. These tweaks are maintained across Batch Schedule upgrades.

• Support for multiple scheduling modes:

  • Cyclical (or Hourly)

  • Adhoc (or Standalone)

  • End of Day (or Nightly)

• Support for Custom Batch Entities, either through the UI or the public APIs provided.

• Flexible Schedule Invocation options:

  • POM Scheduler - Supports multiple cadences and frequencies that can suit most scheduling requirements

  • Public APIs - Externally triggered

• Ability to integrate with External systems:

  • External Dependencies

  • Publish callbacks to external systems

  • Invoke ReST endpoints on external systems (Custom Job Types)

• Configurable Email Notifications

  • For different phases of Job Execution

  • Emails to alert users when the system is waiting on certain conditions or when Jobs encounter errors

  • Comprehensive summary of the Nightly Cycle

• Programmatic access through Public APIs

Architecture

From a deployment perspective, the various batch components of POM, can be classified into two logical groups:

• POM Application

• POM Agent

POM Application

The POM application is essentially composed of multiple components. These components are housed in the rgbu-common subnamespace.

POM Jet UI

This is a JET Application that serves as the User Interface for POM. It provides screens for the administration of Batch Schedules as well as monitoring screens to keep track of executing batches.

Different POM roles are provided for accessing the features in this application. Refer to User Roles and OAuth Scopes to understand the definition and use of these roles.

Process Services

This provides all the endpoints needed by the POM UI. It also exposes public APIs that can be used to integrate other applications with POM.

Execution Engine

The Execution Engine is the core component that drives all batch executions within POM. Basically, to run any Job in POM, there must be an Execution Request created on the Execution Engine. The Execution Engine then processes the request by creating Job requests on the respective POM Agents.

Agent

The POM Agent is a lightweight, schedule agnostic component that executes jobs requested by the POM application and returns a job status upon job completion or error. For each request received by the Agent, it spawns an executor, based on the Job type, to run the Job associated with that request.

The Common Agent depicted above is deployed within the rgbu-common namespace itself. This Agent can be used by multiple Batch Schedules, without needing to deploy a separate Agent within the Consuming Application namespace. The only restriction is that this Common Agent will only support ReST-based Job types.

Customers also have the option to create their own custom schedules and configure those to use this common agent to execute their batch. See Customizing Batch Schedules for more information.

Scheduler

The POM Scheduler is the component that is mainly responsible for the scheduling of tasks within POM. The Scheduler processes tasks by creating Execution Requests on the Execution Engine.

Refer to Scheduler Tasks for further details.

POM Agent

The POM Agent is deployed alongside the Consuming Application (for example, Merchandising) and responds to requests from POM for running Jobs.

The POM Agent is a repave-aware component that does the following:

• Processes each Job request received by running the respective Job.

• Sends a status update to POM upon Job completion.

• Provides the ability to download Job logs.

Execution Sequence

Multiple components work together to execute batches in POM. The following diagram makes this evident.

• To run any Job in POM, an Execution Request must be created on the Execution Engine:

  • By scheduling a task using the POM Scheduler

  • Run an Adhoc Job, through the POM Jet UI

  • Invocation of public execution APIs

• The Execution Engine handles that request by creating a Job Request on the appropriate Job Agent.

• The Job Agent spawns a new thread to handle the Job Request. This thread dynamically selects an executor based on the Job type associated with the Job Request.

• The Job Agent invokes the Execution Engine to update the Job status periodically.