EPM 11.1.2.4: EPMA is not compatible with Google Chrome and Microsoft Edge browsers

To get the context of the issue discussed in this blog, I would suggest you to first read following two posts:

EPM 11.1.2.4: Microsoft Edge and Google Chrome browsers support patching : Part-1
EPM 11.1.2.4: Microsoft Edge and Google Chrome browsers support patching : Part-2

In order to make EPM 11.1.2.4 environment compatible to run on Google Chrome and Microsoft Edge browsers we apply some patches mentioned in the following knowledge article: 

Browser Support Added for Google Chrome and Microsoft Edge with EPM System Releases Beginning with Release 11.1.2.4 - Doc ID 2675883.1

Post patching when we validated our EPM environments, all applications like Workspace, Essbase, HFM, HPCM, DRM, FDMEE are working fine. We haven't faced any showstopper issue/error in these applications as such.

But its important to note here that EPMA is not compatible with Google Chrome and Microsoft Edge browsers. It not like EPMA doesn't work at all on Google Chrome and Microsoft Edge browsers. You may face issue while using few of the EPMA functionalities.

One such issue is when we try to create Import Profile in EPMA Dimension Library (EPMA dimension library--File--Import--Create profile--New Profile--File Properties), there is a blank screen coming in place of "File Properties" page in Chrome and Edge browsers. While the same works fine in Internet Explorer browser. Please notice following screenshots depicting the same:

In Google Chrome and Microsoft Edge browsers (Blank Screen):



In Internet Explorer browser (Working):



So you can recommend your end users to use IE (Internet Explorer) only for EPMA related work. For other applications, Google Chrome and Microsoft Edge work all fine.

That's all for this post. Please let me know in comment box how the latest browsers support patching goes for you.

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!!!

Share this post:

Read More

EPM 11.1.2.4: Microsoft Edge and Google Chrome browsers support patching : Part-1

Note: This is Part-1 of 'Google Chrome and Microsoft Edge Browser Support' patching blogs . You can read Part-2 here.

In April 2020, one of our clients (on EPM 11.1.2.4) informed us that effective immediately, their IT team would begin supporting Microsoft’s new Edge* web browser making it the default browser on user machines. Users were recommended to use Edge for day-to-day browser activities. However, they did mention that there are several apps that are not yet compatible. So if you use one of those apps that have known compatibility issues, then you can continue using Internet Explorer (IE11) in these cases.

*Microsoft Edge is based on the Chromium open-source engine, just like Chrome. Compared to IE, with Edge, you can look forward to significantly faster browsing performance and compatibility, better overall security, and a slew of helpful new features.

We checked the EPM 11.1.2.4 certification matrix and informed the client that currently (as of May 2020), Google Chrome and Microsoft Edge Browsers are not supported by all the EPM applications so we should use IE11 only to smoothly access all the Hyperion apps.

But this whole picture got changed when in June 2020, Oracle notified that Google Chrome and Microsoft Edge Browser Support has been added to Enterprise Performance Management (EPM) 11.1.2.4 (click here to read).

Oracle updated the EPM 11.1.2.4 certification matrix to reflect the new changes, as shown below:

In order to make your EPM 11.1.2.4 environment compatible with Google Chrome and Microsoft Edge Browsers, you must update to the following supported releases:

• Hyperion Shared Services 11.1.2.4.100+ (Patch 31319089. Use Patch 31574562 for release 11.1.2.4.9xx) 
• Hyperion Planning, Hyperion Capital Asset Planning, Hyperion Workforce Planning, Hyperion Project Financial Planning 11.1.2.4.009+ (Patch 29889455) 
• Hyperion Calculation Manager 11.1.2.4.014+ (Patch 28557058) 
• Hyperion Financial Reporting 11.1.2.4.712+ (Patch 30670918. Use Patch 30671119 for release 11.1.2.4.9xx) 
• Hyperion Financial Management 11.1.2.4.208+ (Patch 28511735) 
• Hyperion Financial Close Management and Hyperion Tax Governance 11.1.2.4.253+ (Patch 29060830) 
• Hyperion Tax Provision 11.1.2.4.202+ (Patch 25316913) 
• Hyperion Financial Data Management 11.1.2.4.220+ (Patch 25312033) 
• Hyperion Profitability and Cost Management 11.1.2.4.130+ (Patch 29461894) 
• Hyperion Workspace 11.1.2.4.825+ (Patch 31124100. Use Patch 31486872 for release 11.1.2.4.9xx) 
• Hyperion Data Relationship Management 11.1.2.4.350+ (Patch 31420887)
• Additionally, you must also update Oracle JDeveloper / Application Development Framework 11.1.1.7.1 (Patch 31246831).

