Showing posts with label Financial Data Quality Management. Show all posts
Showing posts with label Financial Data Quality Management. Show all posts

Friday, April 9, 2021

// // Leave a Comment

EPM 11.2: How to check FDMEE application patch version

Its important to know the current patch version of your EPM (Enterprise Performance Management) products/applications, especially when you are planning to apply any new Oracle patches or want to check the compatibility of existing EPM applications with any other products/software/tools.

For FDMEE (Financial Data Quality Management, Enterprise Edition), you can check its current patch version using following methods:

1. AIF_version.xml (more reliable method):

This is the most reliable method because when you apply any new patch to FDMEE, this is the file which will be updated with the new patch level so it always shows the current version of your FDMEE application.

On FDMEE server, you can find AIF_version.xml file in the following folder:

E:\apps\OracleEPM\Middleware\EPMSystem11R1\products\FinancialDataQuality\xml\AIF_version.xml

When you open this AIF_version.xml file, FDMEE version will be displayed as shown below:

EPM 11.2: How to check FDMEE application/patch version

2. Workspace (Not always the true reflection of the current patch level of EPM products)

To see your EPM products versions in Workspace, navigate to: 

Workspace-->Help-->About Oracle Enterprise Performance Management System Workspace, Fusion Edition

You would have seen on many occasions that the EPM products version number shown in Hyperion Workspace do not match the patch versions that have been recently applied in an EPM environment.

It happens because EPM java web applications versions shown in Workspace are sourced from Shared Services registry (logical web application entry--displayVersion property).

EPM 11.2: How to check FDMEE application/patch version

Further the versions displayed in Shared Services registry are sourced from some property/configuration files of the respective EPM products which get updated immediately after applying any new patches. For example, in case of FDMEE, its is AIF_version.xml file as mentioned in method-1.

Sometimes, applications version shown in Workspace or the displayed version shown in Shared Services registry does not get refreshed from the respective source file of that application. And that's when you see a mismatch in version shown in Workspace and the actual application version. And that's why method-1 is more reliable one to know the FDMEE current patch version.

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

Sunday, March 7, 2021

// // 2 comments

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

You may like to read Part-1 first to understand the background of Microsoft Edge and Google Chrome browsers support patching in Hyperion/EPM 11.1.2.4 setup. 

In this post, I will tell how it worked for us. We have recently applied these browsers (Microsoft Edge and Google Chrome) compatibility patches in our EPM/Hyperion 11.1.2.4 environment. 

As discussed in last post, below is what we need to apply in order to make your EPM/Hyperion 11.1.2.4 environment working on Microsoft Edge and Google Chrome browsers:

EPM 11.1.2.4: Microsoft Edge and Google Chrome browsers support patching
Important Notes:
  • Above list provides the minimum patch version for each Hyperion application you need to install, If you want, you can go for higher version too. 
  • I assume your EPM/Hyperion 11.1.2.4 environment is up-to-date in terms of patches and you have all the prerequisite patches already applied.
  • Its recommended to have EPM/Hyperion application schemas backup and if possible, backup of the existing installation/configuration directory to handle unforeseen critical issues.
  • You should apply these patches in below given order. 
  • I have all these Hyperion applications installed and configured on Windows server 2012 R2, therefore below given steps are applicable for Windows machines. For other operating systems, you can refer 'README' document of the respective patch number.
  • Stop all the Hyperion services and WebLogic Admin server of your environment before proceeding further.
Lets start the patching now. 

Hyperion Workspace 11.1.2.4.825 (Patch 31124100)
----------------------------------------------------------------------
This patch needs to be applied on all your EPM Foundation/Workspace servers of the Hyperion environment. 

Download the patch and place it under apps\OracleEPM\Middleware\EPMSystem11R1\OPatch directory.

Open command prompt and apply the patch using below commands:

cd E:\apps\OracleEPM\Middleware\EPMSystem11R1\OPatch 
opatch.bat apply E:\apps\OracleEPM\Middleware\EPMSystem11R1\OPatch\31124100 -oh E:\apps\OracleEPM\Middleware\EPMSystem11R1 -jdk E:\apps\OracleEPM\Middleware\jdk160_35

Hyperion Shared Services 11.1.2.4.100 (Patch 31319089)
-------------------------------------------------------------------------
This patch needs to be applied on all your EPM Foundation/Workspace servers of the Hyperion environment. 

