OBIEE 12c was released recently and like with OBIEE 11g it comes bundled with a suite of Essbase and EPM products, the noticeable highlight from an EPM perspective is that it is the first sight of Essbase 12c.
It is worth stressing that this Essbase for BI and not EPM, they are currently different code lines and by the time EPM 12c is released which could be 2017, Essbase 12c may have gone through many more changes.
Though what this release for BI does provide is a glimpse into a couple of big changes to the architecture behind Essbase, the two standout ones are:
I am going to try and cover these in a little more detail but as Essbase is not standalone and bundled with OBIEE then there are a few restrictions.
When you carry out a default install of OBIEE 12c the EPM/Essbase components are automatically installed.
At the point of configuration there is an option whether to include the Essbase components
The EPM components are all deployed into the same WebLogic managed server as OBI and these include
Essbase Agent.
It doesn’t look like it is currently possible to deploy the Essbase web application to its own managed server which is a bit of pain and also I am not a fan of trying to deploy too bunch into one managed server, this is similar in the EPM world to deploying web applications to a single managed server which I usually steer away from for a number of reasons.
There is an interesting statement in the documentation “Essbase Java Agent offers improved concurrency and networking capabilities over the classic C Agent”
Does this also mean the Java agent is going to offer more stability and less likely to freeze? Until it is possible to deploy Essbase to its own managed server away from the other BI components then I feel there are too many factors involved to be able to prove this.
Once OBI has been configured and you take a look at the deployments within the WebLogic admin console you will see the Essbase web application.
If you are wondering CDS stands for Cube Deployment Services which forms the Essbase Business Intelligence Wizard, this is a web based tool for building Essbase cubes.
It gives the feel of a very simplistic version of Essbase Studio and provides functionality to deploy ASO cubes from BI models within an RPD.
In OBIEE 11g it included EAS and Studio but these have now been dropped and replaced with CDS, if you are from the EPM world then I doubt you will be too impressed with this functionality but I suppose if you are looking to build straight up aggregation ASO cubes this simplifies the process.
I am not going to go into any more detail on CDS as maybe that is for another day or I am sure it will be covered by others.
Anyway back to Essbase, once the BI managed server has been started the Essbase Java Agent should be up and running.
One of the many reasons why the Essbase C agent has been replaced the Java agent is that in 12c there is no longer OPMN and the WebLogic framework pretty much runs the show.
I have never really believed in Essbase and OPMN unless you are clustering on a *nix system, ok you can get OPMN to restart Essbase if it crashes but the amount of drawbacks outweigh any benefit, it would have been nice to be given the option to deploy or not.
It is all change in 12c and we will have to see if the WebLogic framework handles it any better.
No longer will you see an Essbase process running and you will only the java process which is running all the deployments in the WebLogic managed server.
If you start an Essbase application then you will notice that not everything has moved to Java and C is still being used for the Essbase Server process, I suspect the long term goal would be for the server to also move to Java.
The essbase.log has is engraved into anybody that uses Essbase, in version 11 there was also the ODL version which made it confusing as there were now two Essbase logs, in 12c the essbase.log has gone and moved into the logs directory of the managed server.
jagent.log is the replacement.
The contents of the log are very different to what you have been used to with old Essbase log.
To verify the agent is up and running you should be looking for:
Oracle Essbase Jagent 12.2.1.0.000.150 started on 9799 at Fri Oct 31 00:45:47 GMT 2015
OBI 12c uses a range of ports starting at 9500 by default and the Essbase agent is assigned 9799, though saying that the Essbase server range still starts at 32768.
What is a bit concerning is the log seems to be full of a repetitive error:
exception.during.capi.request[[java.lang.NoClassDefFoundError: Could not initialize class oracle.epm.jagent.logging.LoggerHelper
This type of error usually means that a class is not contained in the java classpath but the class in the error message is definitely in the path, it is a bit annoying as it could be important messages that are not being logged, I am going to put it down to being at the moment.
You can also check the status of Essbase in the WebLogic admin console or using WLST.
As Essbase is running as a web application a page should be returned for the agent over http(s)
Though technically speaking it is possible that the web application could be up and running but there is an issue with the agent which is preventing it from starting.
The application logs are a couple of directories below the jagent log
As the Essbase server has not changed you still have the old style log and the ODL log so much for progression :)
Some of the Essbase components are still installed under a products folder similar to the current EPM structure.
The Essbase ARBORPATH and location of the Essbase applications by default is/bidata/components/essbase , this is defined by an XML file which I will cover in more detail when I go through clustering.
As the Essbase Server (ESSSVR) has not changed there are no shocks around how the applications operate and store metadata/data.
The essbase configuration file (cfg) has not gone away but I suppose you were thinking that it was going to be in the above bin directory, don’t be silly you are used to that so it is time for a change :)
All the BI configuration files are situated under the fmvconfig directory and this is where the essbase.cfg sits, remember this is Essbase for BI and it doesn’t mean it will apply to EPM though I suspect it might.
The cfg file is relatively the same with the noticeable addition of the JAGENT_ID
PRIMODIAL_AGENT_ID just rolls off the tongue :)
There is a long list of cfg settings that are no longer relevant in 12c and these can be found in the documentation.
In Essbase for BI security is not controlled by Shared Services and falls into Enterprise manager using Oracle Platform Security Services (OPSS) so that is why OPSS is set as the authentication module, I am not going to go into as it is hideous and you can read all about it here
So how about starting and stopping Essbase.
As Essbase is deployed in the BI WebLogic managed server then once the managed server is started then Essbase should also be started, the managed server can also be controlled by the WebLogic node manager.
Alternatively if you only wanted to start/stop the Essbase then this could be done from the WebLogic console.
This could also be done using WLST using startApplication('ESSBASE') and stopApplication('ESSBASE')
As I mentioned earlier EAS has been removed from OBIEE 12c though technically you can still use EAS in an EPM environment to connect to Essbase 12c, no doubt doing this is not supported and you will encounter the following error if you try to implement any changes.
Error: 1051734 Operation not supported, authentication is managed by Fusion Middleware in this version of Essbase
Luckily there is still Maxl and even ESSCMD still lives on in 12c, both can be accessed from:
Connecting to essbase can still be achieved in the same way as previously in Maxl.
The documentation recommends going through the discovery URL which is a similar to the method currently available in EPM via APS.
Moving on to the next big change in 12c and one I am sure many will welcome is the security file finally being moved into the RDBMS.
The security file has always been troublesome and I have lost count the number of the times I have seen it being corrupted and having to resort to backup.
From Essbase 11.1.2 some of the elements from the security file like users and groups moved into the Shared Services database but unfortunately not all.
The documentation I feel is being a bit biased to Oracle database in its description.
“The Essbase RDBMS schema is the Oracle relational database that stores Essbase application and database metadata”
As the agent and server are now using different technologies then so are the methods of connecting to the RDBMS schema.
“The Agent connects to the Essbase RDBMS schema using EclipseLink, an open source mapping and persistence framework. The Essbase Server connects to the Essbase RDBMS schema using ODBC DataDirect drivers.”
The following set of tables form part of the Essbase RDBMS schema
Many of the table names are easy to relate to and it doesn’t take long to understand how are they are being populated, a few of the tables are still a bit of mystery to me at the moment.
Let us take a couple of examples and to start with create a new substitution variable.
You will not be surprised to realise the information is then stored in the table ESSBASE_SUBSTITUTION_VARIABLE, depending on the scope of the variable you may need to also bring in the ESSBASE_APPLICATION and ESSBASE_DATABASE tables if you want to view meaningful information.
Now for another example by creating a new filter.
Once again not difficult to figure out the driving tables this time are ESSBASE_FILTER and ESSBASE_ROW
A simple SQL query can return the filter information from the database.
Moving the contents into the RDBMS certainly opens up more possibilities around querying information than was previously available when it was held in the security file.
I am sure some of you are thinking that now it should be possible to directly populate the tables instead of using Maxl or an API, the problem there is that the data is cached in memory and if changes are made to the tables these will not be seen as active until restarting or the cache is somehow refreshed. It makes sense that it is held in memory as in theory it should provide faster access and less activity against the database.
I was going to cover the changes to clustering Essbase now that OPMN no longer exists but I think I will leave it for today and will cover it in the next part.
It is worth stressing that this Essbase for BI and not EPM, they are currently different code lines and by the time EPM 12c is released which could be 2017, Essbase 12c may have gone through many more changes.
Though what this release for BI does provide is a glimpse into a couple of big changes to the architecture behind Essbase, the two standout ones are:
- The Essbase C agent is now replaced by a java agent.
- The Essbase security file is no more and finally moves into the RDBMS
I am going to try and cover these in a little more detail but as Essbase is not standalone and bundled with OBIEE then there are a few restrictions.
When you carry out a default install of OBIEE 12c the EPM/Essbase components are automatically installed.
At the point of configuration there is an option whether to include the Essbase components
The EPM components are all deployed into the same WebLogic managed server as OBI and these include
Essbase Agent.
- Cube Deployment Services.
- Workspace (EPM application with limited functionality).
- Calculation Manager (EPM application also known as Allocations Manager).
- Hyperion Provider Services (APS).
It doesn’t look like it is currently possible to deploy the Essbase web application to its own managed server which is a bit of pain and also I am not a fan of trying to deploy too bunch into one managed server, this is similar in the EPM world to deploying web applications to a single managed server which I usually steer away from for a number of reasons.
There is an interesting statement in the documentation “Essbase Java Agent offers improved concurrency and networking capabilities over the classic C Agent”
Does this also mean the Java agent is going to offer more stability and less likely to freeze? Until it is possible to deploy Essbase to its own managed server away from the other BI components then I feel there are too many factors involved to be able to prove this.
Once OBI has been configured and you take a look at the deployments within the WebLogic admin console you will see the Essbase web application.
If you are wondering CDS stands for Cube Deployment Services which forms the Essbase Business Intelligence Wizard, this is a web based tool for building Essbase cubes.
It gives the feel of a very simplistic version of Essbase Studio and provides functionality to deploy ASO cubes from BI models within an RPD.
In OBIEE 11g it included EAS and Studio but these have now been dropped and replaced with CDS, if you are from the EPM world then I doubt you will be too impressed with this functionality but I suppose if you are looking to build straight up aggregation ASO cubes this simplifies the process.
I am not going to go into any more detail on CDS as maybe that is for another day or I am sure it will be covered by others.
Anyway back to Essbase, once the BI managed server has been started the Essbase Java Agent should be up and running.
One of the many reasons why the Essbase C agent has been replaced the Java agent is that in 12c there is no longer OPMN and the WebLogic framework pretty much runs the show.
I have never really believed in Essbase and OPMN unless you are clustering on a *nix system, ok you can get OPMN to restart Essbase if it crashes but the amount of drawbacks outweigh any benefit, it would have been nice to be given the option to deploy or not.
It is all change in 12c and we will have to see if the WebLogic framework handles it any better.
No longer will you see an Essbase process running and you will only the java process which is running all the deployments in the WebLogic managed server.
If you start an Essbase application then you will notice that not everything has moved to Java and C is still being used for the Essbase Server process, I suspect the long term goal would be for the server to also move to Java.
The essbase.log has is engraved into anybody that uses Essbase, in version 11 there was also the ODL version which made it confusing as there were now two Essbase logs, in 12c the essbase.log has gone and moved into the logs directory of the managed server.
jagent.log is the replacement.
The contents of the log are very different to what you have been used to with old Essbase log.
To verify the agent is up and running you should be looking for:
Oracle Essbase Jagent 12.2.1.0.000.150 started on 9799 at Fri Oct 31 00:45:47 GMT 2015
OBI 12c uses a range of ports starting at 9500 by default and the Essbase agent is assigned 9799, though saying that the Essbase server range still starts at 32768.
What is a bit concerning is the log seems to be full of a repetitive error:
exception.during.capi.request[[java.lang.NoClassDefFoundError: Could not initialize class oracle.epm.jagent.logging.LoggerHelper
This type of error usually means that a class is not contained in the java classpath but the class in the error message is definitely in the path, it is a bit annoying as it could be important messages that are not being logged, I am going to put it down to being at the moment.
You can also check the status of Essbase in the WebLogic admin console or using WLST.
As Essbase is running as a web application a page should be returned for the agent over http(s)
Though technically speaking it is possible that the web application could be up and running but there is an issue with the agent which is preventing it from starting.
The application logs are a couple of directories below the jagent log
As the Essbase server has not changed you still have the old style log and the ODL log so much for progression :)
Some of the Essbase components are still installed under a products folder similar to the current EPM structure.
The Essbase ARBORPATH and location of the Essbase applications by default is
As the Essbase Server (ESSSVR) has not changed there are no shocks around how the applications operate and store metadata/data.
The essbase configuration file (cfg) has not gone away but I suppose you were thinking that it was going to be in the above bin directory, don’t be silly you are used to that so it is time for a change :)
All the BI configuration files are situated under the fmvconfig directory and this is where the essbase.cfg sits, remember this is Essbase for BI and it doesn’t mean it will apply to EPM though I suspect it might.
The cfg file is relatively the same with the noticeable addition of the JAGENT_ID
PRIMODIAL_AGENT_ID just rolls off the tongue :)
There is a long list of cfg settings that are no longer relevant in 12c and these can be found in the documentation.
In Essbase for BI security is not controlled by Shared Services and falls into Enterprise manager using Oracle Platform Security Services (OPSS) so that is why OPSS is set as the authentication module, I am not going to go into as it is hideous and you can read all about it here
So how about starting and stopping Essbase.
As Essbase is deployed in the BI WebLogic managed server then once the managed server is started then Essbase should also be started, the managed server can also be controlled by the WebLogic node manager.
Alternatively if you only wanted to start/stop the Essbase then this could be done from the WebLogic console.
This could also be done using WLST using startApplication('ESSBASE') and stopApplication('ESSBASE')
As I mentioned earlier EAS has been removed from OBIEE 12c though technically you can still use EAS in an EPM environment to connect to Essbase 12c, no doubt doing this is not supported and you will encounter the following error if you try to implement any changes.
Error: 1051734 Operation not supported, authentication is managed by Fusion Middleware in this version of Essbase
Luckily there is still Maxl and even ESSCMD still lives on in 12c, both can be accessed from:
Connecting to essbase can still be achieved in the same way as previously in Maxl.
The documentation recommends going through the discovery URL which is a similar to the method currently available in EPM via APS.
This method of connecting becomes more relevant when using Essbase clustering as it will determine the active agent node and then connect to it.
Not all the same functionality is available in 12c due to the changes and these are covered in the documentation.
It is definitely not possible to shut down Essbase using Maxl.
Moving on to the next big change in 12c and one I am sure many will welcome is the security file finally being moved into the RDBMS.
The security file has always been troublesome and I have lost count the number of the times I have seen it being corrupted and having to resort to backup.
From Essbase 11.1.2 some of the elements from the security file like users and groups moved into the Shared Services database but unfortunately not all.
The documentation I feel is being a bit biased to Oracle database in its description.
“The Essbase RDBMS schema is the Oracle relational database that stores Essbase application and database metadata”
As the agent and server are now using different technologies then so are the methods of connecting to the RDBMS schema.
“The Agent connects to the Essbase RDBMS schema using EclipseLink, an open source mapping and persistence framework. The Essbase Server connects to the Essbase RDBMS schema using ODBC DataDirect drivers.”
The following set of tables form part of the Essbase RDBMS schema
Many of the table names are easy to relate to and it doesn’t take long to understand how are they are being populated, a few of the tables are still a bit of mystery to me at the moment.
Let us take a couple of examples and to start with create a new substitution variable.
You will not be surprised to realise the information is then stored in the table ESSBASE_SUBSTITUTION_VARIABLE, depending on the scope of the variable you may need to also bring in the ESSBASE_APPLICATION and ESSBASE_DATABASE tables if you want to view meaningful information.
Now for another example by creating a new filter.
Once again not difficult to figure out the driving tables this time are ESSBASE_FILTER and ESSBASE_ROW
A simple SQL query can return the filter information from the database.
Moving the contents into the RDBMS certainly opens up more possibilities around querying information than was previously available when it was held in the security file.
I am sure some of you are thinking that now it should be possible to directly populate the tables instead of using Maxl or an API, the problem there is that the data is cached in memory and if changes are made to the tables these will not be seen as active until restarting or the cache is somehow refreshed. It makes sense that it is held in memory as in theory it should provide faster access and less activity against the database.
I was going to cover the changes to clustering Essbase now that OPMN no longer exists but I think I will leave it for today and will cover it in the next part.
Interesting info John..thanks for sharing..
ReplyDeleteVery Useful info, thanks for sharing john... Ur always rocking as usual....
ReplyDeleteThank you so much for posting wonderful post . I always enjoy readying your post . If possible can you hint how peoplesoft and hyperion can be integrated ... Thank you from heart for your great work .
ReplyDeleteAs Always Thank you for a wonderful post.
ReplyDeleteQuick Question - How to access Cube Deployment Services?
Hi John,
ReplyDeleteaccording to the Oracle documentation, CDS is not supported yet.
http://docs.oracle.com/cd/E66975_01/doc.1221/readme/essbase_122120_readme.html
Can you please help to clear up some of the confusion.
Hi, it was originally supported in the first release of Essbase 12c for BI, support was removed from 12.2.1.1.0
ReplyDelete