Package Management

The EntireX Adapter is provided as a package called WmEntireX. This document describes how to set up and manage your EntireX Adapter packages, set up access control lists (ACLs). It covers the following topics:


Package Dependency Requirements and Guidelines

This section contains a list of dependency requirements and guidelines for user-defined packages. For instructions on setting package dependencies, see webMethods Service Development Help.

  • A user-defined package must be dependent on its associated adapter package, WmEntireX. (The WmEntireX package is dependent on the WmART package.)

  • Package dependencies ensure that at startup the Integration Server automatically loads or reloads all packages in the proper order: the WmART package first, the adapter package next, and the user-defined package(s) last. The WmART package is automatically installed when you install the Integration Server. You should not need to reload the WmART package manually.

    Tip:
    When you create connections, adapter services, and adapter notifications, define them in user-defined packages rather than in the WmEntireX package. This makes it easier to manage packages. As you create user-defined packages in which to store connections, adapter services, and adapter notifications, use the package management functionality provided in the Designer and set the user-defined packages to be dependent on the WmEntireX package. That way, whenever the WmEntireX package loads or reloads, the user-defined packages load automatically as well.

  • If the connections and adapter services of an adapter are defined in different packages, then:

    • a package that contains the connection(s) must have a dependency on the adapter package.

    • packages that contain adapter services must have a dependency on their associated connection package.

  • Keep connections for different adapters in separate packages so that you do not create interdependencies between adapters. If a package contains connections for two different adapters, and you reload one of the adapter packages, the connections for both adapters will reload automatically.

  • The Integration Server will not allow you to enable a package if it has a dependency on another package that is disabled. That is, before you can enable your package, you have to enable all packages on which your package depends. For information on enabling packages, see Enabling and Disabling Packages.

  • The Integration Server will allow you to disable a package even if another package that is enabled has a dependency on it. Therefore, you have to manually disable any user-defined packages that have a dependency on the adapter package before you disable the adapter package. For information on disabling packages, see Enabling and Disabling Packages.

  • You can give connections, adapter services, and notifications the same name provided that they are in different folders and packages.

Enabling and Disabling Packages

All packages are automatically enabled by default. To temporarily prohibit access to the elements in a package, disable the package. When you disable a package, the server unloads all of its elements from memory. Disabling a package prevents the Integration Server from loading that package at startup.

Start of instruction setTo enable a package

  1. Open the IS Administration Console if it is not already open.

  2. In the Packages menu of the navigation area, click Management.

  3. Click No in the Enabled column.

    As a result, the server displays a tick and "Yes" in the Enabled column.

Note:
Enabling an adapter package will not cause its associated user-defined package(s) to be reloaded. For information on reloading packages, see the webMethods Service Development Help.

Important:
Before you manually enable a user-defined package, you first have to enable its associated adapter package (WmEntireX). Similarly, if your adapter has multiple user-defined packages, and you want to disable some of them, disable the adapter package first. Otherwise, errors will be issued when you try to access the remaining enabled user-defined packages. See Managing Packages in the webMethods Service Development Help doumentation or choose Software AG Designer Guides > webMethods Service Development Help > Managing Packages in the Software AG Designer online help.

Start of instruction setTo disable a package

  1. Open the IS Administration Console if it is not already open.

  2. In the Packages menu of the navigation area, click Management.

  3. Click Yes in the Enabled column for the package that you want to disable. The server issues a prompt to verify that you want to disable the package. Click OK to disable the package. When the package is disabled, the server displays "No" in the Enabled column.

Note:
A disabled package will remain disabled until you explicitly enable it using the IS Administration Console. It will not be listed in the Designer.

Importing and Exporting Packages

To export packages, use the Designer. You can export the package to a ZIP file and save it to your hard drive. The ZIP file can then be imported for use by another Integration Server.

Important:
Do not rename packages you export. The rename function is comparable to moving a package: when you import the renamed package, you lose any triggers, connections, and notifications associated with this package. For details on managing packages, see webMethods Service Development Help.

Group Access Control

To control which development group has access to which adapter services, use access control lists (ACLs). You can use ACLs to prevent one development group from inadvertently updating the work of another group, or to allow or deny access to services that are restricted to one group but not to others. For general information on assigning and managing ACLs, see webMethods Service Development Help.