EPM 11.2.15 Upgrade-in-Place

I have a lab installation of 11.2.14, and decided to try out an upgrade-in-place to 11.2.15. I noticed several misleading entries in the Installer’s task list. First, it shows all my “Installed versions” as 11.2.8, and does not show the updated versions from my previous patching. This could be confusing at first, but if the EPM inventory has not updated the base installation version, this would be normal and expected.

 I am surprised however that OHS and WebLogic are not shown as being updated, nor are the Oracle Database Clients. I know for a fact there’s point updates applied to both OHS and WebLogic as part of this upgrade. As I observed later, Oracle Database Client updates are not done in 11.2.15.

It is good to see the tradition of EPM installers using one CPU thread continues:

After a successful completion of the installation phase, I moved on to the next step, updating the RCUSchema.properties file:

The traditional RCU Schema properties file has been modified by the installer to add placeholder entries for the new, required schemaPrefixEssbase and dbURLEssbase parameters. Now, I need to modify the entries to add the schema prefix I would like the Essbase21c installation to use, as well as the current Essbase hostname and port information. My question is, what exactly is the “Essbase SID” being requested? In an Oracle database, it is requesting host:port/service_name or SID, that’s general enough. For SQL however, it’s being more specific in its request.

I am assuming that the configuration process will poll the EAS schema and copy necessary data from that DB, and other information required would be copied from the Shared Services DB. Well, this is the “RCUSchema.properties” file after all, so let’s assume this is requesting the RCU schema used.

I’m entering my schemaPrefixEssbase as BS11215UPGES (12-character limit!) and my dbURLEssbase as <myDBservernameHERE>:1433:BS11215UPGRCU , which is my RCU database name in SQL Server.

A couple of notes before proceeding:

I did not modify any of the information that was pre-populated and encoded in the top half of the RCUSchema.properties file. I know my password is good as I control this SQL server. However, in the field, I would validate the actual, unencrypted password with my tool of choice against the live server to ensure there weren’t changes I was unaware of. If I attempted to use an incorrect password here, I could have issues redeploying my WebLogic applications and the Essbase portion of the configuration would be unsuccessful.

In the same vein, if the installation had been using an Oracle database, I would want to make sure the schema user in question had DBA/SYSDBA rights before proceeding, as the new Essbase configuration will need to create new schema users. If we did not have those rights, I would expect to see some kind of failure notification during the deployment.

Now that I have saved the file, and started the WebLogic Admin Console, it is time to run the Configuration Utility.

Note there is just one entry now for Essbase, and no entries for EAS or APS. Also, “Configure Web Server” is still being checked by default. We want to uncheck that as we will perform that step later.

The “Deploy to Application Server” screen is unchanged, take the defaults and move on.

The “Deploy to Application Server: Oracle WebLogic” screen has no mention of Essbase, EAS or APS at all now:

The “Configure Essbase Server” has some new items:

The checkboxes outlined above aren’t able to be unchecked at this time. Otherwise everything else can be kept at defaults for my build.

Confirmation screen shows my deployments, along with pre-configuration steps and “Configure Essbase Server”:

Configuration went quickly as the deployment and other activities utilized all available processing power:

After deployment was completed, Essbase configuration went in a similar fashion.

 Note that one of the requirements of the upgrade to Essbase 21c is the TEMP location on your server be able to accommodate 3x the size of your Essbase applications. I made sure to change my TEMP location in Windows for the system and installation account to a new location on a disk with enough capacity to meet this requirement. During Essbase configuration, I see my applications were copied to D:\Temp and presumably are being converted to Unicode and brought into the new Essbase 21c ecosystem. Depending on the size of your applications, this may take a while. A long while. I have 18GB of Planning applications and it took about an hour to complete. Essbase is LCMing your old applications and data, so if you have a process in place to do this weekly, you’ll have an idea of how long it may take.

