FDMEE: System Maintenance Tasks: Maintain EBS GL Balances Table

Topic: How to manually run FDMEE System Maintenance Tasks: Maintain EBS GL Balances Table

Hi Friends,

This is the fifth post under Oracle Hyperion Financial Data Quality Management (FDMEE): System Maintenance Tasks blog series where we are going to cover the Maintain EBS GL Balances Table script.

If you have not yet read the previous four posts of this blog series, I would suggest you to go through them on below links to get a comprehensive picture of Oracle Hyperion Financial Data Quality Management (FDMEE) System Maintenance Tasks:

FDMEE: System Maintenance Tasks: Maintain FDMEE Data Tables
FDMEE: System Maintenance Tasks: Maintain ODI Session Data

FDMEE: System Maintenance Tasks: Maintain Application Folder

FDMEE: System Maintenance Tasks: Maintain Process Tables  

In this fifth post, we will focus on the ‘Maintain EBS GL Balances Table’ task and will see how to manually execute ‘Maintain EBS GL Balances Table’ purge script.  

Important Note:

• This post has been written and associated activities have been demonstrated on Oracle Hyperion Financial Data Quality Management (FDMEE) version 11.1.2.4.210.
• The demonstrating Hyperion environment has Oracle database server 12.2.0.2 (18c) as backend database.
• There is no outage required on the Oracle Hyperion Financial Data Quality Management (FDMEE) application to execute these purge scripts. But it is advisable not to run any data loads during the purge activity.
• Based on the data retention policy of your organization, you should pre-decide how many days of data you want to retain for Oracle Hyperion Financial Data Quality Management (FDMEE) EBS GL Balances Table.
• Don't forget to take complete Oracle Hyperion Financial Data Quality Management (FDMEE) schema backup before attempting to run these purge scripts

Maintain EBS GL Balances Table

FDMEE is the EPM tool for data integration. Using FDMEE, ERP applications like Oracle EBS, PeopleSoft, SAP, etc. can be directly connected to your target Oracle Hyperion applications for data loading.

You would have seen FDMEE integration system having Oracle EBS General Ledger as data source system and HFM or Hyperion Planning as target applications. Data (GL_Balances) is extracted from Oracle EBS source system using ODI (FDMEE), moved to staging tables (AIF_EBS_GL_BALANCES_STG), and then eventually loaded to your target applications after transformation.

‘Maintain EBS GL Balances Table’ purge script maintains the AIF_EBS_GL_BALANCES_STG table in the FDMEE schema. EBS General Ledger balances contain a snapshot of the General Ledger balances and are deleted based on the General Ledger period. ‘Maintain EBS GL Balances Table’ purge process determines the list of General Ledger periods between the start and end periods. 

Following are the input parameters which you need to enter while running ‘Maintain EBS GL Balances Table’ purge script:

• Source System
• Start Period
• End Period

Before proceeding further, with purging steps, I would suggest you to check and note down the pre-purge FDMEE schema size to see how much space has been freed up post purge activity.

Step-by-Step process to execute ‘Maintain EBS GL Balances Tables’ purge script

1- Log in to Workspace with Admin credentials.

2- Open Oracle Hyperion Financial Data Quality Management (FDMEE) console (Data Management) from Workspace and on the Workflow tab, under Other, select Script Execution:

3- In Script Execution, and then in Custom Script Group, select System Maintenance Tasks.

4- From the Scripts grid, select Maintain EBS GL Balances Table script and Click Execute.

5- It will prompt to enter the following parameter values on Execute Script screen.

• Source System
• Start Period
• End Period

6- Click on the search icon for Source System. 

Select any Source System name for which you want to purge data and click OK.

7- Source System will be populated. 

8- Now enter Start Period and End Period. 

For example: If you want to purge all data from Nov-2016 to Oct-2017, then select Start Period and End Period as shown below:

9- Keep Execution mode selected as Online. The online method processes the report immediately.

Execution modes:

online  — ODI processes the data in sync mode (immediate processing).

offline — ODI processes the data in async mode (runs in background).

10- Optionally, If you want to schedule the purge script run rather than running it instantly, click on Schedule option and enter the scheduling details as per your requirement.

11- If you want to instantly run the purge script, then directly click on OK (not on the Schedule option).

You will see a message informing the process ID of your script run as shown below:

12- To see the status of your script execution, click on the Process Details link under the Workflow tab—Monitor—Process Details. 

13- Above we can see our script with Process ID 8184 executed successfully. 