Download the patch and place it under apps\OracleEPM\Middleware\EPMSystem11R1\OPatch directory.

Open command prompt and apply the patch using below commands:

cd E:\apps\OracleEPM\Middleware\EPMSystem11R1\OPatch 
opatch.bat apply E:\apps\OracleEPM\Middleware\EPMSystem11R1\OPatch\31319089 -oh E:\apps\OracleEPM\Middleware\EPMSystem11R1 -jdk E:\apps\OracleEPM\Middleware\jdk160_35

Oracle JDeveloper / Application Development Framework 11.1.1.7.1 (Patch 31246831)
-----------------------------------------------------------------------------------------------------------------
This patch needs to be applied on all your EPM Foundation/Workspace servers of the Hyperion environment. 

After downloading the patch zip file, extract it to C:\Patch_Top. There should now be a 31246831 directory in the C:\Patch_Top directory.

Open command prompt and apply the patch using below commands:

cd E:\apps\OracleEPM\Middleware\oracle_common\OPatch\ 
opatch.bat apply C:\Patch_Top\31246831\oui -oh E:\apps\OracleEPM\Middleware\oracle_common -jre E:\apps\OracleEPM\Middleware\jdk160_35

Hyperion Planning, Hyperion Capital Asset Planning, Hyperion Workforce Planning, Hyperion Project Financial Planning 11.1.2.4.009+ (Patch 29889455)
---------------------------------------------------------------------------
This patch needs to be applied on all your Hyperion Planning application servers and Web servers of the environment. 

Download the patch and place it under apps\OracleEPM\Middleware\EPMSystem11R1\OPatch directory.

Open command prompt and apply the patch using below commands:

cd E:\apps\OracleEPM\Middleware\EPMSystem11R1\OPatch 
opatch.bat apply E:\apps\OracleEPM\Middleware\EPMSystem11R1\OPatch\29889455 -oh E:\apps\OracleEPM\Middleware\EPMSystem11R1 -jdk E:\apps\OracleEPM\Middleware\jdk160_35

Delete the tmp directory for the Planning server in: 

<MIDDLEWARE_HOME>/user_projects/domains/EPMSystem/servers/<server> 
where <server> is the Planning server (for example, Planning0).

The full path for tmp is: <MIDDLEWARE_HOME>/user_projects/domains/EPMSystem/servers/<server>/tmp.

Hyperion Calculation Manager 11.1.2.4.014  (Patch 28557058)
-------------------------------------------------------------------------------
This patch needs to be applied on all your Calculation Manager servers and Web servers of the Hyperion environment. 

Download the patch and place it under apps\OracleEPM\Middleware\EPMSystem11R1\OPatch directory.

Open command prompt and apply the patch using below commands:

cd E:\apps\OracleEPM\Middleware\EPMSystem11R1\OPatch 
opatch.bat apply E:\apps\OracleEPM\Middleware\EPMSystem11R1\OPatch\28557058 -oh E:\apps\OracleEPM\Middleware\EPMSystem11R1 -jdk E:\apps\OracleEPM\Middleware\jdk160_35

On the server where Oracle Hyperion Calculation Manager is installed, delete the cached files in the following directories:

<Middleware_Home>/user_projects/domains/<DOMAIN_NAME>/servers/<CalcMgr0>/tmp 
<Middleware_Home>/user_projects/domains/<DOMAIN_NAME>/servers/<CalcMgr0>/cache

Hyperion Financial Reporting 11.1.2.4.712  (Patch 30670918)
----------------------------------------------------------------------------------
This patch needs to be applied on all your Financial Reporting servers, Web servers and also on HFM application server (if you use HFR for reporting) of the Hyperion environment. 

To apply this patch first Uninstall the Financial Reporting Studio by going to Control Panel, Add or Remove Programs, and then uninstall Financial Reporting Studio. 

On the Financial Reporting server machines, download the patch and place it under apps\OracleEPM\Middleware\EPMSystem11R1\OPatch directory.

Open command prompt and apply the patch using below commands:

cd E:\apps\OracleEPM\Middleware\EPMSystem11R1\OPatch

opatch.bat apply E:\apps\OracleEPM\Middleware\EPMSystem11R1\OPatch\30670918 -oh E:\apps\OracleEPM\Middleware\EPMSystem11R1 -jdk E:\apps\OracleEPM\Middleware\jdk160_35

