Scheduling FDM Tasks – A Second Option

In my last post I introduced you to the FDM Task Manager which can be used to schedule scripts to execute on a defined timeline.  While the Task Manager addresses the majority of needs/requirements, there are instances when a more robust scheduling solution is required.  For example, a batch process that should only execute on business day 1-5.  The FDM Task Manager has no sense of the business day.  While a custom solution could be implemented in FDM to maintain a close calendar, you may already have an Enterprise level scheduling solution – like Tidal – that includes this level of business intelligence.

So how can you have a 3rd party tool – including Windows Scheduler – execute an FDM script? There is another component of FDM called UPSShell.  UPSShell enables FDM custom scripts to be executed from a command line and/or batch file.  In the Shared Components directory of FDM, there is UPSShell.exe.  Double-clicking on the executable seemingly does nothing.  However open an instance of Notepad and select Edit -> Paste

Ok, great you have the format of the call but what does each section mean?  Let’s walk through it.  The first section is the path to where the UPSShell object is located:

C:\Oracle\MIDDLE~1\EPMSYS~1\products\FINANC~1\SHARED~1\upsShell.exe 

Next are the parameters for which script to execute:

CustomScriptEx=AppName~UserID~PW~DOMAIN~LoadBalancerName~LogDirectory~ScriptName~LanguageCode(Default=1033)~EncodeUnicode(Default=0)

Let’s break this down a little further.

  • CustomScriptEx: This is the keyword to execute a custom script.  You should not change this.
  • AppName:  This is the name of the FDM application in which the script exists
  • UserID: This is the user name that will be used to login to the application and execute the script.  This user must have access to the application.
  • PW: The password for the user ID.  This will be stored in plain text.  More on this in a moment.
  • Domain: The domain for the User ID.  This should match how you log into the FDM web interface – i.e., if blank on the web, blank in the call.
  • LoadBalancerName: The name of the FDM load balance server
  • Log Directory: The path to where the log file for the shell execution is stored.  This does not have to be the log directory in the Outbox
  • ScriptName: The name of the FDM custom script to execute.
  • LanguageCode: The language of the application.  1033 is English.
  • EncodeUnicode: If the scripts are encoded in Unicode.  0 = False.

So one of the first questions I get is, “I don’t like the password being in clear text, can I mask it?”  The answer is potentially.  Because the UPSShell can be executed from a command line, it can accept arguments.  So you can create a process that encrypts the password and then call the UPSShell execution using the encrypted password.


While the above obviously doesn’t show an encrypted password, it shows you an approach that could allow you to pass an encrypted password.

One final note, you cannot call any custom scripts that require parameters to be passed since there is no mechanism to pass the parameter to the FDM application.  Instead you would need to execute another script which makes a call to the script that requires the parameters.  The script executed from the UPSShell would need to supply the parameters to the script which it is calling.

Once the batch (.bat or .cmd) file is created, it can be executed by any scheduling program that allows the execution of a batch file.  And there you have it, like most things in FDM, there are multiple ways to schedule the execution of a script – FDM Task Manager and the UPSShell object.  As always, feel free to comment with questions or commentary on how you use these different methods to streamline your application.

This entry was posted in Out of the Box Functionality and tagged , , , , . Bookmark the permalink.

One Response to Scheduling FDM Tasks – A Second Option

  1. Curro says:

    Hi Tony, great blog.

    Just few comments about batching upsshell.

    In the past, I remember we had some issues with return code. In some situations, upsshell call was returning 0 even if there were errors, so we had to check if the error file existed.

    For password, we used a system variable which was only accessible by the local admin.

    @echo call D:\Hyperion\products\FinancialDataQuality\SharedComponents\upsShell.exe CustomScriptEx=FDMDEV~plnadmin~%%HYPPWD%%~~mg1vappz07~D:\FDM_DATA\FDMDEV\Outbox\Logs\UpsShell~FDMBatchProcess~1033~1
    @call D:\Hyperion\products\FinancialDataQuality\SharedComponents\upsShell.exe CustomScriptEx=FDMDEV~plnadmin~%HYPPWD%~~mg1vappz07~D:\FDM_DATA\FDMDEV\Outbox\Logs\UpsShell~FDMBatchProcess~1033~1
    set rc=%errorlevel%
    if /i “%rc%” EQU “0” goto CheckErrFile
    if /i “%rc%” NEQ “0” exit %rc%
    :CheckErrFile
    if exist “D:\FDM_DATA\FDMDEV\Outbox\Logs\UpsShell\plnadmin.err” exit 1
    exit 0

    HTH

    Regards!

Leave a Reply