This document describes how to set up and manage your EntireX Adapter packages, set up access control lists (ACLs). It covers the following topics:
The EntireX Adapter is provided as a package called WmEntireX. This section 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 the Developer User's Guide.
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 Developer 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 Integration Server Administrator 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 Developer User's Guide.
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.
To disable a package
Open the Integration Server Administrator 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 enable the package. When the package is disabled, the server displays "No" in the Enabled column.
A disabled package will:
remain disabled until you explicitly enable it using the Administrator.
not be listed in the Developer.
To import and export packages, use the Developer. 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 importing and exporting packages, see the
Developer User's Guide.
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 the Developer User's Guide.
