Solely Hyperion – Oracle Hyperion EPM weblog: Triggering Pipeline from Groovy Rule

Why
Do We Course of Forecast Durations One by One?

Think about
you’re operating a forecast information load for a complete fiscal 12 months, the place
every interval represents a month or quarter.

#
You don’t need a number of forecast durations operating on the identical time—this
may trigger information conflicts.
# You must look forward to every job to
end earlier than beginning the subsequent one.
# If a job fails, you wish to detect it early and cease execution.

This
script does all of that routinely!

Initializing
the Final Job ID

At
the beginning of the method, we initialize a variable to maintain monitor of the
final job that was submitted:

String
LAST_JOB_ID = “”  // Initialize

• If a job
  remains to be operating, we look forward to it to complete earlier than beginning a brand new one.
• If a job
  fails, we detect the failure and cease processing additional.
• We use
  this variable to regulate job execution circulate.

Looping
Via Forecast Durations

We
loop by every forecast interval (as much as 8 durations on this case).

for
(int i = 1; i

    strive {

        println “Checking forecast interval
${i}”

• The
  script iterates over 8 forecast durations one after the other.
• For every
  interval, we retrieve essential particulars like:

Fetching
Forecast Interval Particulars

For
every interval, we retrieve the corresponding substitution variables:

String
monthVar = “Fcst_Per${i}”

String
yearVar = “Fcst_Per${i}_Yr”

String
quarterVar = “Fcst_Qtr${i}”

String
fcstMonth =
operation.software.getSubstitutionVariableValue(monthVar).toString()

String
fcstYear =
operation.software.getSubstitutionVariableValue(yearVar).toString()

String
fcstQuarter =
operation.software.getSubstitutionVariableValue(quarterVar).toString()

• These
  values inform us which forecast interval we’re engaged on.
• If the
  values are lacking or invalid, we skip the interval (as proven within the
  subsequent step).

Skipping
Durations That Don’t Match the Forecast 12 months

if
(fcstYear != forecastYear) {

    println “Skipping interval ${i} because it
doesn’t match forecast 12 months $forecastYear.”

    proceed

}

• If the forecast
  12 months for the interval doesn’t match the anticipated 12 months, we skip it.
• This
  prevents us from processing information for the unsuitable 12 months.

Skipping
Invalid Durations

if
(fcstMonth == “-” || fcstYear == “-“) {

    println “Skipping interval ${i} resulting from
invalid values.”

    proceed

}

• If the forecast
  month or 12 months is lacking (“-“), we skip this era.
• This
  avoids operating the job with incomplete information.

Ready
for Earlier Job to End Earlier than Beginning a New One

if
(LAST_JOB_ID && LAST_JOB_ID.isNumber()) {

    boolean jobRunning = true

    int checkAttempts = 0

    whereas (jobRunning && checkAttempts

        sleep(5000)

        String activeJobStatus =
getJobStatus(connectionNamedm, LAST_JOB_ID)

        if (activeJobStatus ==
“RUNNING”) {

            println “Ready for earlier
job to complete earlier than beginning Forecast Interval $i…”

        } else if (activeJobStatus ==
“FAILED”) {

            println ” Warning: Earlier
Pipeline Job ($LAST_JOB_ID) failed. Shifting to subsequent interval instantly.”

            break

        } else {

            jobRunning = false

        }

        checkAttempts++

    }

}

• Earlier than
  submitting a brand new job, we examine if the final submitted job (LAST_JOB_ID)
  remains to be operating.
• We wait
  for the job to complete, checking each 5 seconds (utilizing
  sleep(5000)).
• If the
  job fails, we print a warning and transfer to the subsequent interval.

It
ensures no two jobs run on the identical time, stopping conflicts & additionally it helps detect
failures early and cease additional execution if wanted.

Submitting
a New Pipeline Job

If
the whole lot seems to be good, we submit a brand new job for the forecast interval:

HttpResponse
jsonResponse = operation.software.getConnection(connectionName)

    .publish()

    .header(“Content material-Kind”,
“software/json”)

    .physique(json([

        “jobName”: “Job
Name”,

        “jobType”:
“pipeline”,

        “variables”: [

            “FCST_Month_1”:
fcstMonth,

            “FCST_Year_1”: fcstYear,

            “FCST_Period_1”:
fcstPeriod,

            “FCST_Qtr_1”:
fcstQuarter,

            “IMPORTMODE”:
“Replace”,

            “EXPORTMODE”:
“Merge”,

            “ATTACH_LOGS”:
“Yes”

        ]

    ]))

    .asString()

We name
the Oracle EPM REST API to submit a pipeline job for the
forecast interval.

• The job
  makes use of essential variables comparable to:
• Forecast
  Month, 12 months, and Quarter
• Import
  and Export Modes

Storing
and Monitoring Job ID

ReadContext
ctx = JsonPath.parse(jsonResponse.physique)

String
jobId = ctx.learn(‘$.jobId’)

if
(jobId == null || jobId.toString().trim().isEmpty()) {

    println ” Error: Retrieved empty job
ID for interval ${fcstPeriod}. Skipping…”

    proceed

}

LAST_JOB_ID
= jobId.toString()

println
“Saved LAST_JOB_ID: ${LAST_JOB_ID}”

• We
  extract the job ID from the API response and retailer it in
  LAST_JOB_ID.
• This ID
  is used to monitor and look forward to job completion within the subsequent iteration.

Making certain
Job Completes Earlier than Shifting to Subsequent Interval

boolean
isComplete = waitForCompletion(connectionName, LAST_JOB_ID, “Pipeline
Job”)

if
(!isComplete) {

    throwVetoException(” Pipeline job
failed for forecast interval ${i}. Stopping execution.”)

}

• The
  script waits for the job to finish earlier than transferring to the subsequent
  interval.
• If the
  job fails, we abort execution instantly.

This
script ensures that forecast durations are processed so as, stopping overlapping
jobs and dealing with errors gracefully.

✔ Prevents a number of forecast jobs
from operating on the identical time.
✔ Mechanically waits for earlier
jobs to finish earlier than beginning new ones.
✔ Detects job failures and stops
execution if one thing goes unsuitable.
✔ Handles lacking or invalid information
correctly.

This
makes your Oracle EPM automation extra dependable and prevents undesirable
surprises in forecast processing!