Click on the Show button for Process ID 8184 to open the corresponding log file.

In the log file, look for the message "Maintain EBS GL Table: Completed" to confirm that the script has run successfully without any error. If you encounter any errors, troubleshoot them based on the cause mentioned in the log file. 

You need to repeat all of the above steps for other Source System from where your FDMEE data extractions are running to target Hyperion applications. 

Once you are done with running the Maintain EBS GL Balances Table purge script, you can check your Hyperion Financial Data Quality Management (FDMEE) schema size to see how much space has been cleared.

Here it’s important to note that after running the Maintain EBS GL Balances Table purge script, your DBA needs to do FDMEE tables reorganization activity in order to reclaim freed space. 

Actually, when you delete the data from the Oracle tables, the data blocks will go onto the free list for that table. That free space will be used for the subsequent insert and update operations into the table. You need to perform table reorganization to reclaim that free space.

Note: Reorganization of tables requires outage in your Hyperion environment so you have to stop all your application services prior to the reorganization activity to be performed by your application DBA.

You may also need to ask your DBA team to 'Rebuild Indexes' in your Hyperion Financial Data Quality Management (FDMEE) database after performing the 'Tables Reorganisation' activity.

If you miss rebuilding indexes after tables reorganization activity, your FDMEE data load job may take longer than normal to complete.

Index rebuild becomes absolutely necessary especially when you delete millions of records from FDMEE tables as part of running FDMEE purge scripts because the corresponding indexes of those deleted records go in the unusable state after tables reorganization activity. Due to this bulk deletion of records, indexes become fragmented causing indexes taking more time to give the output and hence delaying your FDMEE data load job.

You will observe the following type of error during your FDMEE data load run if you do not rebuild database indexes after tables reorganization activity:

ORA-01502: index 'FDMEE_ODI.PK_AIF_EBS_GL_BALANCES_STG' or partition of such index is in unusable state.

Once both the DBA tasks (Tables reorganization + Rebuilding Indexes) are completed, compare pre and post purge size of your Hyperion Financial Data Quality Management (FDMEE) schema to see how much has the schema size reduced. 

Maintain EBS GL Balances Table purge script can also be automated to run using Executescript batch file located in the folder: 

<drive>\Oracle\Middleware\user_projects\epmsystem1_fdm\FinancialDataQuality.

We will cover the automation part in a separate post of this blog series. 

That's all for this post.

I hope this article has helped you.
Your suggestions/feedback are most welcome.

Keep learning and Have a great day!!!

Read More

DRM: How to check DRM User creation date

Topic:  How to find out 'Users creation date' in Oracle Data Relationship Management (DRM)

Hi Friends,

Auditing of users is an important part of any Oracle Hyperion Production system. You might have faced a scenario where you need to find out when a particular business user was added or assigned access into your Hyperion applications to cross-check whether there was a corresponding change request or incident number raised for record or not. These are some pertinent questions, which you have to find answers to, during Oracle Hyperion applications auditing.  

In this post, we will explore how to find out when was a new user created/added into your Oracle Data Relationship Management (DRM) system.

Important Note:

• This post has been written and associated activities have been demonstrated on Oracle Data Relationship Management (DRM) version 11.1.2.4.344.
• The demonstrating Hyperion environment has Oracle database server 12.2.0.2 (18c) as backend database. 

When you log in to Oracle Data Relationship Management (DRM) Web Client with DRM Administrator account and navigate to: Administer—Security—Users, you will see your DRM users list as shown below:

A new user is added/created to Oracle Data Relationship Management (DRM) system either directly from DRM Web Client (Administer—Security—Users) or synchronized from Hyperion Shared services when ‘Common User Provisioning’ is enabled in your Oracle DRM system.

Adding/creating a new user in Oracle DRM is a kind of transaction that is recorded in a table name RM_TRANSACTION_HISTORY in DRM_DB relational repository schema.

RM_TRANSACTION_HISTORY table contains a row for each transactional update to your DRM repository (DRM_DB schema).

There is a column name C_ACTION in the table RM_TRANSACTION_HISTORY that records activities/actions like Add User, Add Node, Insert Node, Delete Node, ChangeProp, etc. 

In order to extract Oracle DRM users creation date along with who created that user, perform below steps:

1- Login to your DRM_DB relational repository schema (using SQL developer).

2- Run the below query:

