Overview
About Adapter for MSMQ
IBM webMethods Adapter for MSMQ is an add-on to IBM webMethods Integration Server that allows you to exchange information with other systems through a Microsoft Message Queue (MSMQ) system. This capability provides seamless and real-time communication to and from the MSMQ system.
Using Adapter for MSMQ, you can route documents, or any piece of information, from webMethods components to systems that use Microsoft Message Queuing. For example, you might use Adapter for MSMQ to extract information from an XML-based purchase order, repackage it as an order record, and deliver it to a queue for processing by a back-end enterprise system. You also might use Adapter for MSMQ to monitor a queue and issue updates to various systems when a message appears in that queue.
Overview of Queuing Concepts
This section discusses the following topics:
- Queuing
- Message queuing computer
- Messages
Queuing
Queuing is a programming technique in which two programs exchange data asynchronously, without calling one another directly. Using queuing, two programs communicate by passing messages to one another via a queue. Conceptually, a queue is like an "inbox." When one program wants another program to process a piece of information, it simply puts that information into the other program's queue. On the other end, the receiving program monitors its designated queue and processes messages that other programs deposit in it.
There are two types of queues, public and private. Public queues are registered with a directory service and can be located by any message queuing application. Private queues are registered solely on the local system and usually cannot be located by other applications.
Systems that interface with one another through queuing never interact directly; they only interact with their queues. In fact, a program might not process its queue until hours, days, or weeks after another program deposits a message in it.
Message Queuing Computer
A message queuing computer, such as an MSMQ message queuing computer, acts as an intermediary between the programs that want to exchange information. It functions as a server, controlling the flow of information in and out of a set of queues. Queues reside on the message queuing computer and you can associate multiple queues with one message queuing computer.
The programs that want to communicate with one another (whether they are the suppliers of information or the consumers of information) are the clients of message queuing. Because these programs do not interact directly, they are considered peers of one another. Under this architecture, one program is not subordinate to, or a client of, the other.
Messages
A message is a discrete unit of information that one program wants to pass to another. The following examples are possible message types:
- A string containing a purchase order
- A binary data structure containing an employee record
The message queuing computer does not impose any constraints on the content or format of messages exchanged via a queue, and neither does Adapter for MSMQ.
When a program puts a message into a queue, the client envelops or wraps the message with control information such as routing information, priority codes, and message type. The term "message" also can refer to the entire message structure; that is, the control information in addition to the unit of information to be passed. In this context, the unit of information is usually referred to as the message body, the application data, or the user data. When this distinction is necessary, this book uses the term Body to refer to the content of the message.
To use queuing effectively, programs that communicate via a queue must agree on a common message content and structure. For example, if Program A is designed to pick up and process cXML-formatted purchase orders from a queue named "Orders", programs that interact with Program A must deliver properly-formatted cXML purchase orders to the Orders queue. Identifying the content and structure of the Body is a key activity that you must perform when designing a system that exchanges data through Adapter for MSMQ.
Architecture and Components
This diagram illustrates how Adapter for MSMQ interfaces with an MSMQ system using the MSMQ libraries. Following the diagram are descriptions of the different architectural pieces involved in the integration process.
For a more detailed description of the run-time data flow for the different types of Adapter for MSMQ services, see Adapter Services.
- IBM webMethods Integration Server . Adapter for MSMQ is installed and runs on Integration Server.
- WmART Package. The WmART package provides a common framework for webMethods 6.0 and later adapters to use Integration Server functionality, making Integration Server the run-time environment for Adapter for MSMQ. The WmART package is installed with Integration Server.
- Adapter for MSMQ. Adapter for MSMQ is delivered as a single package called WmMSMQAdapter. Adapter for MSMQ provides Integration Server Administrator user interfaces that enable you to configure and manage adapter connections and listeners, and IBM webMethods Designer user interfaces that enable you to configure and manage adapter services and notifications.
- Adapter Connection Templates. Adapter connections enable Adapter for MSMQ to connect to MSMQ systems. You must configure an adapter connection before you can configure adapter services. The adapter provides a template for adapter connections in Integration Server Administrator. For a detailed description of adapter connections, see Adapter Connections.
- Adapter Service Templates. Adapter services enable Adapter for MSMQ to implement the MSMQ COM libraries to perform operations on MSMQ queues. Adapter for MSMQ provides adapter service templates that enable you to configure services to put, get, and peek messages. For example, a Get service enables you to retrieve messages from a MSMQ queue that are then sent to another application such as a purchase order entry system. Adapter for MSMQ's adapter service templates are available in Designer. For more information about adapter services and using the adapter service templates, see Adapter Services.
- Adapter Listener Template. An adapter listener monitors the queue for messages and passes the messages to a listener notification. You must configure adapter listeners before you can configure adapter notifications. Adapter for MSMQ provides adapter listener templates that enable you to configure listeners, which monitor a queue for messages. For more information about listeners and how to use them, see Adapter Listeners and Listener Notifications.
-
Adapter Notification Template. A notification waits for
an adapter listener to pass a message to a listener notification. A listener notification then passes the
messages to Integration Server. For
example, an adapter listener could listen for a specific priority on a queue, such as a priority of 4. The
adapter listener monitors the queue for all messages that contain this priority, retrieves the messages from
the queue, and then passes them to the adapter listener notification for further processing.
Adapter for MSMQ provides adapter notification templates that enable you to configure notifications, which process the message either synchronously or asynchronously. For more information about listener notifications and using the templates, see Adapter Listeners and Listener Notifications.
- MSMQ Libraries. Adapter for MSMQ uses the MSMQ client libraries to communicate with the MSMQ server.
- Message Queuing Computer. The message queuing computer acts as an intermediary between the programs that want to exchange information. It also functions as a server, controlling the flow of information in and out of a set of queues. Adapter for MSMQ requires that you specify the queue path name when you configure transactional or non-transactional connections. For detailed instructions on how to configure connections, see Configuring Adapter Connections. For more information about message queueing computer, see Message Queuing Computer.
- Queue. The queue acts as an "inbox" to receive messages from the adapter services and hold messages until other adapter services retrieve them. Adapter for MSMQ requires that you specify the queue name when you configure transactional or non-transactional connections. For detailed instructions on how to configure connections, see Configuring Adapter Connections. For more information about queues, see Queuing.
The following diagram illustrates the use of Adapter for MSMQ and Integration Server in a business-process integration.
Package Management
Adapter for MSMQ is provided as a package called WmMSMQAdapter, which you manage like any package on Integration Server.
There are several considerations regarding how you set up and effectively manage your packages on Integration Server, such as those described in the following list.
- Configure user-defined packages for your connections, adapter services, and listener notifications. See Package Management for details.
- Understand how package dependencies work so that you make the best decisions about how to manage your adapter services and notifications. See Package Dependency Requirements and Guidelines for details.
- Control which development groups have access to which adapter services and notifications. See Group Access Control for details.
- Understand how clustering, an advanced feature of Integration Server, works to effectively manage your adapter services and notifications. See Clustering Considerations and Requirements for details.
- Enable and disable packages. See Enabling Packages and Disabling Packages for details.
- Load, reload, and unload packages. See Loading, Reloading, and Unloading Packages.
Adapter Connections
Adapter for MSMQ connects to one queue at run time; that queue can be either public or private. You can configure one or more connections at design time to use in integrations. The number of connections you configure, and the types of those connections, depend on the number of queues that you are connecting to and your integration needs.
Adapter for MSMQ connections contain parameters that Integration Server uses to manage connections to the queue. Adapter for MSMQ uses these connections to provide services. You configure connections using Integration Server Administrator. You must have Integration Server administrator privileges to access Adapter for MSMQ administrative screens.
For instructions to configure and manage Adapter for MSMQ connections, see Adapter Connections. For more information about setting user privileges, see the IBM webMethods Integration Server Administrator’s Guide for your release.
For a list of tasks that you must complete before you can create your connections, see Before Configuring or Managing Adapter Connections.
Transaction Management of Adapter for MSMQ Connections
When you define a connection, the transaction type you choose determines the type of transaction management that the connection's operations will use. Adapter for MSMQ connections support the transaction types listed in the following table. For a detailed discussion of transaction management and the Adapter for MSMQ, see Transaction Management Overview.
| Transaction Type | Description |
|---|---|
| Transactional | Transactional connections can be applied only to transactional
queues. A transactional connection allows you to group one or more requests into a single Logical Unit
of Work (LUW). You can control these requests manually (explicit transactions), or you can allow the
Integration Server transaction
manager to control them for you (implicit transactions). To control these requests explicitly within a given LUW, you use the built-in services described in Built-In Transaction Management Services. If you do not use these built-in services, Integration Server will manage the requests automatically (implicitly). If a transaction uses only a single connection, or multiple connections that are all from the same connection pool, you do not need to manage the transaction explicitly. However, if a transaction uses multiple LOCAL_TRANSACTION transaction connections from different connection pools, you must manage the transaction explicitly. Note: Implicit transactions complete when the flow service that contains the LUW
finishes executing. If you create a looping operation within your LUW that could potentially involve
a large number of requests, you might want to manage the transactions explicitly to reduce the
possibility that you will need to roll back a large number of requests in the event a single request
fails.
|
| Non-Transactional | A non-transactional connection is stateless and can be applied
only to non-transactional queues. All services associated with a non-transactional connection perform
a single request as an autonomous unit of work. For example, when a flow invokes a Get service associated with a non-transactional connection, these services remove each message from the MSMQ queue immediately after they process the message. |
Changing the Connection Associated With an Adapter Service at Design Time
Integration Server provides a built-in service that you can use at design time to change the connection associated with an adapter service. This built-in service, setAdapterServiceNodeConnection, is provided in the WmART package's pub.art.service folder. Using this service, you can change the specific connection associated with an adapter service at design time so that you do not need to create and maintain multiple adapter services.
For details, see the IBM webMethods Integration Server Built-In Services Reference for your release.
Changing the Connection Associated with an Adapter Service at Run Time
Integration Server enables you to dynamically select the connection a service uses to interact with the adapter's resource. This feature enables one service to interact with multiple, similar backend resources.
For example, a service can be defined to use a default connection that interacts with customer number 1's order queue. However, at runtime you can override the default connection and instead use another connection to interact with customer number 2's order queue.
For more information about overriding a service's default connection at runtime, see Dynamically Changing a Service's Connection at Run Time.
Connection Pools
Integration Server includes a connection management service that dynamically manages connections and connection pools based on configuration settings that you specify for the connection in Integration Server Administrator. All adapter services and adapter listeners use connection pooling.
A connection pool is a collection of connections with the same set of attributes. Integration Server maintains connection pools in memory. Connection pools improve performance by enabling adapter services to reuse open connections instead of opening new connections.
Run-Time Behavior of Connection Pools
When you enable a connection, Integration Server initializes the connection pool, creating the number of connection instances you specified in the connection's Minimum Pool Size field. Whenever an adapter service needs a connection, Integration Server provides a connection from the pool. If no connections are available in the pool, and the maximum pool size has not been reached, the server configures one or more new connections (according to the number specified in Pool Increment Size) and adds them to the connection pool. If the pool is full (as specified in Maximum Pool Size), the requesting service will wait for Integration Server to obtain a connection, up to the length of time specified in the Block Timeout field, until a connection becomes available. Periodically, Integration Server inspects the pool and removes inactive connections that have exceeded the expiration period that you specified in Expire Timeout.
You can enable the system to retry the initialization any number of times, at specified intervals.
For information about configuring connections, see Adapter Connections.
Built-In Services For Connections
Integration Server provides built-in services that enable you to programmatically control connections. You can use them to enable and disable a connection, and to return usage statistics and the current state (Enabled or Disabled) and error status for a connection. These services are located in the WmART package, in the pub.art.connection folder.
Another built-in service, pub.art.service:setAdapterServiceNodeConnection, enables you to change the connection associated with an adapter service. For details, see Changing the Connection Associated With an Adapter Service at Design Time.
For information about the setAdapterServiceNodeConnection service, see the IBM webMethods Integration Server Built-In Services Reference for your release.
Adapter Services
Adapter services enable you to connect to the MSMQ system and initiate an operation on the MSMQ system from Integration Server. For example, you can create a Put service and put a message on a MSMQ queue.
You call adapter services from flow services or Java services to interact with queues. Integration Server uses the adapter connections to execute the adapter services, which perform MSMQ messaging services.
Adapter services are based on templates provided with the Adapter for MSMQ. Each template represents a specific technique for doing work on the MSMQ system, such as using the Put template to deliver a message to a specified queue. An adapter service template contains all the code necessary for interacting with the MSMQ system but without the data specifications. You provide these specifications when you configure a new adapter service.
Configuring a new service from an adapter service template is straightforward. Using Designer, you assign the service a default adapter connection.
After you select the connection for the adapter service, you use Designer to configure the adapter service by selecting the adapter service template and the data specifications, such as the message property fields. For information, see the IBM webMethods Service Development Help for your release.
The Adapter for MSMQ provides the following adapter service templates:
| Adapter Service Template | Description |
|---|---|
| Put Service | Opens a session to an MSMQ Server and delivers a message to a specified queue. For more information, see Configuring Put Services. |
| Get Service | Opens a session to an MSMQ Server and retrieves and removes a message from a specified queue. For more information, see Configuring Get Services. |
| Peek Service | Opens a session to an MSMQ Server and retrieves a copy of a message without removing the original message from a specified queue. Configuring Peek Services. |
Put Service
A Put service creates an MSMQMessage object from the input signature properties, which becomes the input document. You specify input signature properties when you configure a Put service. A Put service places the message into an MSMQ queue.
Run-Time Processing for Put Services
The following diagram illustrates how a Put service delivers a message to a queue on an MSMQ Server.
| Step | Description |
|---|---|
| 1 | A flow or Java service, typically invoked by an Integration Server client,
initiates the Put service on Integration Server. You configure the Put service, and the wrapping flow or Java service, using Designer. |
| 2 | The Put service retrieves a connection from the service's
associated connection pool. You configure and enable the adapter connection using Integration Server Administrator. For more information about connection pooling, including the run-time behavior of connection pools, see Connection Pools. |
| 3 | The Adapter for MSMQ uses the Put
service's input document, or the message properties from the input signature of the Put service, to
create an MSMQMessage object. You define the Put service's input signature when you configure the service. Using Designer, the fields that you select on theInput Message Propertytab in the adapter service become the service's input signature. |
| 4 | The Adapter for MSMQ puts the MSMQMessage object into the MSMQ queue. |
| 5 | The Put service returns a document that contains the output message fields. You define the output signature of the Put service, or output document, when you configure the service. The fields that you select on the Output Message Propertytab become the service's output signature. |
Get Service
A Get service retrieves and removes messages from an MSMQ queue. A Get service also creates an output document that contains message properties and the Body. When you configure a Get service, you specify the output signature properties, which become the output document.
Run-Time Processing for Get Services
The following diagram illustrates how a Get adapter service retrieves a message from a queue on a Messaging Queuing computer. When a Get service executes, it checks the queue, retrieves the message, and converts the message into a document.
| Step | Description |
|---|---|
| 1 | A flow or Java service, typically invoked by an Integration Server client,
initiates the Get service on Integration Server. You configure the Get service, and the wrapping flow or Java service, using Designer. |
| 2 | The Get service retrieves a connection from the service's
associated connection pool. You configure and enable the adapter connection using Integration Server Administrator. For more information about connection pooling, including the run-time behavior of connection pools, see Connection Pools. |
| 3 | The Get service uses the values from the input signature
fields as filter criteria. You define the Get service's input signature when you configure the service. The fields that you select on theFiltertab in the adapter service become the input signature of the service. |
| 4 | The Get service retrieves the message from the MSMQ queue. The document, or the properties from the output signature of the Get service, contain the retrieved message properties and the Body. |
| 5 | The Get service returns a message to the Integration Server that contains output signature properties and the Body. You define the output signature of the Get service when you configure the service. The fields that you select on the Output Message Propertytab become the output signature of the service. |
Peek Service
A Peek service retrieves a copy of the first message that matches the filter criteria specified for the Peek service from the MSMQ queue. A Peek service creates an output document that contains message properties and the Body. When you configure a Peek service, you specify the output signature properties, which become the output document.
Run-Time Processing for Peek Services
The following diagram shows how a Peek adapter service retrieves a copy of a message from a queue on a Messaging Queuing computer without removing the original message. When the Peek service executes, it checks the queue, retrieves a copy of the message, and converts the message data into a document.
| Step | Description |
|---|---|
| 1 | A flow or Java service, typically invoked by an Integration Server client,
initiates the Peek service on Integration Server. You configure the Peek service, and the wrapping flow or Java service, using Designer. |
| 2 | The Peek service retrieves a connection from the connection
pool associated with the service. You configure and enable the adapter connection using Integration Server Administrator. For more information about connection pooling, including the run-time behavior of connection pools, see Connection Pools. |
| 3 | The Peek service uses the values from the input signature
fields as filter criteria. You define the input signature of the Peek service when you configure the service. The fields that you select on theFiltertab in the adapter service become the service's input signature. |
| 4 | The Peek service retrieves a copy of the message from the MSMQ queue and leaves the original message on the queue. The MSMQ message, or the properties from the output signature of the Peek service, contain the retrieved message properties and the Body. |
| 5 | The Peek service returns a message to the Integration Server that contains output signature properties. You define the output signature of the Peek service when you configure the service. The fields that you select on the Output Message Propertytab become the output signature of the service. |
Adapter Listeners and Listener Notifications
The Adapter for MSMQ provides listeners and listener notifications to perform the following functions:
- Monitor messages
- Filter messages
- Process messages
Listeners
A listener continually monitors a queue for messages. When a message appears on a queue, the listener fetches the message. The listener passes the message to the listener notification.
Unlike the Put and Get adapter services, you never invoke a listener directly from a service or client. Instead, a listener is a real-time process that you configure, enable, and disable using Integration Server Administrator. Refer to Configuring New Listeners for detailed instructions on how to configure listeners.
Listener Notifications
A listener notification works in conjunction with a listener to filter and process messages in the Adapter for MSMQ. When a listener detects a message on a queue, the listener performs a Get operation to retrieve the message and passes the message to the listener notification. The listener notification receives the message and performs a filter on the messages based on the filter criteria that you selected when you configured the listener notification. The listener notification processes the message either synchronously or asynchronously.
The Adapter for MSMQ includes the following listener notifications:
- Asynchronous Listener Notifications
- Synchronous Listener Notifications
Asynchronous Listener Notifications
When you create an asynchronous notification, the Adapter for MSMQ creates a publishable document type. The publishable document type defines the structure of the document that includes the Body and message properties. At run time, after the listener retrieves a message from the queue, the listener invokes the asynchronous notification. The asynchronous notification publishes the document that has the structure defined by the document type that was created along with the asynchronous notification.
An asynchronous listener notification can publish a document in either of the following ways:
- Publish to a Broker when Integration Server is connected to a Broker (default).
- Publish locally to Integration Server when Integration Server is not connected to a Broker.
To process the message from the queue, create an Integration Server trigger that subscribes to the document type that the Adapter for MSMQ created along with the asynchronous notification. For more information about using triggers with services, see the Publish-Subscribe Developer’s Guide for your release.
Beginning with Integration Server 8.0, you can choose the destination to which asynchronous notifications should publish messages. Specifically, you can choose whether the asynchronous notification templates use JMS APIs to publish messages to Integration Server or IBM webMethods Broker APIs to publish notification messages to IBM webMethods Broker.
For steps for selecting a publish destination for asynchronous notification messages, see Listener Notifications.
Synchronous Listener Notifications
When you create a synchronous listener notification, the Adapter for MSMQ creates the following document types:
- Request Document. The synchronous Request document contains the Body and message properties.
-
Reply Document. At run time the listener
notification invokes a specified service and passes it to the specified Request document. The service
returns the Reply document to the Adapter for MSMQ. The listener notification waits until the service has finished processing the
message before it initiates the next service. A synchronous listener notification does not publish a document. Note: WmART generates both document types by default, however, the Adapter for MSMQ does not use the Reply Document.
Synchronous adapter notifications execute flow services and return values from those services. Integration Server 8.0 supports the following two execution modes to determine how the notification executes a flow service and returns output:
- Service Invoke mode: When this mode is selected, the adapter notification invokes a flow service directly and returns values as output from that service.
- Publish and Wait mode: When this mode is selected, the adapter notification publishes the received data either to the local Integration Server or to the Broker connected to that Integration Server by converting request documents into publishable documents, and then waits for a reply. This mode is needed when a synchronous adapter notification is represented as a receive step in a process model.
For steps for specifying execution modes for synchronous adapter notifications, see Listener Notifications.
Listener Notification Templates
The Adapter for MSMQ provides the following adapter listener notification templates:
| Listener Notification Template | Description |
|---|---|
| Asynchronous Listener Notification | Publishes a document type that Integration Server processes asynchronously. That is, the Integration Server does not wait until it has finished processing a document before processing another document. |
| Synchronous Listener Notification | Invokes a service to process the message before receiving the next message. |
For more information about configuring asynchronous and synchronous notifications, see Configuring Listener Notifications.
Listener Transactionality and Behavior
Listeners can be either transactional or non-transactional, and exhibit different behaviors when they are associated with a non-transactional connection than with a transactional connection.
Transactional Listeners
A listener is transactional when it is associated with a transactional connection, and exhibits the following behavior:
- The Listener monitors the queue.
- The Listener receives a message and passes it to the notifications. (The Adapter for MSMQ removes this message from the queue.)
- If the message matches all of the selection criteria for any notification, the notification processes the message.
- If the notification processes the message, the Listener commits the message. (The Adapter for MSMQ removes the message from the queue.)
- If no notification processes the message,
the message is lost. Important: If you enable a transactional listener, but have not enabled any notifications to process the message, the message may be lost. To prevent the loss of messages, IBM recommends a default notification that is always enabled. For information about notification configuration, see Listener Notifications.
Non-Transactional Listeners
A listener is non-transactional when it is associated with a non-transactional connection, and exhibits the following behavior:
- The Listener monitors the queue.
- The Listener receives a message. (The Adapter for MSMQ removes this message from the queue.)
- If the message matches all of the selection
criteria for any notification, the notification processes the message.
However, if the message does not match the selection criteria for the notification, the notification discards the message.
Important: For a non-transactional listener, there should be an associated listener notification to filter each type of message that arrives in the queue. If you do not have a listener notification that matches the criteria of a message coming through the queue, the first message will be lost. To prevent messages from being lost, IBM recommends that you configure and enable a default listener notification with no filter criteria.Important: If you enable a non-transactional listener, but have not enabled any notifications to process the message, the message is lost. To prevent the loss of messages, IBM recommends a default notification that is always enabled. For information about notification configuration, see Listener Notifications.
Run-Time Processing of Listeners and Notifications
Run-time processing occurs in listeners and notifications in the following scenarios:
- Listeners and asynchronous listener notifications
- Listeners and synchronous listener notifications
Run-Time Processing of Listeners and Asynchronous Listener Notifications
The following diagram and steps illustrate what happens when a listener retrieves a message from a queue and passes the message to an asynchronous listener notification.
| Step | Description |
|---|---|
| 1 | The listener retrieves a connection from the connection pool associated with the service. |
| 2 | The listener uses the MSMQ libraries to monitor and listen for messages on a queue. |
| 3 | When a message appears on the queue, the listener retrieves the message from the queue and passes it to the asynchronous notification. |
| 4 | The asynchronous notification compares the message property
fields against the Filter fields specified for the notification. If all specified criteria matches
between the two sets of fields, the asynchronous notification will be invoked to publish the
document. If the specified criteria do not match between the message property fields and the Filter fields, the asynchronous notification is not invoked to publish the document. |
| 5 | The asynchronous notification creates a publishable document, which contains the Body, message properties, and envelope information. The asynchronous notification publishes the document that the service, which you created, processes at a later time. |
| 6 | The listener gets the next message from the queue, and the Adapter for MSMQ repeats steps 1 through 5. |
| 7 | Using an Integration Server trigger that you configured to use the publishable document created with the notification, a flow or Java service that you configured on Integration Server is invoked to process the message data in the publishable document. |
Run-Time Processing of Listeners and Synchronous Listener Notifications
The following diagram and steps illustrate what happens when a listener retrieves a message from the queue and invokes a synchronous listener notification.
| Step | Description |
|---|---|
| 1 | The listener retrieves a connection from the connection pool associated with the service. |
| 2 | The listener uses the MSMQ libraries to monitor and listen for messages on a queue. |
| 3 | When a message appears, the listener retrieves the message from the queue. The listener passes the message to the synchronous notification. |
| 4 | The synchronous notification compares the message properties
fields against the Filter fields specified for the notification. If all specified criteria matches
between the two sets of fields, the listener invokes the synchronous notification to process the
message. If the specified criteria does not match between the message property fields and the Filter fields, the synchronous notification is not invoked to process the message. |
| 5 | The synchronous notification creates the following documents
types:
|
| 6 | After the service has processed the data in the Request document, the listener retrieves another message from the queue. |
Using Version Control Systems to Manage Adapter Elements
The adapter supports the Version Control System (VCS) Integration feature provided by Designer. When you enable the feature in Integration Server, you can check adapter packages or elements into and out of your version control system from Designer. For more information about the VCS Integration feature, see the Configuring the VCS Integration Feature.
Beginning with Integration Server 8.2 SP3, the adapter supports the local service development feature in Designer. This feature extends the functionality of the VCS Integration feature to check package elements and their supporting files into and out of a VCS directly from Designer. For more information about local service development and how it compares to the VCS Integration feature, see the IBM webMethods Service Development Help.
Infrastructure Data Collector Support for the Adapter for MSMQ
Infrastructure Data Collector monitors the system and operational data associated with webMethods run-time components such as Integration Servers, Broker Servers, Brokers, and adapters, and reports the status of these components on Optimize for Infrastructure or other external tools. When you start monitoring an Integration Server, Infrastructure Data Collector automatically starts monitoring all ART-based adapters that are installed on Integration Server.
For information about monitored key performance indicators (KPIs) collected for the monitored adapter components, see the Optimize documentation for your release.
Viewing the Adapter's Update Level
You can use Integration Server to view the list of updates that have been applied to the adapter. The list of updates appears in the Updates field on the adapter's About page in Integration Server Administrator.
Controlling Pagination
About this task
When using the adapter on Integration Server 8.0 and later, you can control the number of items that are displayed on the adapter Connections screen and Notifications screen. By default, 10 items are displayed per page. Click Next and Previous to move through the pages, or click a page number to go directly to a page.
To change the number of items displayed per page, set the watt.art.page.size property and specify a different number of items.
To set the number of items per page