EXCEPTIONS

• Oracle JDeveloper / Application Development Framework does not apply to Hyperion Data Relationship Management or Hyperion Workspace.

For more information, read the following knowledge article: Browser Support Added for Google Chrome and Microsoft Edge with EPM System Releases Beginning with Release 11.1.2.4 - Doc ID 2675883.1

So we planned to apply these compatibility patches in our EPM 11.1.2.4 environment starting with DEV to make it work with Google Chrome and Microsoft Edge browsers.

As an obvious next step, we started looking for known issues/errors faced by any users after applying these compatibility patches.

Then we came to know about one technical issue reported as Hyperion Shared Services not working in Google Chrome and Microsoft Edge (Doc ID 2698535.1).

Notably, as per the Doc ID 2698535.1, this issue is reported not only in EPM 11.1.2.4 but also in the very latest EPM 11.2.1 and EPM 11.2.2 releases (Let me know in the comment section if you have a functional EPM 11.2.1 or 11.2.2 environment and face this issue on Microsoft Edge or Google Chrome browser.) 

As per Doc ID 2698535.1, after applying these compatibility patches mentioned in Doc ID 2675883.1, from Shared Services Console, attempting the following tasks results in an "empty" grey screen or grey pop-up:

• create new Native User
• provision existing user
• LCM import/export
• Migration Status Report

In short, you will be having issues while using Hyperion Shared Services Console on Google Chrome or Microsoft Edge browsers post applying these patches.

Oracle has already raised two bugs for this problem as mentioned in Doc ID 2698535.1:

1. Unpublished bug created for 11.1.2.4 Bug 31686588
2. Unpublished bug created for 11.2.1 Bug 31546643

As a workaround for this issue in Hyperion Shared Services console, the following is suggested in Doc ID 2698535.1:

• For 11.1.2.4, workaround is to use Internet Explorer 11.x or Firefox 31+ ESR
• For 11.2.1, workaround is to use Internet Explorer 11.x or Firefox ESR
• For 11.2.2, workaround is to use Firefox ESR 

We decided to first clear the air about this compatibility patches and reported bugs before we patch our systems.

To that effect, we recently had a call with Oracle, and below is what we can summarize based on our discussion:

As far as these two bugs are concerned, there is still no solution provided for EPM 11.1.2.4, EPM 11.2.1, or EPM 11.2.2. Most probably, these bugs will be fixed in the EPM 11.2.3 release (as of Oct 2020). 

For EPM 11.1.2.4, you should go-ahead and patch your EPM 11.1.2.4 environment with these compatibility patches. As post patching there will be no impact on EPM 11.2.4 functioning with IE11 browser i.e. all the features/functionalities will continue to work fine on IE11 browser regardless of whether you have applied the new compatibility patches or not to make your EPM 11.2.4 environment compatible with Google Chrome and Microsoft Edge.

Post compatibility patching, the reported issue of "empty" grey screen in Doc ID 2698535.1 is limited to Hyperion Shared Services Console only for the tasks like create new Native User, provision existing user, LCM import/export, Migration Status Report. Other functionalities/features/consoles in EPM 11.1.2.4 work fine on Google Chrome and Microsoft Edge browsers. 

For the end-users, there are hardly any issues because Hyperion Shared services Console is mostly used by Hyperion Admins for user management and LCM related tasks.

The above summary gives a sense of security that at least there is nothing to lose after applying these compatibility patches mentioned in Doc ID 2675883.1 in your EPM 11.1.2.4 environment. After applying these patches in your EPM 11.1.2.4 environment, you can use:

• Google Chrome or Microsoft Edge browser for all the activities except on Hyperion Shared Services console
• IE11 for Hyperion Shared Services console activities only (mostly by Hyperion Admins)

