Hyperion & stuff

Stuff about Hyperion and stuff

Category Archives: EPMA

An Exception occurred during Application deployment.: Unable to load the following resource: %RESOURCE_NAME%

EPMA never ceases to amaze me.

The other day, I was getting this error when trying to deploy a Planning app

Detail : An Exception occurred during Application deployment.: Unable to load the following resource: %RESOURCE_NAME%com.hyperion.planning.olap.HspVerifyOutlineException: Verify Outline failed with the following errors:
Error [1200497] detected in member formula for member “ABCDEFG”.

After a few hours of troubleshooting, I noticed that this member “ABCDEFG” is enabled on both Plan1 and Workforce plan types but has HSP_NOLINK attached to it.  Since Plan1 and Workforce have different dimensionality, the member formula returned with an error on the other plan type.  The weird thing is deployment was working earlier that day.

After tracing back my steps, I remember that I reordered some alternate hierarchies in which the shared members were found before the primaries.  This didn’t cause any error, only warning messages when deploying.  So I tried changing the order back and redeployed.  Guess what?  It worked.  Apparently, this warning stopped EPMA / Planning from erroring out on the member formula.

Apparently in EPMA two wrongs make is right.

Advertisements

Dimension does not contain any member or hierarchy items

When using interface tables to update EPMA (version 11.1.1.3) dimensions, I sometimes got the “Dimension does not contain any member or hierarchy items” warning.  A quick way to remedy this issue is to recreate the interface tables using the EPM System Configurator.

Select Hyperion Foundation -> Performance Management Architect -> Interface Datasource Configuration -> Edit an Existing Datasource Link.  Make sure Create Interface Tables is checked to recreate all the tables.  Config tool will give a warning that it will wipe out all the interface tables.  This method has worked for me 2 out of 2 times.  Give it a try.

Update: Turns out leaving the Load ID empty when using the UI also fixed the issue.

Moving members in EPMA using interface tables

Another undocumented feature that I learned today from Oracle support is the ability to move primary members in interface tables.  However, this only works in the latest 11.1.1.3_04 patch of EPMA (I think).  Without any changes, I don’t think it’s possible to move a primary member already in EPMA when loading using interface table.  What happens is EPMA will add the member in question to a new parent as a SHARED member.  Annoying isn’t it.

To remedy this, simply add a new column to the HS_XXX_HIERARCHY tables called ISPRIMARY.  The value for this column is ‘Y’ when member is a primary member and ‘N’ when member is a shared member.  Quite a nifty feature when using the interface tables and your dimensional hierarchies keep changing.

In 11.1.2, the ISPRIMARY column comes pre-build in the interface tables.  So no need to do the above.

BTW, I’ve only tested this on moving PRIMARY members and not SHARED members.  I don’t know whether it’s even possible to move SHARED members using this method.

Update: In 11.1.1.3 the workaround above only work if the load profile mode is set to “Replace” in EPMA and will NOT work with “Merge”.

EPMA wrong deployment host

I had a scare recently with yet another EPMA issue.  After a load balancing exercise on the Hyperion servers by distributing the components, suddenly EPMA deployment for Essbase apps wouldn’t work anymore.  It returned with HTTP Error 500, bla bla bla.  Previously I had moved EAS and APS from the box running EPMA to another box.  When trying to deploy an Essbase app manually, I noticed that the EPMA deployment host was somehow pointing to the server running EAS.  After several tries of restarting EPMA, reconfiguring Web Server and restarting EAS, I finally decided to reconfigured the old EAS and Web Server running on the same box as EPMA.  Guess what, it worked.  The EPMA deployment host was now back to the right server.  I didn’t think that EAS would be related to Essbase deployment, but I guess it is.

Deployment pending

EPMA 11.1.1.3

In EPMA, there’s this “awesome” feature that forces failed deployment to wait until time out is reached.  Typically after a failed deployment, EPMA changes the application status to “Deployment pending”.  In this state, the application may not be deployed or deleted which is quite annoying (I think).  Turns out there’s a setting to change this time out value.

  • Look in the configuration file here %APP_SERVER_DEPLOYMENT_DIR%\EPMAWebServer\applications\EPMAWebServer\awb\WEB-INF\conf\AWBConfig.properties.  Change the settings called
  • There’s a setting called DEPLOY_PENDING_TIMEOUT_MINUTES.  The default is 480 minutes (or was it 240).  Change this to a small value, like 10, to expire the deployment.
  • Restart EPMAWebServer web application.
  • Log in to Workspace Application Library and check the status.  The status should change to Deployed.
  • Change the DEPLOY_PENDING_TIMEOUT_MINUTES setting back to normal and restart EPMAWebServer.

Target application does not exist

EPMA 11.1.1.3

Recently, I accidentally removed an EPMA-managed Essbase application directly from EAS console.  This resulted in EPMA showing the “Target application does not exist” for the particular application.  I found out there are two (possibly more?) ways to fix this.

The easy (lucky) way is to recreate the Essbase application directly in EAS.  This is the second time this thing happen to me.  The first time around, I recreated the delete application as an empty application.  It didn’t work, so I had to take the hard way.  This time around, I had a backup that I can restore in EAS.  Maybe EPMA had to make sure that the structure is there, so empty application didn’t work.  Once restored, I managed to remove the application from EPMA.

The hard way is to remove the application from the SQL back-end (avoid).  Mind you that this way is not supported by our good, hardworking friends at Oracle support.  Here’s the SQL (tested this once and seem to work just fine).  Use at your own risk !!!
delete from ds_property_application where I_APPLICATION_ID=(select distinct I_APPLICATION_ID from ds_application where c_application_name = ‘APP_NAME’)
select count(*) from ds_property_dimension where I_APPLICATION_ID=(select distinct I_APPLICATION_ID from ds_application where c_application_name = ‘APP_NAME’)
delete from ds_property_dimension where I_APPLICATION_ID=(select distinct I_APPLICATION_ID from ds_application where c_application_name = ‘APP_NAME’)
delete from ds_property_dimension_ref where I_APPLICATION_ID=(select distinct I_APPLICATION_ID from ds_application where c_application_name = ‘APP_NAME’)
delete from DS_PROPERTY_RELATIONSHIP where I_APPLICATION_ID=(select distinct I_APPLICATION_ID from ds_application where c_application_name = ‘APP_NAME’)
delete from ds_property_application_array where I_APPLICATION_ID=(select distinct I_APPLICATION_ID from ds_application where c_application_name = ‘APP_NAME’)
delete from ds_property_application_ref where I_APPLICATION_ID=(select distinct I_APPLICATION_ID from ds_application where c_application_name = ‘APP_NAME’)
delete from ds_application where I_APPLICATION_ID=(select distinct I_APPLICATION_ID from ds_application where c_application_name = ‘APP_NAME’)
delete from ds_view where I_View_ID=(select distinct I_view_id from ds_application where c_application_name = ‘APP_NAME’)
delete from ds_library where I_library_ID in (select distinct I_library_id from ds_application where c_application_name = ‘APP_NAME’)
delete from or_object where c_object_ID=’1_’ || (select distinct I_APPLICATION_ID from ds_application where c_application_name =
‘APP_NAME’)

Typically, I would do a select before deleting anything to make sure everything is OK.