Monitoring the WebSphere Adapter polling state using the Performance Monitoring Infrastructure in WebSphere Application Server

Learn how to differentiate between the following two scenarios: a) WebSphere® Adapter is not delivering events to the endpoint because there might not be events available, and b) WebSphere Adapter might not be delivering events to the business flow if there are no events to be delivered, or if there is an internal problem with the adapter mechanism. This article describes how this can be achieved by using the Performance Monitoring Infrastructure in WebSphere Application Server.

Ramya Rajendiran (ramya.raji@in.ibmcom), Staff Software Engineer, IBM

Photo of Ramya RajendiranRamya Rajendiran is a Software Engineer at IBM India Software Labs in Bangalore, India. She is currently working in the support and development of file based resource adapters. She has close to 6 years of experience working with IBM WebSphere Commerce, WebSphere Adapters, and IBM Supply Chain Product. She has co-authored an IBM Redbook titled WebSphere Commerce Line-Of-Business Tooling Customization.



Naga Srikanth Boddapati (nagasrikanth@in.ibm.com), Software Engineer, IBM

Photo of Naga BoddapatiNaga Srikanth Boddapati is a System Software engineer at the IBM Software Labs in Bangalore, India. He is currently working in development and customer support for WebSphere Adapters for Email and PeopleSoft. He has 7 years experience working in different components of WebSphere Application Server. He has spent the majority of his time on the Performance Monitoring Infrastructure component of WebSphere Application Server.



Pushkar Kumar Mishra (npushkar.mishra@in.ibm.com), Software Engineer, IBM

Photo of Pushkar Mishra Pushkar Kumar Mishra is a Software Engineer at the IBM India Software Labs in Bangalore, India. He currently works in the support and development of FTP File resource adapter. He has close to two and half years of experience working with WebSphere Application Server, Mobile Internet Optimization Platform (MIOP), and WebSphere Adapters and 3 years of industry experience. He has headed one important module in MIOP and has been involved in various other activities.



05 December 2012

Introduction

WebSphere Adapters provide service-based business connectivity to many standard technologies and External Information Systems (EIS). They can be used as a quick configuration-based connectivity option between IBM® runtimes, such as IBM Process Server, WebSphere Message Broker, WebSphere Application Server, and external information systems, such as SAP, JDBC databases, PeopleSoft®, Siebel® Systems, and others. They are JCA compliant adapters that provide standard architecture for bi-directional connectivity to these heterogeneous information systems.

WebSphere Adapters' inbound functionality is defined as communication from an Enterprise Information Systems (EIS) to the IBM runtime through the adapter using an event-based model. WebSphere Adapters can listen to or be notified of events on the EIS, retrieve the events, and act upon them.

Design of the existing WebSphere JCA Framework

The WebSphere Adapter inbound functionality provides a framework where events can be polled from different message providers (EIS) and delivered to the main business flow on the IBM runtime. The adapters deliver the message to the main business flow through message endpoints or Message Driven Beans (MDBs). This framework enables messages to be delivered or consumed without dependency on the messaging semantics or infrastructure.

This framework is inherently decoupled and the message producer and consumer are not in the same execution context. Refer to the JCA spec for more information about the inbound design.

Customer pain points

If there are no events being delivered to the business flow, the reasons might be as follows:

  • There are no events in the EIS.
  • The adapter has encountered errors during polling for events and is unable to continue.

Currently, the WebSphere Adapter framework does not differentiate between these two scenarios. Therefore, you look at the adapter logs to understand the current state. This necessitates the need for an easier mechanism to understand the adapter polling state, rectify problems in the infrastructure if any, and ensure business continuity.


Using PMI to monitor polling

Performance Monitoring Infrastructure (PMI) is the core monitoring infrastructure for WebSphere Application Server and WebSphere family products such as Portal, Commerce, and so on. The performance data provided by PMI helps to monitor and tune the application server performance. PMI provides a comprehensive set of data that explains the runtime and application resource behavior. It can also be extended to include the metrics for the application and the application health.

PMI provides database connection pool size, servlet response time, Enterprise JavaBeans (EJB) method response time, Java™ Virtual Machine (JVM) garbage collection time, CPU usage, and so on. This data can be used to understand the runtime resource utilization patterns of the thread pool, connection pool, and so on, and the performance characteristics of the application components like servlets, JavaServer Pages (JSP), and enterprise beans. Using PMI data, the performance bottlenecks in the application server can be identified and fixed.

