EPM Sync and Runs

Four actions move work between your folder and the Pod: Pull from EPM, Push to EPM, Deploy, and Execute. You can start them from three places:

• the editor title bar of any open rule, which acts on that one rule,
• the right-click menu in the Pod tree, where the target can be a single rule, a folder, a plan type, or the whole application,
• the Command Palette (Ctrl+Shift+P / Cmd+Shift+P), under EPM Workbench.

All four need the Full tier and a Pod with a live connection. Execute applies to rules and templates only.

Pull from EPM

Fetches the Pod’s current copy of the selected artifacts down into your Pod Folder and updates the sync badges from what it found.

If Pull would overwrite a file you changed locally, it stops and lists those files with the time you last edited each one. You then choose Overwrite All, Skip All, Choose per file, or Cancel Pull. Overwriting saves a copy of your local file first, so nothing you wrote is lost.

Push to EPM

Writes your local copy back into Calculation Manager on the Pod. That is all it does: the rule is updated in Calc Manager but is not deployed, so the Planning application still runs the previously deployed version until you Deploy.

Deploy

Deploys the rule in EPM, which creates the deployed copy in the Planning application as well as in Calculation Manager. Deploy is where %Template and %Script references are expanded, so the deployed rule contains the fully resolved calculation.

Execute

Execute is the whole round trip: it Pushes, then Deploys, then runs the rule on the Pod and brings the log back into VS Code.

Before it submits, Execute looks at the Problems panel for the rule. Any Error-severity problem on the file stops it, with the offending lines listed. You can proceed anyway with Ignore, silence the gate with Ignore for 24h, or cancel and fix the rule. Warnings and information never block Execute.

Run-Time Prompt values are asked for last, after every other confirmation, so cancelling at the prompt costs you nothing.

Confirmations and unsaved changes

By default, Deploy and Execute ask for confirmation before acting and Push does not. The epmWorkbench.confirmBeforeSync setting is a ladder: confirm before all three, before Deploy and Execute (the default), before Execute only, or never.

Push, Deploy, and Execute always act on the last saved copy on disk, never on an unsaved editor buffer. When the rule has unsaved changes, they ask what to do about it, and the dialog’s “Always…” buttons write your answer into epmWorkbench.saveBeforeRun. Both settings are described in Settings.

The Runs Panel

Every action becomes a Run in the EPM Runs panel at the bottom of VS Code, next to Terminal and Output. Open it from the panel area, from the command EPM Workbench: Show Runs, or from the Show Runs button on the notification that appears when a Run finishes.

Each Run shows:

• its title and the Pod it targeted, for example “Execute Monthly Allocation”,
• how long it took and how long ago it started,
• who it ran as: Service Account or EPM account, if you signed in with your own EPM account,
• a timeline of Steps. An Execute, for instance, walks Generate Payload, Deploy Payload, Update Sync State, and Execute Rule. Each Step shows its duration and, where Oracle assigned one, its job id.

Click View log on a Step to read what came back, including Groovy log() output and calc script error text. The log window has Copy all and Open in editor for anything you want to keep or search.

A Run ends as Succeeded, Failed, Canceled, or Interrupted. Individual Steps can also read as Pending, Submitting, Running, or Skipped.

Cancel

Cancel stops the Steps that have not started yet. It does not stop the one already in flight. Remaining Steps are skipped and marked as such, but the Step already running finishes on the Pod, because Oracle does not stop a submitted job partway, so the panel keeps showing that Step as running rather than as stopped.

If VS Code closes while a Run is in flight, the extension checks that Run’s Oracle job the next time you open the workspace, and again whenever you open the Runs Panel. If Oracle has a verdict, the Run settles as Succeeded or Failed, because the job kept going on the Pod after VS Code went away. If there is no verdict to be had, it settles as Interrupted. Either way nothing is submitted on your behalf: Steps that never started stay unstarted, and there is no Resume button. Start the action again when you are ready.

If something goes wrong

Connection and credential problems usually surface on the first Step of a Run. For setting up or repairing a connection, see Install and first Pod. For specific error messages, see Troubleshooting.