As for the client, upgrading the current EPM version 11.1.2.4 to EPM 11.2 is still a good 6 months away (as of Oct 2020) and their IT team has already made Microsoft Edge the default browser, we are going to apply these compatibility patches in our 11.1.2.4 DEV environment for Microsoft Edge and Google Chrome compatibility. 

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

EPM 11.2 servers and HyperThreading

A few days ago, we had a discussion with our server build team for acquiring new hardware for EPM 11.2 installation & configuration. To put it in context, one of our clients has EPM 11.1.2.4 on-premise setup consisting of multiple Hyperion instances running across IBM AIX 7.1 (Oracle Database), RedHat Linux 6.10 x86_64 (Essbase app), and Windows Server 2012 R2 64-bit (all other apps like HFM, FDMEE, DRM, HPCM, etc.) in a distributed environment.

Recently, the client wished to move the complete setup to the latest EPM 11.2.x release having Windows Servers 2019 and Linux 7 (why EPM 11.2 and not EPM Cloud for this setup? Well its a matter we will discuss some other time.)

In the current 11.1.2.4 setup, we have both kinds of servers -Physical Servers + VM Servers. To be precise, only HFM and Essbase apps are hosted on Physical machines in both PROD and TEST environments rest all are on VM servers.

All Physical servers (HFM + Essbase App servers) have HyperThreading** ENABLED while there is no HyperThreading on VM machines. 

**HyperThreading: HyperThreading is Intel’s term for simultaneous multithreading (SMT). This is a process where a CPU splits each of its physical cores into virtual cores, which are known as threads. For example, most of Intel's CPUs with two cores use hyper-threading to provide four threads, and Intel CPUs with four cores use hyper-threading to provide eight threads. Therefore, when HyperThreading is enabled, every CPU core has two CPU threads instead of one. A server with 8 cores would appear to have 16 CPU threads. If one thread is idle or stalls on a cache miss, the other thread can continue to execute. This is a potential throughput advantage, especially for multithreaded workloads that frequently have cache misses. HyperThreading (HT) permits the CPU to continue useful processing by running the other thread. On the other hand, both threads compete for the core’s resources, and each thread may run slower than if it owned an entire core. Each thread potentially displaces the other thread’s level 1 cache contents, causing both threads to run slower. This is especially visible for compute-intensive workloads that might normally fit in the cache without HT. The result is that it's reasonable to enable HyperThreading by default, but it can be valuable to test performance to see whether it adds performance for a specific application or not.

The current EPM 11.1.2.4 setup is working perfectly fine for past many years having an optimum performance for all the apps.

Now, while we have decided to upgrade it to EPM 11.2, it was quite apparent for us to get the answers of the following queries:

• Is there any recommendation for HyperThreading in EPM 11.2 version (Windows server 2019, Linux 7)?
• Can we continue with having the existing 11.1.2.4 HyperThreading CPU configuration even in EPM 11.2?
• Is there any known issue or performance improvement if we continue to run Essbase and HFM on HyperThreading enabled servers even in EPM 11.2?

Let's try to find out.......

Oracle and HyperThreading:

Oracle will work just fine on any OS that is running and recognizes a HyperThreading enabled system and will take advantage of the logical CPUs to their fullest extent (assuming the OS reports that it recognizes that hyper-threading is enabled). All Oracle versions can take advantage of hyper-threading and is considered a supported configuration since no support code has been added for it on the Oracle end to take advantage of HyperThreading; all the changes were in the OS, the bios, and the hardware. When Oracle asks the OS how many CPUs are in the system, the OS just reports the total number of logical CPUs.

Oracle Hyperion and HyperThreading:

I googled and read some blogs and what I found is that the experience of Oracle EPM apps with HyperThreading is quite mixed. For some, it worked well while others didn’t. I will leave it up to you to google and read those observations.

I remember there used to be a line in the Essbase 11.1.2.1 dbag document -"Enabling hyperthreading on the computer on which Essbase Server runs is not recommended." But now this line is no more there in Essbase dbag Release 11.1.2.4, implying the statement is no more valid.

My current EPM 11.1.2.4 configuration was done much before I joined this project so not sure about the exact reason to have HyperThreading enabled physical servers for Essbase and HFM apps and not for other apps which were installed on VM machines (please let me know if you know any technical correlation). But I am sure there must have been some idea behind opting the current 11.1.2.4 servers' CPU configuration (on Windows Server 2012 R2 and Linux 6).

