Part 11 of 12 in the Oracle EPM Cloud REST API series.
Change metadata in Planning, a new member, a renamed entity, an added dimension, and it is not immediately usable in calculations and reports until the underlying cube catches up. That catch-up step is a cube refresh, and it is the third job type this series covers in detail, alongside business rules and data imports.
The request
{
"jobType": "CUBE_REFRESH",
"jobName": "MyRefreshCube",
"parameters": {
"allowedUsersDuringCubeRefresh": "All Users",
"terminateActiveRequestsBeforeCubeRefresh": "false",
"logOffAllUsersBeforeCubeRefresh": "true",
"allowedUsersAfterCubeRefresh": "Administrators"
}
}
Same endpoint as the previous two job types, .../applications/Vision/jobs, same POST method, same headers.
The parameters explained
These four parameters exist because a cube refresh is disruptive. It typically requires exclusive or near exclusive access to the application while it runs, so Oracle gives you control over who stays logged in during the process.
allowedUsersDuringCubeRefresh sets who can remain connected while the refresh is running, commonly restricted to administrators only.
terminateActiveRequestsBeforeCubeRefresh decides whether any in-flight requests get forcibly ended so the refresh can start immediately, rather than waiting for them to finish naturally.
logOffAllUsersBeforeCubeRefresh controls whether every connected user gets logged out before the refresh begins, which is the safer setting for a change significant enough to need a refresh in the first place.
allowedUsersAfterCubeRefresh sets who is allowed back in once the refresh completes, useful for keeping an application locked to administrators only until validation is finished.
Why this one belongs in a script
Cube refreshes tend to follow metadata changes closely, and metadata changes are themselves often scripted or triggered by an upstream system, an EDMCS push, a bulk member load, or an EPM Automate import. Tucking the refresh into the same automation as the metadata change itself means there is no gap where the application sits in an inconsistent state, with metadata updated but the cube not yet reflecting it. A human remembering to click Refresh Database manually, sometime after the metadata load finished, is exactly the kind of manual step this series set out to remove back in part one.
As with the previous two job types, the response and the polling approach are unchanged from what part nine already covered: a jobID, a status field on the same negative one through four scale, and a GET call against the job's own ID to confirm it actually finished before anything downstream depends on the refreshed cube being ready.
Three job types down. The final post in this series steps back from specific jobs to cover the habits that separate a script that works once from one you can trust every month end, along with where to look when something does not go as planned.