EPM Automate vs Groovy
The Real Debate

Groovy business rules live inside EPCM's Calculation Manager. No external tool, no server, no credentials file. You write the script in a browser, save it, and assign it to a menu item, a form action, or a Task Manager job. Runs as the authenticated user — no separate auth setup.

The Groovy EPM API gives you access to cube data, member hierarchies, forms, and REST connections through a Java-based object model. operation.application is your entry point to everything in the application.

/*RTPS: {Period} {Year}*/
def period = rtps.Period.value
def year   = rtps.Year.value

// Call EPCM REST API — no external tool needed
def conn = operation.application.getConnection("Local")
def body = json([
  jobType: "CalculateModel",
  jobName: "M01",
  parameters: [Period: period, Year: year]
])
def resp = conn.post(
  '/HyperionPlanning/rest/v3/applications/NovaPrism_EPCM_PROD/jobs'
).header("Content-Type","application/json").body(body).asString()

if (resp.status != 200) throwCalcException("M01 failed: " + resp.body)

Groovy gives you full Java exception handling. Wrap any operation in try/catch, inspect the response body, throw a CalcException with a meaningful message that surfaces directly in the EPM Cloud job console and Task Manager alert system. No external monitoring required.

You can also write validation results back to a control member in the cube — Rule Balancing can then monitor that member and surface the error in the Finance Controller's dashboard before they even check email.

try {
  def resp = conn.post(calcUrl).body(body).asString()
  def job  = parseJson(resp.body)

  // poll until complete
  while (job.status == "PROCESSING") {
    sleep(5000)
    job = parseJson(conn.get(statusUrl + job.jobId).asString().body)
  }

  if (job.status != "SUCCESS") {
    // write flag to cube for Rule Balancing visibility
    operation.grid.dataCellIterator("CALC_STATUS_FLAG").each {
      it.data = -1  // non-zero = Rule Balancing will flag it
    }
    throwCalcException("M01 failed: " + job.errorMessage)
  }

} catch (Exception e) {
  throwCalcException("Groovy error: " + e.message)
}

Groovy can read exactly which cells the user just modified in a form, dynamically generate a FIX statement scoped only to those entities and periods, and run a targeted Custom Calc against those intersections only. This is Groovy's original killer feature — and why Oracle built it.

For NovaPrism's M04 (Actual/WhatIf), a single headcount change in IS should trigger only the Finance and HR pool re-allocations, not IT (ticket-count driver is unchanged). Groovy can encode that logic. EPM Automate cannot.

// read which entities were modified in the current form session
def changedEntities = operation.grid.dataCellIterator()
  .findAll { it.changed }
  .collect { it.getMemberName("Entity") }
  .unique()

if (changedEntities.isEmpty()) return

// generate targeted calc script — only affected entities
def fixClause = changedEntities.collect { "\"${it}\"" }.join(",")
def script = """
FIX(${fixClause}, "PCM_Input", "Actual", "Working", "Q1")
  /* recalc Finance+HR pools only */
  "Finance_Pool_Staged" = ...;
  "HR_Pool_Staged" = ...;
ENDFIX
"""
operation.application.getEssbaseServerConnection().calculate(script)

Groovy's epmAutomate() method lets you call EPM Automate commands inline from a business rule. This is the hybrid approach — Groovy as the orchestrator, EPM Automate as the executor. It's useful for sequencing: Groovy validates data, then calls epmAutomate("exportSnapshot", [name:"pre-close-backup"]) before kicking off the calculation. But for pure admin tasks, this adds Groovy complexity for no gain.

// Groovy validates, then calls EPM Automate inline
def poolTotal = operation.grid.getDataCell(
  "IT_Pool_Staged", "ES", "PCM_Input"
).data

if (Math.abs(poolTotal - 52.0) > 0.1) {
  throwCalcException("IT pool validation failed: ${poolTotal}")
}

// snapshot before calculation — epmautomate called inline
epmAutomate("exportSnapshot", [name: "pre-M01-Q1-FY25"])

// now trigger the model via REST
// ... (REST call as shown in Round 1)

EPCM Pipelines can only call Calculation Manager business rules — not native EPCM rule sets directly. This is the documented limitation. The standard workaround: create a Groovy business rule in Calculation Manager that calls the EPCM REST API to trigger calculateModel. The Pipeline calls the Groovy rule; the Groovy rule calls the model. One extra hop, but it keeps everything inside the Pipeline orchestration framework.

When the Finance Controller wants a one-click Pipeline on the EPCM home page that runs load → calculate → copy → aggregate, the Groovy wrapper is the only way to include the calculation step natively.

/*RTPS: {ModelName} {Scenario} {Year} {Period}*/
// This rule is called by the Pipeline job step
// It in turn calls the EPCM REST API to run the model
def app  = "NovaPrism_EPCM_PROD"
def model = rtps.ModelName.value  // runtime prompt = "M01"
def conn  = operation.application.getConnection("Local")
def url   = "/HyperionPlanning/rest/v3/applications/${app}/jobs"
def resp  = conn.post(url)
  .header("Content-Type", "application/json")
  .body(json([jobType:"CalculateModel", jobName:model,
               parameters:[awaitCompletion:true]]))
  .asString()

if (resp.status != 200) throwCalcException(resp.body)

Groovy rules live inside the EPM application. They can be exported as part of a Migration snapshot and imported into test/prod. But there's no native Git integration — you'd export the Calculation Manager rule to a text file, commit that, and import on the target. More friction than committing a .sh file.

That said, Groovy rules are promoted through the same LCM migration path as all other EPCM artifacts — so for teams using EPM Automate's importSnapshot for their release process, Groovy rules come along automatically.

A Groovy rule assigned to a form's "After Save" event fires the moment a user submits data. For NovaPrism, a Groovy rule on the headcount driver form can immediately validate the submission, update staging members, and trigger a targeted recalculation — all before the Finance Controller closes the tab. No schedule. No midnight batch window. No stale data.

This is the user-experience argument for Groovy: the model responds in seconds to data changes, rather than the user waiting until the next scheduled run.