Looking at my services, I now have an Oracle Essbase Service, my EAS, APS and OPMN services are gone:

Next step is to re-run Configtool to set up OHS with the new Essbase links, and refresh Workspace using the new procedure.

Be sure to check “Set the logical address for the applications to this web server” as required in the documentation. Note that EAS and APS are presented as components in this step:

I wanted to see if EAS and APS still were set in OHS to go to their original contexts. Note APS now has a context of “essbase”!

Done with that!

 Going in to look at the files that changed post-configuration, I noticed my RCUSchema.properties file changed to remove the “cheat-sheet” that was present after the upgrade installation was completed:

Another item of note: Planning RMI, which we’ve seen has issues with 11.2.8-11.2.14 in which the DLL referenced in the Registry Entry for the service was incorrect/missing or the Oracle Client 32-bit DB we used for a work-around was changed? Seems to work fine after the 11.2.15 upgrade. There were no changes to the dbclient32 directories made.

 Searching further, some OHS files have been updated. As we know, EPM drops a few different mod_wl_ohs.conf files around the system. There’s this location:

 D:\Oracle\Middleware\user_projects\epmsystem1\httpConfig\ohs\config\fmwconfig\components\OHS\instances\ohs_component

 And this one:

 D:\Oracle\Middleware\user_projects\epmsystem1\httpConfig\ohs\config\fmwconfig\components\OHS\ohs_component

 Both were created when 11.2.8 was installed, and both were updated by configtool shortly afterwards. You could be forgiven for modifying one or both of these when making tuning changes, because which one is really used? Well, in 11.2.15, it appears to be the latter, as that is the only one of the two that was updated by configtool.

 In mod_wl_ohs.conf, APS is now pointing to port 9010, EAS/Console is pointing to port 9110, and a new entry, /essbase has been added pointing to port 9010. Interesting, APS and Essbase are listening on the same port now.

 Httpd.conf appears to be unchanged, epm.conf has added a Location for /essbase:

Moving on to the directory structure changes, user_projects now has an “applications” directory, which contains the Essbase applications:

user_projects/domains now contains the original EPMSystem domain and a new essbase_domain:

This is the Essbase 21c lineage at work.

 Before starting up my services, I see the Essbase applications are still present in the old EssbaseServer > essbaseserver1 > app directory! I wasn’t expecting to see duplicates hanging about taking up precious disk space:

I would not delete these until your functionality checkouts are completed, however. These could serve as local backups for reference. The app copies that were in my D:\Temp directory were removed when the configuration completed.

 EAS and APS are still present in my EPMSystem domain:

EAS and APS are also still present in the WebLogic Admin Console associated with the EPMSystem domain at port 7001:

Selecting Environment > Servers on the left of WL Admin Console I see APS and EAS are shutdown and not reachable:

I decided to check to see what WebLogic was doing in the new Essbase domain. The WebLogic Admin Console is started by default if you use the Essbase start script or the Essbase Service, but is on port 7010, not 7000 or 7001. I found my missing EAS server. APS is now part of Essbase so no separate JVM for this guy:

I fired up OHS, started Foundation Services, and refreshed Workspace.

Next, I started the Oracle Essbase Service and waited for the system to settle down. Ports 9010 and 9110 are listening. I am presented with a login screen at localhost:9010/essbase/jet:

I can log in as ‘admin’ and use the hamburger menu on the left to go to “Jobs”, and see all my applications are listed with green checks showing they were LCM’d in to the system by the Essbase 21c configuration:

EAS is up and running and I can access the Web Console from port 19000 as I usually do.

I can open my Planning applications, see subvars and data, and the Essbase Applications are starting when accessed.

I opened the Planning Datasource interface and it shows the Essbase Server Unicode box is NOT checked. I was hoping it would be checked, since all apps must be Unicode in 11.2.15/21c:

When I look at the application in EAS, it IS in Unicode mode and the box is unable to be unchecked: