Adapter Development Kit 9.12 | webMethods Adapter Development Kit Documentation | webMethods Adapter Development Kit Installation and User’s Documentation | The Adapter Definition | Creating a WmAdapter Implementation Class
 
Creating a WmAdapter Implementation Class
 
Creating WmAdapter Implementation Class with example
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 Software AG.
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 Software AG Development Partners. If you are a Development Partner, you must register your major code with Software AG.
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
The adapter resources that you must describe to Integration Server include:
*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.
For example, you might initialize the ARTLogger resource.
*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 DSPS
You 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.