How to migrate an ODI Enterprise Edition load plan yourself
TLDR
Move one cross-system ODI Enterprise Edition load plan. Preserve its dependency order, data-owner checks, and restart behavior while migrating the reporting job in phases.
To migrate an Oracle Data Integrator Enterprise Edition (ODI EE) load, pick one reporting load plan and trace the scenario versions and source owners it coordinates. Model the serial, parallel, and conditional steps before changing any schedule. The replacement should prove the same reporting output and restart behavior, even when a source is late.
Which part of a failed ODI Enterprise Edition load should be replayed?
AR failed during the Finance Close Load Plan after AP finished. Check the actual restart mode and AP's receipt and input digest for the same close manifest before deciding which branches to run.
Recovery. Reuse AP and rebuild AR's incomplete staging if the configured policy permits and the AP digest matches. If the plan requires a fresh session or the digest differs, rebuild or reconcile the affected artifacts. Check the receiver's posting key before retrying an uncertain external posting.
Cutover check. Compare Operator step and session outcomes, AP and AR rows and minor-unit totals, the reconciliation gate and the posting key. In the same-manifest restart fixture, AP remains at 11 rows, AR finishes at 7, the total is 25,000 minor units, and posting occurs once only after reconciliation.
Prove the Finance Close Load Plan can restart at the right boundary
The sample inputs and expected results in this walkthrough are synthetic.
In Operator collect a failed instance and its restart, plus a successful run under the same period/context. For each step record the Load Plan Instance ID, Load Plan Run ID, child Session ID, scenario version, physical target, predecessor steps, restart type and whether prior effects were reused. Oracle documents different restart modes for serial and parallel steps and for Run Scenario steps. Preserve those distinctions in the orchestrator. Oracle Load Plan operations · Oracle Run Scenario restart modes
| Plan behavior | Successor contract | Parity evidence |
|---|---|---|
| Serial stop after failure | Each completed step publishes an output digest under one close manifest. Downstream reads only a predecessor receipt for that manifest. | Reopening the run reuses the successful predecessor only when the configured restart policy and digest permit it. |
| Parallel branch failure | Stage AP and AR independently. A join reads committed receipts from both. Capture whether the incumbent waits for other children or terminates them. | One failed branch never permits a partial posting. A restarted plan either reuses or rebuilds the other branch according to its recorded policy. |
| Case and exception steps | Store selected branch and skip reason using pinned variables. Give exception notifications and compensations their own IDs and retry policy. | A case that intentionally skips a branch differs from a missing receipt. Only one notice for the same incident reaches the mock receiver on restart. |
| Scenario restart from failed task or new session | Recover from the recorded task boundary when supported. A fresh session rebuilds only attempt-private artifacts or reconciles prior effects first. | Verify the published AP/AR row sets across session attempts. A new run ID alone is not authority to post again. |
Use entity, close_date, input_manifest, scenario_version, step_key, attempt, status, output_digest, effect_key for the ledger. A unique (entity, close_date, posting_revision) holds the business posting identity across reruns. Build separate scheduler states for abandoned attempt, operator pause, technical retry, reconciliation failure and posted. A rerun with changed source digest is a reviewed close revision. Preserve legal-entity and calendar ownership when exposing a rerun button.
Verify recovery at three failure points
Use one entity. AP commits 11 lines and 11000 minor units. AR times out after staging 5 of 7 rows, and the complete AR input totals 14000. Under restart-from-failed-children, recover only AR for that manifest. Confirm AP's original receipt, final 18 lines and 25000 minor units, and one posting. For a reconciliation failure, no posting receipt exists. For a crash after external posting, ask the receiver for the posting key before allowing retry. Switch at one agreed close period and keep the paired legacy and successor evidence for any period that requires correction.
Inventory the plan and the owners
Export the selected load plan and scenario revisions from the deployed environment with an authorized ODI owner. Collect the design mappings and dependency objects with Smart Export as appropriate for your version. Record the contexts, agent, logical schemas, staging locations, and access approvals. Verify which sources and target objects are in scope with their owners. Other integrations may share those objects and should have an explicit place in the cutover plan. Oracle Data Integrator export guide
Read the Load Plan Editor and Operator history together. Oracle load plans can contain serial, parallel, conditional, and Run Scenario steps. They also have exception and restart settings that determine which work is replayed after failure. Note those settings for every branch, along with the variable values, timeout, and observed failure handling. Oracle's load-plan and restart documentation
Replace the plan one branch at a time
For a cross-system reporting load, model an accounts branch and a billing branch as separate Python or SQL jobs with the same business date. Let the scheduler run them in parallel only if the source and staging contracts permit it. Give each branch an immutable manifest and a versioned output. Publish the joined reporting dataset only when both approved manifests are complete and the expected account keys match.
Keep a durable table of plan date, branch state, source revision, validation status, and publication receipt. Encode explicitly whether a failed branch should rerun independently or require every sibling to rerun for a consistent snapshot. Make writes safe to replay by partition and business key. Record who can approve an exception, a late file, or a replacement input before publishing.
Implementation runbook
Capture a Load Plan tree and its restart policy
In ODI Studio export the Load Plan and the exact deployed scenario for every Run Scenario leaf. Record each serial, parallel and case branch, child order, variable expression, exception step, retry/error policy, agent and logical schema in the active context. Export Operator records for a complete run, a stopped/failed run, and its restart. Capture Load Plan Instance ID, Run ID, child Session IDs, step outcome and the scenario versions actually selected. A plan can select the latest version based on an alphabetical version string sort. Freeze the concrete version before translating it. ODI Load Plan export and restart model
On an existing ODI 12.2.1.4 domain configured with a standalone or standalone colocated agent, Oracle documents running an isolated validation plan like this. Use only the non-production agent/context when collecting comparator runs. Check the repository/operator statuses for failed versus completed branches.
./startloadplan.sh -INSTANCE=OracleDIAgent1 FinanceClose DEV \
-AGENT_URL="$ODI_DEV_AGENT_URL" -SYNC=yes
Include the old scheduler, calendars, catch-up rules, overlap permissions and launch parameters. An exception branch is executable work, so document its notifications, compensation and effect on the status separately. Oracle command-line Load Plan operations
Translate the hierarchy into a DAG and recovery ledger
Map sequential children to dependencies, parallel children to independent tasks, case children to mutually exclusive branches with explicit skipped statuses, and exception handlers to separate recovery/notification tasks. At each task define its materialized input and output ID, whether a failed attempt requires cleanup, and whether a plan restart reuses a successful run or resets its scope. Keep the shared reference snapshot fixed for a close cycle. Enforce one writer per target partition and do not let parallel branches race to refresh the same dimension. In step_run(plan_id, close_date, step_name, input_digest, status, output_digest), persist completion with an upsert/load transaction, then configure the orchestrator to resume only eligible children on failure. Run IDs identify attempts. The close cycle and input manifest identify logical work.
A finance-close variant starts with a serial period-control task that fans out to AP and AR loads. Reconciliation waits for both, and posting waits for reconciliation. AP staged 11 rows totaling 110.00. AR inserted 5 of 7 rows into private staging before stopping. Restart the AR task with the same manifest, wipe or version its incomplete staging, and confirm 7 AR rows totaling 140.00. AP must remain at 11 rows/110.00 without running again if its original restart policy reuses successful work. Reconciliation expects 18 rows and 250.00 before one posting receipt is emitted. Now force a reconciliation exception and require posting to remain absent. The rollback boundary is the last acknowledged posting ID, plus the active date and step ledger. Drain or pause the active plan before moving ownership.
Run the acceptance logic locally
Run this self-contained fixture with Python 3. It uses synthetic inputs and no vendor connection. For migration signoff, repeat the same checks against a sandbox on your selected replacement.
run_steps, attempts, receipts = {}, {"AP": 0, "AR": 0}, set()
manifest = "close-2026-10-v1"
def run_branch(branch, rows, fail=False):
key = (manifest, branch)
if key in run_steps:
return
attempts[branch] += 1
stage = []
for amount in rows:
stage.append(amount)
if fail and len(stage) == 5:
raise RuntimeError("staging interrupted")
run_steps[key] = (len(stage), sum(stage))
def publish():
required = [(manifest, step) for step in ("AP", "AR")]
if not all(key in run_steps for key in required):
return False
assert sum(run_steps[key][0] for key in required) == 18
assert sum(run_steps[key][1] for key in required) == 25_000
receipts.add(manifest)
return True
run_branch("AP", [1_000] * 11)
try:
run_branch("AR", [2_000] * 7, fail=True)
except RuntimeError:
assert not publish()
run_branch("AP", [1_000] * 11)
run_branch("AR", [2_000] * 7)
assert publish() and publish()
assert attempts == {"AP": 1, "AR": 2} and receipts == {manifest}
Use AI to translate the plan and exercise restart behavior
Read this redacted ODI EE load plan and two Operator run summaries. Describe each serial, parallel, and case dependency, the scenario version behind each step, and the restart setting. Return a dependency table with any variables, context, or ownership gaps.
Draft a local orchestrator and fixtures for two sources. Make the billing branch fail after accounts succeeds, preserve the successful manifest where the restart rule permits it, and prove that the report stays unpublished until both branches reconcile. List which assertions would change under a rerun-all policy.
Verify the reporting snapshot and coordinate the switch
For a sample day, let accounts stage A1 and A2 successfully while billing fails. Expect the reporting partition to stay unpublished. On retry, use billing rows for A1 at 50.00 and A2 at 75.00. Under a restart-failed-branch policy with a pinned accounts snapshot, expect two matches totaling 125.00 and a single accounts extraction. Add an unknown account to billing and verify that the plan either holds publication or records an approved exception.
Schedule by business date and prevent overlapping publication for that partition. Send operators a reconciliation summary with both source totals, unmatched keys, completed branches, and deadline status. Run against a shadow destination, then cut over at an agreed reporting boundary with each source owner present. Roll back by restoring the old scheduler only after the two teams agree which branch state and output version are authoritative.
Need help with the migration?
Explore Oracle Data Integrator Enterprise Edition migration services or browse all DIY migration guides.
