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:
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.
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.
To enable a package
Open the IS Administration Console if it is not already open.
In the menu of the navigation area, click .
Click 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
Designer online help.
To disable a package
Open the IS Administration Console if it is not already open.
In the menu of the navigation area, click .
Click 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 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.
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.
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.