In , Workflow Packages are used to facilitate the transportation of data between different environments, such as development, test, and production environments. Workflow Packages are an essential part of the /wiki/spaces/DRXXE/pages/6203150.

The benefits of using Workflow Packages as part of a CI/CD pipeline to speed up time from development to deployment are several:

• Version control: Development, test, and production environments are integrated into the same artifact repository and version controlled.
• Rollback: Changes are easy to rollback.
• Predictable: The same content is guaranteed in all environments.
• Dependent: Simple dependency handling.
• Zero downtime: Zero downtime upgrades are possible (Canary, Blue, Green).

Use the System Exporter(3.0) and System Importer(3.0) to compile, export, and import Workflow Packages. To automate the steps in the CI/CD process use the mzcli command packageexport(3.0) to build Workflow Packages from the command line, and use the command systemimport(3.0) to import the Workflow Packages as MZP files.

Once compiled, a Workflow Package is read-only, assigned a package name, and version number. The package name and version number uniquely identify the contents of the package. A package can never be split.

A Workflow Package can be customized only by applying parameters (external references) or by defining dynamic workflows, so called dynamic parameterization.

Even though Workflow packages are read-only, objects such as profiles, Ultra, and APL, can still exist in multiple copies in different packages, but workflows inside a workflow package will only use the copy which is inside the same package.

Since the package is generated/compiled when it's created, commands for regenerating configuration cannot be used with workflow packages, so any error indicating the need for that can only be resolved by creating a new version of that package.

A Workflow Package is created in the form of an MZP package and contains:

• Selected workflows with all their dependencies (profiles, Ultra, APL, etc).
• All code necessary to execute the workflows.
• A package information file containing information about which exact  version each configuration was generated in, so that the system can detect a mismatch between the system it runs on and the system it was generated on.

Rollback

Since a Workflow Package is a fixed, unmodifiable version of workflows and other configuration, the only action needed for a rollback is to switch to the version in which the workflow package is executed. However, if the rollback is performed because of errors in the latest package, it is recommended to remove that package from the system.

Upgrade

When a Workflow Package is installed or  is upgraded, the package content is always validated against the system version. A workflow package can consist of generated code and if the code generation version differs between the  and the package, the package is then flagged as outdated. In this case, a new package must be created on a  installation with the same version before continuing.