I mentioned it in my last post but I can now announce I have successfully created and tested a Windows service wrapper for OHS.
Using this you can control OHS via a Windows service, rather than relying on running scripts. This is useful for environments where interactive login with the Windows service account is not allowed.
You can find the project here:
https://github.com/justdan96/ohsw
Because this can be used with other things - not just OHS - and also so I don't potentially get sued I've decided to name the project "Oh! Service Wrapper". Because it's surprisingly useful!
This is just the first version so it really is a "use at your own risk" deal. Feedback, questions and improvements are welcome via the GitHub repository.
It's written in Golang so compilation is straightforward and there are no external dependencies. When I get around to it I'll create a GitHub action to create Windows executables automatically.
Tuesday 28 January 2020
Monday 13 January 2020
EPM 11.2: OHS Changes
Yet another blog post on EPM 11.2! This time we are looking at the changes for EPM 11.2 related specifically to OHS.
The first thing you may be wondering is: how do you start the OHS server? Well it's a change from the previous few versions as OHS no longer uses OPMN for this task. Instead it uses Node Manager. If you followed the official installation and configuration guide you should have a service like the below:
With that service running we have some helper scripts to get OHS online. Browse to MIDDLEWARE_HOME\user_projects\FND1\httpConfig\ohs\bin\. Then run the following command to start OHS and store the epm_admin credentials so you aren't prompted later:
startComponent.cmd ohs1 storeUserConfig
To stop OHS simply run the command:
stopComponent.cmd ohs1
From now on you can start OHS with:
startComponent.cmd ohs1
It is a bit annoying to not have a nice Windows service to start that will bring OHS online but I might work on that soon.
If you completed the above, your OHS server is starting however it isn't listening on port 19000 but rather port 7777 then you need to copy all the files and folders from MIDDLEWARE_HOME\user_projects\epmsystem1\httpConfig\ohs\config\fmwconfig\components\OHS\ohs_component\ to MIDDLEWARE_HOME\user_projects\epmsystem1\httpConfig\ohs\config\fmwconfig\components\OHS\instances\ohs1.
The OHS configuration files are read from httpConfig\ohs\config\fmwconfig\components\OHS\instances\ohs1 - but the configtool only updates the files in httpConfig\ohs\config\fmwconfig\components\OHS\ohs_component. Don't ask me why they have duplicate folders! I picked up this tip from a comment by Dan C on the epmonprem.pro blog, so I can't take credit for that discovery.
Next if you want to know specifically which version of OHS (and the underlying version of Apache) is being used you can run the commands below. Change paths to suit your environment:
cd /d E:\Oracle\Middleware\ohs\ohs\bin
SET PATH=E:\Oracle\Middleware\ohs\ohs\bin;E:\Oracle\Middleware\ohs\bin;E:\Oracle\Middleware\ohs\oracle_common\bin;%PATH%
httpd.exe -version
You should see output like the below:
Server version: Oracle-HTTP-Server-12.2.1.3.0/2.4.25 (Win64)
Server built: Aug 17 2017 20:40:27
If you need to change any configuration in OHS just be sure that the previous version of Hyperion used OHS 11.1.1.7, Apache 2.2, and some syntax is no longer valid. A common bit of customisation that I do, that thankfully still works in OHS 12.2.1.3, is changing the EPM logo in the logon page.
First browse to E:\Oracle\Middleware\EPMSystem11R1\common\epmstatic\bpmui\ and then create the path below:
E:\Oracle\Middleware\EPMSystem11R1\common\epmstatic\bpmui\themes\theme_skyros\images_global\
Next take a copy of the logon_panel.gif file, edit it and place it in this location. We will use an OHS configuration setting to ensure that our edited image is used, rather than the version in the Workspace WAR file.
Browse to E:\Oracle\Middleware\user_projects\FND1\httpConfig\ohs\config\fmwconfig\components\OHS\instances\ohs1\ and edit the file "epm_rewrite_rules.conf". Add the following line:
RewriteRule ^/workspace/bpmstatic/themes/theme_skyros/images_global/logon_panel.gif /epmstatic/bpmui/themes/theme_skyros/images_global/logon_panel.gif [PT]
Restart OHS. You will now see your updated logo!
The first thing you may be wondering is: how do you start the OHS server? Well it's a change from the previous few versions as OHS no longer uses OPMN for this task. Instead it uses Node Manager. If you followed the official installation and configuration guide you should have a service like the below:
With that service running we have some helper scripts to get OHS online. Browse to MIDDLEWARE_HOME\user_projects\FND1\httpConfig\ohs\bin\. Then run the following command to start OHS and store the epm_admin credentials so you aren't prompted later:
startComponent.cmd ohs1 storeUserConfig
To stop OHS simply run the command:
stopComponent.cmd ohs1
From now on you can start OHS with:
startComponent.cmd ohs1
It is a bit annoying to not have a nice Windows service to start that will bring OHS online but I might work on that soon.
If you completed the above, your OHS server is starting however it isn't listening on port 19000 but rather port 7777 then you need to copy all the files and folders from MIDDLEWARE_HOME\user_projects\epmsystem1\httpConfig\ohs\config\fmwconfig\components\OHS\ohs_component\ to MIDDLEWARE_HOME\user_projects\epmsystem1\httpConfig\ohs\config\fmwconfig\components\OHS\instances\ohs1.
The OHS configuration files are read from httpConfig\ohs\config\fmwconfig\components\OHS\instances\ohs1 - but the configtool only updates the files in httpConfig\ohs\config\fmwconfig\components\OHS\ohs_component. Don't ask me why they have duplicate folders! I picked up this tip from a comment by Dan C on the epmonprem.pro blog, so I can't take credit for that discovery.
Next if you want to know specifically which version of OHS (and the underlying version of Apache) is being used you can run the commands below. Change paths to suit your environment:
cd /d E:\Oracle\Middleware\ohs\ohs\bin
SET PATH=E:\Oracle\Middleware\ohs\ohs\bin;E:\Oracle\Middleware\ohs\bin;E:\Oracle\Middleware\ohs\oracle_common\bin;%PATH%
httpd.exe -version
You should see output like the below:
Server version: Oracle-HTTP-Server-12.2.1.3.0/2.4.25 (Win64)
Server built: Aug 17 2017 20:40:27
If you need to change any configuration in OHS just be sure that the previous version of Hyperion used OHS 11.1.1.7, Apache 2.2, and some syntax is no longer valid. A common bit of customisation that I do, that thankfully still works in OHS 12.2.1.3, is changing the EPM logo in the logon page.
First browse to E:\Oracle\Middleware\EPMSystem11R1\common\epmstatic\bpmui\ and then create the path below:
E:\Oracle\Middleware\EPMSystem11R1\common\epmstatic\bpmui\themes\theme_skyros\images_global\
Next take a copy of the logon_panel.gif file, edit it and place it in this location. We will use an OHS configuration setting to ensure that our edited image is used, rather than the version in the Workspace WAR file.
Browse to E:\Oracle\Middleware\user_projects\FND1\httpConfig\ohs\config\fmwconfig\components\OHS\instances\ohs1\ and edit the file "epm_rewrite_rules.conf". Add the following line:
RewriteRule ^/workspace/bpmstatic/themes/theme_skyros/images_global/logon_panel.gif /epmstatic/bpmui/themes/theme_skyros/images_global/logon_panel.gif [PT]
Restart OHS. You will now see your updated logo!
Friday 3 January 2020
EPM 11.2 Reusing a Single RCU Repository
Edit: some news here - Oracle Support is saying that actually the RCU doesn't need to be run for each server in your environment. To paraphrase slightly:
"EPM 11.2 requires Repository Creation Utility (RCU) to create schemas to support Oracle Enterprise Performance Management System Java web applications.
After running the RCU on your first server and before running EPM System Configurator on your second, the RCUschema.properties file on each EPM machine must be updated (on all your servers). There is no need to run the RCU on your other servers.
EPM Configurator "Deploy to Application Server" tasks will fail until Repository Creation Utility (RCU) has been run to create supporting Weblog schemas and EPM_ORACLE_HOME/common/config/11.1.2.0/RCUSchema.properties has been updated properly."
This appears to contradict what the documentation says, so we may have to wait for official clarification.
So the RCU is a new requirement for EPM installations with 11.2. Previously it was required for the EPMA batch client or the DRM web API deployment but now it is required for every EPM environment you wish to deploy.
One thing in the installation guide stuck out to me: "You must run RCU on each machine in your environment."
Excuse me: what?
I've had dealings with the RCU before, and never do you need to run it twice. The repository is created and then used. So I read that line with... let's say some scepticism. Once I actually went through the EPM configuration I found that, yes, the configtool will error out if you try to reuse a previously configured RCU repository. So you can't scale out without creating another prefix in the RCU for every server you have. I also found the RCU had shortcomings of its own.
What I say next is not official or supported in any way. It is of academic interest only, currently. But there is actually a reason why you can't reuse the RCU repository.
When you first run the configtool on your 2nd machine it will try to push some configuration into the tables you configured in the RCU. This configuration already exists, so that fails.
Subsequent runs of the RCU will then attempt to query the EPMSystem domain configuration to find those same tables. However the domain configuration hasn't been properly set up on that machine yet, so it will again fail. If it can find the domain configuration then it will work.
I have tested a method to get around this - it works flawlessly in my testing. The method is this:
"EPM 11.2 requires Repository Creation Utility (RCU) to create schemas to support Oracle Enterprise Performance Management System Java web applications.
After running the RCU on your first server and before running EPM System Configurator on your second, the RCUschema.properties file on each EPM machine must be updated (on all your servers). There is no need to run the RCU on your other servers.
EPM Configurator "Deploy to Application Server" tasks will fail until Repository Creation Utility (RCU) has been run to create supporting Weblog schemas and EPM_ORACLE_HOME/common/config/11.1.2.0/RCUSchema.properties has been updated properly."
This appears to contradict what the documentation says, so we may have to wait for official clarification.
So the RCU is a new requirement for EPM installations with 11.2. Previously it was required for the EPMA batch client or the DRM web API deployment but now it is required for every EPM environment you wish to deploy.
One thing in the installation guide stuck out to me: "You must run RCU on each machine in your environment."
Excuse me: what?
I've had dealings with the RCU before, and never do you need to run it twice. The repository is created and then used. So I read that line with... let's say some scepticism. Once I actually went through the EPM configuration I found that, yes, the configtool will error out if you try to reuse a previously configured RCU repository. So you can't scale out without creating another prefix in the RCU for every server you have. I also found the RCU had shortcomings of its own.
What I say next is not official or supported in any way. It is of academic interest only, currently. But there is actually a reason why you can't reuse the RCU repository.
When you first run the configtool on your 2nd machine it will try to push some configuration into the tables you configured in the RCU. This configuration already exists, so that fails.
Subsequent runs of the RCU will then attempt to query the EPMSystem domain configuration to find those same tables. However the domain configuration hasn't been properly set up on that machine yet, so it will again fail. If it can find the domain configuration then it will work.
I have tested a method to get around this - it works flawlessly in my testing. The method is this:
- On your second machine, attempt the "Deploy to Application Server" tasks for your chosen applications. Let it run, fail and complete.
- Then browse to "E:\Oracle\Middleware\user_projects\domains\EPMSystem\" directory and rename the "config" folder to "config_old".
- Next copy the "config" folder from the location above on your first server, to the same location on your second server.
- Finally re-run the configtool, selecting the same "Deploy to Application Server" tasks. This time it will succeed.
As I said - this is just for information. I will probably raise an SR to get Oracle to address this issue, since it seems like just a silly mistake that the configtool tries to read the domain configuration when it isn't available on that machine.
EPM 11.2 WebLogic Server Startup Error
Just a quick one, if you are trying to start up a WebLogic service on EPM 11.2 (Planning, for instance) and you see in the sysout log the following error:
java.lang.IllegalArgumentException: Unable to use KSS for Demo Key Stores, KSS is unavailable
You should know that the reason for this is an entry missing in the classpath. Without this entry the service startup will fail.
To correct that, go to the Windows registry and browse to HKEY_LOCAL_MACHINE\SOFTWARE\Hyperion Solutions\Planning0\HyS9Planning_PLN1 (or equivalent).
Then look in the list of JVMOption properties for one with a value starting with "-Djava.class.path=". If you look at this value and scroll right to the end you should see a semicolon by itself. After that semicolon, insert:
E:\Oracle\Middleware\oracle_common\modules\internal\features\jrf_wlsFmw_oracle.jrf.wls.classpath.jar
Then the next time you start up the service it will work!
java.lang.IllegalArgumentException: Unable to use KSS for Demo Key Stores, KSS is unavailable
You should know that the reason for this is an entry missing in the classpath. Without this entry the service startup will fail.
To correct that, go to the Windows registry and browse to HKEY_LOCAL_MACHINE\SOFTWARE\Hyperion Solutions\Planning0\HyS9Planning_PLN1 (or equivalent).
Then look in the list of JVMOption properties for one with a value starting with "-Djava.class.path=". If you look at this value and scroll right to the end you should see a semicolon by itself. After that semicolon, insert:
E:\Oracle\Middleware\oracle_common\modules\internal\features\jrf_wlsFmw_oracle.jrf.wls.classpath.jar
Then the next time you start up the service it will work!
Oracle RCU Does Not Support SSL for SQL Server
As the title suggests, this is just a warning to anyone in a highly security-conscious environment. If SSL connections for SQL Server are mandatory in your environment you will not be able to run the Oracle RCU, required before you can deploy applications to WebLogic.
There are 2 Oracle Support documents that cover this, DocID 2545309.1 and DocID 2343965.1.
The solutions given are thus:
I did wonder about migrating an RCU repository between SQL Servers. The interesting thing about running the RCU is that actually there is only one table that mentions server names at all. Assuming the database you ran the RCU against is called "OWSM" and the prefix you chose is "EPM" then you can check that by running the below command:
SELECT * FROM [OWSM].[EPM_STB].[COMPONENT_SCHEMA_INFO]
Theoretically that could mean that you could migrate between SQL instances just by editing the DB_HOSTNAME column in this table - but I have no idea how much that would mess things up! Passwords appear to be embedded into SQL tables, so even though there are documents covering how to change the RCU schema passwords and change the data sources appropriately I am not sure if they could actually work in this case.
There are 2 Oracle Support documents that cover this, DocID 2545309.1 and DocID 2343965.1.
The solutions given are thus:
I did wonder about migrating an RCU repository between SQL Servers. The interesting thing about running the RCU is that actually there is only one table that mentions server names at all. Assuming the database you ran the RCU against is called "OWSM" and the prefix you chose is "EPM" then you can check that by running the below command:
SELECT * FROM [OWSM].[EPM_STB].[COMPONENT_SCHEMA_INFO]
Theoretically that could mean that you could migrate between SQL instances just by editing the DB_HOSTNAME column in this table - but I have no idea how much that would mess things up! Passwords appear to be embedded into SQL tables, so even though there are documents covering how to change the RCU schema passwords and change the data sources appropriately I am not sure if they could actually work in this case.
Subscribe to:
Posts (Atom)