EPM Version 11 – What property files?

Just before I start I would like to point out this blog is based on version 11.1.1.3 and no doubt the contents are subject to change in future versions.

A number of times question have been raised about the location of property files in version 11. Pre version 11 there are a multitude of property files to contend with depending on the product. I have always contested why the need for so many files and it would have been useful if they were consolidated and more information provided on what they are used for, in version 11 the storage of certain property files has certainly changed.

If you have been involved in the installation of version 11 you would of come across the Shared Services registry, this is not really to be confused with Shared Services. From the official documentation :-

The Shared Services Registry is part of the database that you configure for Shared Services.
Created the first time you configure EPM System products, the Shared Services Registry simplifies configuration by storing and re-using the following information for most EPM System products that you install:

• Initial configuration values such as database settings and deployment settings
• The computer names, ports, servers, and URLs you use to implement multiple, integrated, Hyperion products and components
• Dependent service data

Breaking it down the Shared Services registry is basically a set number of tables held in the Shared Services relational database, these tables hold the information that used to be stored in property files. Instead of a product opening one of the files to find out configuration settings it will query the registry tables (most of the time using JDBC) to find out the information,

In version 9 some of the examples of these files are :-

HBRServer.properties – contains configuration information for business rules, such as connection details to the EAS repository, this file can usually be found in the EAS installation directory and within the planning web application server so planning can connect to HBR.



PlanningSystemDB.properties – contains connection information to the planning system repository and can be found with the planning web application server.



CSS.xml (shared services configuration information), shared services web application server uses this file to collect information about native/external providers such as MSAD configuration details.



Other products such as essbase would retrieve this information by querying Shared Services directly, if you look in the system 9 essbase configuration file you will see the url it uses to retrieve this information from HSS.



If you put the CSS URL into a browser it will return the exact same details as the CSS.xml

Right so there are a very small selection of some of the property files used in System 9, in version 11 these files either don’t physically exist or if they do exist they are not used anymore and the information is read from the HSS registry.

At present it can get extremely confusing because some property files are still being used in the same way, for example many of the financial reporting .properties files are still being and are not part of the HSS registry but I am not going dwell on that today.

When you start up any of the Hyperion products how do they know the location of the HSS registry? Well if you have a look in the EPM installation directory you will find a file called reg.properties that can be found in \hyperion\common\config\9.5.0.0\



This file contains all the repository connection information to the HSS registry and each product now reads the file to find the location.

Going back to essbase, if you have a look in the essbase.cfg in version 11 you will notice a difference from the system 9 version.



The URL has been removed, in version 11 essbase has been updated so when started up it checks the value reg.properties and connects to the HSS registry and then retrieves the CSS information.

If there is problem communicating with the HSS registry via the reg.properties information you will see something like the following in the essbase.log



If you do see that message it is always useful to examine the SharedServices_Security_Client.log which is in the same directory.



Anyway back to the HSS registry and property information, if you want you want to find out what is stored in the registry you can run a script (epmsys_registry.bat or epmsys_registry.sh) in the \Hyperion\common\config\9.5.0.0, this will generate a html document (registry.html) with details of all the stored information in the registry.



The number of properties stored can be quite extensive depending on the number of EPM products you have installed on the machine.

Ok, so how you do you change a value of one of the properties? Well there are two official methods (yes two I am not hacking the tables which may be considered a third and dangerous option) and I will go through them both. The first and probably the quickest/easiest method is to use LCM.

If you logged into Shared Services, expand Application Groups and then Foundation you will see the option of “Deployment Metadata”, click on this.



You will see “Shared Services Registry” in the right hand pane, expanding this will drill down to the different products and property options, so let’s stick on the same track and extract the CSS information.



The path to this is “Shared Services Registry” > “Foundation Services Product – 9.5.0.0” > “Shared Services 9.5.0.0” > “CSS Config”

Tick “CSS Config” and click the “Define Migration” button.



Just click through a couple of screens hitting next and then execute the migration



You can launch the migration status report to see the current status of the LCM export.



Once completed you can go to the LCM export location that will be under \hyperion\common\import_export\...