select C_USER_NAME as USER_NAME, C_ACTION as ACTION, C_ACTION_DESCRIPTION as ACTION_DESCRIPTION, D_TIMESTAMP as Date_Time from RM_Transaction_History where C_ACTION = 'Add User' order by Date_Time desc;

3- Your output will be generated as shown below:

Description of the output:

• USER_NAME = The already existing DRM user who has created/added the new user.
• ACTION = Add User activity is performed
• ACTION_DESCRIPTION = User ‘NEW USERNAME’ added
• DATE_TIME = Date and time when the NEW USERNAME was created/added into Oracle DRM system in descending order (Newest user creation date first--oldest user creation date in last).

Optionally, if you would like to display DATE_TIME in 'YYYY-MM-DD HH24:MM:SS' format:

Run the below query:

select C_USER_NAME as USER_NAME, C_ACTION as ACTION, C_ACTION_DESCRIPTION as ACTION_DESCRIPTION, TO_CHAR(D_TIMESTAMP, 'YYYY-MM-DD HH24:MM:SS') as Date_Time from RM_Transaction_History where C_ACTION = 'Add User' order by Date_Time desc;

Note: In the above two examples, USER_NAME column signifies different kinds of DRM users who can create/add new users into Oracle DRM system. Below is the detail of the same:

• USER_NAME = ‘ADMIN’ implies that the new user has been created/added by DRM Default Administrator
• USER_NAME = ‘@@PROCESS’ implies that the new user has been created/added by synchronization process from Hyperion Shared Services  in a ‘Common User Provisioning’ enabled Oracle DRM application. '@@PROCESS' is a default internal user in Oracle DRM set up to handle inter-process communication between server components.
• USER_NAME = ‘Any existing application user’ implies that the new user has been created/added by an existing DRM business user who has been assigned privileges (Application Administrator privilege) to create/add a new user into Oracle DRM application. 

That's all for this post.

I hope this article has helped you. 

Your suggestions/feedback are most welcome.

Keep learning and Have a great day!!!

Read More

FDMEE: VBScript Error: ActiveX component can't create object: 'fdmapi.clsAppServerDM'

Hi Friends,

In Oracle Hyperion Financial Data Quality Management (FDMEE), while running data load jobs from your source system to Oracle Hyperion target applications, you might have encountered following error in data load run log:

Microsoft VBScript runtime error: ActiveX component can't create object:'fdmapi.clsAppServerDM'

Snippet from data load run log:

2020-04-23 05:11:06,542 DEBUG [AIF]: Comm.executeVBScript - START

2020-04-23 05:11:06,542 INFO  [AIF]: Executing the following script: \\Network_path\FDMData\data\scripts\event\AftValidate.vbs

2020-04-23 05:11:06,542 DEBUG [AIF]: The command to be executed is:

cscript \\Network_path\FDMData\data\scripts\event\AftValidate.vbs "275" "****" "E%3A%5Capps%5COracleEPM%5CMiddleware%5Cuser_projects%5Cepmsystem_fdm" "%25EPM_ORACLE_HOME%25%2F..%2Fjdk160_35" "ORAOLEDB.ORACLE"

Microsoft (R) Windows Script Host Version 5.8

Copyright (C) Microsoft Corporation. All rights reserved.

2020-04-23 05:11:06,590 ERROR [AIF]: The script has failed to execute:

2020-04-23 05:11:06,594 INFO  [AIF]: 
\\Network_path\FDMData\data\scripts\event\AftValidate.vbs(17, 1) Microsoft VBScript runtime error: ActiveX component can't create object: 'fdmapi.clsAppServerDM'

2020-04-23 05:11:06,594 FATAL [AIF]: Error in CommData.validateData

Traceback (most recent call last):

  File "<string>", line 4516, in validateData

  File "<string>", line 453, in executeScript

  File "<string>", line 634, in executeVBScript

RuntimeError: 0

Actually, this error is thrown when Oracle Hyperion Financial Data Quality Management (FDMEE) processes VB code in VB script AftValidate.vbs or any other VB Script for that matter.

Important Note:

• This post has been written and associated activities have been demonstrated on Oracle Hyperion Financial Data Quality Management (FDMEE) version 11.1.2.4.210.
• Different paths and folders' names mentioned in this blog may slightly vary for different Hyperion setups but at large, it should be the same. 
• It's very important to test any workaround/fix first in a non-Prod environment, and move/apply it to PROD only when you are fully sure about its workability.
• The workaround of this issue requires Hyperion Financial Data Quality Management (FDMEE) services to be restarted so inform your users accordingly. 

Solution:

