ROBOCOPY Backup files over Network paths and ERROR 5 (0x00000005) Copying NTFS Security to Destination Directory-Access denied

As part of the annual EPM DR Rehearsal, we got a requirement to move Prod Application backup files from PROD Network location to DR network path.

In this post, we will see how we can RoboCopy EPM backup files from one Network location to another network path.

Why ROBOCOPY?

If you are copying files from one network path to another and you have Windows Vista or later operating systems then Robocopy is a better choice than any other option. Because you don't need to bother with drive mappings, since it handles UNC paths just fine.

Robocopy is not a third party software. It's native (built-in) to all versions of Windows Vista and later.

It is usually far more reliable than xcopy command, and provides a lot more options.

Robocopy is tolerant of interrupts during copying i.e. it can pick up where it left off if it gets stopped for some reason. It has the ability to recover from certain types of network hiccups automatically.

Read Link1 and Link2 for more details about ROBOCOPY and its various options.

Script using ROBOCOPY to copy EPM backups from PROD to DR network path:

@echo off

for /f "delims=" %%a in ('wmic OS Get localdatetime ^| find "."') do set "dt=%%a"

::Format the WMIC command output in DDMMYYYY format

set "YY=%dt:~0,4%"

set "MM=%dt:~4,2%"

set "DD=%dt:~6,2%"

set "today_date=%DD%%MM%%YY%"

::Define Source path

set sourcepath1=\\PROD_Network_Share\data\EPM_Backups\%today_date%

set sourcepath2=\\PROD_Network_Share\data\EPM_Backups\DataZip

set sourcepath3=\\PROD_Network_Share\data\EPM_Backups\Scripts

::Define Destination path

set destinationpath1=\\DR_Network_Share\data\EPM_Backups_Copy\%today_date%

set destinationpath2=\\DR_Network_Share\data\EPM_Backups_Copy\DataZipCopy

set destinationpath3=\\DR_Network_Share\data\EPM_Backups_Copy\ScriptsCopy\%today_date%

::Define Log path

set logfile=E:\Admin\Prod_To_DR_Copy.log

::Run RoboCopy commands

REM Copy all the files, folders and sub-folders from source to destination

robocopy %sourcepath1% %destinationpath1% /E /COPY:DAT /NP /LOG+:"%logfile%"

REM Copy today'sdate(DDMMYY).zip file from source to destination

robocopy %sourcepath2% %destinationpath2% %today_date%.zip /COPY:DAT /NP /LOG+:"%logfile%"

REM Copy all the files with extensions .sh, .mxl, .ksh, .scr from source to destination

robocopy %sourcepath3% %destinationpath3% *.sh *.mxl *.ksh *.scr /COPY:DAT /NP /LOG+:"%logfile%"

Below is what each ROBOCOPY command options used above means:

• /E = Copy files including subfolders (even empty ones)
• /COPY:copyflag[s] = what to COPY for files. Here we have selected DAT: D=Data, A=Attributes, T=Timestamps 
• /NP = No Progress - don’t display % copied text in logfile; this keeps filesize down. 
• /LOG+:logfile = Output status to LOG file (+= append to existing log).

ERROR 5 (0x00000005) Copying NTFS Security to Destination Directory. Access denied

When I was trying to figure out the right set of options for ROBOCOPY command, I encountered this error multiple times.

This error is usually caused by RoboCopy trying to copy the security settings of the files, and this causes some mismatch regarding the file permissions. 

There is a /B switch in RoboCopy for copying in backup mode but Backup mode cannot circumvent explicit NTFS deny ACL’s if the copier isn’t the objects’ owner.

Solution: Use /COPY:DAT only

Option /COPY:copyflag[s] can take multiple values based on what you want to copy for files. To Copy ALL file info (equivalent to /COPY:DATSOU), there is an option /COPYALL.

To overcome the above-mentioned error, you should use /COPY:DAT instead of the /COPYALL option, because /COPY:DAT  ignores the NTFS access control lists (the COPY:S parameter) of the files you're copying. 

This works because /COPYALL is equivalent to /COPY:DATSOU, D=Data, A=Attributes, T=Timestamps, S=Security=NTFS ACLs, O=Owner info, U=aUditing info. While we mainly need Data and Timestamps of the files for EPM backups.

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

Send PowerShell email from Windows batch file without creating separate email.ps1 file

In this article, we will see how we can send a PowerShell email from the Windows batch file without creating any separate email.ps1 file.

Suppose you have a batch script to perform a certain task and once that task is completed you want to be notified through an email alert.

One way to achieve this is by creating a separate email.ps1 file and calling that email.ps1 from your batch file. You can find multiple solutions on Google for this approach. But if the purpose is just to send an email alert with an attachment like a log file or with some text in the email body then why to go for creating another email.ps1 file.

You can simply insert the below code at the end of your batch script or with some conditional statements to send an email alert within the batch script:

:: Send Email using PowerShell

Powershell.exe -command "& {Send-MailMessage -From Admin@company.com -To users@company.com -Subject 'Prod Hyperion Backup Copy to DR for DR Rehearsal' -SmtpServer 'smtpserver.company.com' -Body 'PFA log file consisting of details of PROD Hyperion Backup files copied to DR Network path' -Attachments 'E:\Data\Prod_DR_Copy.log'}"

Here:

• '&' is the call operator. The call operator (&) allows you to execute a command, script, or function.
• Change the parameter values (To, From, Subject, Body, SmtpServer, Attachments) as per your requirement.  

There are many other parameters that you can add to the above command as per your need. Read this Link1 and Link2 for more details.

Make sure you copy and paste the above code as it is. Because on some occasions, I have noticed that using double quotes ("") in place of single quotes ('') will throw PowerShell error:

Send-MailMessage :  A positional parameter cannot be found that accepts arguement "SomeWord"...

It happens because the PowerShell command processor strips your double quotes and your "SomeWord" appears as a parameter to Send-MailMessage. So to avoid this error, you need to escape double quotes in your command.

The best way is to use single quotes ('') in your command as given above but If you really want to use double quotes for whatsoever reason, then use it like below by escaping double quotes ("") in -Subject and -Body parameters:

Powershell.exe -command "& {Send-MailMessage -From Admin@company.com -To users@company.com -Subject \"Prod Hyperion Backup Copy to DR for DR Rehearsal\" -SmtpServer "smtpserver.company.com" -Body \"PFA log file consisting of details of PROD Hyperion Backup files copied to DR Network path\" -Attachments "E:\Data\Prod_DR_Copy.log"}"

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

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 process log:

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:

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:

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

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