The path created should match the path you drilled down into in Shared Services and you as you can see the CSSConfig.xml file has been created, this file is a replication of the old CSS.xml



You can use this method to export any of the properties from the registry, so say you wanted the equivalent of the old HBRServer.properties files you would select > “Shared Services Registry” > “Essbase 9.5.0.0” > “Logical Web App@yourmachine11_10080 > “LOGICAL_WEB_APP (Logical Web App Properties)”



It is pretty much the same as the old HBRServer.properties file except it does not include the database connection details as they are stored under (Database Connections).

Once you have edited your property file it is pretty much straight forward to import it back into the HSS registry using LCM.



In Shared Services expand “Application Groups” > “File System” and select the name to used in the LCM export. Tick the value in the right hand pane and “Define Migration” button.



On the destination Options screen select the Operation Type of “update” as the details already exist in the registry and we just want to overwrite them.



Then it is just really executing the migration and all being well the properties will be updated in the registry.

That is the LCM method but say Shared Services was down for some reason, say the MSAD details were now incorrect and it was stopping Shared Services from starting up, you still need to access the CSS information and this can be down using a command line route. It is using the same batch script (epmsys_registry) that was run earlier to generate the html report.

The command line for exporting information from the registry is :-

epmsys_registry view componentType

The componentType is the full path and component name you want to export, to get this information you have to look the html report (registry.html) that we generated earlier, it does not follow the same path name as used in the LCM route.



Above is a section of the html document that has the CSS property information, so this means the component name will be CSSConfig, when addressing the component name you have you prefix it with @ so it will be @CSSConfig
Note is also against files as it is stored as a file in the HSS registry.

Now we have to generate the full path, the current path is SHARED_SERVICES_PRODUCT as shown in the top of the table and its parent is FOUNDATION_SERVICES_PRODUCT as shown at the bottom of the table.

So we now have FOUNDATION_SERVICES_PRODUCT/SHARED_SERVICES_PRODUCT/@CSSConfig

But this is not the full path if you click the FOUNDATION_SERVICES_PRODUCT link it will take you to its parent.



This has a parent of SYSTEM9



SYSTEM9 does not have any parents so the full path will be

SYSTEM9/FOUNDATION_SERVICES_PRODUCT/SHARED_SERVICES_PRODUCT/@CSSConfig

We can now use the command line operation :-

epmsys_registry view SYSTEM9/FOUNDATION_SERVICES_PRODUCT/SHARED_SERVICES_PRODUCT/@CSSConfig



Running this command line will generate a file in the same directory as the command line utility



The file in this case is exactly the same as CSS.xml or CSSConfig.xml and can be edited with any text editing application.

Once the file has been updated the syntax to import the file back into the registry is :-

epmsys_registry updatefile componentType componentValue

Which in this instance negates to :-

epmsys_registry updatefile SYSTEM9/FOUNDATION_SERVICES_PRODUCT/SHARED_SERVICES_PRODUCT/@CSSConfig Comp_1_SHARED_SERVICES_PRODUCT_CSSConfig



The file is loaded back into the registry overwriting the existing one.

If you want to view/update a property that is not file related then it is pretty much the same process except the syntax is slightly different to update.



Say we want to view the property value for the SMTP Mail Server, to view the property would be exactly the same as before :-
epmsys_registry SYSTEM9/FOUNDATION_SERVICES_PRODUCT/SHARED_SERVICES_PRODUCT/@SMTPMailServer



As it is file related the value is just outputted to the command line window.

To update the property value then the syntax is :-

epmsys_registry updateproperty componentPath/@componentProperty value

If I want to update the SMTP Mail Server property to be EPMmailServer.com then I would use the following command line

epmsys_registry updateproperty SYSTEM9/FOUNDATION_SERVICES_PRODUCT/SHARED_SERVICES_PRODUCT/@SMTPMailServer EPMmailServer.com



To make sure that the property has definitely been updated you can just generate the registry report again.



Right, hopefully you kept with me and have understood about the Shared Services registry and know how to update properties if you ever have to.