Delete the Financial Reporting precompiled jsp files located at:
<ORACLE_HOME>\Middleware\user_projects\domains\EPMSystem\precompiled\hr

Use the EPM System configurator to redeploy the Financial Reporting Web Application.  If RA Framework, OHS, or IIS are installed on a separate host, it must be patched also.

In order to run the new Oracle Hyperion Financial Reporting Web Studio, you must enable proxying. I am sure it would have already been enabled in your environment too. If not, kindly refer 'README' document of the patch.

At the end, when you start your EPM services, remember to connect to the EPM Workspace machine on patched Financial Reporting server machine. Download the Financial Reporting Studio installer from the EPM Workspace menu: From the Tools menu, select Install and then select Financial Reporting Studio and then launch the installer. Follow the installation guide to install the Financial Reporting Studio to the location you want.

Hyperion Financial Management PSU 11.1.2.4.209 (Patch 29343616)
----------------------------------------------------------------------------------------
This patch needs to be applied on all your Hyperion Financial Management application servers, HFM Web servers and also on HFR application server (if you use HFR for reporting) of the Hyperion environment.  

Download the patch and place it under apps\OracleEPM\Middleware\EPMSystem11R1\OPatch directory.

Open command prompt and apply the patch using below commands:

cd E:\apps\OracleEPM\Middleware\EPMSystem11R1\OPatch

opatch.bat apply E:\apps\OracleEPM\Middleware\EPMSystem11R1\OPatch\29343616 -oh E:\apps\OracleEPM\Middleware\EPMSystem11R1 -jdk E:\apps\OracleEPM\Middleware\jdk160_35

If you are applying this patch to version 11.1.2.4.208 or an earlier version, also execute the following sql command to upgrade the HFM schema against the Financial Management database. Use appropriate sql as per your database type.

<EPM_ORACLE_HOME>\products\FinancialManagement\Server\conf\<DB Type>_from_11.1.2.4.208_to_11.1.2.4.209_SchemaUpgrade.sql

E:\apps\OracleEPM\Middleware\EPMSystem11R1\products\FinancialManagement\Server\conf\Oracle_from_11.1.2.4.208_to_11.1.2.4.209_SchemaUpgrade.sql

In addition, you must run below by login to HFM schema:

<EPM_ORACLE_HOME>\products\FinancialManagement\Server\conf\Oracle_Create_ImportApp.sql

<EPM_ORACLE_HOME>\products\FinancialManagement\Server\conf\Oracle_Create_InsightDetails.sql

This step is required for 'Importing Application' feature. 

If you are using the extract data to database functionality with Oracle database as the target database, you will need to reconfigure DSN. To reconfigure:
  1. Select Navigate, then Administer, and then Consolidation Administration.
  2. From Admin Tasks, click Configure DSN. 
  3. Select any data source that has Oracle database as database type, and then click on Edit.
  4. Enter the database connection information, including the database server network address as Host.
  5. Click Test Connection. If successful, click on Save.

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)
---------------------------------------------------------------------------
We don't use these two components in our EPM setup. You can follow README document to apply these patches, if there components are there in your EPM/Hyperion environment.

Hyperion Data Relationship Management 11.1.2.4.350  (Patch 31420887)
---------------------------------------------------------------------------------------------
This patch needs to be applied on all your DRM application server and DRM Web services servers of the Hyperion environment.  

Make sure you have stopped the DRM services. 

Take a backup of DRM schema (Must!) before applying the DRM patch.

Save a backup copy of the drm-config.xml file found under directory
E:\apps\OracleEPM\Middleware\EPMSystem11R1\products\DataRelationshipManagement\server\config

Uninstall the existing 11.1.2.4 release:
a.    Stop the Data Relationship Management service.
b.    Verify all processes are shut down.
c.    Run the installer from that release and choose the Remove option.

Run the new setup.exe to install this patch release.

If a multiple-machine configuration is being used, repeat the uninstall and install steps above for each machine.

When using an Oracle repository and upgrading from a Data Relationship Management release prior to 11.1.2.4.330, run the following statement for the current schema owner for each application to be updated: GRANT CREATE TYPE, CREATE SEQUENCE TO <user>;

In the Configuration Console on the application controller machine, select Application, then 'Apply Updates' for all existing applications.

