Run Data Management rule on Autopilot: Streamlining DM Data Jobs with Groovy

Have you ever wanted to run a series of Data Management integrations in Oracle Cloud EPM automatically for specific forecast periods — all while staying user-friendly with runtime prompts and full-on status tracking?

Well, this Groovy business rule does exactly that. Let’s break it down

 

This Groovy rule is designed to automate and control the execution of Data Management (DM) integration jobs for forecast data. It dynamically interprets user input, validates required conditions, and executes the appropriate integration job for each forecast period in sequence.

The rule orchestrates the execution of multiple forecast data movement jobs in Oracle Cloud EPM. The jobs transfer forecast data from one scenario/version to another (like from mid-forecast to working version) using a Data Management (DM) integration job. The timing and execution logic is governed by runtime prompt inputs and substitution variables.

Step 1: Initialization

 Key strings are defined:

• connectionName: Represents the Planning connection.
• connectionNamedm: Targets the Data Management connection.
• integrationJobName: The name of the integration job to execute.

Step 2: Handling Runtime Prompt (RTP)

  

Here’s where it gets interactive. A runtime prompt (RTP_Fsct_Calc_Year) decides which year we’re forecasting. If it’s not selected, the rule politely says nope:

 Depending on the option chosen, it maps to a substitution variable (either the first or second forecast year):

If we don’t get the expected sub var? Yup, another veto.

Step 3: Helper Methods for Job Monitoring

Two utility functions keep tabs on integration jobs—polling the status every 5 seconds until it’s no longer running. If something fails, it throws a friendly but firm error. 

Step 4: Looping Through Forecast Periods

The script loops through eight forecast periods, checking their validity and year alignment. If a period is invalid or mismatched with the selected forecast year, it’s skipped.

 

Before starting a new job, it ensures the last one has finished:

Then it calculates a readable period name (e.g., Jan-25) and kicks off a DM job using a REST call:

If the response or job ID isn’t valid, that period’s status is marked as a failure.

After all periods are attempted, a summary of results is printed—indicating success, skips, or fails for each period:

And a classy touch at the end—logging who ran the rule:

 The Rule is,

• Dynamic: Adjusts to different forecast scenarios using runtime prompts.
• Reliable: Waits for job completion before proceeding—no overlaps!
• Informative: Logs detailed progress and summaries for every step.
• Fail-Safe: Skips bad input, and vetoes on hard stops like missing sub vars.

 

Hope this is helpful, happy days on the Cloud!