How do you set up Email Notifications to the end users in Hyperion Planning.

Hi,

We are using Hyperion Planning 11.1.2.2 and the client has asked us to set up the Email notifications. Find below are the steps to setup the Email Notifications.

Step No:1

Check Connectivity:
Confirm that you can successfully send an email from the Planning server.  Security settings on the mail server may block attempts to relay email from a server that does not usually send email. To check this, send a test email from the command line on the Planning server using the instructions below.

Open a command line window and enter the commands after the >> characters. The text on lines without the >> is what the server will respond with. Make sure you enter the commands correctly as you will not be able to use the backspace key. Replace "smtpserver_hostname" with the hostname of your mail server, and replace "your_email@your_domain.com" by an email address you can check. Notice that the last line of the body data entry section should be a single dot on its own line.

 >> telnet smtpserver_hostname 25
220 smtpserver_hostname (...)
>> helo smtpserver
250 smtpserver_hostname
>> mail from:anyone@anydomain.com
250 2.1.0 Ok
>> rcpt to:your_email@your_domain.com
250 2.1.5 Ok
>> data
354 End data with .
>> subject:test message
messagebody ...
.
250 2.0.0 Ok: queued as (...)>> quit
221 2.0.0 Bye
Connection to host lost.

You should receive the test email. If you do not, the issue is most likely with the mail server configuration or security settings. Contact the IT department for help troubleshooting the issue.

 

Step No:2

Configuring Planning.

1) Log into the Planning application as the application owner (typically "admin"). IMPORTANT NOTE: The email server details must be set up by the application owner.

2) Enter mail server host name under Administration > Application Settings > Advanced Settings > System Settings tab and Save. Use the same host name that you used in the connectivity test above.

3) Set up default settings for users: Administration > Application Settings > Current Application Defaults > Email Options > set Workflow and Tasklist Notification to "Yes" and Save

  

Configure Users In Planning

1. Log into the Planning application as the application owner (typically "admin")
2. File > Preferences (or File > Preferences > Planning if accessing user preferences via Workspace)
3. In the "Email Options" section, enter an email address. This need not be a real working email address but it must be syntactically valid (e.g. noreply@yourdomain.com). All email is sent as the application owner, so this user must have a valid email to act as a "from" address or email notifications will not work.
4. In the same screen, make sure the "Workflow and Task List Notification" is set to "Yes"
5. Have all other Planning users check their user preferences under File > Preferences (or File > Preferences > Planning if accessing user preferences via Workspace). In the "Email Options" section they should enter their email address, and confirm that "Workflow and Task List Notification" is set to "Yes" (in most cases it should be, since this is the default)

 Test

1. Log into the Planning application as an administrator
2. File > Workflow > Manage Process
3. Select a Scenario and Version and click "Go"
4. Start a Planning Unit by clicking on the "Start" radio button for one of the listed Entities
5. Click on the "Details" link next to the started Planning Unit
6. Click on "Change Status" and promote the Planning Unit to another administrator. This new administrator user should receive an email notification.
7. After the test is complete you can stop the Planning Unit again by clicking the "Exclude" radio button

Updating HFM Application Server Keys on a Large HFM Application

Recently I had to update the HFM application server keys on a big HFM application running on version 11.1.2.3, running on a single dedicated Win2008 server (64 bit) CPU 2 X 8 way 3.0 GHz 32GB RAM. The backend is Oracle 11g. End user loads are moderate—the typical concurrent number of users topped out at around 10. The HFM application dimensionality was in the medium range:

2 scenarios

400+ unique entities

35 currencies

4700+ unique accounts

6000+ unique custom1

33000+ unique custom2

We were working with fairly straightforward business rules without too many complex calculations that are being performed.

The data was coming in through an SAP G/L data load. Data density was high, and in order for FDM to process it, we had to divide the data load into two files. In fact, the SAP data files were so large that the FDM batch loader was the only way to load them; the manual user-driven load would time-out at import.

How I updated the keys:

To get started, I read through the Oracle HFM tuning guide (Dec 2013 updated) and made some modifications that it suggested.

(1) Memory settings modifications:

MinDataCacheSizeInMB set to 2000

MaxDataCacheSizeInMB set to 4500

MaxNumDataRecordsInRAM set to 30000000

(2) Thread settings modification:

NumConsolidationThreads set to 8

All four registry settings were added as new DWORD decimal values at this location — HKEY_LOCAL_MACHINE\SOFTWARE\Hyperion Solutions\Hyperion Financial Management\Server.

Additionally, since an Oracle provider OLE DB was also a part of the setup, we made a modification that Oracle suggested for Statement Caching to mitigate memory leak issues (Oracle Doc ID 761418.1).

Next I performed several rounds of testing by running consolidations in the HFM app and saw about 1/4 to 1/3 time improvement. For example, consolidation all with data on one primary entity hierarchy for one period: before 20-21 minutes, after 13-15 minutes.  After the registry memory settings update, you will see the the HsvDataSource process on the server consume more memory as you execute tasks in the HFM app that calls up new subcubes.  When it reaches the maximum memory threshold and you continue to execute subcube tasks in the HFM app, it will release records to free up memory for new subcubes to load.  In System Messages or on the HFM event log, you will see the “FreeLRUCachesIfMoreRAMIsNeeded” messages.  I did not see those messages often after the modifications.  According to the Oracle tuning doc, I could ramp up the memory settings even more since the server has 32GB RAM but I’ve left it at these levels because the testing was done on the DEV box (less resources). So perhaps we might go back and push it up if the end users give us feedback.

On opening data grids, web forms, and running Financial Reporting reports, what we’ve seen with the new code base on 11.1.2.x is that it’s slightly slower. The modified memory settings do help speed it up a bit after enough subcubes have been loaded into memory.  Nevertheless, the performance on loading data grids in 11.1.2.x is somewhat slower compared to 11.1.1.3, possibly due to the change in code.

Our objective going into this process was to maximize the benefits of moving onto 64-bit platform with plenty of memory resources.  I wanted to realize faster consolidation processing time and the testing results have shown that we’ve achieved a significant improvement.  Note that your results may not match up to what I’ve described and it will vary due to factors such as the application design, HFM rules design, and hardware setup.

Hyperion Planning - Version 11.1.2.2 - GRID_PARTIAL_FETCH_SIZE

Goal
Is there a way to increase the default amount of data retrieved when the form is opened, so that users don’t run into this issue " Fetching Data...." when they scroll down on a form? 

Solution
1.In EPM Workspace open Administration -> Application -> Properties -> Application Properties
2.Click add and in new row enter a new application parameter GRID_PARTIAL_FETCH_SIZE
3.Value should be in format ‘row size, column size’ (e.g. 25,20 means forms when opened will load by default 25 rows and 20 columns). If the property is not defined, the default value is 25 rows and 17 columns. If a user navigates beyond this data-set, message ‘Fetching data’ appears and next data set is retrieved.
4.After adding the property, re-start of Planning server is required
5.This change needs to be made for every application.
6.Since this is an application property, this affects all users and the property value needs to be chosen carefully. Increasing it to a very high value can have an impact on performance on the client side, because this would increase client DOM size.