FTP Notes and Rules

When I first started working on our iForms, no one could give me a lot of information on what directory did what, where to post VGR, where to post HTML, etc. I kinda had to experiment on my own and as a result we had a few emergency releases to LIVE. I've compiled my notes on FTP and the server locations we use. I'm not sure if they're universal among McKesson systems or not, but I figured hey... all theses notes, surely there's a kernel of wisdom in there somewhere (statistics right?).

So here we go...


VGR location for release:

/u/live/orders/toolkit/database

  • Anything (VGR or HTML) put in this location will go out to TRAIN or LIVE with a release to either
  • You only have to put VGR here, a new or changed filename has to be released and bounced to work in HEO
  • You can manipulate an existing VGR file and place it here, and the changes will take effect immediately (?I think? I'm really not sure about this, sometimes it seems to work and sometimes it doesn't... if anyone knows what the 'x' factor is here please chime in)

HTML Locations:

LIVE HTML: /u/live/orders/database
TRAIN HTML: /u/train/orders/database

  • You can manipulate the HTML and place it here but be aware that any changes made thusly are applied immediately
  • If you put VGR and HTML here, it will allow you to use the @VGR command (I'll come back to that)

Accessory Files

LIVE accessory files: /u/live/htdocs/heo/web/dbmi/iformgen
TRAIN accessory files: /u/train/htdocs/heo/web/dbmi/iformgen

  • This directory is where the Javascript libraries, CSS files, and image files are stored.
  • Each has the directories; images, scripts, and style to organize those files (if not you may want to create them)
  • Images contains a subdirectory , "Icons", for smaller images used in iForms (saves a lot of digging through tiny files to find actual pictures
  • Style contains several directories and individual files. The most important of those is the UI file or directory, if you're using UI, this is where the "look" of your iForms is kept and if you're not, I'd advise looking into it, maybe Scott or I can hit on that later if there's interest
  • Scripts contains the most files, these are all the routines and functions that are used across multiple forms.
    • Again we have a UI directory or files which holds the JQuery library and the UI library that gives our iForms the "feel" they share
    • Other common functions are in the scripts directory, the Calendar, tool tip script, multi item dropdown
    • Also worth mentioning, this is where my tools file "SGMC_tools.js" is kept, which holds all of our shared "in-house" functions
  • Extra care MUST be taken when copying anything from your TEST to your LIVE system in these directories, because any changes will affect ALL iForms in LIVE immediately. Backups should always be made of current LIVE accessory files before updating. I'm going to say that again with more "oomph" just because it's that important... when you make changes to CSS or JS files that are shared across multiple forms, BE SURE YOU TEST ALL OF THOSE FORMS BEFORE YOU COPY THAT ACCESSORY FILE INTO LIVE.

General Rules:

  • THERE IS NO UNDO IN FTP... MAKE BACKUPS... BACKUP YOUR BACKUPS, IF YOU MAKE A CHANGE… MAKE A COPY.
  • McKesson advises copying both the VGR and HTML to ALL locations. (I don’t like this, but it does make things easier for everyone)

Building and Testing Protocol:

I wanted to share my protocols with you, and I'm coming back to that @VGR now. This is far from iron clad of course, it's just the way I do it and it seems to work well. A little background, we have over one hundred forms that have come out of Zynx which I'm working to update and make user-friendly so for the purposes of this example, we'll say I've just picked a new one to work on, lets say... adultivfluid_01.htm and adultivfluid_01.vgr

  1. make a copy of those files renamed to ivtest
  2. then I do my voodoo on them and we'll hit on specifics another time (if anyone else is using Zynx forms let me know and I'll go into detail on what I do to them)
  3. I then copy the ivtest file into the TRAIN HTML directory only. This is where they live for the duration of the testing phase
  4. Now I don't have to bounce and release (interrupting my coworkers) but instead in HEO I use "@VGR=ivtest" and voila, launches the form. Now we're free to test, update and modify at will without bothering a soul
  5. Once the form has cleared testing and our approval committee, it is then renamed back to adultivfluid_01 and placed in the VGR directory (at this point a release and bounce to LIVE will send it out, so take care)
  6. Now it can be released to TRAIN, we make sure it searches ok, give it a last look then release it to LIVE (all dependencies should be copied to LIVE at this point also)
  7. Any test file names should be removed now. A clean server is an easy-to-search sever

And that's what I have for FTP and testing procedures. Everyone is welcome to comment in on what they do differently or on anything you want to add to my summary.

10 comments:

  1. As I understand it, the three folders that matter (in terms of HTM/VGR) files are:
    (1) /u/live/orders/toolkit/database
    (2) /u/train/orders/database
    (3) /u/live/orders/database

    If you are testing and you want your changes to show up immediately in your TRAIN environment, copy your HTM/VGR files to #2.

    If you have an emergency fix and you need your changes to go LIVE (beware!), copy your HTM/VGR files to #3.

    Now, as I understand it, #1 is the "X" factor. When you do a release / bounce (either to live or train), it will copy the contents of #1 to the corresponding environment folders (#2 or #3 for train or live, respectively). So if you have a change that is ready to go live, but you want to wait until your live release, put it in there. I believe that's also why it's highly recommended to copy your HTM/VGR files to both #1 and #2 in VGR class since, when you bounce your train environment, you may end up overwriting your files with older versions.

    Again, I could be wrong, but that's how I understand it.

    ReplyDelete
  2. I am trying to set the iForms so that they open to fullscreen size (100%), so that no matter the monitor size the iForm will fill it.

    I tried manipulating the heo.ini file, but dont know if it can be set to 100%.

    Currently, it reads:
    PopupFullHeight=800
    PopupFullWidth=1050

    When I change the settings, it appears to do nothing.

    DO you know how I can set the iForms to open to 100%?

    Thanks,

    Mike

    ReplyDelete
  3. Hey Mike,
    You're in the right place, but you want to scroll down a little further to the line that reads

    # The following setting controls if the client fills the screen or not
    ShowMaximized=true

    Make sure it's not commented out and it's set to "true"

    Then comment out the two "PopupFull.." lines

    # Size of a full screen popup (iForm)
    #PopupFullHeight=825
    #PopupFullWidth=1050

    and that should launch HEO full screen.

    As to making the iForm fit no matter the monitor size, that takes a little more doing. They're going to appear somewhat different on different resolution screens. Best practice is try building to the lowest resolution that your hospital Regularly uses, so that on higher res screens it'll just mean a little more empty space.

    ReplyDelete
  4. I got another question while im here that is prety straight forward. Can you concatenate variables in the VGR comment (53)?

    I want to catch 3 values on the form and then put them all in the coment field.

    Thanks,

    Mike

    ReplyDelete
  5. I don't see why you wouldn't be able to. You would just need to create an additional LOCAL variable, let's call it "myfullcomment" for the sake of argument.

    INIT,SET,LOCAL,myfullcomment,TO,

    Then, in your mapping, you can just do something like:

    EDIT,SET,,myfullcomment,CAT,myVar1
    EDIT,SET,,myfullcomment,CAT,myVar2
    EDIT,SET,,myfullcomment,CAT,myVar2

    EDIT,SET,,orderstring,CAT,"@LOAD_ORDER=OIS=1234^^^OOS=0^^^53=`myfullcomment"

    ReplyDelete
  6. Think it be possible to just put something like 53=this:`va1 that:`var2 how:`var3"

    ReplyDelete
  7. Yeah that works just fine, you can make nice pretty sentences like that.

    ReplyDelete
  8. Note:

    The "Accessory files" can live wherever you like, however, if you're prefacing the path to those with BASE_URL, you'll need to check what the BASE_URL parameter is set to in your HEOConfig.ini. For example, on my system, these files are in /u//htdocs/heo/web.

    ReplyDelete
  9. CSS file is recognized: Need Advice

    if the iforms are stored at /u/train/orders/database, and there's an image folder at /u/train/orders/database/BASE_URLdbmi, so where would i store the css file and what would the path be called in the iform.

    ReplyDelete
  10. Schanta,

    Please note that the "/u/train/orders/database" folder is ONLY for VGR files and the HTM files that they call. The HEO server does not "serve" the pages from this location so having a folder in that same location won't work (nor can you do relative locations like "/images/myimage.jpg"). If you want to refer to external files, HEO has separate folders set up for that kind of thing.

    Generally speaking, they're at "/u/train/htdocs/heo/web/" but you can double check by looking in your HEOConfig.ini file for the BASE_URL= setting. If you go here, you'll generally find a "dbmi" folder. That's why in the demo files, you'll see "BASE_URLdbmi" (and why I assume you put that folder in your htm/vgr folder as seen above) - because HEO parses out any reference to BASE_URL and replaces it with whatever is there in your HEOConfig.ini file, and in this case would turn it to "/u/train/htdocs/heo/web/dbmi/"

    Please note that the HEOConfig.ini is different for LIVE and TRAIN so when you push something to live, make sure that your supporting files (js/css/images/whatever) are synched up as well.

    ReplyDelete