Monitoring Operation-Flow Topology through a farm of DataPower Appliances
KDunphy 120000KVFB Visits (9198)
ITCAM for SOA's Operation Flow workspaces show you how the various Web Services and ESB's in your Enterprise SOA architecture work together to implement your business services. In the case of a mature, complex ESB implemented with the WebSphere DataPower appliance's Multi-Protocol Gateway (MPGW) service, you have the opportunity to extend ITCAM for SOA's monitoring beyond only SOAP messages.
This approach allows you to monitor non-SOAP messages inside a farm of DataPower ESB devices. The ITCAM for SOA data collectors (DC's) for the WebSphere Application Server family and other full application servers do not include this capability.
When you configure your DataPower MPGW services to be monitored by ITCAM for SOA, you must create several XSL style sheets. These style sheets assert the identifiers that will be used to identify these transactions to ITCAM for SOA, and also include code for propagating the SOAP header that is used to follow each transation through your enterprise. By customizing the code used in this latter task, you can extend this function beyond SOAP messages. However, if you want to follow the transaction to the back-end server, you must use SOAP for that last hop to the back-end server.
ITCAM for SOA's requirement, as it applies to processing the correlator string in order to monitor the transaction as it passes through the appliance, is that at each hop of the flow, the exter-correlator() function must be invoked at the appropriate point in the transaction, as illustrated in Configuring DataPower Processing Rules in the ITCAM for SOA InfoCenter. How that correlator string is propagated is not important – as long as the data collector on the sending side and the receiving side agree on what to expect, the string just has to get from the sender to the receiver. When you are monitoring a full application server, the DC's logic for locating this correlator string is hard-coded. When you are monitoring a system in which two or more DataPower appliances are sending messages among themselves, you have enough control in each MPGW to choose any of a number of ways to exchange that correlator string.
On a non-SOAP message using HTTP, you could choose to use an HTTP header instead of a SOAP header. If your transport protocol does not include an extension mechanism similar to headers, you could include the correlator string in a MIME attachment, perhaps. Or perhaps the XML schema being used for the messages includes some extension mechanism that could be used. Whatever you choose to use, you must be consistent – all the senders and all the receivers must use the same implementation.
When you receive an incoming message, your XSL style sheet must check for the presence of this correlator, and call the exter-correlator() function with either the value of the inbound correlator or the NEW_CORRELATOR keyword. The return value from exter-correlator() is a new correlator string that you must attach to the outbound message.