I have created many custom GPTools, scripts and models that I have incorporated into WMX workflows as steps. What is the best way to share these tools across my organization, so that the steps work for everyone?
For example, I have attempted to store a toolbox on our ArcSDE Geodatabase, but when I set a path to a tool script from WMX to the toolbox in SDE - the path calls on my user name and C drive:
/toolboxpath:"C:\Documents and Settings\motta\APPLICATION DATA\ESRI\Desktop10.0\ArcCatalog\Connection to diaengsql01.sde\DEN.WMX.SharedWMXToolbox" /tool:BatchDescribeProjection64Bit
Additionally, our organization is utilizing 32 bit and 64 bit operating systems. This is causing me frustration, because scripts are stored in different folders for 32 and 64 bit users. Should I store them on a network drive?
Is there anyway to store and call upon tools in SDE? Scripts? Should I be thinking about .dll's?
The first thing I'd recommend is to ensure that any models/scripts in your toolbox are set to use relative paths, not absolute paths. (There's a description of this option here.) You'll likely need to do this no matter what else you do.
Next, I can think of two ways to proceed, though I've only used the first one myself:
1) Use the [ENV:...] token and an environment variable to point to your toolbox Our project had an installer that would copy the toolboxes & supporting files into a location under "C:\Program Files" or "C:\Program Files (x86)" depending on whether the host machine was running 32-bit or 64-bit windows. Before it finished, the installer created a system environment variable (ex., "PROJ_INSTALL_DIR") that pointed to the install folder. That let us use an environment variable token in the step's arguments to refer to the toolbox location. For example:
...and that would expand out to "C:\Program Files\MyProject\Toolboxes\..." or "C:\Program Files (x86)\MyProject\Toolboxes...", depending on the individual machine.
The downside is that without an installer, it's not easy to control the toolbox location or environment variable settings on each machine. Also, changing the "/toolboxpath" step argument to include a token plays havoc with the parameter-editing GUI in the WMX Administrator; this is a little annoying if you need to make changes to the step parameters in the future.
2) Install the tools in a shared location on your network If your organization has a shared directory that's accessible by all of the users of this script -- for example, "S:\Shared" -- you could install the toolbox and its supporting files there. (I think you could also use a UNC path -- ex. "\\servername\Shared".) Either way, you'd just update your "/toolboxpath" step arguments appropriately, then you should be good to go.
I haven't tried this "shared area" approach myself, so I may be missing some pitfalls. Certainly all of the machines will need to be on the (same) network. Also, if your tools refer to any data that's packaged with the toolbox (say, FCs in a single file GDB), I suppose there could be resource contention issues.
I hope this helps. I'm definitely curious to hear how you solve this; please post an update if/when you can!
Hi Brian, Thanks for the awesome response. I have (at least, for now) set up my toolbox, scripts, etc. on a shared drive. I didn't want to get into the issues you cited with the environment token. I think I may go down the UNC path - path in the near future. I just need to study up on that, because that is new for me.