However seeing the good performance of the current 11.1.2.4 PROD environment (Essbase, HFM, FDMEE, DRM, and HPCM) over the past many years and in the absence of any conclusive stats about HyperThreading impact in EPM servers, I was tempted to take the current PROD 11.1.2.4 HyperThreading setup as a reference for the EPM 11.2 hardware configuration too.

But, notably, EPM 11.2 version will be running on Windows servers 2019 compared to currently used Windows servers 2012 R2, so I thought better to consult Oracle to make a final recommendation on HyperThreading for EPM 11.2 Servers' CPU configuration.

And below is what Oracle said:

There are no specific Recommendations on HyperThreading for EPM 11.2 version (Windows server 2019) and we didn't see any issues reported by other customers as well. However, you can enable HyperThreading in your 11.2 setup and let us know if you face any issues post the implementation.

So it’s clear that there is no clear-cut YES/NO from the Oracle side as far as Enabling/Disabling HyperThreading in EPM 11.2 servers are concerned. Oracle leaves it to the discretion of your Hyperion technical team and Servers build team to decide whether you want to have servers built with HyperThreading enabled or disabled. Of course, it will vary with different Hyperion environments, OS, applications and most importantly it should be guided by the time-tested performance of your Hyperion applications for example in terms of HFM consolidation, Essbase calculation, aggregation, data load, and report script run, FDMEE data load run time, etc.

But yes! Oracle will come to your rescue if you face any issues post EPM 11.2 implementation (irrespective of what you chose for your CPU configuration).

And for those who are interested to know how we have decided to go for HyperThreading in EPM 11.2 servers. Well, it’s still under discussion (as of Sep 2020)....(but its almost certain that our EPM 11.2 servers will be having the same Hardware configuration what we have in our existing 11.1.2.4 setup being a time-tested reference for our current set of Essbase, HFM, HPCM, FDMEE, DRM, etc. applications).

Do leave a comment to let me know how you have built your EPM 11.2 servers (with/without HyperThreading).

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

Automation of 'Maintain EBS GL Balances Table' System Maintenance Task

 In 'FDMEE System Maintenance Tasks' blog series, we have already covered the following topics:

Manual implementation:

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

FDMEE: System Maintenance Tasks: Maintain EBS GL Balances Table

Automation: 

Automation of 'Maintain FDMEE Data Tables' System Maintenance Task

Automation of 'Maintain ODI Session Data' System Maintenance Task

Automation of 'Maintain Application Folder' System Maintenance Task

Automation of 'Maintain Process Tables' System Maintenance Task

If you have not already gone through the above articles, I would suggest you read them first to get a comprehensive understanding of all the Hyperion Financial Data Quality Management (FDMEE) System Maintenance Tasks.

Note:

• The demonstrating Hyperion environment has the 'Windows Server 2012 R2 Standard' operating system. 
• The demonstrating Hyperion environment has 'Oracle database server 12.2.0.2 (18c)' as backend database. 
• This post has been written and associated activities have been demonstrated on Oracle FDMEE version 11.1.2.4.220.
• There is no outage required on the FDMEE application to execute these scripts. But it is advisable not to run any data loads during the activity.
• Don't forget to take complete FDMEE schema backup before attempting to run these scripts. 
• Different paths and folder names mentioned in this post may slightly vary for different Hyperion setups but at large it should be the same.

Command syntax of FDMEE batch utility executescript.bat:

----------------------------------------------------------------------------------
executescript <username> <password> "<script name>" "<parameters>" <execution mode>

Where:

• <username>: is your FDMEE user running the script
• <password>: can be either the hard-coded password or a file with encoded password (-f:filename)
• <script name>: is the name of the script registered in Script Registration page (not the python script filename). You find the script name here: Navigate-Administer-Data Management-Setup tab-Script Registration
• <parameters>: are the script parameters in the form "Display Name=Parameter Value"
• <execution mode>: is either SYNC (synchronous) or ASYNC (asynchronous). SYNC—Process runs immediately and control returns when process completes. ASYNC—When the ODI job is submitted, control returns. The load process continues to execute in ODI.

