Forum Replies Created
-
AuthorReplies
-
Here’s a simple way to get around the undesired encoding conversion:
37
38 encoding system identity
39 foreach file [glob -nocomplain “$path/*.pdf”] {
40 set pdfmsg [read_file -nonewline $file]
41 # set pdffp [open $file]
42 # fconfigure $pdffp -translation binary -encoding binary
43 # set pdfmsg [read $pdffp]
44 # close $pdffp
Setting the system encoding to ‘identity’ disables encoding conversions as you are asserting that the encoding in the file is the same as the native encoding of the system.
Correction/clarification – on 5.7 (definitely on Linux) the addition of multiple process shutdown causes a problem where processes that are not able to shut down quickly are never SIGINT’d or SIGKILL’d. the code above fixes that.
This is a BUG on ALL platforms introduced since 5.7 when multiple processes separated by commas were allowed. hcienginestop is broken. Replace the stopProcess proc with this:
Code:
######################################################################
# stopProcess – Stop the engine using progressively meaner tactics
#
sub stopProcess {
local( $pid );
local( @procs) = ();
local( $flag) = 0;
local( $proc_len);$proc_len = @opt_proc;
foreach $p (@opt_proc) {
if ($proc_len > 1) {
print “Stopping process $p n”;
}if( ($pid = &getHciEnginePid( $p )) == 0 ) {
print “Process ‘$p’ is not runningn”;
next;
}# First try sending it a “die” command
print “Trying hcicmd…n”;
if ($onNT) {
if( system( “hcicmdnt.exe -p $p -c “. die”” ) ) {
printf STDERR “hcicmd failed!nn”;
push(@procs,$p);
}
} else {
if( system( “hcicmd -p $p -c “. die”” ) ) {
printf STDERR “hcicmd failed!nn”;
push(@procs,$p);
}
}
}if (( $len = @procs ) != 0) {
@opt_proc = @procs;# Give it time to die
$flag = &waitForAll();
} else {
$flag = 0;
}#For flag, the true means there are some processes which are still running
if ( $flag ) {
#There are some processes which are still running# On Windows, try SIGKILL
if ( $onNT ) {
foreach $opt_p (@opt_proc) {
$PidFile = “$Pwdir/$opt_p/pid”;
print “Now trying SIGKILL…n”;
kill( ‘KILL’, $pid );
unlink( $PidFile ); # remove the pid file
print “Process ‘$opt_p’ is not runningn”;
}
return 1;
}# On NUIX, try SIGINT first
foreach $opt_p (@opt_proc) {
# Now try SIGINT
print “Now trying SIGINT…n”;
if( kill( ‘INT’, $pid ) == 0 ) {
print STDERR “Unable to send SIGINT: $!n”;
}
}
if (&waitForAll()) {
#There are some processes which are still running
#Try SIGKILL then
foreach $opt_p (@opt_proc) {
# Now try SIGKILL
print “Now trying SIGKILL…n”;
if( kill( ‘KILL’, $pid ) == 0 ) {
print STDERR “Unable to send SIGKILL: $!n”;
}
}
if (&waitForAll()) {
#There are some processes which can not be killed
foreach $opt_p (@opt_proc) {
print “nUnable to stop process ‘$opt_p’!n”;
}return 0;
}
}
}if ($proc_len > 1) {
#All processes are not running
print “All Processes are not runningn”;
}
return 1;
}We (at Florida Department of Health) have done testing with creating messages directly in the outbound PHINMS message queue in the database, and adding all associated required information as part of the insert. This seems to work fine. Inserts can be a bit tricky as the message data is a BLOB type field.
Apart from that you can also just set up Folder Based Polling and place a file with the data in the appropriate folder on the PHINMS server. The folder you place the file in is already configured with the appropriate settings for transmission. This is the easiest way to do it.
Messages can be placed in the outbound queue one at a time, no problem. I cannot speak for how efficient this is as it takes around 10 to 20 seconds to actually arrive at the destination. I would say it is probably more efficient to do batching due to the overhead.
Frans
Perhaps ps2txt? Awesome … glad you got it working. We have also had slowdowns with the RMI setup at some point, but another guy here did something to speed that right up. I will see if I can info from him about it. Frans
Which version of Cloverleaf are you using? You can see if the port is available by opening a command port on the Mac and doing a telnet
The port number depends on the cloverleaf version but is typically something in the 13000s like 13008 or 13013 etc.
Frans
This may seem a bit of a silly question … is your server and client of the same version? I have had the error you noted once before when the server and client were of different versions (or at least something similar). Are you sure your server allows connections on port 13xxx that your version of Cloverleaf uses (firewall perhaps blocking the port) from remote machines.
Is your Cloverleaf servers host server running? Under UNIX you have to start it with hciss -s h if it is not in the system startup scripts. Under Windows the service needs to be running.
Also, with versions of Cloverleaf before 5.5 we could not get basic security to work on Linux (dunno about Mac). Something goes wrong with the certificate exchange.
Let me know what you find …
I will look at my notes and see if I can find other possible issues.
Frans
You can just copy the necessary files from the UNIX server (if you have one) to Linux and replace the jre with a Linux version, copy the necessary jar files over and voila … you have a client. We did this here at DOH because we have migrated our desktops to Linux. The folders we copied are:
$HCIROOT/clgui
$HCIROOT/client
Set the HCIROOT environment variable in something like /etc/bashrc
mv $HCIROOT/client/java $HCIROOT/client/java.bak
cp -r
$HCIROOT/client/java copy any jars or objects it misses or that are extra from java.bak to java
Oh, if you want the documentation to work you have:
– Add the docs folder to the list above
– Add the Adobe4.0 folder to the list above
– delete and link the acroread binary in the Adobe4.0 folder to the acroread binary on your Linux machine. Works like a charm.
If you need better directions let me know.
Frans
We have not done orders to labcorp with SOAP. We have a VPN to labcorp and we do Cloverleaf to Cloverleaf HL7 (for results only at this time). We are ramping up delivering data to our county systems using tclSOAP. Seems to work quite well. There seems to be a few quirks when you use tclSOAP with .NET Web Services (had to change the type of the web service in .NET), but none that I could find with Cache or Java. HTTPS works too, X509 certificates too. In order to get tclSOAP to work you will need to install tclXML, tclDOM, libxml2, and perhaps a few others. They are all listed on thee tclXML or tclSOAP sites. Just google for those keywords. One nice feature of all of this is that you could also install tclXSLT … which helps with XML translations 😉 There are other solutions listed if you search clovertech for web services.
-
AuthorReplies