In order to fix this error, you need to execute the RegisterVBAPI.vbs script to register the FDMEE Visual Basic (VB) API in your FDMEE server. Oracle Hyperion Financial Data Quality Management (FDMEE) does not automatically register the Visual Basic API DLL at the time of installation. Therefore, if you use VB (Visual Basic) scripts in your FDMEE application then you have to manually run RegisterVBAPI.vbs to register the VB API before you can use it in your FDMEE vbs scripts. This part is also covered in the Oracle Hyperion Financial Data Quality Management (FDMEE) administration guide.

Note: Preferably, as a leading practice, you should use Jython in FDMEE and not VB (Visual Basic) as Oracle is moving away from its Microsoft dependency with each new update.

Steps to register the VB (Visual Basic) API DLL manually in Oracle Hyperion Financial Data Quality Management (FDMEE) server:

1- Login to all the FDMEE servers of your Hyperion environment and perform below steps on each one of them.

2- Open a command prompt and navigate to path: E:\apps\OracleEPM\Middleware\EPMSystem11R1\products\FinancialDataQuality\lib\Windows

3- Execute RegisterVBAPI.vbs script as mentioned below.

The RegisterVBAPI.vbs script requires your Oracle Instance path (wrapped in quotes) to be passed as input parameter to it. So enter the following command:

RegisterVBAPI.vbs "E:\apps\OracleEPM\Middleware\user_projects\epmsystem_fdm"

After running RegisterVBAPI.vbs script, first, you will see the below message. Click OK.

Then you will see 2^nd message as shown below. Click OK.

3rd and the last message will appear as shown below. Click OK.

You need to make sure RegisterVBAPI.vbs script run is successful. To confirm the same, above message: “FDMEE VB API Registration Finished” must appear on your screen. If you don’t see the above message, it means VB (Visual Basic) API DLL is not successfully registered and you may again face data load failure reporting the same error.

Once you are done with running RegisterVBAPI.vbs script, restart Hyperion Financial Data Quality Management (FDMEE) service in all your FDMEE servers.

Now retry to run your FDMEE data load job. It should be working fine this time. 

You may also like to refer below Oracle Document for related details:

Doc ID 2573674.1

That's all for this post.

I hope this article has helped you. 

Your suggestions/feedback are most welcome.

Keep learning and Have a great day!!! 

Read More

FDMEE: System Maintenance Tasks: Maintain Process Tables

Hi Friends,

This is the fourth post under Oracle Hyperion Financial Data Quality Management (FDMEE): System Maintenance Tasks blog series where we are going to cover the Maintain Process Tables script.

If you have not yet read the previous three posts of this blog series, I would suggest you to go through them on below links to get a comprehensive picture of Oracle Hyperion Financial Data Quality Management (FDMEE) System Maintenance Tasks:

FDMEE: System Maintenance Tasks: Maintain FDMEE Data Tables
FDMEE: System Maintenance Tasks: Maintain ODI Session Data

FDMEE: System Maintenance Tasks: Maintain Application Folder

In this fourth post, we will focus on the ‘Maintain Process Tables’ task and will see how to manually execute ‘Maintain Process Tables’ purge script.  

Important Note:

• This post has been written and associated activities have been demonstrated on Oracle Hyperion Financial Data Quality Management (FDMEE) version 11.1.2.4.210.
• The demonstrating Hyperion environment has Oracle database server 12.2.0.2 (18c) as backend database. 
• There is no outage required on the Oracle Hyperion Financial Data Quality Management (FDMEE) application to execute these purge scripts. But it is advisable not to run any data loads during the purge activity.
• Based on the data retention policy of your organization, you should pre-decide how many days of data you want to retain for Oracle Hyperion Financial Data Quality Management (FDMEE) Process Tables.
• Don't forget to take complete Oracle Hyperion Financial Data Quality Management (FDMEE) schema backup before attempting to run these purge scripts.

Maintain Process Tables

The purpose of running Maintain Process Tables script is to purge old/historical Process IDs and related details from associated execution tables in Oracle Hyperion Financial Data Quality Management (FDMEE). This will not only reduce the overall FDMEE schema size but also help improve the performance of your FDMEE application. 

The “Maintain Process Tables” script cleans up the Process IDs in the Process details related FDMEE tables by the number of days you enter as input parameter while running the script.

It deletes entries from following Oracle Hyperion Financial Data Quality Management (FDMEE) execution tables (AIF_ tables):