Now the command syntax in the more detailed form will look like below:

executescript <username> <password> "<script name>" "<parameterdisplay1=value1>" "<parameterdisplay2=value2>" <SYNC | ASYNC>

If you are going to use an encrypted password (which is the recommended best practice), following will be the command syntax:

executescript <username> <password | -f:password.txt> "<script name>" "<parameterdisplay1=value1>" "<parameterdisplay2=value2>" <SYNC | ASYNC>

You will find the configuration steps for password encryption in the FDMEE admin guide as shown below:

You need to ensure that your encrypted password.txt file is placed in the location defined in Navigate-Administer-Data Management-Setup tab-System Settings-Encrypted Password Folder.

Automating 'Maintain EBS GL Balances Table' System Maintenance Task:

---------------------------------------------------------------------------------------

In this post, we will see how to automate 'Maintain EBS GL Balances Table' System Maintenance Task. I suggest you to first read this post FDMEE: System Maintenance Tasks: Maintain EBS GL Balances Table for theoretical understanding, manual implementation, and post-execution activities of 'Maintain Process Tables' System Maintenance Task.

When you execute ‘Maintain EBS GL Balances Table’ purge script manually from Data Management console, it seeks the following input parameter: 

• Source System
• Start Period
• End Period

To run ‘Maintain EBS GL Balances Table’ purge script using executescript.bat command-line utility below is the command syntax:

executescript username password "MaintainEBSGLBalancesTable" "Source System=EnterSourceSystemID" "Start Period (format must be yyyy-mm-dd)=EnterStartPeriod" "End Period (format must be yyyy-mm-dd)=EnterEndPeriod" SYNC

Description:

• Source System: In Source System you need to enter the ID number of your respective source system what you get in the output by running below query against FDMEE schema:

SELECT SOURCE_SYSTEM_NAME, SOURCE_SYSTEM_ID FROM AIF_SOURCE_SYSTEMS;

Above query-output is same as what you see in Data Management console Source Systems list values while manually running Maintain EBS GL Balances Table script, as shown below:

• Start Period and End Period can be chosen from the values what you get in the output by running below query against FDMEE schema:

          SELECT PERIODDESC, PERIODKEY FROM TPOVPERIOD;

Above query-output is same as what you see in Data Management console Period list values as shown below:

If you want to quickly check what is the min and max value of period to help you choose your Start Period and End Period, you can run below query against FDMEE schema:

           SELECT MIN(PERIODKEY), MAX(PERIODKEY) FROM TPOVPERIOD; 

Note: Start Period and End Period values must be entered in the 'YYYY-MM-DD' format only.

Now let's understand the automation script for 'MaintainEBSGLBalancesTable' with the help of an example.

Suppose using FDMEE Admin user, you want to run 'Maintain EBS GL Balances Table' purge script for 2 Source Systems (IDs 7 & 8) for the Start Period Nov 2016 to End Period Oct 2017.

In order to achieve the above goal, create a batch script name 'MaintainEBSGLBalancesTable.bat' under folder E:\Admin\scripts having the following content: 

MaintainEBSGLBalancesTable.bat:
--------------------------------------------------

@echo off

REM Set the value for the variables 

set "username=admin"

set "password=YourAdminPassword"

set "startperiod=2016-11-01"

set "endperiod=2017-10-31"

set "logfile=E:\Admin\scripts\MaintainEBSGLBalancesTable.log"

REM Clear the content of existing logfile

rem.> %logfile%

REM Navigate the executescript.bat utility folder

cd "E:\apps\OracleEPM\Middleware\user_projects\epmsystem_fdm\FinancialDataQuality"

REM Run executescript to perform "MaintainEBSGLBalancesTable" for a set of Source System IDs and for mentioned Start and End Period

for %%f in (7 8) do (

   echo call executescript %username% %password% "MaintainEBSGLBalancesTable" "Source System=%%f" "Start Period (format must be yyyy-mm-dd)=%startperiod%" "End Period (format must be yyyy-mm-dd)=%endperiod%" SYNC

   call executescript %username% %password% "MaintainEBSGLBalancesTable" "Source System=%%f" "Start Period (format must be yyyy-mm-dd)=%startperiod%" "End Period (format must be yyyy-mm-dd)=%endperiod%" SYNC

echo ------------------------------------------------------------------------------

echo ------------------------------------------------------------------------------

) >>%logfile%

