Skip,
I have developed and implemented several (>dozen) HL7 interfaces to our Lab
System using the TCP/IP.  I can say without hesitation that it works better
than 99% of the 'interface engines' I typically have to interface to.  If we
have an interface problem, it usually requires someone to manually reset a
socket or process on the engine, and I do nothing.  On at least half of
these, they call me to make any changes needed instead of doing it on the
interface engine, since I seem to be able to get it done more quickly and
reliably than on the engine.  I attribute this directly to
Objectscript/Cache, not to any particulary genius on my part.

Mark

"Skip Hill" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I'm hoping for some feedback from the developer community concerning using
> ObjectScript and background JOB processes to provide server based TCP/IP
socket
> communications with other systems.
>
> I have a requirement to develop a HL7 interface for inbound (to the Cache
server
> from an external system) messages and outbound (from the Cache server to
an
> external system).
>
> On other platforms, it was necessary to resort to C++ and/or assembly
level
> coding to control the socket level communications on a given port. This
process
> then interacted with the application environment through files, pipes and
> semaphores. It was not pretty, but it worked well.
>
> I've read about the OPEN/READ/USE commands, and the overview for "Using
TCP
> Binding to Connect Client/Server Systems in the documentation. It would
appear
> that Cache is well endowed in this area, and up to the task. What I'm
wondering
> is
>
> 1. Is it reasonable to expect that I can develop a reliable, effective and
> efficient TCP/IP socket communications driver written in ObjectScript and
> running as a job on the Cache server.
>
> 2. Or does it get complicated and cumbersome, requiring system boots to
clear up
> problems with failed connections, timeouts, etc.
>
> 3. What kinds of caveats or warnings might be appropriate to consider. For
> instance, maybe stopping/starting/monitoring these jobs is problematic, or
for
> some reason they create unexpected resource demands, or it's fine with
only one
> fixed client connecting to a socket, but it gets complicated with numerous
> multiple clients, or perhaps the packet mode works great but not the
stream
> mode.
>
> 4. Is anyone aware of a "how to do it" sample that I might glean some
direction
> from.
>
> Any help will be appreciated.
>
> Skip Hill



Reply via email to