OneGate supports using different configurations using the same program set name, so that one may interchangeably use live code and development code at the same point in time This can be useful if you're testing new features that are modular and simply want one module to work in test code, or if you want to use an entire copy of all relevant configurations as a testbed, and alter those configurations to protect your production environment.
By way of example, let us assume that the same command lines, fields, etc., are all required for an entire project, but we don't want to affect live data. Assume that an environment variable triggers the change in which data your application actually utilises (filePro users, consider PFDIR by way of example). You can keep your live system running, and also run a development testbed at the same time without having to have multiple servers. The following illustrates the steps required to do so:
To use an alternate testbed, simply call the new CGI name you picked in step 1 above in your URL.
When OneGate sees that it is not called "onegate" or "onegate.pl", it will check for a configuration directory with the same name with which it was invoked, at the same directory depth that the main onegate directory resides. (eg., If your onegate directory is /usr/local/lib/onegate, your directory for a testbed named "onetestbed1" would be /usr/local/lib/onetestbed1.) If said directory is both present and readable, it will use this directory for all configuration values. The one thing to ensure is that you maintain the same max_session_count configuration in all testbeds, as OneGate will use the same lock directory for all lockfiles in order to maintain an accurate count of instances, whether one is using one production environment or a production environment and five different testbeds. The [maindir]/locks directory (in this specific case, [maindir] being what you installed into, rather than the testbed version of it) is always used for all locks, no matter whether you're running production or any one of several testbeds.
You may alter your testbed configurations at will, changing field requirements, configuration options, and all other manner of functionality.
In order to ensure that you can go back through a complete product chain with one testbed or another, it is recommended you utilise the %p cookie on the command line, or the ONEGATE_CGINAME environment variable. Instead of hardcoding onegate into place in a URL (eg., http://somehost.com/cgi-bin/onegate) throughout your application code, you should use the value obtained from the cookie or variable instead. This will let you chain through an entire product using the same production code or testbed as you start with. You may of course use hardwired values for production and simply insert specific testbed names in the URL's for certain modules if you're just adding functionality modularly.
NOTE: The ogconfig and ogclone tools will work on alternate testbeds if you supply the name of the testbed (the name from step 1 above) as the first argument to either program.