cd E:\Admin\scripts

You can put your Source System IDs in the segment (7 8) separated by a single space. 

Change the paths and variables mentioned in the script as per your requirement and FDMEE application setup.

Now login to your FDMEE server, open an Administrator Command prompt, and run 'MaintainEBSGLBalancesTable.bat'.

After completion of the script your log file will be generated in below format:

To verify whether your above-mentioned process IDs have successfully completed or not, you can navigate to Process Details page (In Data Management console, click on the Process Details link under the Workflow tab—Monitor—Process Details):

We see our process IDs have executed successfully. Click on the 'Show' button against the respective Process IDs to open the corresponding log file to see more details. 

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

Automation of 'Maintain Process Tables' System Maintenance Task

In 'FDMEE System Maintenance Tasks' blog series, we have already covered the following topics:

Manual Implementation: 

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
FDMEE: System Maintenance Tasks: Maintain EBS GL Balances Table

Automation:

Automation of 'Maintain FDMEE Data Tables' System Maintenance Task
Automation of 'Maintain ODI Session Data' System Maintenance Task
Automation of 'Maintain Application Folder' System Maintenance Task

If you have not already gone through the above articles, I would suggest you read them first to get a comprehensive understanding of all the Hyperion Financial Data Quality Management (FDMEE) System Maintenance Tasks.

Notes:

• The demonstrating Hyperion environment has the 'Windows Server 2012 R2 Standard' operating system. 
• The demonstrating Hyperion environment has 'Oracle database server 12.2.0.2 (18c)' as backend database. 
• This post has been written and associated activities have been demonstrated on Oracle FDMEE version 11.1.2.4.220.
• There is no outage required on the FDMEE application to execute these scripts. But it is advisable not to run any data loads during the activity.
• Don't forget to take complete FDMEE schema backup before attempting to run these scripts. 
• Different paths and folder names mentioned in this post may slightly vary for different Hyperion setups but at large it should be the same.

Command syntax of FDMEE batch utility executescript.bat:
----------------------------------------------------------------------------------
executescript <username> <password> "<script name>" "<parameters>" <execution mode>

Where:

• <username>: is your FDMEE user running the script
• <password>: can be either the hard-coded password or a file with encoded password (-f:filename)
• <script name>: is the name of the script registered in Script Registration page (not the python script filename). You find the script name here: Navigate-Administer-Data Management-Setup tab-Script Registration
• <parameters>: are the script parameters in the form "Display Name=Parameter Value"
• <execution mode>: is either SYNC (synchronous) or ASYNC (asynchronous). SYNC—Process runs immediately and control returns when process completes. ASYNC—When the ODI job is submitted, control returns. The load process continues to execute in ODI

Now the command syntax in the more detailed form will look like below:

executescript <username> <password> "<script name>" "<parameterdisplay1=value1>" "<parameterdisplay2=value2>" <SYNC | ASYNC>

If you are going to use an encrypted password (which is the recommended best practice), following will be the command syntax:

executescript <username> <password | -f:password.txt> "<script name>" "<parameterdisplay1=value1>" "<parameterdisplay2=value2>" <SYNC | ASYNC>

You will find the configuration steps for password encryption in the FDMEE admin guide as shown below:

You need to ensure that your encrypted password.txt file is placed in the location defined in Navigate-Administer-Data Management-Setup tab-System Settings-Encrypted Password Folder.

Automating 'Maintain Process Tables' System Maintenance Task:

-------------------------------------------------------------------------------------------------

In this post, we will see how to automate 'Maintain Process Tables' System Maintenance Task. I suggest you to first read this post FDMEE: System Maintenance Tasks: Maintain Process Tables for theoretical understanding, manual implementation, and post-execution activities of 'Maintain Process Tables' System Maintenance Task.

When you execute ‘Maintain Process Tables’ purge script manually from Data Management console, it seeks the following input parameter: Days to keep records

To run ‘Maintain Process Tables’ purge script using executescript.bat command-line utility below is the command syntax:

executescript username password "MaintainProcessTables" "Days to keep records=EnterDaysInNumber" SYNC

