I realize this is slightly off topic as it's not specific to Meditech, but 
similar problems may arise for you all in your quest for robust scripts so I 
thought I would chime in...

I have a subtle and insidious problem with my McKesson HBOC scripts which use 
the HBOWEM server connection, and other scripts using the console connection. 
My web connection scripts do not appear to be affected, so far.

My problem is that I have found data streamed to the connection with the Key or 
Enter functions to be intermittently unreliable. 

Sometimes characters will be doubled up, and sometimes characters will be 
dropped. I think it's probably some kind of windows system resource issue 
(although the machine running the scripts has plenty of memory and twin Xenons, 
so it's no slouch), but it's quite erratic. URLs and UNC type file paths are 
particularly troublesome as "\\server\directory\file" often gets sent as the 
truncated "\server\directory\file" causing problems.

My solution has been to define a new function to do my data entry that 
incorporates a view statement to double-check the displayed typed current 
output before hitting enter to send to the application so I know for sure that 
I am sending what I should be, and if not, to erase the field and re-key before 
sending.

This works fine for fields that are displayed and wait for the user to 
progress, but doesn't help when the application is in an immediate keystroke 
mode that doesn't wait for enter, a non-echoing mode (like for passwords) or 
when the missing or doubled character is non-printable like the "Enter" key 
itself. I haven't figured out a good way to ensure THAT gets delivered exactly 
once and only once, every time.

Of course timeouts eventually catch the problem and the scripts can recover and 
continue from an anchor point, but it would be really nice to have some sort of 
built in guaranteed character delivery method or be able to catch mis-keyed 
data better.

Mark Bouver
Sr. System Analyst
Good Samaritan Medical Center
[EMAIL PROTECTED]
561-671-7008 

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Rich McNeil
Sent: Friday, March 31, 2006 11:40 AM
To: [email protected]
Subject: RE: [Talk] How to build a robust script for Meditech --- best
practices? Examples gratefully accepted!


Henry,

I believe we're going to develop a Webinar on the subject of running
reliable, unattended scripts.  In the mean time, I thought I might address
it directly.

These scripts are actually rather simple in structure...

Sub Script
        Do
                Reset   
                Doit
                Wait x 'seconds 
        Loop Until Done
End Sub

Reset is a big Do...Loop with PauseLoop's and At's (or Rules in Rules based
scripting) that gets the app to an "anchor point" from anywhere it might be
from within the app and even starting the app if necessary.  It should have
an "ultimate reset" which shuts down everything and starts over.  This is
easily accomplished with our BootMgr which, after a period of script
inactivity, will reboot the PC, login, and restart the script.

Doit is the script which, if it has problems, reports them and exits.  For
scripts that run continuously, the Done conditional logic isn't necessary.

This strategy is the result of, and has saved us from, a lot of 2AM calls,
and it should work for you.

Rich McNeil
Boston Software Systems
866 653 5105 x813 -or- 508 318 5327
www.bostonworkstation.com

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Henry Hansen
Sent: Thursday, March 30, 2006 5:03 PM
To: [email protected]
Subject: [Talk] How to build a robust script for Meditech --- best
practices? Examples gratefully accepted!

Hello,

Generally speaking, my scripts work OK when conditions are good.  It's
when the "edge" cases of Meditech client instability, network link
failures etc., come into play.

I sure would appreciate reading about the strategies successful
scripters use so they can sleep at night and know their scripts are
printing things such as pharmacy MARs reports reliably every evening.

Unfortunately, the network instability is something totally out of my
control - as is the Meditech installation.  (We are geographically
about 300 miles away from our data centre hosting the Meditech
servers).  Overall, it's pretty good, but we'll see a few Citrix
session drops a week, and a few times per day the 3 Tier Meditech
client's startup/shutdown will take anywhere from .5 seconds to a few
minutes, or completely freeze.  Obviously I'd have a lot more hair if
this situation improved ... but I still need to build some type of
error recovery, and this environment seems like a real good place to
perfect error recovery coding.

My strategy so far has been to use a VB6 EXE and the three tier client
for the added Boston Scripting functionality.  MeditechCS connection
BTW.

When the time comes to run the report.

Start the Meditech client.
Set a timeut of a couple of minutes.
Save the window handle.
Set an on error goto
Do normal script processing that generally works fairly well.
Call Shutdown and exit.

The error handler looks like this:
-------------
ScriptError:
        Logit ("RunMedStan - Error handler:  " & Err.Source & " " &
Hex(Err.Number) & " " & Err.Description)
        If Err.Number = seDoEvents Then DoEvents: Resume
        Call ExitMeditech
        Logit ("Error handler finished.")

The ExitMeditech sub looks like this:

Sub ExitMeditech()

  Dim I As Integer

  If Active Then
     Logit ("ExitMeditech:  Attempting to shutdown and exit.")
     Logit ("ExitMeditech:  Sending 4 ESCs - waiting 1 second between
each.")
     For I = 1 To 4
       Key "{ESC}"
       Wait 1#
     Next
     Logit ("ExitMeditech:  Sending 4 ESCs - waiting 0.25 second between
each.")
     For I = 1 To 4
        Key "{ESC}"
        Wait 0.25
     Next
     Logit ("ExitMeditech - Connecting to non existant stream.")
     Connect "fred", stStream     ' Close Boston Scripting
     Logit ("ExitMeditech - Setting Shutdown=True")
     Shutdown = True
     Wait 0.5
     Logit ("ExitMeditech:  Meditech client should be closed.")
     Logit ("ExitMeditech:  Sending @_UNLOAD")
     Key "@_UNLOAD"
  Else
     Logit ("ExitMeditech:  Meditech doesn't appear to be active.")
  End If
  '
  '  If the Window is still hanging around.
  '
  If IsWindow(meditech_hwnd) Then
    Logit ("ExitMeditech - hwnd still valid, killing process.")
    KillProcess (meditech_hwnd)
  End If

End Sub

Thanks,
Henry Hansen @ Palliser Health





Reply via email to