This is something I've always wanted and would be happy to pay for:

We often need to transfer files to other systems. One of the methods is
using TCP/IP over a VPN. We avoid this because doing this from D3 is a bit
of a nightmare.

I would love to have a windows program/service that allows us to define a
particular task (there might be many different transfers to many different
systems) and then all of the parameters associated with the task such as:
send file(s), received file(s), 'wrapper' info (stx, etc.), ack/nak, port
number...

I don't care what it's written in as long as it works and is readable.

Anyone interested?
Jeff

On Jan 29, 11:49*am, "Jeff Caspari" <mu... (AT) idt (DOT) net> wrote:
We use a commercial, cheap product called "Anyplace Control". Works,
even fairly fast. Doesn't care if the files are blobs.

What's the matter with letting the host OS handle it by scripting ftp,
sftp, or ftp+ssl, etc from D3? (In Linux I like the lftp program which
handles all of these variants through a standard interface.)

Each interface tends to be unique, so I typically have "ftp.put.xxx"
and "ftp.get.xxx" programs for each client / vendor / customer remote
site that I need to exchange files with. Once you have a stable and
robust methodology, then it is very fast to clone an existing program
for a new site.

To send a file, I use %creat and %write to create the file in a local
directory, then execute "ftp.put.xxx filename". To receive a file, I
execute "ftp.get.xxx" then poll the target local directory to see what
I got. The "ftp.get.xxx" can use wildcards and pattern matching
("mget") to only pull down specific files, after which I typically
will delete them from the remote server if allowed, else I use the
"nlist" ftp command to compare what's on the remote site to what I've
already gotten and selectively "get" only the new file(s).

If you need to install or otherwise manipulate a file sent to a remote
site, then either run a program on that system (could be a cron job)
or use ssh to run a script on the other end (in which case you would
likely use scp to send the file instead of ftp).

/Scott Ballinger
Pareto Corporation
Edmonds WA USA
206 713 6006

Jeff, last year I wrote a utility that allows D3 data to be pushed
into a pipe and pulled out on another system. Please let us know how
close this is to your requirements.

This was written because one of my clients writes code on their office
system, and then they need to move everything into their client
system. It's a typical scenario where we have BASIC source and
object, some dict defs, some control records, some new MD items, etc.
Packaging everything up is a real pain. Moving it to other systems is
a pain, local or remote. Restoring it is a pain.

Here is a sample definition for sending data:

Send Operation 1 in AccountA on System1
SELECT DICT WORK1 WITH A1 NOT D]
T-DUMP DICT WORK1
Send Operation 2
T-DUMP WORK2,TODAY
Send Operation 3
T-DUMP MD FEE FIE FO FUM

Receive Operation 1 in AccountB on System2
SELECT DICT WORK1 WITH A1 NOT D]
DELETE DICT WORK1
T-LOAD DICT WORK1
Receive Operation 2
CREATE-FILE WORK2,YESTERDAY 1 3
T-LOAD WORK2,YESTERDAY
Receive Operation 3
T-LOAD MD (O

Once those corresponding send/receive operations are defined, you
execute any command like SEND.WORK. That can be done at any time, in
a phantom, etc. The data is transparently sent to a middle-tier
repository of your choosing. Then on the receiving system you just
enter RECEIVE.WORK, whether from TCL, phantom, etc. The data is
transparently loaded.

This can be used to move data from a VAR to end-user sites, to share
work among D3 developers on different systems, and to allow end-users
to do small app upgrades using whatever current release info happens
to be available.

You don't need to touch anything related to data export, transfer, or
import. You just need to define the specific data that's going out
from the source, and the corresponding instructions to put the data
where you want it in the target.

The source and target must be D3 but can be any D3NT or *nix system.
There are no third-party communications tools that require
installation or purchase.

I haven't productized this yet, but like many utilities, I'm happy to
clean it up for sale. Honestly, I write a lot of stuff like this that
personally I think is pretty cool, but I'm constantly discouraged from
offering things like this out to our market. Maybe I should write
a regular blog called "MV utilities that never see daylight". I'm
sure a lot of people would be able to contribute material.

HTH
T



"Jeff Caspari" wrote:

I explained this poorly. I'm sorry.

I am talking about send HL7 (medical) data over socket connections. We
regularly need to interface our Laboratory Information System to remote
systems using TCP socket based protocol.

This might be receiving and acknowledging incoming lab orders from a
practice management system such as eClinical and sending HL7 laboratory
results back to their system. All using TCP socket connections.

Or we might need to interface our LIS to a laboratory analyzer, which we
typically do using serial connections, using a socket interface.

These scenarios present real challenges to us. We usually resort to coding
in a D3 program socket level code. However this is really difficult and
every new job is a new headache.

So I was hoping to handle all of this through a windows service where we
simply place the [HL7] files from D3 into an outgoing folder and let the
windows service handle all of the socket layer work. Given that there are a
number of different requirements regarding the way the data is 'wrapped'
based on who we are interfacing with we would also need the ability to set
parameters for how the wrapper is defined as well as other information.

A product that does all of this is called NeoTools (now I see it's called
CorePoint):
http://www.corepointhealth.com/sites...s-overview.pdf

However this is way more than we need and way too expensive.

Thanks again and sorry for the poor original explanation.

Jeff

"Jeff Caspari" <munge (AT) idt (DOT) net> wrote

Jeff,

We use a product call HL7connect to do this. The version we have is a fairly "lite" product that just operates in a send or receive mode only. No mapping or anything like Chameleon etc.... I don't know what products they are offering these days. I think they've complicated the product a bit since we purchased. But from what you describe, it sounds like what you need. It just listens for incoming messages and drops them in a directory. In send mode it will just poll a designated directory at defined time frames and format the messages found into the HL7 TCP/IP stream that is defined. The version we have will handle up to 10 connections at a time but I'm sure there's beefier versions if you need it.

Steve

Thanks, Steve. I am investigating... They don't seem very responsive to my
emails.

Jeff


"Steve Douglas" <sdouglas (AT) mbms (DOT) net> wrote

Jeff,

We use a product call HL7connect to do this. The version we have is a
fairly "lite" product that just operates in a send or receive mode only. No
mapping or anything like Chameleon etc.... I don't know what products they
are offering these days. I think they've complicated the product a bit
since we purchased. But from what you describe, it sounds like what you
need. It just listens for incoming messages and drops them in a directory.
In send mode it will just poll a designated directory at defined time frames
and format the messages found into the HL7 TCP/IP stream that is defined.
The version we have will handle up to 10 connections at a time but I'm sure
there's beefier versions if you need it.

Steve