Skip to main content
Feedback

Packaged components

Creating a packaged component of your deployable components or processes that you have built is the first step in deployment. Deployable components must be packaged before they can be deployed or shared to the Process Library or as part of an integration pack.

When you create a packaged component or process, you essentially take a "snapshot" of its development on the Build tab, typically when you are done building the process or component and are ready to deploy it to your test or production environment.

The act of creating a packaged component applies to a single, user-defined version number to a component or process, which stays associated with the component even as it is deployed various times across multiple environments (or shared among process libraries and integration packs).

Understanding packaged component versions

Each time you create a packaged component of a process or component, a new version of the packaged component is generated. You can specify an alphanumeric version ID that suits your needs, such as 1.0, Version 1.0, or Alpha Release. If you choose not to specify your own custom version, a version number for each component is automatically generated, which increments based on the latest revision number, respectively.

For example, if you packaged the component previously and used 8.0 as a version number but do not populate this field, then 9.0 will be the new version number when you package the same component again.

The version ID that you specify uniquely identifies version of the packaged component and stays with the version no matter where it is deployed or shared. For instance, you may specify your own version number if you want to adopt numbering for an external source (for example, when coordinating your integrations with application or database changes external to your next release), or if you want to loosely group multiple components to be deployed together.

You can create any number of packaged component versions for a single process or component. For instance, you want to create a packaged component when the initial development is complete, and again each time you apply a fix after testing. You could also tie your packaged components to some larger milestones, such as the coordinated rollout of an integration project.

More about packaged components

For processes, API Service/Proxy components, and Processing Group components, a packaged component contains the primary component and all the dependent components that are required to support that component (such as subprocesses, connectors, or maps). For other deployable components (such as certificates), a packaged component is comprised of the individual component itself.

You create and manage deployable packaged components from the Packaged Components page (Deploy > Packaged Components). In addition to creating new packaged components, you can manage them by:

  • Reviewing the history of the packaged component
  • Viewing detailed information about a specific package version
  • Comparing two versions of a package
  • Determining if the component was shared to an integration pack or process library

Required privileges

You must have the Packaged Component Management privilege (formerly known as Package Management) to create and manage deployable packages.

You can also package processes and components from the Build page, provided that you have both the Build Read and Write Access privilege and the Packaged Component Management privilege.

Packaged component Usage

Packaged components give you greater control over the life cycle and distribution of your processes and components. By creating a packaged component (or rather, creating a version of the finished product in development) and giving it a unique version ID, you can keep track of where each version is being used and whether the same version is being used in more than one place. And if you make a packaged component shareable, that same packaged component with its unique version ID can be:

  • Deployed to one or more environments
  • Published in the Process Library
  • Added to an integration pack

All packaged components can be deployed, but only packaged components marked as shareable when created can be published in the Process Library or added to an integration pack. Furthermore, only certain types of packaged components can be shared:

  • Processes that do not contain Process Route components can be shared in the Process Library.

  • API Service components and processes that do not contain Process Route components can be added to an integration pack.

  • Other types of deployable components (such as certificates and custom libraries) can be deployed, but they cannot be shared.

On this Page