• AIF_PROCESSES
• AIF_PROCESS_DETAILS
• AIF_PROCESS_LOGS
• AIF_PROCESS_PARAMETERS
• AIF_PROCESS_PERIODS
• AIF_PROCESS_STEPS
• AIF_BAL_RULE_LOADS
• AIF_BAL_RULE_LOAD_PARAMS
• AIF_BATCH_JOBS
• AIF_BATCH_LOAD_AUDIT
• AIF_TEMP

Before proceeding further, with purging steps, I would suggest you to check and note down the pre-purge FDMEE schema size to see how much space has been freed up post purge activity.

Step-by-Step process to execute ‘Maintain Process Tables’ purge script

1- Log in to Workspace with Admin credentials.

2- Open Oracle Hyperion Financial Data Quality Management (FDMEE) console (Data Management) from Workspace and on the Workflow tab, under Other, select Script Execution:

3- In Script Execution, and then in Custom Script Group, select System Maintenance Tasks.

4- From the Scripts grid, select Maintain Process Tables script and Click Execute.

5- It will prompt to enter the following parameter value on the Execute Script screen.

Days to keep records

Enter the number of days you want to retain entries for in FDMEE Process Tables from today’s date. For example, if you want to delete all the entries except all 3 months (90 days) entries in FDMEE Process Tables, enter 90 in Days to keep records.

Note: Maintain Process Tables scrip takes some time to execute so it’s advisable not to purge too much in one go.

6- Keep Execution mode selected as Online. The online method processes the report immediately.

Execution modes:

online  — ODI processes the data in sync mode (immediate processing).

offline — ODI processes the data in async mode (runs in background).

7- Optionally, If you want to schedule the purge script run rather than running it instantly, Click on Schedule option and enter the scheduling details as per your requirement.

8- If you want to instantly run the purge script, then directly click on OK (not on the Schedule option). 

You will see a message informing the process ID of your script run.

9- To see the status of your script execution, click on the Process Details link under the Workflow tab—Monitor—Process Details. 

Click on the Show button for the Process ID of your script run to open the corresponding log file.

In the log file, look for the message "Maintain Process Tables: Completed" to confirm that script has run successfully without any error. If you encounter any errors, troubleshoot them based on the cause mentioned in the log file. In our case, we see no issue in the script execution.

Once you are done with running the Maintain Process Tables purge script, you can check your Hyperion Financial Data Quality Management (FDMEE) schema size to see how much space has been cleared as a result of FDMEE Process Tables purging.

Here it’s important to note that after running the FDMEE Process Tables purge script, your DBA needs to do FDMEE tables reorganization activity in order to reclaim freed space. 

Actually, when you delete the data from the Oracle tables, the data blocks will go onto the free list for that table. That free space will be used for the subsequent insert and update operations into the table. You need to perform table reorganization to reclaim that free space.

Note: Reorganization of tables requires outage in your Hyperion environment so you have to stop all your application services prior to the reorganization activity to be performed by your application DBA.

Don't forget to ask your DBA team to 'Rebuild Indexes' in your Hyperion Financial Data Quality Management (FDMEE) database after performing the 'Tables Reorganisation' activity.

If you miss rebuilding indexes after tables reorganization activity, your FDMEE data load job will be taking longer than normal to complete.

Index rebuild becomes absolutely necessary especially when you delete millions of records from FDMEE tables as part of running FDMEE purge scripts because the corresponding indexes of those deleted records go in the unusable state after tables reorganization activity. Due to this bulk deletion of records, indexes become fragmented causing indexes taking more time to give the output and hence delaying your FDMEE data load job.

You will observe the following type of error during your FDMEE data load run if you do not rebuild database indexes after tables reorganization activity:

ORA-01502: index 'FDMEE_ODI.PK_AIF_*' or partition of such index is in unusable state.

Once both the DBA tasks (Tables reorganization + Rebuilding Indexes) are completed, compare pre and post purge size of your Hyperion Financial Data Quality Management (FDMEE) schema to see how much has the schema size reduced. 

Maintain Process Tables purge script can also be automated to run using Executescript batch file located in the folder: 

<drive>\Oracle\Middleware\user_projects\epmsystem1_fdm\FinancialDataQuality.

We will cover the automation of Maintain Process Tables purge script in a separate post of this blog series. 

That's all for this post.

I hope this article has helped you.
Your suggestions/feedback are most welcome.

Keep learning and Have a great day!!!

Read More

EPMA: Transform Classic to EPMA Wizard: Communication error occurred: %1