Make sure to save any configuration changes made in the Data Relationship Management Console. Click on save configuration to do so. 

Redeploy the Data Relationship Management Web service application (oracle-epm-drm-webservices.ear) to Oracle Weblogic. The oracle-epm-drm-webservices.ear file is located in the %EPM_ORACLE_HOME%\products\DataRelationshipManagement\api directory. This step is only required if applying this patch to an installation where the Web service application has been previously deployed. See the “Redeploying a Web Services Application” section in the Oracle® Fusion Middleware Security and Administrator's Guide for Web Services for instructions to redeploy using Oracle Enterprise Manager. 

FDMEE (Hyperion Financial Data Management) Patch Set Update 11.1.2.4.220 (Patch 25312033)
----------------------------------------------------------------------------------------------------------------------
This patch needs to be applied on all your Hyperion Financial Data Management application servers (FDMEE) of the Hyperion environment.  

Download the patch and place it under apps\OracleEPM\Middleware\EPMSystem11R1\OPatch directory.

Open command prompt and apply the patch using below commands:

cd E:\apps\OracleEPM\Middleware\EPMSystem11R1\OPatch

opatch.bat apply E:\apps\OracleEPM\Middleware\EPMSystem11R1\OPatch\25312033 -oh E:\apps\OracleEPM\Middleware\EPMSystem11R1 -jre E:\apps\OracleEPM\Middleware\jdk160_35

Additional Installation Instructions:

1.    Copy the following script files.
For Windows, copy from:
EPM_ORACLE_HOME/FinancialDataQuality/bin/executescript.bat.template 
to:
EPM_INSTANCE_HOME/FinancialDataQuality/executescript.bat

2.    If your deployment is a distributed environment where Hyperion Financial Management and Planning are on different servers than FDMEE, copy the following jar files:

Copy files from the Hyperion Financial Management server folder EPM_ORACLE_HOME\common\hfm\11.1.2.0\lib to the same directory on the FDMEE server.
Copy files from the Planning server on the EPM_ORACLE_HOME\common\planning\11.1.2.0\lib to same directory on the FDMEE server.

3. Now, on the servers where FDMEE is installed, you must delete tmp and cache files in the following directories:

<MIDDLEWARE_HOME>/user_projects/domains/<DOMAIN_NAME>/servers/<MANAGED_SERVER_NAME/tmp/

<MIDDLEWARE_HOME>/user_projects/domains/<DOMAIN_NAME>/servers/<MANAGED_SERVER_NAME/cache

Hyperion Profitability and Cost Management (HPCM) 11.1.2.4.131 (Patch 31159372)
-----------------------------------------------------
This patch needs to be applied on all your Hyperion Profitability and Cost Management (HPCM) of the Hyperion environment. 

Perform a full system backup, including EPM Architect and the Profitability and Cost Management databases. If you have Management Ledger applications, you should back them up using Life Cycle Management (LCM) in Shared Services. 

This patch must automatically re-register your Profitability and Cost Management applications, which will delete native non-Admin user provisioning.  Use Life cycle Management (LCM) in the Shared Services console to export the Native Directory under Foundation, usually located at Foundation => Shared Services => Native Directory, so you can restore it later.  
 1)  From the Shared Services console, open the Application Groups folder.
 2)  Open the Foundation sub-folder and select Shared Services.  
 3)  Export the Native Directory artifact and all content under it.  

You will need the resulting LCM export file later to restore the user provisioning.

Download the patch and place it under apps\OracleEPM\Middleware\EPMSystem11R1\OPatch directory.

Open command prompt and apply the patch using below commands:

cd E:\apps\OracleEPM\Middleware\EPMSystem11R1\OPatch

opatch.bat apply E:\apps\OracleEPM\Middleware\EPMSystem11R1\OPatch\31159372 -oh E:\apps\OracleEPM\Middleware\EPMSystem11R1 -jdk E:\apps\OracleEPM\Middleware\jdk160_35

Clear the WebLogic cache under
E:\apps\OracleEPM\Middleware\user_projects\domains\EPMSystem\servers\Profitability0

When you will start the Profitability service (Hyperion Profitability - Java Web Application) it automatically performs any required database updates after applying a new patch - there is no need to run a manual SQL script.