You need to enter the number of days you want to retain data for, in FDMEE Process tables.

Suppose using FDMEE Admin user, you want to run 'Maintain Process Tables' purge script for 90 days (3 months) i.e. you want to delete all the FDMEE Process details keeping only last 90 days (3 months) details.

In order to achieve the above goal, create a batch script name 'MaintainProcessTable.bat' under folder E:\Admin\scripts having the following content: 

MaintainProcessTable.bat:
--------------------------------------------------

@echo off

REM Set the value for the variables  

set "username=admin"
set "password=YourAdminPassword"

set "DaysToKeepRecords=90"

set "logfile=E:\Admin\scripts\MaintainProcessTable.log"

REM Clear the content of existing logfile

rem.> %logfile%

REM Navigate the executescript.bat utility folder

cd "E:\apps\OracleEPM\Middleware\user_projects\epmsystem_fdm\FinancialDataQuality"

REM Run executescript to perform "MaintainProcessTable" for the mentioned days to keep Records 

> %logfile% (

echo call executescript %username% %password% "MaintainProcessTables" "Days to keep records=%DaysToKeepRecords%" SYNC

call executescript %username% %password% "MaintainProcessTables" "Days to keep records=%DaysToKeepRecords%" SYNC

)

cd E:\Admin\scripts

Change the paths and variables mentioned in the script as per your requirement and FDMEE application setup.

Now login to your FDMEE server, open an Administrator Command prompt, and run MaintainProcessTable.bat.

After completion of the script your MaintainProcessTable.log will be generated as shown below:

To verify whether your process ID has successfully completed or not, you can navigate to Process Details page (In Data Management console, click on the Process Details link under the Workflow tab—Monitor—Process Details):

Click on the 'Show' button against the Process ID to open the corresponding log file to see more details. 

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

Automation of 'Maintain Application Folder' System Maintenance Task

In 'FDMEE System Maintenance Tasks' blog series, we have already covered the following topics:

Manual implementation:

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
FDMEE: System Maintenance Tasks: Maintain EBS GL Balances Table

Automation: 

Automation of 'Maintain FDMEE Data Tables' System Maintenance Task

Automation of 'Maintain ODI Session Data' System Maintenance Task

If you have not already gone through the above articles, I would suggest you read them first to get a comprehensive understanding of all the Hyperion Financial Data Quality Management (FDMEE) System Maintenance Tasks.

Note:

• The demonstrating Hyperion environment has the 'Windows Server 2012 R2 Standard' operating system. 
• The demonstrating Hyperion environment has 'Oracle database server 12.2.0.2 (18c)' as backend database. 
• This post has been written and associated activities have been demonstrated on Oracle FDMEE version 11.1.2.4.220.
• There is no outage required on the FDMEE application to execute these scripts. But it is advisable not to run any data loads during the activity.
• Don't forget to take complete FDMEE schema backup before attempting to run these scripts. 
• Different paths and folder names mentioned in this post may slightly vary for different Hyperion setups but at large it should be the same.  

Command syntax of FDMEE batch utility executescript.bat:
----------------------------------------------------------------------------------
executescript <username> <password> "<script name>" "<parameters>" <execution mode>

Where:

• <username>: is your FDMEE user running the script
• <password>: can be either the hard-coded password or a file with encoded password (-f:filename)
• <script name>: is the name of the script registered in Script Registration page (not the python script filename). You find the script name here: Navigate-Administer-Data Management-Setup tab-Script Registration
• <parameters>: are the script parameters in the form "Display Name=Parameter Value"
• <execution mode>: is either SYNC (synchronous) or ASYNC (asynchronous). SYNC—Process runs immediately and control returns when process completes. ASYNC—When the ODI job is submitted, control returns. The load process continues to execute in ODI.

Now the command syntax in more detailed form will look like below:

executescript <username> <password> "<script name>" "<parameterdisplay1=value1>" "<parameterdisplay2=value2>" <SYNC | ASYNC>

If you are going to use an encrypted password (which is the recommended best practice), following will be the command syntax:

executescript <username> <password | -f:password.txt> "<script name>" "<parameterdisplay1=value1>" "<parameterdisplay2=value2>" <SYNC | ASYNC>

You will find the configuration steps for password encryption in the FDMEE admin guide as shown below:

