Have you
ever wondered how the display version operates in workspace or questioned why
the version has not been updated after a patch has been applied, if so then
this might be of interest to you.
I know I have been asked on many occasions by customers why the version number in workspace does not match the patch that has been applied in an environment, I usually say that workspace should be not be counted on as a true reflection but never gone into detail why not.
I am going to attempt to go through the main core products and show where the version number is populated from, you might be naïve and think that it is one standard for all but please remember this is EPM and still under the covers it is a mishmash of products all working in different ways.
This is going be based on 11.1.2.3 but it should be relevant for 11.1.2.2 and possibly earlier depending on product.
So let’s take the workspace and UI version first.
The above versions are contained in two property files within the workspace web application.
Located in
<MIDDLEWARE_HOME>\EPMSystem11R1\products\Foundation\workspace\InstallableApps
is the enterprise archive file workspace.ear and contained within the packaged file is the web application archive file workspace.war
The two property files contain the current version number.
To prove this I updated the version number in the files and repackaged them.
A restart of foundation is required to deploy the changes.
Ok so that shows where those versions are sourced from.
Now let’s move on to planning which is currently displaying the following version in workspace.
For the majority of java web applications the version number can be found in the Shared Services registry.
If you run a registry report and look at the logical web application entry then you will see a displayVersion property which workspace reads in when selecting the help > about menu.
This is fine but when you apply a patch there is usually no interaction with the registry so the version must originate from somewhere before the registry being updated.
For planning there is a property file located in the java archive file
<MIDDLEWARE_HOME>\EPMSystem11R1\products\Planning\lib\HspJS.jar
The PlanningConfig file contains the planning version.
Once again I will update the version and repackage the file.
When the planning web application is restarted the version in the file is checked against the display version in the Shared Services registry and if they don’t match the registry is updated.
Restart the foundation web application again and the version in workspace should be updated.
On to HFM which is again slightly different to where the version is sourced from.
The version is contained within the web application archive but this time it is derived from the manifest file in the META-INF directory.
The manifest is a special file that can contain information about the files packaged in an archive file and in this case the version is read from the Implementation-Version line.
To confirm this I updated the version in the manifest file.
Restarted the HFM java web tier service and checked the HSS registry.
The display version is updated in the FM LWA and ADF LWA entries but workspace only uses the version in the ADF entry.
Restart Foundation and the new version is displayed.
Now you should have got the concept I will quickly go through some of the other core products, each of them the version is read from the HSS registry in workspace but the version is updated in the registry from the following source files:
Provider Services – This also uses the manifest located in the ess_es_server java archive file
Financial Reporting - This also uses the manifest located in the HReports java archive file
FDMEE – Yet again a slightly different way of maintaining the release version and is stored nice and simply in an xml file.
Calculation Manager uses the build version within a property file in the calcmgrcommon java archive file
EPMA is always different and there is property file file within the structure of the java web application archive.
The version displayed is a combination of the awb.display.version and build.number property.
The Reporting and Analysis Framework version doesn’t look to me like it gets updated unless there is a direct change to the display version in the HSS registry for the RA_FRAMEWORK_LWA entry.
You may have noticed I have not mentioned Shared Services and this is because in 11.1.2.3 it is embedded in workspace and unless I am missing something there is no option to view the version in workspace.
In previous versions when Shared Services was separate the version was available by using the help > about option in the Shared Services console.
The version is not read from the HSS registry and is sourced from the manifest in the interop-sdk java archive file.
The version displayed is a combination of the Current-Version and Drop-Number properties.
I think that covers the majority of product components and if you find that a version is not updated in workspace when a patch has been applied then it could be down to the file that contains the versions is not part of the patch or the file has not been updated.
At least you should be able to trace it back to the source and impress others, just remember where you heard it from :)
I know I have been asked on many occasions by customers why the version number in workspace does not match the patch that has been applied in an environment, I usually say that workspace should be not be counted on as a true reflection but never gone into detail why not.
I am going to attempt to go through the main core products and show where the version number is populated from, you might be naïve and think that it is one standard for all but please remember this is EPM and still under the covers it is a mishmash of products all working in different ways.
This is going be based on 11.1.2.3 but it should be relevant for 11.1.2.2 and possibly earlier depending on product.
So let’s take the workspace and UI version first.
The above versions are contained in two property files within the workspace web application.
Located in
<MIDDLEWARE_HOME>\EPMSystem11R1\products\Foundation\workspace\InstallableApps
is the enterprise archive file workspace.ear and contained within the packaged file is the web application archive file workspace.war
The two property files contain the current version number.
To prove this I updated the version number in the files and repackaged them.
A restart of foundation is required to deploy the changes.
Ok so that shows where those versions are sourced from.
Now let’s move on to planning which is currently displaying the following version in workspace.
For the majority of java web applications the version number can be found in the Shared Services registry.
If you run a registry report and look at the logical web application entry then you will see a displayVersion property which workspace reads in when selecting the help > about menu.
This is fine but when you apply a patch there is usually no interaction with the registry so the version must originate from somewhere before the registry being updated.
For planning there is a property file located in the java archive file
<MIDDLEWARE_HOME>\EPMSystem11R1\products\Planning\lib\HspJS.jar
The PlanningConfig file contains the planning version.
Once again I will update the version and repackage the file.
When the planning web application is restarted the version in the file is checked against the display version in the Shared Services registry and if they don’t match the registry is updated.
Restart the foundation web application again and the version in workspace should be updated.
On to HFM which is again slightly different to where the version is sourced from.
The version is contained within the web application archive but this time it is derived from the manifest file in the META-INF directory.
The manifest is a special file that can contain information about the files packaged in an archive file and in this case the version is read from the Implementation-Version line.
To confirm this I updated the version in the manifest file.
Restarted the HFM java web tier service and checked the HSS registry.
The display version is updated in the FM LWA and ADF LWA entries but workspace only uses the version in the ADF entry.
Restart Foundation and the new version is displayed.
Now you should have got the concept I will quickly go through some of the other core products, each of them the version is read from the HSS registry in workspace but the version is updated in the registry from the following source files:
Provider Services – This also uses the manifest located in the ess_es_server java archive file
Financial Reporting - This also uses the manifest located in the HReports java archive file
FDMEE – Yet again a slightly different way of maintaining the release version and is stored nice and simply in an xml file.
Calculation Manager uses the build version within a property file in the calcmgrcommon java archive file
EPMA is always different and there is property file file within the structure of the java web application archive.
The version displayed is a combination of the awb.display.version and build.number property.
The Reporting and Analysis Framework version doesn’t look to me like it gets updated unless there is a direct change to the display version in the HSS registry for the RA_FRAMEWORK_LWA entry.
You may have noticed I have not mentioned Shared Services and this is because in 11.1.2.3 it is embedded in workspace and unless I am missing something there is no option to view the version in workspace.
In previous versions when Shared Services was separate the version was available by using the help > about option in the Shared Services console.
The version is not read from the HSS registry and is sourced from the manifest in the interop-sdk java archive file.
The version displayed is a combination of the Current-Version and Drop-Number properties.
I think that covers the majority of product components and if you find that a version is not updated in workspace when a patch has been applied then it could be down to the file that contains the versions is not part of the patch or the file has not been updated.
At least you should be able to trace it back to the source and impress others, just remember where you heard it from :)
