The decoupled nature of web services adds its own set of problems, notably how to trace problems between the two systems. At some point, it is necessary to see what message was received by Maximo and what was sent back by Maximo. There are two common approaches: 1) enable axis debugging or 2) use a proxy.
Under the hood, Maximo uses axis to implement web services. Axis has options for logging messages which get captured in SystemOut. It makes SystemOut very large and it is difficult to find a transaction and its reply. Using it usually involves turning it on for a short test, then turning it back off as soon as possible. It is not useful for diagnosing a problem after the fact.
Configuring a proxy makes it easy to see a request and a response pair, and it doesn’t fill up the Maximo logs. Unfortunately, it requires configuring the client to use the proxy instead of communicating directly to Maximo. This might be acceptable in a development environment, but it’s not feasible in a production environment. If SSL/TLS is used or required, additional complexity is added to using a Proxy. This option isn’t useful for diagnosing problems after the fact either.
A third option is to use a custom Implementation class that logs the request and reply. In essence, the implementation class looks like this:
public class LoggingMOSWebService extends MOSWebService {
/* ... snip ... */
@Override
public OMElement processDocument(OMElement arg0) throws RemoteException {
log("request", arg0);
OMElement rc = super.processDocument(arg0);
log("reply", rc);
return rc;
}
/* ... snip ... */
}
This class is compiled and included in the Maximo meaweb application. Maximo has to be rebuilt, redeployed, and restarted for the class to become available.
To use the class, specify it as the Implementation class when creating the web service, like this:
Now, whenever a web service call is made to MXASSET, the request is logged in a file, and the reply is logged in a separate file. The filenames will indicate the web service that was called and associate the request and replies together. This can be deployed in a production environment without negative performance impact, and without filling the Maximo logs. It is important to schedule a job to clean up the files periodically. The data is available in a post mortem situation to help diagnose problems.
A complete set of logging classes has been created and is available on GitHub here: https://github.com/ThatMaximoGuy/WebServiceLogging
To use it,
Service Type |
Implementation Class |
Object Structure Service |
com.interlocsolutions.maximo.ws.LoggingMOSWebService |
Standard Service |
com.interlocsolutions.maximo.ws.LoggingActionWebService |
Enterprise Service |
com.interlocsolutions.maximo.ws.LoggingEnterpriseWebService |
The log files will have the following naming convention: servicename_uuid_[request|reply]_timestamp.uniqifier.xml
For example, MX_ASSET_urn_uuid_6E17F23EA79C2646741470776643777_request_20160809_170421.062823027.xml
represents the request on the MX_ASSET web service, with uuid 6E17F23EA79C2646741470776643777, made on August 9, 2016 at 5:05:24 PM.
The reply to this request was in: MX_ASSET_urn_uuid_6E17F23EA79C2646741470776643777_reply_20160809_170442.088323028.xml
I use this at my current client. We don’t need to refer to the transactions often, but when we do, they are nice to have.
To learn more about web services, Maximo, or support, contact Interloc today!