You need to ensure that your encrypted password.txt file is placed in the location defined in Navigate-Administer-Data Management-Setup tab-System Settings-Encrypted Password Folder.

Automating 'Maintain Application Folder' System Maintenance Task:

-------------------------------------------------------------------------------------------------

In this post, we will see how to automate 'Maintain Application Folder' System Maintenance Task. I suggest you to first read this post FDMEE: System Maintenance Tasks: Maintain Application Folder for theoretical understanding, manual implementation, and post-execution activities of 'Maintain Application Folder' System Maintenance Task.

When you execute ‘Maintain Application Folder’ purge script manually from Data Management console, it seeks the following input parameter:

• Target Application
• Days to keep Inbox directory
• Days to keep Outbox directory
• Days to keep Data directory

To run ‘Maintain Application Folder’ purge script using executescript.bat command-line utility below is the command syntax:

executescript username password "MaintainApplicationFolder" "Target Application=EnterYourTargetAppName" "Days to keep Inbox directory=EnterDaysInNumber" "Days to keep Outbox directory=EnterDaysInNumber" "Days to keep Data directory=EnterDaysInNumber" SYNC

Description:

• TargetAppName should be entered the same as what you get in the output by running below query against FDMEE schema:

          SELECT APPLICATION_NAME FROM AIF_TARGET_APPLICATIONS; 

Above query-output is same as what you see in Data Management console Target Applications list values as shown below:

• You need to enter the number of days you want to retain files/folders for, in FDMEE Inbox, Outbox and Data folders.

Suppose using FDMEE Admin user, you want to run 'Maintain Application Folder' purge script for 2 Target applications name TargetApp1, TargetApp and for 90 days (3 months) retention period i.e. you want to delete all the files/folders in FDMEE Inbox, Outbox and Data folders keeping only last 90 days (3 months) data. 

In order to achieve the above goal, create a batch script name 'MaintainApplicationFolder.bat' under folder E:\Admin\scripts having the following content: 

MaintainApplicationFolder.bat:
--------------------------------------------------

@echo off

REM Set the value for the variables 

set "username=admin"

set "password=YourAdminPassword"

set "DaystokeepInboxdirectory=90"

set "DaystokeepOutboxdirectory=90"

set "DaystokeepDatadirectory=90"

set "logfile=E:\Admin\scripts\MaintainApplicationFolder.log"

REM Clear the content of existing logfile

rem.> %logfile%

REM Navigate the executescript.bat utility folder

cd "E:\apps\OracleEPM\Middleware\user_projects\epmsystem_fdm\FinancialDataQuality"

REM Run executescript to perform "MaintainApplicationFolder" for a set of 2 Target Applications and 90 days to keep the application directories

for %%f in (TargetApp1 TargetApp2) do (

   echo call executescript %username% %password% "MaintainApplicationFolder" "Target Application=%%f" "Days to keep Inbox directory=%DaystokeepInboxdirectory%" "Days to keep Outbox directory=%DaystokeepOutboxdirectory%" "Days to keep Data directory=%DaystokeepDatadirectory%" SYNC

   call executescript %username% %password% "MaintainApplicationFolder" "Target Application=%%f" "Days to keep Inbox directory=%DaystokeepInboxdirectory%" "Days to keep Outbox directory=%DaystokeepOutboxdirectory%" "Days to keep Data directory=%DaystokeepDatadirectory%" SYNC

   

echo ------------------------------------------------------------------------------

echo ------------------------------------------------------------------------------

) >>%logfile%

cd E:\Admin\scripts

Change the paths and variables mentioned in the script as per your requirement and FDMEE application setup.

You can put your Target Application names in the segment (TargetApp1 TargetApp2 ) separated by a single space. 

Now login to your FDMEE server, open an Administrator Command prompt and run MaintainApplicationFolder.bat.

After completion of the script your MaintainApplicationFolder.log will be generated in below format:

To verify whether your process IDs have successfully completed or not, you can navigate to Process Details page (In Data Management console, click on the Process Details link under the Workflow tab—Monitor—Process Details):

We can see our process IDs have executed successfully. Click on the 'Show' button for a particular Process ID to open the corresponding log file to see more details. Similarly, you can verify other process IDs recorded in the log file for all the Target Applications.

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