Packages

You can reuse your webMethods packages in webMethods Integration projects to streamline development and maintain consistency across multiple integrations. By leveraging existing packages, you can avoid redundant work and ensure that proven services, APIs, and assets are efficiently incorporated into new projects.

A package is a container for related assets such as services, configurations, and other resources. These packages are the primary unit of deployment and versioning in webMethods Integration. When a project is created, a package is created with the same name as the project. For example, if you create a project that is named FlowAny, an associated package is automatically generated in the system as FlowAnyProject. When you add a service, specification, or document type to the project, they are stored in the corresponding package. So, a package contains the assets that are used in the project. Thus, you can easily manage all the services and files in the package as a unit.

Apart from your project assets, you can add the integration packages that are stored in any external repositories to a project and use it along with other assets in the project. Currently, you can add packages that are stored in GitHub.

Important: webMethods packages that are referenced in your package are pulled from the webMethods Package Registry and like containers are secured by using an access token. This token is automatically generated and included in the runtime manifest file by your tenant. This token can become invalidated and result in errors when syncing. In which case you must do a resync from webMethods Integration to get a refreshed token.

Packages offer many benefits such as,

  • Modularity and Reusability - Organize and modularize your integration components and services, making it easy to reuse and share them across different projects.
  • Version Control - Maintain and manage package versions, which is crucial for tracking changes, ensuring compatibility, and rolling back to previous versions if needed.
  • Isolation and Security - Provide a level of isolation, helping you control access to specific integration assets. This improves security and safeguards against unauthorized modifications.
  • Ease of Deployment - Simplify the deployment process by bundling related integration components into a single unit. This reduces deployment errors and ensures consistency.
  • Enhanced Maintenance - Easier to maintain and manage integration assets, as changes can be localized within a package without affecting other parts of the system.
  • Customization - Create custom packages that are tailored to your organization's specific needs, promoting flexibility and adaptability to your requirements. Thus, packages offer a structured and efficient way to manage, deploy, and maintain integration components, promoting modularity, reusability, and security for efficient integration management.

Packages Tab

The Packages tab lists the packages that are used in your project. The main package is created when the project was set up is highlighted in blue and appears on the first row. Custom packages that are imported from external repositories are listed beneath the main package.

The Packages tab displays the following details about the packages that are used in a project.
Package Name
Name of the package. You can click the package name to view complete details of a package in the Package Details view that consists of the following tabs: Package Information, Assets, Security, and Libraries.
Version
Indicates the version number of the package.
Load Status
Indicates whether a package is loaded and ready for use. The following are the package load statuses:
  • Yes if the package is loaded and active..
  • Partial if the package is loaded with errors such as missing dependencies or corrupted files.
  • No if the package is not loaded are services are unavailable for use. In this case, you can reload a package.
Actions
Lists all actions that you can do on a package. If the package load status is No, then the options to reload and enable are displayed.

End-to-end workflow for reusing webMethods packages

  1. Package creation and storage
    1. Use webMethods Service Designer to create your package.
    2. Include all necessary assets: connections, adapter services, and supporting components.
    3. Test all services locally to ensure they are error-free.
    4. Save the package in a Git repository or another version control system for easy access and reuse.
  2. Add packages to projects
    1. Import packages from Git into your integration projects.
    2. Make sure that all dependencies and configurations are correctly mapped.
  3. Manage connections
    1. Configure environment-specific credentials and endpoints as needed to manage runtime connections.
  4. Deploy to runtimes
    1. Run services from packages using runtime environments.
    2. Deploy across different stages, for example, dev, test, prod for consistent and scalable execution.

Assets supported in packages

The table provides a list of assets that are supported when a package is built by using IBM® Designer and is imported into the webMethods Integration project.

webMethods Integration Server Configuration or Asset Name Minimum Runtime Version Supported Description
Flow Service 11.0.0 Flow services that are built by using supported assets can be imported into webMethods Integration projects and deployed to runtimes.
Java™ Service 11.0.6 By default, Java services are denied from execution in the runtime. If needed, you can enable execution selectively from the Security tab of the imported package.
Map Service 11.0.0 Map and transformations are supported in runtimes.
Document Type 11.0.0 Document types in the package are supported and can be used by services in the runtime.
Flat File Dictionary 11.0.6 Flat File dictionary in the package is supported and can be used by services in the runtime.
Flat File Schema 11.0.6 Schema in the package is supported and can be used by services in the runtime.
Schema 11.0.6 Schema in the package is supported and can be used by services in the runtime.
Global Variables 11.0.6 Package-scoped global variables are supported and can be used within the packages in the runtime.
FTP 11.0.7 Only outbound FTP is supported, allowing users to send files to external servers. Inbound FTP is not supported, that is, the runtime cannot act as an FTP proxy. Files can be stored externally in a mounted volume. Ideally, it is not advised to store files within the container, as containers are volatile.
HTTP 11.0.7 Only outbound HTTP is supported. Inbound FTP is not supported for deploy anywhere integrations. However, inbound calls are supported for regular workflows or flow services in webMethods Integration.
SMTP 11.0.7 Only outbound SMTP is supported, and users can send outbound emails by using the pub.client.smtp services. SMTP aliases are not supported in version 11.0.6.

Key points to consider for packages

  • The Packages feature supports debugging and follows a process similar to regular flow services.
  • Simultaneous import of packages that contain assets with the same namespace is not allowed. Attempting to import under such conditions might result in unexpected behavior, as all assets might not be successfully imported.
  • The Add missing package dialog is displayed during export-import scenarios. The dialog is not shown in the clone scenarios for package services. Make sure that the package services are available in the target project. For deploy anywhere flow services, this dialog is not shown in all scenarios.
  • You cannot have different versions of the same custom package between projects that are hosted in the same runtime. A user can choose to upgrade the version of a custom package during an import. But, this action also upgrades the package that is referenced in all other projects to that version. You cannot revert to the previous version.
  • For the AS400 Connector, you need to create and enable the connection in the flow service before you run the services.
  • If a package is available in the package view but not available in the Cloud Designtime, a warning message appears indicating that the package is not available in the Cloud Designtime.
  • If the Cloud Designtime restarts and the custom package cannot be restored due to an expired Git token, you are prompted to reenter your Git credentials. The user interface displays a message to indicate that the token is expired, and that you need to update the Git token to restore the package.
  • For projects linked to a Git repository, if your Git token expires during a Cloud Designtime restart, a prompt appears to reenter your Git credentials. You need to update the Git token details to restore the package.