1. FDM to FDMEE Migration The Path to Ensure Success
Michael van der Merwe
My-EPM.COM

2. About My-EPM.COM 20 years BI/DW/EPM experience
10 years Upstream/FDM/FDMEE
Ex-Hyperion/Oracle Global Lead
Focus on FDM/FDMEE/DRM
Implementation/Design/Training
About My-EPM.COM

3. FDM to FDMEE Migration - Agenda
FDM & FDMEE - a short history
New-build vs Migration Utility
Post-Migration steps
Turning VB into Jython
Customer Case Studies
Improvements & Gaps
Q&A

4. FDM & FDMEE – a short history
Final FDM version x
Only FDMEE available from x
FDM & FDMEE available x
FDMEE x added functionality with each patch (PSU)
Most reliable, stable & feature-rich versions from
onwards
FDMEE offers 90% parity to FDM, with additional helpful features

5. New-build vs Migration Utility

6. Re-build vs Migration Utility
Re-Build when…
Historical data not required, target app data migration sufficient
< 25 locations/import formats (use Excel Interface)
Rebuild effort < 5 days
Migration Utility when…
Historical data is required
> 25 locations/import formats in FDM app
Rebuild effort > 5 days
You don’t mind a little ODI tinkering

7. Migration Utility
Available from only, onwards suggested
Requires setup procedure in ODI Studio (make sure it’s installed during main EPM install), use the latest version of the utility, first version had ‘issues’
Read utility readme and follow procedure
Use copy of source Prod FDM app DBs as source for Migration – use latest date possible to prevent data and mapping gaps (map freeze)
First set up & test FDMEE and ensure it’s stable before commencing migration

8. Migration Utility
Clean up FDM apps before making copies of PROD DB’s for migration (consolidate into one app if possible)
For multiple source FDM apps, use migration prefixes for location names when running migration utility to prevent overlap
Create target applications in Workspace with same naming conventions as PROD FDM target apps
Run SETUP_DATA for ranges of 1-3/1-6 months, not all periods at once (process prefers smaller chunks of data)
Use Application folders to separate access to app folders after migration

9. Post-Migration steps

10. FDM Application Objects Auto-Convert
Target Application
Global Categories
Application Categories
Global Periods
Application Periods
Logic groups
Check Entity Group
Check Rule Group
Import Format
Locations
Data Mappings (#SCRIPT maps must be rebuilt, SQL or Jython)
Data along with its workflow status, maps, and drill regions
YES, these items are all migrated, but won’t all work without intervention!!
Orphan objects will be skipped

11. Post-Migration steps EXTRACT_SETUP converts metadata – run first
EXTRACT_DATA converts data – run second
Manual conversion steps:
ALL scripts (incl event, import, map scripts)
ALL logic accounts
Check reports might have to be re-created
ALL custom reports
Check period, category mapping and app settings
Security, Orphan Locations, ControlReview Groups and Orphan import formats are NOT converted
Location data load rules’ import files set to ‘sample.txt’
Security via Shared Services Security Groups
Copy Inbox from source system to target
Sign-Switch tag could exist on dimensions other than Account

12. Post-Migration steps – Import Formats
Six types of delimiters for source files:
Comma ,
Pipe |
Exclamation !
Colon :
Semi-colon ;
Tab
All others auto-substituted with comma, all file data load rules have Sample.txt set as default source file

13. Post-Migration steps – Maps
All Conditional map expressions must be re-built
SQL (more efficient) or Jython syntax only
If adding additional dimensions, define values in import format and add maps on dimensions
Refresh members option on Dimension maps if target does not display or target metadata changes
Multi-Dimension maps with/without Lookup dimensions could offer a better alternative to conditional
map scripting

14. Post-Migration steps – Reports
Report names and SQL defined on interface
Report RTF’s defined in BI Publisher Desktop MS Word Add-in (separate set-up)
Use report query XML export as test data in BIP
Upload finished RTF & XLF files for report to work

15. Turning VB into Jython

16. Turning VB into Jython - Import Scripts
The equivalent of Import – Data Pump scripts in FDM
Import Integration scripts replaced by Open Interface/Universal Data adaptor and BefImport event script
Import scripts used to manipulate data during import process
Execute during import process when assigned to import format used by location and data load rule
Every line in source data file is evaluated
Avoid temptation to overuse import scripts
Parsing strings that cannot be parsed by an import format
Temporary variables storing header information
Data mapping should be done in maps, not import scripts

17. Turning VB into Jython – FDM vs FDMEE
FDM (VB)
Purpose: If there is a profit center in the file capture it as Entity, otherwise use Entity field
FDM source entity result:
PC1
PC2
300
PC4
PC5
FDMEE (JYTHON)
Purpose: If there is a profit center in the file capture it as Entity, otherwise use Entity field
FDMEE source entity result:
PC1
PC2
300
PC4
PC5

18. Turning VB into Jython – FDM vs FDMEE
FDM (VB)
Purpose: Select CR value from CSV and convert sign if DR value is empty
FDMEE (JYTHON)
Purpose: Select CR from CSV value and convert sign if DR value is empty 18

19. Turning VB into Jython – FDM vs FDMEE
Remove spaces in strfield
Replace space and return 2nd field
Test location name from POV
Properties of fdmContext: APPID,CATKEY,CATNAME, EXPORTFLAG, EXPORTMODE, FILENAME, 
IMPORTFLAG, IMPORTFORMAT,IMPORTMODE, IMPSTATUS, 
INBOXDIR, LOADID, LOCKEY,LOCNAME, MULTIPERIODLOAD, 
OUTBOXDIR, PERIODKEY, RULEID, SCRIPTSDIR, SOURCENAME,SOURCETYPE, TARGETAPPDB, TARGETAPPNAME,
USERNAME

20. Customer Case Studies

21. Customer Case Study – Top 3 SA Insurer
3 legacy FDM apps, 4 years’ data from one, 2 years from remaining 2, including one HFM/FDM QMR app
Approx 3million rows of data per year
All locations had unique names, simplifying migration, no prefixes used, added 2 custom dimensions (total of 6)
Custom QMR validation scripts and reports converted
Post-migration updates in FDMEE DB included:
Target application/dimension resets
Doubled sign-switch due to sign-switch on other dimensions than account
Map, Import format, Logic Account, Check report updates required
Import scripts with DR/CR selection had to make special provision for text-formatted values (“100,000.00”)

22. Customer Case Study – UK TV Channel
One FDM application, data migration not required, app rebuild in FDMEE
Custom EBS connection scripts in FDM
All import scripts combined into BefImport eventscript (no UDA available in )
Dynamic Jython-based connection and SQL queries
Significant improvement in import processing speed

23. Customer Case Study – Fortune 100 Multi-national
One Upstream application, data migration not required, app rebuild in FDMEE
2 years Enterprise data migrated to HFM, using multi-load CSV’s, all data in one data set, additional load for adjustments
FDMEE data mapping was the easy part, HFM meta data structures need to be stable first
SAP adapter setup still a challenge, can work but should be attempted in a later phase

24. Improvements/Gaps

25. Improvements & Gaps
Data Load Rules / Multi-Dimension maps offer more dynamic import and mapping options
Import/Validate view on single screen offers improved data visibility
Workspace integration offers seamless interface
Improved scalability & performance via ODI engine
Universal Data Adapter improves custom DB imports
Import field formatting more sensitive in Jython script
Jython dev lacks a Workbench – diy with Eclipse etc
Event scripting requires different approach vs FDM
FDMEE Service is memory-intensive
No separation of FDMEE applications in same system

26. Q&A

27. Contact: My.epm.com@gmail.com www.my-epm.com