← All articles
Enterprise Integrations & Use Cases, Oracle Cloud ERP Automation, Technical Tutorials

Oracle ESS Job Monitoring and Recovery. Submission Is Only the Beginning

An Oracle Enterprise Scheduler Service (ESS) request can be accepted successfully and still fail to achieve its business purpose. That distinction is the foundation of reliable monitoring.

Capture the request ID and its operating context

Submitting a job produces a request ID. The request ID proves that Oracle accepted a particular request. It does not prove that the scheduled process ran, completed without warnings, imported the intended records, or produced usable output. Operational automation must preserve that ID, monitor the request to a terminal state, and decide what evidence is needed before a workflow is considered complete.

Fusion Toolkit v3.0’s submit-ess-job command implements the core submit-and-poll loop. The operational design around it, including log capture, alerting, business verification, and recovery, is just as important as the command itself.

Oracle’s ERP Integration Service returns a numeric request ID from submitESSJobRequest. The same service accepts that ID in getESSJobStatus and exposes operations for execution details. The Scheduled Processes interface also uses request identifiers to locate status, parameters, logs, and output. Capture the request ID with the automation run record. At minimum, retain the Toolkit profile and declared environment, job package and definition names, a protected representation of parameters, submission timestamp, request ID, observed terminal status or timeout, process exit code, and a link or procedure for business verification. Parameters can contain business identifiers and dates, so logs require access control and retention. Do not solve observability by copying sensitive payloads into an unrestricted monitoring label.

Bounded polling, not unbounded waiting

The following example uses placeholders and waits up to 45 minutes, polling every 15 seconds.

fusion-toolkit --profile erp-test submit-ess-job \
  --jobPackageName /oracle/apps/ess/example/package/ \
  --jobDefinitionName EXAMPLE_JOB \
  --parameters '<typ:paramList>TEST_VALUE</typ:paramList>' \
  --poll-interval 15 \
  --max-wait 2700

The v3.0 defaults are a 10-second polling interval and a 1,800-second maximum wait. Values below two seconds are raised to two seconds. A short interval gives faster status visibility but creates more SOAP traffic. A long interval reduces traffic but delays alerting. Match the interval to the process duration and response target rather than using an aggressive universal value. The --max-wait flag bounds how long the client waits. It does not set an Oracle execution limit and does not cancel the ESS request. If the command times out, the Oracle job may still be waiting, running, or completing. The request ID is therefore essential for follow-up.

Terminal states and warning semantics

The command polls until the ERP Integration Service reports a terminal string.

  • SUCCEEDED produces exit 0, meaning technical completion succeeded but any required business verification should still be performed.
  • WARNING also produces exit 0 with a warning in the log, meaning completion needs review; exit-code-only monitoring is insufficient if warnings matter.
  • FAILED produces a nonzero exit; inspect the Oracle log and output before deciding on recovery.
  • ERROR produces a nonzero exit; inspect failure details and dependent requests.
  • CANCELLED produces a nonzero exit; determine who or what canceled it and whether resubmission is valid.

Oracle’s Scheduled Processes UI documents a broader lifecycle, including Ready, Wait, Running, Blocked, Paused, Retrying, Error Auto-Retry, Error Manual Recovery, Validation Failed, Succeeded, Warning, and other states. The SOAP status vocabulary for a particular integration may be narrower or normalized differently. Monitor the value actually returned by the service and use the Oracle UI when the process remains in a nonterminal state unexpectedly.

WARNING deserves special treatment. Fusion Toolkit currently returns exit 0 for it because the request completed rather than failed. If a warning can mean rejected records, missing notifications, or incomplete output in your process, alert on the log status or add an explicit post-run verification instead of relying only on the shell exit code.

Submission-only mode needs a durable monitor

Some orchestration systems should submit quickly and monitor elsewhere. The --no-poll option supports that pattern.

fusion-toolkit --profile erp-test submit-ess-job \
  --jobPackageName /oracle/apps/ess/example/package/ \
  --jobDefinitionName EXAMPLE_JOB \
  --parameters '<typ:paramList>TEST_VALUE</typ:paramList>' \
  --no-poll

