It all started on my second project for Oracle. I hadn't been in the job that long when I was put in charge of installing, patching and maintaining a bunch of different products for a new project here in Perth. It included three Portal installs, two Oracle Internet Directories, two Collaboration Suite installs and an eBusiness Suite and a few other bits and pieces (partridge in a pear tree...) . This would be the first of many environments (about 20!) we would be implementing, so we needed a some kind of layout or template to apply so it would be easy to find things and do multiple installs on one machine.
Having been a production DBA for some time, I knew we would be getting calls and emails from end users saying "I can't access portal" or "I need a patch applied to Apps". Not only did I need a way of identifying which portal they were talking about, but which machine was it installed on, what the admin port for enterprise manager was, username/password etc etc.
I had done some training with Oracle OnDemand just before the project, so I figured, who else would have a good set of standards, so I investigated how to install things "OnDemand Certified". Their standards were good, had a few pitfalls, but with a bit of extending, would work well. (The OnDemand standard at the time meant I couldn't install a second or third portal into the same environment - let alone the same server, not sure what they are at the moment).
OK, so how could I design and build these environments without a) confusing the heck out of me and my team, and b) killing one application by installing another one (try 2 ContentDB's on one machine and you'll know what I mean).
A few things were pretty apparent.
* Identifying an environment was first. No use getting an email saying Portal's down, then searching through 13 environments to find which one.
* Once you're in an environment, ports are a HUGE issue,
* Install directories are fairly important,
* While not 100% necessary, differing installation users and groups may help.
First, lets talk ports.
If you've ever done an install of Application Server, or CollabSuite, or eBS, (the list goes on), you'll know about ports and assigning port numbers to processes. I don't know if you've thought about it as you're clicking Next > Next > Next, but you can tell the install to manually assign port numbers. I know it's easier to just let it do it itself, and if you're just installing a single development instance of Apps Server, thats fine. But if you're looking at multiple installs per server, (or HA'ing across multiple servers) you really need to know port numbers. This is where staticports.ini comes in handy.
Thankfully OnDemand already had a standard when it came to port numbers, and for the most, I agreed with it. Basically it assigned an environment a number, and then used that number within all ports to do with that environment.
For example, a development environment could be assigned the number 120, webcache listener has the number 45, so the webcache listen port for this development environment is 12045. Another development environment 123 would have the webcache listener as 12345.
Once you get past the initial frustration of things not being where they used to be (ie 7777, 1521 etc etc) it makes complete sense, and you know off the top of your head which port to be going to on whatever environment you're looking at.
OK, so next time I'll talk about install directories, identifying an environment, install users and maybe give you a handy set of scripts to build a website tying it all together... maybe... depends, give me feedback on this first :-)
Also, if you're interested in the list of port numbers across eBusiness Suite, application server (IDM, Portal, J2EE etc) and database, let me know.
Catcha next time.