Hi Friends,

In this post, we will discuss an Oracle Hyperion Enterprise Performance Management Architect (EPMA) error “communication error occurred: %1” which we encountered while using ‘Transform classic to EPM Architect Wizard’ in Workspace and will see how it got fixed.

Important Note: 

• This post has been written and associated activities have been demonstrated on Oracle Hyperion Enterprise Performance Management Architect (EPMA) version 11.1.2.4.000.2614
• It's very important to test any workaround/fix first in a non-Prod environment, and move/apply it to PROD only when you are fully sure about its workability.

Problem description

Actually, as part of Oracle Hyperion Financial Management (HFM) application cloning activity from PROD to TEST, we imported our PROD HFM app (an EPMA app) to the TEST environment. 

Then to complete the migration, we were trying to convert the imported Classic HFM app to EPMA in our TEST environment. But when we opened ‘Transform classic to EPM Architect Wizard’ from Workspace (Launch Workspace -> Navigate ->Administer-> Transform Classic to EPM Architect), the application summary page first took 30 mins showing the “Loading….” message. Eventually, it threw this below message:

Error: communication error occurred: %1

The following images will show you the issue replication:

Troubleshooting

We immediately checked the Oracle Hyperion Enterprise Performance Management Architect (EPMA) log: (E:\apps\OracleEPM\Middleware\user_projects\domains\EPMSystem\servers\EpmaWebReports0\logs\EPMA.log) to see EPMA web-tier activities during the live issue and noticed following error message appeared multiple times:

[SRC_CLASS:com.hyperion.awb.web.util.MessageRetriever] [SRC_METHOD:getMessage] [[java.util.MissingResourceException: Can't find resource for bundle java.util.PropertyResourceBundle, key The application ID (HSS) for application name: ESBAPP............................

Point to note was that 39 of the registered Essbase apps were causing an error like above. 

Actually, the Application Summary page of ‘Transform classic to EPM Architect Wizard’ shows the applications list to which the user has access to transform. If the ‘logged in user’ is not provisioned as ‘Application Administrator’ for an application; the user will not be able to migrate that application to EPMA. For all those applications which cannot be transformed, an explanation is provided in the ‘Comment’ column. Following are a few messages which are normally observed in the 'comment' column of Application Summary page for the apps which are nontransformable:  

• Application view already exists
• User must be provisioned as Application Administrator for this application.
• Connection to the Essbase server failed.

The Application Summary page’s applications list is extracted from the Hyperion Shared Services server/schema. It displays all the applications of your Oracle Hyperion environment like Hyperion Essbase, Hyperion Planning, Hyperion HFM, etc. which are registered with Oracle Hyperion Shared services.

Before populating the applications list for the transformation, it also validates that application by connecting to the respective application server (like Essbase Server, HFM Server), EPMA application library, and Hyperion Shared Services provisioning of that application, etc. So if the number of applications is very large, the Application Summary page is supposed to take some time in order to populate the list. 

In our case, Transform classic to EPM Architect Wizard was encountering a communication error while fetching the details of those 39 Essbase apps from Oracle Hyperion Shared Services and validating the same with the Hyperion Essbase server. For sure there was some conflict that was delaying the process of populating the applications list eventually causing that communication error after 30 mins of loading. The reason why it was happening is still unknown (let me know your thoughts on the same). 

Solution that worked for us:

We first tried with restarting all the Hyperion services including EPMA and Hyperion Essbase services but that didn't help.

As the error in EPMA.log was pointing to Essbase apps, we next focussed our attention to the same and noticed there were a total of 86 Essbase cubes/apps in our environment including so many ‘not so important’ cubes created for various testing, data validation etc. purposes.

Deleting unwanted apps from your Oracle Hyperion environment not only improves the apps loading time in Application Summary page of Transform Classic to EPM Architect Wizard but also saves your server resources from being unnecessarily consumed. 

So we triggered an Essbase apps cleanup drive and deleted around 40 unwanted Essbase applications after consulting their usability with business users and applications team (similarly you can plan for deleting other unwanted apps like HFM too).

Post this unwanted Essbase apps cleanup drive, we again ran ‘Transform Classic to EPM Architect Wizard’ and observed that the Application Summary page got populated with all the applications in less than 4 mins as shown below:

Thus the communication error ‘communication error occurred: %1’ got resolved for us.

That's all for this post.

I hope this article has helped you. 

Your suggestions/feedback are most welcome.

Keep learning and Have a great day!!!

Read More