Thanks for all your help, Jim.
The vendor system is Oracle Identity Manager and is being installed by an outfit called Entology who has been very cooperative, though we have both been learning as we go in building this interface.
Since most of our existing inbound tcp-ip interfaces use mlp_tcp.pdl which looks for x0b start and x1c0d termination, I asked the vendor to encapsulate their xml message with these characters, and the message handoff was then successful. I also constructad a very simple reply in xml format that is sent back over. It’s always a “success” message built by a reply gen tcl in the Inbound TPS., meaning simply that we took possession of the message, but not necessarily that it is sound. That appears to be adequate for now, at least.
We have also successfully built the interface on the receiving side (Cerner Millennium) and managed to post our first couple of transactions to achieve the expected changes in the target database (woo hoo!).
One remaining issue is a snag with message flow. It appears that OIM opens a connection and then closes it with each message. When several messages are sent in quick succession, the first one processes through but the second get gets a “connection refused”. I figure it’s because the Cloverlef thread also terminates when the client goes away, and has not quite released the socket by the time the second message tries to open a new connection on that port. The sender evidently jost stops, without retrying.
Entology says they can’t just avoid closing the connection, as each new message will open a new one. They are on Linux OS running a jBOSS application server (whatever that is).
Anyone have any advice on how to direct this vendor? Would I be correct in asking them to configure their interface to either build a delay between their messages or to have it retry repeatedly if a connection is refused? If so, what is a typical configuration? Continue trying for what length of time and at what kind of intervals?
I mentioned that we encapsulated the XML messages with the MLP start and termination codes. On a philosophical level, though, isn’t an XML message self-decribing. Would it not be sufficient for the Cloverleaf driver to just look for the beginning and ending root element tags to determine the start and end of message (but the tags need to remain part of the message. Wouldn’t this suggest a general-purpose PDL that recognizes xml messages generically? Does such an animal exist already and not need to be re-invented?
And, as for ACKing or NAKing the message, there is a practical limit to the amount of validation that the inbound TPS tcl script can do to decide if the message is sound or not. In the Xlate process, there is built-in functionality in Cloverleaf that validates the incoming XML message against the referenced XML Schema. So, we could be accepting and ACKing a message in inbound TPS that will later be rejected by the Xlate. Is there a way to draw upon this XML validation in order to ACK or NAK the incoming message?