Invoke Profitability and Cost Management, open an application, and check in the System Information tab under Model Summary to verify that the Schema Version is 11124.153. If instead you get a Schema Version Mismatch error, report this to Oracle Support.  You can also search the hpcm.log file for SQL errors following the first recent occurrence of the string '11124.153'. If you find an error that you can resolve, the database upgrade can be performed manually after resolving the error, to complete the installation (see the Performing Manual Database Updates section below).

From the Shared Services console, import the LCM file you created earlier, to restore the native user provisioning.

Note also that any changes made previously to the hpm_ws_client.properties file to customize either of the web services sample programs will be overwritten by the patch and must be reapplied.

Optional – Performing Manual Database Updates (only when there are errors in the automatic update):
--------------------------------------------------------------------------------------------------------
If errors occurred during the automatic database updates performed during service startup, and you have identified and corrected the problem, you can follow these instructions to complete the required database updates manually.

1.    Shut down the Profitability service (Hyperion Profitability – Web Application).

Run the appropriate database update patch script for your database type.  Run the script from the Profitability and Cost Management product database/schema/user.  Capture the SQL script log output and save it.  If there are any errors, report them to Oracle Support.

Database Type: MS SQL Server 
Database Patch Files: Run the following database update script using Microsoft SQL Server Management Studio against the Profitability and Cost Management product database: <EPM_ORACLE_HOME>\products\Profitability\database\Common\MSSQLServer\create_11.1.2.4.131.sql

Database Type: Oracle
Database Patch Files: Run the following database update script in the Profitability and Cost Management product schema/user using Oracle SQL Developer:<EPM_ORACLE_HOME>\products\Profitability\database\Common\Oracle\create_11.1.2.4.131.sql

2.    Start the Profitability service (Hyperion Profitability - Java Web Application).

3.    Invoke Profitability and Cost Management, open an application, and check in the System Information tab under Model Summary to verify that the Schema Version is 11124.142.  

4.    For each Detailed application, you must re-deploy the Reporting Tables and Views.

5.    Complete any remaining steps you have not performed in the Applying this Patch section above.

Once all the patching steps are completed, do the following:
--------------------------------------------------------------------------------------------
1.    Stop all EPM services.

2.    For each of the following folders, create a backup copy of the folder, then delete all the contained files within the original folders:

apps\OracleEPM\Middleware\user_projects\domains\EPMSystem\servers\FoundationServices$\cache

apps\OracleEPM\Middleware\user_projects\domains\EPMSystem\servers\FoundationServices$\tmp

apps\OracleEPM\Middleware\user_projects\domains\EPMSystem\servers\RaFramework$\cache

apps\OracleEPM\Middleware\user_projects\domains\EPMSystem\servers\RaFramework$\tmp

apps\OracleEPM\Middleware\user_projects\domains\EPMSystem\precompiled\raframework

apps\OracleEPM\Middleware\user_projects\domains\EPMSystem\precompiled\workspace

[NOTE: The value of the above strings will actually be a digit in your environment (e.g., FoundationServices0). Depending on the deployment, the number could be 0, 1, 2, etc.]

3.    You need to clear browser's cache and temporary files on all the client/users machines.

4.    Start all EPM services and WebLogic Admin server of your EPM environment.

5.    Validate the Hyperion applications on Microsoft Edge and Google Chrome 80+ browsers.

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

There is one issue observed in EPMA that you can read about in below article:



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

Friday, October 2, 2020

// // 2 comments

FDMEE 11.1.2.4.220: Essbase Export data file has changed naming convention

It has not been long since we applied FDMEE (Financial Data Quality Management, Enterprise Edition) Patch Set Update 11.1.2.4.220 (Patch 25312033) in one of our TEST environments. Earlier it was on version FDMEE 11.1.2.4.210. The patch got successfully applied but during environment validation, we observed that for data load to Essbase target applications, the data export files (.dat) coming into the FDMEE outbox folder have changed its naming convention. 

This naming convention change is there only for Hyperion Essbase data files. HFM (Hyperion Financial Management) application data files continue to be using the same old naming convention. 

On investigation, we noticed it's happening exactly after we applied FDMEE (Financial Data Quality Management, Enterprise Edition) PSU 11.1.2.4.220.

What is the issue?

Earlier, in FDMEE 11.1.2.4.210, for Essbase Target applications data load, the export data file names were in the format: 

