WebMethods operational management

There has been a stir recently about webM working with Tivoli, BMC, CA, HP, and others aournd management of webM platform. Does anyone have any information about this? It seems unlikely that Tivoli will be willing to support a webM solution…it has to deal with its own (IBM) product line. Does anyone have any details

Ron - We have architected a solution to monitor the webMethods environement. I would be happy to discuss with you. You can contact me directly at lkoch@inventa.com.

Ron, what you heard is true. Open Management Interface (OMI) is a big part of webMethods’ push to enhance their platform’s functionality.

Developed with the cooperation of BMC, Tivoli, Hewlett-Packard, and Computer Associates, OMI is a graphical look into an Enterprise-wide webMethods implementation. I have seen the screen shots from the OMI initiative and they revealed the following functions:

  1. Show a very, very high-level look at your Enterprise-wide webMethods instances and the status of each instance.
  2. Show a high-level view of a single webMethods instance’s status
  3. Show a low-level view of a single webMethods instance and its services
  4. Show a very, very low-level view of data flow within a webMethods instance.

In short, the OMI initiative gives a resource the ability to see dependencies and stati of webMethods instances deployed across a network with varying levels of detail.

I hope that I am doing this topic justice. If somebody else can speak more to the details of OMI, that would be super.

Laura, is you solution based on the OMI specification? I have read some of the press releases and the OMI solution seems to be the way to go.

Can you tell me a little bit about your solution in this forum? I bet that many of us will be interested. In particular I would be interested in:

  1. What platforms you support: B2B, EAI, MIS, TN, BI, etc
  2. What versions you support.
  3. Do you feed alerts, actions, etc into any of the other management vendors? I, persnally, would be interested in your support for Tivoli.
  4. What are your high level capabilities? Auto discovery, BP visualization, root cause analysis, auto recovery, etc?
  5. Are you using JMX?

The webMethods platform has always been a bear to manage so having a single management console is a true god-send.

Ron -
Here are some answers to your questions. I would be happy to setup a WebEx demo of the solution anytime, just let me know.

OMI - Currently, no. The current version of wM doesn’t do OMI.
We will support OMI as soon as we have a version to begin
working against. I believe that it is coming with the 6.0 release.

  1. Platforms: Enterprise (EAI) and Integration Server (B2B)

  2. Versions: 4.x

  3. Alerts into other management vendors: We can feed alerts to any other vendor in the form of SNMP traps. Otherwise, alerts stay within our environment and are managed and recorded in database tables. The information can then be viewed through a “portal” with complete case management, reporting, and escalation procedures.

  4. Capabilities: Most of our technology is focused on long term data analysis, and basic real-time analysis (rules based analysis).
    We are not a management platform, meaning that our software is not geared towards performing administrative or management tasks–it is more geared towards providing in-depth analysis on what is going on and where your resources are being spent.

  5. JMX: We use JMX for other products (e.g. Weblogic), but not for
    wM. We utilize wM-specific API’s and some log file parsing for EAI and B2B.

BMC has the PATROL product that they recently released for monitoring. List price is $5000.00/cpu. We used another method that seemed to work pretty well and inexpensively.

We used a common web server monitoring software (in our case, net saint, but any will do.) We created a flow that also tested a database connection by performing a simple connect and then a select.

If the database returned rows back, the service reported a success and all was well. If the database did not return rows, or a connection could not be made, we trapped the error and returned that back to net saint. The production support people carried email pagers and would receive a page within 30 seconds (use skytel guaranteed delivery.)

The errors we were concerned with were http 500 errors, 404 errors (dns trouble), 550 errors. Plus, we trapped and parsed the oracle $dbMessage and mapped a shortened version and sent the error back along with the page. Hope this helps.


You can read more about OMI and view the specification at the webMethods Web site.