Differences between Load Plans and Packages

Load Plans vs. Packages

Users already knowledgeable of ODI should now wonder: Are Load Plans a new type of packages? Well, although there are similarities between these two objects, they do not have the same objective:

• Packages are (simply said) technical workflows with a strong transaction nature, produced mainly by data integration developers.
• Load Plans aim at making easier the functional design and administration of a production, and are produced by production users and data integration project leads/architects.

Let's discuss the differences:

Capability	Load Plans	Packages	Comments
Edition	Design-Time and Run-Time	Design Time. Packages are compiled into scenarios at run-time.	If production needs to modify the execution flow, it is preferable to deliver a load plan.
Starting/Monitoring	UI, Command-Line, Web Services, Scheduling	UI, Command-Line, Web Services, Scheduling	Both features are equivalent.
Transactions.	Each Load Plan Step contains its own transactions.	Package Steps may share transaction.	If the workflow requires a transaction that spawns accross several steps, use a package.
Parallelism	Yes, using Parallel Steps. Parallel execution is easy to follow in the Operator.	Yes, by starting other scenarios. Parallel execution is hard to follow in the Operator.	When there is a strong need for parallel step execution, use preferably Load Plans.
Restartability	Yes. Status of previous runs is persisted.	Yes. Status of previous executions is overwritten. Database transactions are not  continued, hence restarting the whole package is often needed.	Due to their transactional nature and the fact that their execution is overwritten by the new execution, packages are often restarted as atomic units of work. Load Plan provide better flexibility for restartability.
Branching/Loops	Branching (Case/When is supported) Loops are not supported.	Branching and Looping are supported.	If there is a need for looping in a workflow, use preferably packages.