Adapter Definition
Overview
An adapter definition is the framework of an adapter. The adapter definition is recognized as an adapter by Integration Server, but lacks functionality. This chapter describes how to create an adapter definition.
To create an adapter definition, perform the following tasks:
- Create a IBM webMethods package for the adapter definition.
- Create an adapter definition
implementation class by extending the com.wm.adk.WmAdapter base class. The
adapter definition implementation class represents the main class of the adapter. In this class,
create services and methods that:
- Describe the adapter to Integration Server.
- Describe the adapter's resources to Integration Server, including its connection factories, notification templates, and its default resource bundle implementation class.
- Initialize resources and properties referenced by the adapter definition when the adapter is enabled, and clean up the resources when the adapter is disabled (optional).
- Load the adapter onto Integration Server when the adapter is enabled, and unload the adapter when the adapter is disabled.
For more information, see Creating a WmAdapter Implementation Class.
- Create one or more resource
bundles.
The resource bundle class must extend the java.util.ListResourceBundle base class, and contain all the display strings and messages used by the adapter at run time and at design time. A resource bundle is specific to a particular locale. If you plan to run your adapter in multiple locales, you can include a resource bundle for each locale. Creating a resource bundle for each locale enables you to internationalize an adapter quickly, without having to change any code in the adapter. Each adapter must have one or more resource bundles. For more information, see Creating Resource Bundles.
- Deploy the adapter.
- Create the startup and shutdown Java Services.
- Compile the adapter definition.
Compile your implementation class and construct the Java service nodes for your startup and shutdown services. The ADK provides a sample ANT script that you can run from the packages folder.
- Configure the startup and shutdown Java Service in Designer.
For more information, see Deploying the adapter.
Finally, the users of the adapter use Integration Server Administrator to load the adapter by enabling the adapter package. For more information, see Package Management.
Creating an Adapter Package
Create an adapter package in the same way you create any webMethods package, using Designer. If you need instructions for creating a package, see the IBM webMethods Service Development Help for your release.
- You must use the adapterPackageName\code\source folder as your source base and create directories corresponding to your Java package structure (for example, com\mycompany\adapter\myadapter).
- You must set the package dependency as follows:
The WmART package is installed when you install Integration Server.
Field Value Package WmARTVersion *.*
The following figure shows the webMethods package structure:
Adapter Definition Classes
Adapter Definition Implementation Classes (Example MyAdapter)
Creating a WmAdapter Implementation Class
Create an adapter definition by extending the com.wm.adk.WmAdapter base class. This class represents the main class of the adapter. In this class, you create services and methods that:
- Describe the adapter to Integration Server.
- Describe the adapter's resources to Integration Server.
- Initialize and cleanup resources.
- Add custom Dynamic Server Pages (DSPs) to your adapter's administrative interface.
This section describes the basic steps for implementing an adapter definition.
Describing the Adapter to Integration Server
Create an adapter definition by extending the com.wm.adk.WmAdapter base class. You must override the following base class methods in your WmAdapter implementation class:
| Name | Description | |
|---|---|---|
| getAdapterName | Returns the internal name of the adapter. This name is used to identify the text fields in the resource bundle, and to identify the relationship between the adapter and its associated namespace nodes. For this reason, it is important that the value returned by this method does not change after namespace nodes have been created. This name must be unique within the scope of Integration Server. | |
| getAdapterVersion | Returns the current version of the adapter. This value appears in the adapter's About page. This must not be confused with the package version used when setting package dependencies. | |
| getAdapterJCASpecVersion | Returns the JCA standard version supported by the adapter. This
value must always be 1.0. |
|
| getAdapterMajorCode | Must return a unique numeric value (if required) that you can
obtain from IBM. Every adapter built using the ADK requires an internal ID called a major code. A major code is an integer ID that Integration Server uses to distinguish journal log information between different adapter types. The major code is a four digit number between 1 and 9999. Each adapter implementation must have a major code that is unique from all other adapters built using the ADK that might be present in the same webMethods environment. Adapters with identical major codes generate an error in the Integration Server log. More importantly, Integration Server log entries from same code adapters is indistinguishable. The major code ranges are reserved as follows: |
|
| Major Code Range | Description | |
| 1-6999 | This range is reserved for Software AG built webMethods commercial adapters. | |
| 7000-8999 | This range is reserved for adapters built by IBM Development Partners. If you are a Development Partner, you must register your major code with IBM. | |
| 9000-9999 | This range is reserved for adapters you build for use within your own organization. You do not have to register the major codes for these adapters unless you are running them in an environment where the adapters' major codes conflict with other adapters in your webMethods environment. | |
| getAdapterResourceBundleName | Returns the name of your ListResourceBundle implementation class. The value must be the fully qualified name of the resource's associated implementation class rather than an object instance. | |
| fillAdapterTypeInfo | Sets the names of all connection factory and notification implementation classes in an AdapterTypeInfo object. | |
| supportsParallelAssetInitialization | Indicates if the adapter supports parallel asset
initialization. The default return value is false. Override this method and use the
watt property for the adapter to enable or disable parallel asset initialization. |
|
Describing the Adapter's Resources to Integration Server
- All connection factories and notification templates that the adapter supports. You set the names of all connection factory and notification implementation classes in an AdapterTypeInfo object in your adapter's implementation of the fillAdapterTypeInfo method. Set these names later, when you implement the connections and notifications.
- The default resource bundle implementation class. Create a default resource bundle by extending the java.util.ListResourceBundle base class. Deliver the name of your ListResourceBundle implementation class in your adapter's implementation of the getAdapterResourceBundleName method.
Initializing and Cleaning Up
Initialize and clean up the resources used in your adapter implementation. In your WmAdapter implementation class, you can initialize resources and properties specific to your adapter when the adapter is enabled and release the resources when the adapter is disabled. Resources held by connections, adapter services, and notifications have their own cleanup mechanisms.
- There can be only one ArtLogger instance per adapter (that is, per major code). You must manage the ArtLogger instance in your WmAdapter implementation class, but it is optional. You must use a static accessor method, which facilitates access to the ArtLogger instance. In the example, this is accomplished using the getLogger method.
- You must release the ArtLogger instance (and the adapter's major code) using the ArtLogger.close method when the adapter is disabled,. In the example, this is accomplished using MyAdapter.cleanup, which is called from AdapterAdmin.unregisterAdapter.
- You can also use an ARTLogger object to generate journal log entries for your adapter.
Adding Custom DSPs to the Adapter Interface
By default, the adapter's administrative interface includes DSPs for connections, polling notifications, listeners, and listener notifications. You may add custom DSPs by overriding the following public methods provided in the com.wm.adk.WmAdapter abstract class:| Method | Description |
|---|---|
| getUiItemNames | Returns a list of the label strings to insert in the left hand panel of the Integration Server Administrator page for the adapter. Each label represents a link to the DSP to be executed. |
|
getUiItemUrl
(String itemName) |
Returns the URL of the DSP associated with the given
itemName. This effectively binds the displayable item link/label name with the
DSP to launch when the users of the adapter select that link. The URL is relative to the packages
folder of the server installation. For example, if your adapter name is WmFoo and
your DSP is bar.dsp, the URL would be \WmFoo\bar.dsp. In the
file system, however, the .dsp file actually resides in
packages\WmFoo\pub\bar.dsp; the pub folder is not included in the URL. You may
also append arguments to the URL, using the standard notation ?=. |
|
getUiItemHelp
(String itemName) |
Returns the URL of the help file describing the custom DSP page associated with the given itemName. The pathname requirements are the same as for getUiItemUrl(). For example, if your help file is located in \WmFoo\pub\bar_dsp.html, the path returned by this method must be \WmFoo\bar_dsp.html. |
The labels for these DSPs appear in the navigation area in the left hand window of the interface, immediately below the default labels (the Connections, Polling Notifications, Listeners, and Listener Notifications labels) but above the About label.
For information about creating DSPs, see Dynamic Server Pages and Output Templates Developer’s Guide.
Internationalization Considerations for Custom DSPSYou are responsible for implementing these methods (and the associated DSPs) in a manner that takes into consideration the client's locale. In particular, the implementation of getUiItemNames method must perform the necessary resource domain lookups in order to return locale specific values. The system does not automatically perform these lookups for you.
Creating WmAdapter Implementation Class with example
Procedure
Creating Resource Bundles
A resource bundle describes the adapter resources to Integration Server. For example, connection factories, notification templates. You set the names of all connection factories and notification implementation classes in an AdapterTypeInfo object in your adapter's implementation of the fillAdapterTypeInfo method. Set these names when you implement the connections and notifications.
- A resource bundle contains all the display strings and messages used by the adapter at run time and at design time.
- A resource bundle is specific to a particular locale. If you plan to run your adapter in multiple locales, you can include multiple locale specific resource bundles. Creating a resource bundle for each locale enables you to internationalize an adapter quickly, without having to change any code in the adapter. An adapter must have one or more resource bundles.
- A resource bundle consists of lookup keys that provide locale specific objects (normally text
strings). A lookup key consists of a constant provided by the
com.wm.adk.ADKGLOBAL class (a class provided by the ADK's API) combined with your
adapter's class name or a parameter name. For a list of these constants, see Resource Bundle Lookup Keys. For example, the ADK uses the following
lookup key whenever the display name of the adapter is required. (Assume that the
MyAdapter.getAdapterName method returns the class name
MyAdapter where MyAdapter is the WmAdapter
implementation class.)
MyAdapter.class.getName() + ADKGLOBAL.RESOURCEBUNDLEKEY_DISPLAYNAMEThe following lookup key produces a description for a parameter named password, which is used to configure a connection pool:
"password" + ADKGLOBAL.RESOURCEBUNDLEKEY_DESCRIPTIONThe adapter automatically references lookup keys to provide the following:
- Display names, and property
descriptions of the:
- Adapter definition
- Connection types
- Adapter service templates
- Polling notification templates
- Text, display names, and property descriptions for the following elements of your adapter:
- Parameters used to configure nodes
- Metadata group names
- Log entries
- Exception text
- Display names, and property
descriptions of the:
Resource Bundle Lookup Keys
The following table describes the automatic resource bundle lookups performed for each type of adapter element, and describes how the results are used.
| Adapter Element | Key Format | Usage |
|---|---|---|
| Adapter definition |
|
Required. Displays adapter name in Integration Server Administrator and in adapter interface. |
|
Required. Displays adapter description in adapter interface's About window. | |
|
Optional. Displays adapter vendor name in adapter interface's About window. | |
|
Optional. Displays adapter's copyright for third parties in the adapter interface's About window. | |
|
Optional. Encoding used to display adapter's copyright for third parties in
the adapter interface's About window. Required only if the
ADKGLOBAL. RESOURCEBUNDLEKEY_ THIRDPARTYCOPYRIGHTURL is specified. |
|
| Connection type |
|
Displays connection type column in adapter interface. |
|
Displays description column in connection type listing when configuring connections. | |
| Adapter service template |
|
Displays adapter service template name when selecting a template to create an adapter service in Designer. |
|
Displays adapter service template description when selecting a template to create an adapter service in Designer. | |
| Polling notification template |
|
Displays template name column when selecting a template to create polling notification in Designer. |
|
Displays template description column when selecting a template to create polling notification in Designer. | |
| Parameters used to configure nodes |
|
Displays property display name when editing connection, adapter service, and polling notification properties in adapter interface and Designer. |
|
Displays tool tip when mouse is over parameter name when editing service and polling notification properties in Designer. | |
| Metadata group names |
|
Displays property display name when editing parameter group for polling notification in Designer. |
|
Overrides Designer help hyperlink on each tab associated with group. | |
| Log entries |
|
Text in all log repositories (server locale) |
| Exception text |
|
Text in all log repositories (server locale) |
As specified in the preceding table, the lookup keys specifying the adapter's display name, description, and vendor name are required. All other lookup keys are optional, but not specifying the optional lookup keys, can result in generating error messages in the log, thereby making the adapter more difficult to use.
Alternatively, you may define a constant that both the lookup key and getAdapterName use. However, do not call WmAdapter implementation class's getInstance.getAdapterName method to retrieve the adapter name from either of these static initializers, or in the resource bundle constructor. Integration Server instantiates the resource bundle data during execution of the WmAdapter implementation class's constructor super(); calling getInstance method from that point produces undesirable results.
Some lookup keys reference documents, such as copyright and other information. If you include these document files with your adapter, place them under adapterPackageName\pub (where adapterPackageName is the file system folder under the Integration Server's packages folder where your adapter resides). For more information about the Integration Server file system structure, see Creating an Adapter Package.
In your lookup key, identify the resource file using the file path relative to the pub subfolder. For example, to specify the location of the copyright file for MyAdapter, a resource bundle would include the data value:
{ADAPTER_NAME +
ADKGLOBAL.RESOURCEBUNDLEKEY_THIRDPARTYCOPYRIGHTURL,
IS_PKG_NAME + "copyright.html"}
This relative path is equivalent to the following path:
Integration Server_directory\instance\<instance_name>\packages\MyAdapter\pub\copyright.html
This relative path scheme must be used for all URL references used by Designer as well as for the ADKGLOBAL. RESOURCEBUNDLEKEY_ THIRDPARTYCOPYRIGHTURL clause. Other URL references accessed through the Integration Server Administrator or the adapter's administrative interface may use other URL referencing schemes such as absolute paths or valid Internet addresses.
Creating Resource Bundles Class With Example
About this task
To create a resource bundle implementation class
Procedure
Deploying the adapter
The users of the adapter explicitly load and unload an adapter by enabling and disabling the adapter package, using Integration Server Administrator. This section describes:
- Creating Adapter Startup and Shutdown Java Services.
- Compiling the Adapter.
- Registering the Adapter Startup and Shutdown Java Services in Integration Server.
- Debugging the Adapter.
- Loading the Adapter.
- Unloading the Adapter.
This section describes the basic steps for deploying, and debugging an adapter definition.
Creating Adapter Startup and Shutdown Java Services
- The startup method must retrieve an instance of your WmAdapter implementation class and pass it to AdapterAdmin.registerAdapter method.
- The shutdown service must perform the following:
- Retrieve an instance of your WmAdapter implementation class and pass it to AdapterAdmin.unregisterAdapter method.
- Perform the cleanup operations needed by your adapter. In most cases, this is accomplished by calling MyAdapter.cleanup method before the call to AdapterAdmin.unregisterAdapter method.
- Create adapter admin Java class, which is used to generate corresponding Java Services using jcode utility.
- Create Java Services using Designer, which is compiled using Integration Server Administrator.
Creating Java Classes for Adapter Startup and Shutdown
Procedure
Creating Java Services for Adapter Startup and Shutdown using Designer
Procedure
Compiling the Adapter
About this task
Before you load your adapter, you must compile your implementation classes and construct the Java Service nodes for your startup and shutdown services.
Procedure
Registering the Adapter Startup and Shutdown Java Services in Integration Server
Before you begin
- Created your adapter startup and shutdown Java Service.
- Successfully compiled the adapter.
Procedure
Debugging the Adapter
Procedure
Adapter Load Process
The users of the adapter explicitly load and unload an adapter by enabling and disabling the adapter package, using Integration Server Administrator. This figure shows how MyAdapter loads the adapter into Integration Server at run time.
The loading process is described as follows:
- The system calls AdapterAdmin.registerAdapter. This method is the designated package startup service.
- The implementation of registerAdapter instantiates the MyAdapter class by calling its getInstance method. It then registers the MyAdapter object as an adapter by passing it to the registerAdapter method of the AdapterAdmin class provided by the ADK.
- During the construction of the MyAdapter instance, super() calls the base class com.wm.adk.WmAdapter constructor, which instantiates the default resource bundle, calls MyAdapter.initialize, and retrieves basic information about the adapter. (The com.wm.adk.WmAdapter constructor only instantiates the default resource bundle; it instantiates and reads other resource bundles if a request is received using the locale of that supplementary resource bundle.)
- The adapter load process is completed with a call to the static method AdapterAdmin.registerAdapter, which reads and evaluates the adapter's default resource bundle, and updates the Integration Server list of registered adapters. If the resource bundle does not provide the required resource bundle elements, the registration process fails, with an error log entry explaining the failure.
- Upon completion of the adapter's registration, the adapter loads any dependant node packages. See the chapters about connections, adapter services, polling notifications, and listener notifications for descriptions of their respective load processes.
- If the load was successful, the adapter name (as specified in the resource bundle) appears in the list of adapters in Integration Server Administrator. If it does not appear, refresh your browser page. If it still does not appear, check the log for errors.
Adapter Unload Process
During server shutdown or package reload, the system disables the adapter's dependant nodes (or their packages) before it disables the adapter. When you explicitly disable an adapter's package using Integration Server Administrator, disable its dependant nodes first. The diagram shows how MyAdapter unloads the adapter from Integration Server at run time.
To unload an adapter, the server calls AdapterAdmin.unregisterAdapter. This method is the designated package shutdown service. This method performs the following tasks:
- Retrieves the adapter instance.
- Calls the adapter's cleanup method (if implemented).
- Calls AdapterAdmin.unregisterAdapter.
Reporting Adapter Fix Levels
After you deploy an adapter, you may need to deliver a fix. You can identify the fix to Integration Server through the adapter's package manifest file. Whenever the adapter package is loaded, the patch_history field is read from the file and displayed on the adapter's About page. The management of this field is the responsibility of the adapter developer. The Integration Server facilities for creating partial package installations can be used to deliver adapter fixes. For more information, see the IBM webMethods Integration Server Administrator’s Guide for your release.
Package Management
A namespace node package is a package in which the user of the adapter creates the adapter's namespace nodes for connections, adapter services, polling notifications, listener notifications, and listeners. The user of the adapter must not create nodes in the adapter package. Keeping namespace nodes separate from the adapter package simplifies the process of upgrading a deployed adapter.
The procedure for creating a namespace node package is identical to the procedure for creating any webMethods package. For instructions for creating packages, see the IBM webMethods Service Development Help for your release.
All the nodes of an adapter may be located in one package, or they may be distributed among multiple packages. Namespace node packages management tasks include:
- Setting package dependencies for namespace node packages.
- Setting package dependencies for namespace nodes.
- Using access control lists (ACLs) to control which development group has access to which adapter services
- Enabling and Disabling Packages.
- Loading, Reloading, and Unloading Packages.
To perform these tasks, the user of the adapter must use IBM webMethods Integration Server, Designer, and a web browser.
Package Dependency Considerations for Namespace Node Packages
Following are dependency requirements and guidelines for namespace node packages:
- A namespace node package must have
a dependency on its associated adapter package, and the adapter package must have a dependency on
the WmART package. For more information about setting package dependencies, see the
IBM webMethods Service Development Help for
your release. Setting these dependencies ensures that at startup Integration Server automatically loads or reloads all packages in the proper order:
- WmART package.
- Adapter package.
- Node package(s).
- 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 is reloaded automatically.
- You cannot enable a package if it has a dependency on another package that is disabled. That is, before you can enable your package, you must enable all packages on which your package depends. For information about enabling packages, see Enabling and Disabling Packages.
- You can disable a package even if another package that is enabled has a dependency on it. Therefore, you must manually disable any user-defined packages that have a dependency on your adapter package before you disable the adapter package.
If the namespace nodes of an adapter are located in multiple packages, see Package Dependency Considerations for Namespace Nodes. For more information about setting package dependencies, see the IBM webMethods Service Development Help for your release.
Package Dependency Considerations for Namespace Nodes
If all the namespace nodes of an adapter are located in the same package, there is no need to set package dependencies.
However, if the nodes of an adapter are located in multiple packages, then:
- A package that contains the connection node(s) must depend on the adapter package.
- Packages that contain other nodes must depend on their associated connection package.
For more information about setting package dependencies, see the IBM webMethods Service Development Help for your release.
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 about assigning and managing ACLs, see the IBM webMethods Service Development Help for your release.
Enabling and Disabling Packages
All packages are automatically enabled by default. To prevent Integration Server from loading a particular package, you must manually disable that package.
Enabling Packages
To enable the package:
- Start Integration Server Administrator.
- Click Packages > Management.
- In the Management screen, click No in the Enabled column for the package. The No changes to Yes (enabled).
Disabling Packages
To disable the package:
- Start Integration Server Administrator.
- Click Packages > Management.
- In the Management screen, click Yes in the Enabled column for the package. The Yes changes to No (disabled).
Loading, Reloading, and Unloading Packages
Loading Packages
- WmART package.
- Adapter package.
- Node package(s).
Reloading Packages Manually
You must typically reload the adapter package manually as you make changes to the adapter code. Similarly, the users of the adapter must reload their node packages manually when they modify the nodes. Reloading a node package will not cause its associated adapter package to be reloaded.
- In Integration Server Administrator, in
the Management screen, click the
reload icon
in the Reload column. - In Designer, right click the package and select the Reload Package option from the menu.
Unloading Packages
At shutdown, Integration Server unloads the packages in the reverse order in which it loaded them:
- Node package(s).
- Adapter package.
- WmART package (assuming the dependencies are correct).