<Essbase Application Name>_<Process ID>.dat. 

But now in FDMEE 11.1.2.4.220, the data file naming convention has changed to the format: 

<Essbase Application Name>-<Essbase Database Name>_<Process ID>.dat

We see Essbase Database Name has been added with Essbase Application Name in the .dat file name.

You can see below how all the Essbase export .dat files had started to generate with the new naming format after a particular date:


This was also confirmed by comparing the data load process logs of FDMEE 11.1.2.4.220 and 11.1.2.4.210 for the same FDMEE Location or Essbase target application, as shown below:

FDMEE 11.1.2.4.210 process log:

FDMEE 11.1.2.4.220: Essbase Load Outbox data file (.dat) has changed naming convention

FDMEE 11.1.2.4.220 process log:

FDMEE 11.1.2.4.220: Essbase Load Outbox data file (.dat) has changed naming convention

What is the impact?

This naming convention change for Essbase target applications had broken one of our automation processes for Essbase application data load. One impacted script identified was AftLoad.py which was called after the data is loaded to the Essbase target application. In that script, it was hardcoded to read the generated data file in format <Essbase Application Name>_<Process ID>.dat.

Investigation?

As per Oracle documentation, we know that data is written to a data file in the outbox directory of the application (defined in System Settings) in the format <APPLICATION NAME>_<PROCESS ID>.dat. It is then loaded to your Essbase target applications. 

Details of our target applications (Data Management > Setup > Register > Target Application) are stored in AIF_TARGET_APPLICATIONS table in the FDMEE database. 

When we query this table for the below columns:

SELECT TARGET_APPLICATION_TYPE, TARGET_APPLICATION_NAME, ESSBASE_DB_NAME, APPLICATION_NAME FROM AIF_TARGET_APPLICATIONS WHERE TARGET_APPLICATION_TYPE = 'ESSBASE';

We get the following output:

FDMEE 11.1.2.4.220: Essbase Load Outbox data file (.dat) has changed naming convention

Values in the three columns come as: 
  • TARGET_APPLICATION_NAME  = Essbase Application Name
  • ESSBASE_DB_NAME                    = Essbase Database Name
  • APPLICATION_NAME                   = Essbase Application Name-Essbase Database Name
So apparently, to generate the Essbase export data file, FDMEE 11.1.2.4.220 is taking the value of column APPLICATION_NAME while FDMEE 11.1.2.4.210 was taking the value of column TARGET_APPLICATION_NAME. That's why the naming convention of Essbase export data files has been changed in FDMEE 11.1.2.4.220. 

HFM export data files names are unaffected because, for HFM, both APPLICATION_NAME and TARGET_APPLICATION_NAME columns values are the same as obvious:

FDMEE 11.1.2.4.220: Essbase Load Outbox data file (.dat) has changed naming convention

What Oracle said?

We raised an Oracle SR and below is what they updated:

We have cross verified this with Product Development Manager and they said that this is an accepted behavior in FDMEE (Financial Data Quality Management, Enterprise Edition) 11.1.2.4.220 PSU as the Developer has changed the backend code for FDMEE functionality with Essbase. So you need to modify your automated scripts accordingly. 

So what is the workaround?

Well, as advised by Oracle we have modified our automated scripts like AftLoad.py and related batch scripts to incorporate the new naming convention of Essbase export data files. 


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

Wednesday, August 26, 2020

// // 1 comment

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

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:

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

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;

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

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:

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

  • 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;

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

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

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

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; 

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

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:

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

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):

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

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

Wednesday, August 12, 2020

// // Leave a Comment

Automation of 'Maintain Process Tables' System Maintenance Task

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

Manual Implementation: 


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:

Automation of 'Maintain Process Tables' System Maintenance Task

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:

Automation of 'Maintain Process Tables' System Maintenance Task

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):

Automation of 'Maintain Process Tables' System Maintenance Task

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

Wednesday, July 29, 2020

// // 2 comments

Automation of 'Maintain Application Folder' 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:

Automation of 'Maintain Application Folder' System Maintenance Task

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; 

Automation of 'Maintain Application Folder' System Maintenance Task

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

Automation of 'Maintain Application Folder' System Maintenance Task
  • 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:

Automation of 'Maintain Application Folder' System Maintenance Task

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):

Automation of 'Maintain Application Folder' System Maintenance Task

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