Cloverleaf Version: 6.2.6
Platform: AIX 7.2
When running a “service down” scenario on an interface using an outbound protocol thread configured using the java/ws-client protocol, I found that if the web service can’t be reached, the HL7 message is sent to the error database without the message content and with the HTTP error in the User Data field. I also notice that the “TPS Inbound Reply” TPS proc I have seems to be executed even when an outbound message is not sent.
Here are the details.
From the SoapConsumer settings found in the Properties of the java/ws-client protocol, I intentionally misspell the web service end point URL. Thread is restarted to make the change active.
An HL7 message is resent to the inbound thread which translates and routes it to the outbound thread configured with the java/ws-client protocol.
The HL7 message fails to the error database with an “HTTP 404: Not Found” error. This makes sense because I misspelled the URL.
Viewing the failed message in the error database, the Content is blank and the message Metadata tab shows a TCL error message on the TPS proc which handles the inbound response (Outbound tab -> TPS Inbound Reply). Specially, the TPS proc removes the SOAP wrapper from the response generated by the endpoint. This doesn’t make sense to me since I would think that if the outbound message failed, Cloverleaf would not try to process a response since one didn’t come back.
This is all confusing because the message appearing in the error database contains two errors for apparently two different messages: one “HTTP 404” error for the outbound message and one “TCL error” for an inbound response which didn’t come through.
For those of you using the java/ws-client adaptor, how do you handle situations where the endpoint goes offline or is otherwise unavailable?
Without the content of the failed message in the error database, I can’t resend it from there. I would have to find them in the inbound SMAT and resend. Not a problem in testing with a few messages, but could be a nightmare if hundreds or thousands fail in production.
Also, it is frustrating the Cloverleaf doesn’t show the status of the protocol thread as “opening” if the service becomes unavailable and queues messages in the recovery database like a TCP/IP thread.