EPMA Implementation Advanced Tips n Tricks POV Document

download EPMA Implementation Advanced Tips n Tricks POV Document

of 27

description

EPMA Implementation Advanced Tips n Tricks POV Document

Transcript of EPMA Implementation Advanced Tips n Tricks POV Document

EPM SYSTEM 11.1.2.1EPMA ImplementationAdvancedTips & Tricks Point of ViewDocument

O R A C L E H Y P E R I O N E N T E R P R I S E P E R F O RMA N C EMA N A G EME N T A R C H I T E C T

ContentsAuthors: Anshuman Ghose; [email protected] Joy; [email protected]

Review History3Introduction41.1.Different Application Types51.1.1.Workforce Planning5Workforce Initialization5Workforce Customization131.1.2.CAPEX Planning14CAPEX Initialization14CAPEX Customization181.1.3.EPMA based ASO & BSO191.2.Commonly faced EPMA cases211.3.Security28

Review History

Reviewed ByReview DateChanges Proposed

Channanavettil, Prajeev Kanno (US - Bengaluru) 4/4/13This document definitely addresses some of the unique errors that we see while working with EPMA.Change it as POV document instead of calling it as a Whitepaper, since its mostly your views of addressing the issues you have encountered. There might also be a better way of handling the same issues listed by you.

Introduction

The following document serves as a whitepaper for advanced level EPMA developer to understand & troubleshoot using the key tips/tricks while implementing Oracle Hyperion EPMA Version 11.1.2.1 with Hyperion Planning.

The EPMA Application Library enables us to create Application of the following types:a. Planningb. Essbase (ASO and BSO)c. Consolidationd. Profitability

This document discusses the various issues encountered during some full phase EPMA implementations of Planning and Essbase (ASO and BSO) application types, and suggests tips to troubleshoot those issues or cases. This will also highlight some key artifacts list whose presence or absence can impact the EPMA implementation with different modules of Planning i.e. Workforce & CAPEX and different type of Essbase applications i.e. ASO & BSO. The resolutions in addition to the best practices are covered with respective screenshots in the sections for better user understanding.

1.1. Different Application Types1.1.1. Workforce Planning

Workforce Initialization

Initialization Error:Failed to enable workforce during initialization. Please see log for details [Jan 9, 2013 1:30:25 PM]: Content is not allowed in prolog.

Resolution Approach:Before starting the customization, ensure that during app creation the Workforce plan type was not renamed to anything except Wrkforce, else itll throw above mentioned error during final deployment.

Key Observation: This is not an issue if Workforce is initialized with the creation of the app in which case, plan type can be renamed to anything.

Error while deploying an application for the first time:Error: Internal Server Error

Resolution Approach:It is most likely due to some involved component not responding for a long time.

Key Observation: In one case it was due to an app with the same name already existed in Essbase, so deleting it solved the case.

Calc Manager related issue faced during initial stage of deployment : Error: Required application module calcmgr.filterview is not configured

Resolution Approach:In order to resolve this error, re-configuration with EPMA may need to ensure configuration with EPMA has happened properly (even if its already configured), Else it might not work properly and might give the above mentioned error.

Calc Manager Error: An error occurred while trying to deploy to the server, host parameter is null. We got this error while trying to deploy a rule, but when we tried deploying the app from CalcManager, it was going fine.

While validating the rule, it was not able to build a connection with the app and was error ring out stating: The rule could not be validated against the deployed application, because connection information could not be found.