Here, exit 0 means that Oracle returned a request ID. It says nothing about business completion. Use --no-poll only when another component reliably captures the request ID, monitors status, handles alerts, and performs verification. Fire-and-forget is not monitoring. This mode is useful when a central scheduler maintains durable workflow state, when a callback integration owns completion, or when the job commonly outlives an interactive session. It is dangerous when the submitting script discards standard output and no other system knows the request ID.

Timeouts are unknown outcomes

Set --max-wait from observed duration percentiles plus a deliberate operational margin. A job that normally runs for four minutes may justify a 15-minute client bound. A month-end process may require much longer. Avoid a bound so large that a stuck request occupies a scheduler worker indefinitely.

When the maximum wait expires, the current command returns a nonzero result and logs the request ID. Recovery should begin with read-only investigation. Locate the request ID in Scheduled Processes or query its status through a governed interface. Determine whether it is queued, blocked, running, retrying, or terminal. Review parent and child requests for process sets. Download or inspect the execution log and report output where available. Check whether the intended business records were created or changed. Only then decide whether to wait, cancel through an authorized procedure, correct data, or submit again. A timeout is an unknown client observation, not proof of an Oracle failure. Blind resubmission can create two active requests.

Logs, alerts, and business verification

Oracle’s Scheduled Processes details can show duration, technical parameter values, log attachments, output, and item-level completion text. Those artifacts often explain a terminal warning or error better than the status alone. The ERP Integration Service also documents execution-detail download operations. Fusion Toolkit’s submit command currently submits and polls status. It does not automatically download and interpret every ESS execution log. Build the runbook so an alert includes the environment, request ID, job definition, terminal observation, and the exact location or command an operator uses to retrieve details.

Technical success may still require domain verification. An import job may succeed but import zero records because its selection criteria were wrong. A parent process may succeed while a child produces warnings requiring review. A report may complete but deliver no file to the expected destination. A validation job may run successfully and correctly identify rejected transactions. Define “business complete” per job. That might be an expected record count range, a reconciled control total, the presence of an output file, or a follow-up REST read of one synthetic non-production record. Avoid treating a generic success status as evidence for conditions the job does not itself assert.

An ESS alert should answer the first operational questions without exposing secrets.

  • Which declared environment and Toolkit profile ran.
  • Which job definition was submitted.
  • What is the request ID.
  • Was the outcome terminal, warning, timeout, transport failure, or unknown.
  • How long has it been since submission.
  • Is another retry already scheduled or active.
  • Where are the Oracle log and the automation log.
  • What verification is still required.

Use separate alert severities. A WARNING may be a ticket during a test run but a page during a payment cutoff. A polling transport error with an existing request ID is different from a submission fault with no known ID. Deduplicate alerts by environment plus request ID, not job name alone.

Prevent duplicate submissions

ESS submission is a mutation. If the network connection drops after Oracle accepts the request but before the client receives the ID, the client cannot know from the response whether a job exists. Automatically repeating the submission can duplicate imports, reports, postings, or downstream processes.

Reduce the risk with four controls.

  1. Prevent overlapping scheduler invocations for the same logical workload.
  2. Use unique import sets, batch identifiers, or business keys where the Oracle process supports them.
  3. Record attempts before submission and request IDs immediately after receipt.
  4. On an ambiguous result, search Oracle by time, submitter, definition, and safe business identifiers before retrying.

Do not assume that because polling is read-only, the entire command is safe to retry. The first operation submits a new job.

Recover according to observed state

  • For SUCCEEDED, perform the defined business verification and close the run only when it passes.
  • For WARNING, read the log and reconcile affected items.
  • For FAILED, ERROR, validation failure, or manual recovery, identify the root cause and whether Oracle changed any data before the failure.
  • For a timeout or lost response, preserve the request ID if one exists and investigate current state.
  • If the outcome remains ambiguous, escalate rather than guess.
  • For cancellation, confirm the reason, partial effects, and restart semantics.
  • For a blocked or waiting request, inspect incompatibilities, holds, capacity, and dependencies rather than launching a duplicate.

The safest retry is a new, intentional submission after state has been checked and the original request is known to be terminal or absent. Document why the retry is safe and correlate the new request ID with the original incident.

Operational takeaway

Fusion Toolkit provides bounded status polling and scheduler-friendly exits. Reliable operations come from pairing that mechanism with durable request-ID capture, Oracle logs, business verification, overlap prevention, and a recovery runbook tested in non-production.

Continue reading