Enabling PMI for WebSphere Adapter

First, you must install the WebSphere Adapter application onto the WebSphere Process Server, WebSphere ESB, or WebSphere Application Server broker. Next, you need to enable the PMI.

Configuring Performance Monitoring Infrastructure covers the complete steps for enabling PMI as a general, as well as for WebSphere Adapter.

In the above topic, while enabling PMI for WebSphere Adapter, we recommend that you select "Custom monitoring level" because this has the least performance impact.


Understanding how polling works using PMI

The four common scenarios described in this article can be applied to any WebSphere Adapter and evaluate how the PMI metrics change for each of them. We are using WebSphere Adapter for FTP as the sample adapter for demonstration purposes.

Before you begin monitoring

  • The scenarios discussed below apply only if the adapter module or application is successfully deployed on the server.
  • For the proper observation of scenarios, make sure that you evaluate from at least the last 7-10 entries in the PMI table or graph. Do not observe or conclude results from only, for example, two subsequent entries in the PMI table or graph.

Different metrics used in PMI

The GoodRequests metric represents the state of the Adapter. The number shown in this metric keeps incrementing when the adapter polling and delivery are successful.

The BadRequests metric represents the state of adapter when something unusual happens. The number associated with this metric remains constant except when there are some internal problems in adapter processing, such as files are being polled, but the event delivery is not happening.

The ResponseTime metric represents the average time taken by the Adapter to perform a request or response to the EIS.

Scenarios and results

WebSphere Adapter for FTP is used as a sample adapter for demonstration purposes. WebSphere Adapter for FTP, in inbound scenarios, is used for fetching files on the FTP server, optionally performing additional processing on them and delivering them as business objects to the configured endpoint. WebSphere Adapter for FTP is supported in IBM Process Manager and WebSphere ESB.


Scenario 1: Adapter polling and files available on the FTP server for polling

This is an ideal FTP Inbound scenario, where the adapter has already started polling. There are events in the FTP event directory to poll.

  1. Good Requests: Keeps incrementing.
  2. Bad Requests: Remains constant.

Refer to Figure 1 for more details.

Figure 1. Metrics for Scenario 1
Metrics for Scenario 1

Scenario 2: Adapter polling and files not available on the FTP server for polling

This is a scenario where the adapter has already started polling, but there are no events in the FTP event directory to poll. In this case, the adapter keeps polling the directory continuously until it is stopped explicitly or there is a failure in the connection.

  1. Good Requests: Keeps incrementing.
  2. Bad Requests: Remains constant.

Refer to Figure 2 for more detail.

Figure 2. Metrics for Scenario 2
Metrics for Scenario 2

Scenario 3: Adapter polling and connection failure to the FTP server

This is one of the failure scenarios for the FTP inbound adapter where the adapter has already started polling, but while polling, suddenly the connection to FTP server goes off.

There might be an initial jump in "BadRequest" and "ResponseTime" metrics for this scenario. This can be neglected. Keep in mind the preconditions while observing.

  1. Good Requests: Remains constant.
  2. Bad Requests: Remains constant.
  3. Response Time: Remains constant.

Refer to Figure 3 for more detail.

Figure 3. Metrics for Scenario 3
Metrics for Scenario 3

Scenario 4: Adapter polling internal problems while polling or delivery of events

This is again is a failure scenario where the FTP adapter has already started, but while polling or delivery of events some, internal problems occur such as the local event directory might not have deleted the permission. Therefore, the event does not get deleted after the processing completes.

  1. Good Requests: Remains constant.
  2. Bad Requests: Keeps increasing.

Refer to Figure 4 for more detail.

Figure 4. Metrics for Scenario 4
Metrics for Scenario 4

Some examples of internal problems with WebSphere Adapter for FTP are:

  • Files are fetched from the FTP server successfully, but the delivery to the endpoint is failing.
  • When the adapter is configured to archive the file on the FTP server before deleting it from the event directory, the FTP server archive directory does not have the necessary permissions.

Conclusion

This article explained how you can use PMI with WebSphere Adapters to monitor the polling state of the adapter. You can now differentiate between the adapter having internal polling problems and the adapter not having events to poll and take the appropriate action to ensure business continuity.

Resources

Learn

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere
ArticleID=848417
ArticleTitle=Monitoring the WebSphere Adapter polling state using the Performance Monitoring Infrastructure in WebSphere Application Server
publish-date=12052012