Resolution Approaches and Success Status: Initially we tried checking provisions for the user & restarting the services, but they didnt pan out. Guided by the tips from a forum (http://www.orahyplabs.com/2011_03_01_archive.html), we then looked into an EPMA table called OR_OBJECT and found the anomaly. There were 2 records of with same application name in object_data field but with different object IDs. We suspected one of the records to have not got deleted properly when the app was deleted previously. After checking for valid application IDs in table DS_Application, we manually removed the extra record and restarted services. All communications problems were resolved and the rules started validating & deploying properly.

Below Screenshots shows the EPMA messages/warnings during Workforce Initialization final stage:

NOTE: The above shown errors/warnings can be ignored in the initialization process.

Workforce Initialization will always lead to the addition of new inbuilt artifacts: Members, Web Forms, Smart Lists, Menus, and Business Rules.

The below shown highlighted portions of screenshots are the newly introduced inbuilt workforce elements i.e. Dimension Members and Smart Lists, these get introduced before deployment.

The following new members are added to existing Dimensions:

Following new Smart List dimensions come up local to the application

There might be some errors due to the existing Source Plan Type mapping:

Resolution Approach:Change that property at Shared Library to the new Plan Type created by the Initialize process & re-deploy.

As shown in the above screen shot, correct the highlighted properties and re-deploy the application:

Workforce Initialization will always lead to the addition of new inbuilt artifacts: Members, Web Forms, Smart Lists, Menus, and Business Rules.

The below shown highlighted portions of screenshots are the newly introduced inbuilt workforce elements i.e. Web Forms, Menus, and Business Rules, these get introduced after successful deployment.

The following Webforms are added :

The following Menus are added :

The following Business Rules are added :

Workforce Customization

Before customization, it is always advisable to clean up all the out of box elements in order to avoid any kind of unwarranted conflicts during deployment and full phase implementation. The alias of the standard planning dimensions needs to be checked and reverted before deploying the Planning app. The initialization process overwrites any different alias with the standard names for Planning (Account, Period, Employee, Scenario, Version and Year). The entire Workforce inbuilt package elements or artifacts are mentioned in the above portion of this document, so while performing cleanup activities kindly refer them and clean. Then re-deploy the application to start with customization of Workforce plan type.

1.1.2. CAPEX PlanningCAPEX Initialization Initialization Error:Failed to enable CAPEX during initialization. Please see log for details [Jan 9, 2013 1:30:25 PM]: Content is not allowed in prolog.

Resolution Approach:Capex is very similar to Workforce in terms of the Initialization process. Except for the restriction of name in the current product version, the process is smooth enough. Any other name cannot be given to the 5th Plan Type than Capex.

CAPEX Initialization will always lead to the addition of new inbuilt artifacts: Members, Web Forms, Smart Lists, Menus, and Business Rules.

The below shown highlighted portions of screenshots are the newly introduced inbuilt workforce elements i.e. Dimension Members and Smartlists, these get introduced before deployment.

The following new members are added to existing Dimensions and new Smartlists are also added:

CAPEX Initialization will always lead to the addition of new inbuilt artifacts: Members, Webforms, Smartlists, Menus, and Business Rules.

The below shown highlighted portions of screenshots are the newly introduced inbuilt workforce elements i.e. Webforms, Menus, and Business Rules, these get introduced after successful deployment.

The following Web Forms are added :

The following Menus are added :

The following Business Rules are added :

CAPEX Customization

Before customization, it is always advisable to clean up all the out of box elements in order to avoid any kind of unwarranted conflicts during deployment and full phase implementation. The alias of the standard planning dimensions needs to be checked and reverted before deploying the Planning app. The initialization process overwrites any different alias with the standard names for Planning (Account, Period, Entity, Scenario, Version and Year). All the CAPEX inbuilt package elements or artifacts are mentioned in the above portion of this document, so while performing cleanup activities kindly refer them and clean. Then re-deploy the application to start with customization of CAPEX plan type.

1.1.3. EPMA based ASO & BSO

ASO storage property issue:

Based on project experiences, the cases generally appear for the dimensions Account and Period - While aligning business requirement with technical solution, most of the times the requirement comes up as to make storage property of Account or Period as DynamicCalc. BSO supports this requirement fairly, but for ASO its a challenge.

Key Note: DTS is not supported by ASO. Also, DynamicCalc storage property is not supported for dynamic hierarchy dimensions namely Account & Period.

Resolution Approach: As a workaround, create two new dimensions (Local or Shared) as a copy of the prior but storage types as Store/Shared/NeverShare to handle the storage property issue.

ASO attribute association issue:

Key Observation: For version 11.1.2.1, attribute association for an ASO app does not transition to Essbase from EPMA after deployment. It randomly creates associations only for certain generation members and ignores the rest of Level0.

Resolution Approach: The workaround is to re-load associations via rule file to ASO cube again after EPMA deployment.

Key Note: This has been confirmed by an Oracle SR (SR 3-6556501501). This issue is said to be resolved in next version i.e.11.1.2.2.

BSO cube limitation:

Key Observation/Note: EPMA enabled BSO cubes can be done only on a one app to one cube basis. One Essbase app cannot have more than one cube as one EPMA based app.

BSO/ASO app deletion issue:

Key Observation/Note: Deleting an ASO/BSO EPMA app does not delete the same at Essbase. So while deploying a new EPMA app for the first time, ensure you don't have an app with same name in Essbase already from a prior creation.

ASO dimension deletion limitation:

Error: "1060190 cannot Add Dimension - too many dimensions have been created and deleted".

Key Observation: The maximum number of dimensions allowed in an ASO outline is 255 (add and delete). Each dimension added is tagged with a dimension ID that increments with each op. When a dimension is deleted, the ID is not deleted. Using Studio, EIS or EPMA to add and delete dimensions (just to reload changes easily by deleting the whole dimension), the 255 limit may reach and then trouble will start hitting the system with an above mentioned sample error.

Resolution Approach:As a work-around, one solution is to create a "dummy" model. Using Studio, create an application from the same Essbase Model as your regular app but instead of deleting members first, select to delete and restore database. This will give you a fresh copy of the outline. Then stop your application and copy the outline from your dummy cube over the desired environment. Since it was built from the same model, it can be assume that the dimensionality and members are the same. Starting the app should activate the new outline and should be set to go.

***Note: A couple of things to keep in mind i.e. there is no MaxL function to copy the outline, so it can be done through the file system in batch file using copy commands. As a safety precaution, always backup the original outline and data prior to doing this. Two particular areas to check out are Security and drill-through reports (in addition to data integrity)

A second solution would be to export the data, delete and rebuild the outline then import the data.

ASO dimension addition limitation:

Key Observation/Note: Similar to deletion, the ASO cube has a limitation of 255 maximum no of dimensions as well (oracle support doc 1323833.1). To handle this, make a copy of the Essbase application (not EPMA), delete the original one and rename the copied application to the original application.

BSO/ASO Shared Library registration issue:

Key Observation: Sometimes the ASO/BSO EPMA app does not show up at Shared Services & the re-register option at EPMA is also disabled.

Resolution Approach: First, create an application shell via EAS. Right click and select Register. This will ensure its registration with Shared Services. After this operation you can now go and create an app by same name and any database name at EPMA and deploy. Once deployed the Reregister option gets enabled at EPMA.

1.2. Commonly faced EPMA cases

Creating duplicate app from customized module apps:

Key Observation:Creating duplicate app of existing app is always a time saving activity for any implementation, but this feature fails while doing the same save as activity for customized application like Workforce or Capex (apps where we have initialized to add more plan type and then cleaned up/deleted all the out of box elements to use it as per business requirement rather than using its in-built module package elements)

Error Sample log/message shows as below:[Jan 11, 2013 3:58:57 PM]: Parsing Application Properties...Done[Jan 11, 2013 3:58:57 PM]: Parsing Dimensions info...Done[Jan 11, 2013 3:58:57 PM]: Creating Application FinPlan2...Done[Jan 11, 2013 3:59:30 PM]: Registering the application to shared services...Done[Jan 11, 2013 3:59:31 PM]: Initializing Workforce Model...Done[Jan 11, 2013 4:00:31 PM]: Checking for rates properties...Done[Jan 11, 2013 4:00:31 PM]: Loading Smart Lists...Done[Jan 11, 2013 4:00:31 PM]: Loading Alias Tables...Done[Jan 11, 2013 4:00:31 PM]: Updating the default user preferences...Done[Jan 11, 2013 4:00:31 PM]: Loading Dimensions...Done[Jan 11, 2013 4:00:31 PM]: Loading Attribute Dimensions...Done[Jan 11, 2013 4:00:31 PM]: Loading Attribute Members...Done[Jan 11, 2013 4:00:33 PM]: Loading members for dimension Entity...Done[Jan 11, 2013 4:00:33 PM]: Loading members for dimension Version...Done[Jan 11, 2013 4:00:33 PM]: Loading members for dimension Account...Done[Jan 11, 2013 4:00:35 PM]: Loading members for dimension Year...Done[Jan 11, 2013 4:00:35 PM]: Loading members for dimension Period...Done[Jan 11, 2013 4:00:36 PM]: Loading members for dimension Employee...Done[Jan 11, 2013 4:00:49 PM]: Loading Scenario Members...Done[Jan 11, 2013 4:00:50 PM]: Loading Base Currency Members...Done[Jan 11, 2013 4:00:50 PM]: Loading Workforce Model Data Forms...[Jan 11, 2013 4:00:50 PM]: The data form failed to import. Please see log for details. The member Annual Salary does not exist or you do not have access to it.[Jan 11, 2013 4:00:53 PM]: An Exception occurred during Application deployment: The data form failed to import. Please see log for details.

Resolution Approach: In this type of cases, you need to create the application from scratch with initialization and for customization out of box elements clean up activity needs to be taken up again.Then deploy and start working on it as desired by sharing/importing artifacts.

Formula sync to Shared Lib from application:

Sometimes we need to update dimensions on trial basis before moving changes to Shared Library. So we detach that dimension on the application & make following changes.

Key Note: Any change to a shared dimension gets lost when the dimension is detached.

Key Observation: The member formula changes shared using Merge As Shared option is not advisable, as they dont reflect at Shared Library.

Resolution Approach:1. The member formula changes shared using Replace option works though that results in Shared Library outline totally replaced with the app one.2. The other way is to use Synchronize To Shared Library option & then share it (using Share Dimension Merge as Shared option) which gives the desired result without any hiccups.

Implementation scenario illustration for Key Observation:Let us consider 3 different size/length of member formulas to validate the key observation regarding the member formula synch to shared lib from application

Step 1: Member formulas are written of different length.

Member with long sized formula.

Member with medium sized formula.

Member with small sized formula.

Step 2: Now let us use Share Dimension option to sync & bring the dimension back to shared mode while retaining the updates on both sides:

Step 3: Using Merge As Shared option, sharing is done.

Key Observation: All member based changes get reflected in Shared Library but none of the formulae get updated.

Member with long sized formula

Member with medium sized formula

Member with small sized formula

Step 4: Now, using Replace option, sharing is done.

Key Observation: All member based changes as well as formulae get reflected in Shared Library.

Member with long sized formula

Member with medium sized formula

Member with small sized formula

Implicit Share Issue:

Key Observation: Implied Share property proves a pain many a times while designing Web Forms/SV grids as they just dont save values when an entry is made on Child (in case of Bottom Up Version) or Parent (in case of Standard Target Version).

Resolution Approach: The simplest way of tackling this is to change the order of members appearing on row to first Parent then Child as opposed to Child then Parent (as it comes in relative based member selection during form build). The concept here is that Essbase always tries to capture the last existing line item value for any member (like cases when it saves only the last existing line item value if we repeat members by mistake on rows and ignore all preceding ones). Here due to Implied Share property, it recognizes both members as same (in terms of memory allocation) and takes the last existing line item value which happens to be #Missing from Parent line item. So, after we change the order here is the result:

1.3. Security

Deployment option is disabled for ASO/BSO:

Key Observation: Before starting any new ASO/BSO app deployment, make sure the user has Application Manager role for the app at Shared Services.

Essbase objects are non-editable:

Key Observation: User will be able to edit Substitution Variables and execute Calculations for that BSO/ASO app for which he/she has access to. Server Access is required to access any Planning cube at Essbase.

Shared Services role limitation:

Key Observations: 1. Provisioning Manager role in Shared Services provides both view/modify options to the user. Hence exclusively only view option cannot be given in the current product version.2. Dimension Editor role for EPMA provides both view/modify options at Dimension Library to the user. Only read access cannot be given in the current product version.

Application Library access limitation:

Key Observation: Any EPMA user will have a default view access at Application Library. This cannot be restricted. However, that user will not be able to deploy/edit any application.

Planning users access:

Key Observation: Any Planning user will have default none & read filter based access to Plan Type cubes. Write access is driven by Essbase Write Access & corresponding Write filter set for the user.