(error handling omitted)

IEssbase japi = null;
IEssOlapServer server = null;
IEssCubeOutline outline = null;

japi = IEssbase.Home.create(IEssbase.JAPI_VERSION);
IEssDomain domain = japi.signOn(username, password, false, null, "embedded");

server = domain.getOlapServer(serverName);
server.connect();

outline = server.getApplication(appName).getCube(dbName).openOutline();

outline.close();
server.disconnect();


Every time this code is run, a temporary file is created on my Essbase 11 server in the temp folder (C:\Users\xxxxxxx\AppData\Local\Temp\2) called

hy$$$$$$.otl

where $$$$$$ varies from cube to cube and increments with every call.

My IEssbase.JAPI_VERSION reports 11.1.2 and it dumps Hyperion Provider Services - Release 11.1.2.1.00.353 in to the console at startup.

Testing now to see if they are cleared on a restart, but does anyone know if this is just a new maintenance feature of Essbase 11 or a bug of some kind (perhaps in my code)?

Hi Zoltan,

I checked my temp directories and there were some temp otl files there, but there were from a few weeks ago. I then cleared them, ran Dodeca, and then opened a template that used an Essbase cube that did not have caching enabled (forcing an IEssCubeOutline to be used). There was not a temp otl file in the directory.

I don't know for sure, but my thought is that the tmp otl files are opened on the APS server machines (or locally if running embedded mode) and are discarded when IEssCubeOutline.close() is called. If, however, I was stepping code and just stopped it in the middle of execution, as I often do *when I am stepping code*, that perhaps .close() was never called.

Obviously, I would make sure the .close() method is in the finally block so that it gets executed even if an EssException is raised (and, of course, test the IEssCubeOutline object to make sure it isn't null before calling .close()).. (Zoltan: I assume you were doing this already; these last comments are aimed at users who may find this thread while researching similar issues.)

Tim

Tim Tow
Oracle ACE Director
Applied OLAP, Inc

Ya, closing was the first statement my finally block and it seems to produce the intended results.

if (outline != null) {
try { outline.close(); out.println("<p>outline closed</p>"); } catch (Exception ignored) { out.println("<p>1"+ignored.getMessage()+"</p>"); }
}

Odd, I'll have to play around more.

Apparently whatever is happening is only triggered in Essbase 11 as our Essbase 9 server doesn't have any temp OTLs lying around.

[Wed Jun 13 11:50:04 2012]Local/XXXXXXXX///7288/Info(1013210)
User [zgrose@Native Directory] set active on database [Capital]

[Wed Jun 13 11:50:04 2012]Local/XXXXXXXXX/Capital/zgrose@Native Directory/6888/Info(1013091)
Received Command [OpenOutlineEdit] from user [zgrose@Native Directory]

[Wed Jun 13 11:50:05 2012]Local/XXXXXXXXX/Capital/zgrose@Native Directory/852/Info(1013091)
Received Command [CloseOutlineEdit] from user [zgrose@Native Directory]

[Wed Jun 13 11:50:05 2012]Local/XXXXXXXXX///8016/Info(1013214)
Clear Active on User [zgrose@Native Directory] Instance [1]

The Edit in OpenOutlineEdit is interesting...

OK, something is not right here (and it could certainly be me).

Cannot open cube outline. Essbase Error(1022002): User [zgrose] Does Not Have Correct Access for Command [OpenOutlineEdit]

That is the result of:

server.getApplication("Sample").getCube("Basic").openOutline();

In 9.3.1 with a user set to Read access to Sample/Basic the above code is fine.
In 11.1.2 (just downloaded) with a user set to Read, the error is thrown.

Already have a SR open but anyone have any additional insight?

11:

[Fri Oct 05 13:12:55 2012]Local/Sample///5872/Info(1042059)
Connected from [::ffff:10.173.8.183]

[Fri Oct 05 13:12:55 2012]Local/Sample/Basic/zgrose/5872/Info(1013091)
Received Command [OpenOutlineEdit] from user [zgrose]

[Fri Oct 05 13:12:55 2012]Local/Sample/Basic/zgrose/5872/Error(1022002)
User [zgrose] Does Not Have Correct Access for Command [OpenOutlineEdit]


9:

[Fri Oct 05 13:26:38 2012]Local/Sample///Info(1013210)
User [zgrose] set active on database [Basic]

[Fri Oct 05 13:26:38 2012]Local/Sample/Basic/zgrose/Info(1013091)
Received Command [OpenOutlineEdit] from user [zgrose]

[Fri Oct 05 13:26:38 2012]Local/Sample/Basic/zgrose/Info(1013091)
Received Command [CloseOutlineEdit] from user [zgrose]

[Fri Oct 05 13:26:38 2012]Local/Sample///Info(1013214)
Clear Active on User [zgrose] Instance [1]

I believe they changed the requirement for opening an outline in 11.1.2.1 (I *think* it was that version; our QA guys know for sure).. It now requires database designer privilege. We believe it may also have been carried into 11.1.1.4.

I would look at the readme's for the different versions to see if they talk about a change; I am at the airport and have low bandwidth, so I can't download prior versions..

Tim

Tim Tow
Oracle ACE Director
Applied OLAP, Inc

Well that would be a very unfortunate change. Probably explains all the OTL spamming too.

Agree that it is a change/fix/feature sadly. We just discovered this same behavior a couple of weeks ago and had to flip to a system id to read the outline and then flip back to the user id within a VB app. Not what we wanted to do but it was better than giving all the users designer access through their group.

Looks like service accounts are the long term way to go then. That way one can flip from privileged <->unprivileged access relatively easily in .signOn()


FWIW, it appears that

IEssIterator iter = server.getApplication("sample").getCube("Basic").getDimensions();

works for my main requirement of listing the dimensions. Looks to call GetDimInfo instead of OpenOutlineEdit.


[Fri Oct 05 15:03:59 2012]Local/Sample///6004/Info(1042059)
Connected from [::ffff:10.173.8.183]

[Fri Oct 05 15:03:59 2012]Local/Sample/Basic/zgrose/6004/Info(1013091)
Received Command [GetDimInfo] from user [zgrose]

[Fri Oct 05 15:03:59 2012]Local/Sample///2072/Info(1013214)
Clear Active on User [zgrose] Instance [1]