I wanted to take advantage of the multiple instance support in EnterpriseOne that allows multiple instances to run under the same OS user. Typical multi-foundation setups operate each enterprise server install as a different OS user. This works fine, but with the advent of server manager and it's management agents it would require installing and operating a separate managed home for each OS user. This setup works fine, but operating under the same OS user requires only a single agent install which seems like a good idea.
The first think I did was to stop the existing enterprise server using SM. In a shell I performed a recursive copy of the base directory (/u02/jdedwards/e812 in this case) to /u02/jdedwards/port6015 and /u02/jdedwards/port6016). Back in server manager I created two new instances by registering these new installations with unique instance names.
Using SM I went through and modified all the configuration items that were install specific. I went through each configuration category and looked for those settings that referenced the old install path and updated them accordingly. Off the top of my head I had to change the following settings
- Install Path
- Build Area
- XTS Repository
- JDE and JDEDEBUG log configurations
- jdelog.properties log file configurations
- Compiler and associated locations
- The JDENET listen and connect ports (set to 6015 and 6016)
- The IPC Start Key (set to unique, non-overlapping values)
- enterpriseone.sh
If you are on a release earlier than 8.11SP1 (and thus prior to the platform pack installer) the settings are instead contained in the .oneworld located in the user's home location. Since this single file defines paths that would be different for each enterprise server instance it is better to use multiple OS users in this case.
Back in SM I tried to start all my new servers. The new servers all failed to start. Looking at the SM logs and a little digging later I realized a problem in the logic in the RunOneWorld.sh script that determines if processes are already running. The script makes a series of calls to the ps application and filters based on OS user and the JDENET port. Since my new installs included the JDENET port in the path (6015 and 6016) it was incorrectly thinking the startup script itself was an existing E1 process and failed start the server. I changed the install locations so they didn't include the 6015 and 6016 values in the path and all worked.
Sidenotes
This is probably not a typical setup but once configured it works very well. There are a few notes I'd like to mention.
First, when performing my initial installation plan I had anticipated these additional ports and defined them initially. This is probably not normal, so one would have to modify their original plan to add the new ports. This creates many of the DB records required for the server such as the F965* tables and the package discovery tables (812 and later).
Secondly one must be aware of the changes made to RunOneworld.sh and EndOneWorld.sh to set the MULTIPLE_INSTANCE=1 line. Since these scripts are delivered with the tools release they will be overwritten with each new tools release I upgrade the servers to. I'll have to go back and modify those.
Although this isn't a true step by step guide to configuring multi-foundation I hope it helps the experienced CNCs with some guidance to configuring this sort of configuration.
Posts
