Cannot Redeploy ASO Application From EPMA, Part I

Failed to deploy Essbase cube.

Caused by: Failed to build Essbase cube dimension: (CCs) .

Caused by: Cannot end stream build. Essbase Error(1007083): Dimension build failed. Error code [1060114]. Check the server log file and the dimension build error file for possible additional info.

Failed to deploy Essbase cube.

Caused by: Failed to build Essbase cube dimension: (CCs) .

Caused by: Cannot end stream build. Essbase Error(1007083): Dimension build failed. Error code [1060114]. Check the server log file and the dimension build error file for possible additional info.

\\Error Adding Dimension AttGroup

\\Error Initializing Rule File Information

If you have ever seen this error, you could be stuck in a loop of trying to fix the dimension that errored out during deploy.  However, the dimension is not the problem!  It’s perfectly fine!

I had this error happen to me yesterday and I had never seen it before.  I went so far as to remove my Attributes dimension and redeploy – but I got the same error, except at the new bottom of the outline.  What gives?

What I eventually learned was that EPMA will only let you update your outline as many times as 255 divided by the number of dimensions you have minus the number of times you have already deployed the outline.

Huh?

Let’s say you have an outline that has 15 dimensions and you have already deployed/updated the outline 8 times.  The number of times you can deploy the application again would be ((255/15)-8), or 9 more times.

Is this a joke by the Oracle EPMA developers?  The verdict is still out.

I tried two options.  One was recommended by Oracle (that does not fix the problem, but is a short, short, short, short-term bandaid solution for what the developers neglected).  The other was not…but seems to trick EPMA in just the perfect way.

The one recommended by Oracle was to use a utility created by Oracle’s Quality Engineering Team to “compress” the ASO database called “ESSCMDQ”.  You can download that utility here.  Also, see my next post on how to use that utility.

The next option was one I tried…and it worked.  Again, it’s not a long-term solution, but it will get you farther than the ESSCMDQ utility will.  

While I was trying to deploy my original cube without luck, I decided to test if it was a problem with the dimensions or a problem with EPMA.  To do this, (1) in EPMA I simply duplicated the application in the Application Library with a new name and then tried to deploy the new app.  It worked!  That told m there was an issue with EPMA and not with the application itself.  Since we have production users on the system and FR reports connected to this application, I desperately needed the application name (and connections) to stay the same.  (2) I made a copy of the application folder on the Essbase server so as to preserve my outline, data, scripts, rules, etc in case I really screwed things up.  (3) Next, I took the new applications .otl file and copied it to the old application’s folder with the old .otl name.  Then I said a prayer.  I was able to load a data extract via a rules file successfully – cleared gate 1.  I then went into Excel and did a sample retrieve in Smart View successfully – cleared gate 2.  (4) Finally, I went into EPMA and tried to redeploy the old application again.  CLEARED GATE 3!  So far, the application has been working perfectly.  …Although I do realize that I am only going to have so much time before I have to do this process again…  Hopefully before that time comes, I will be have a FINAL resolution so bandaids do not have to be reapplied in the future.