For a month or so around June 15, I we were helping out the Hackett Group at their Seadrill engagement.
They needed to be able to load the exact same trial balance dataset that was beign loaded to HFM, into their new Account Reconcilliation Manager (ARM) product.
We exploited the fact that the data was beoing loaded via FDMEE, usign the Open Interface Adaptor table so that it was retained, and used to also automatically fire off a load of same data into ARM.
One of my client just came across this nasty little Essbase 'feature'...
They have a DR strategy that includes the shipping of Essbase transaction logs to DR server and apply every hour. However they found that the Cube on the DR had different data to their live production cube.
After much investigation it was found to be due to execution of Calc scripts that use Essbase Substitution Variables. Unlike Business Rule execution it appears that on the DR server the calcs will utilise the local Variable settings rather than what is set on the Primary.
They do replicate the .SEC file each evening (and hence the variable values) but if they change the typical variables (e.g. CurrYr or CurrPer) the transaction apply at the DR uses the old variables.
Nasty. They have raised an enhancement request!
At M&G used FDM to decode the XML Currency rates feed from Reuters to derive the required rate combinations and other fields required for loading into SUN GL, for dailiy Spot, Monthly Spot and (calculated) Monthly Average.
A handy new use for a tool they were already using. The Mapping feature in FDM allows easy setting of rate variance tollerances, mapping to target account ranges, realisation account, etc..
Since August I've been pretty much full time helping Simon and his team out at M&G both with Infrastructure and Integration.
The 184.108.40.206.500+ set of patches has been applied, and the great work that was done by Edgewater Ranzal to create HPCM based fully allocated Plan data has been enhanced to run more of the HPCM elements in parallel (e.g. ASO Genealogy). These speed improvements have allowed a fully allocated 48 period rolling forecast to become viable via overnight processes.
Some of the data movement back and forth between the BSO and ASO cubes has also been cut out by use of ASO Reports, in place of the JExports. All good stuff, and a great team to work with.
During July and August I was able to help Rexam migrate from 220.127.116.11 to 18.104.22.168.500+ (yes I know it does not show that as a upgrade path, but I found no need to upgrade to 22.214.171.124 first).
The upgrade went really well, with the new EPM configuration tool accepting most of the existing artefacts and security seamlessly from the EPMData folder or the migrated schemas.
There were a only a few gotcha's - esspecially arounf Essbase and EAS connectivity... consider doing your Essbase artefact copies (via EAS) before applying the .500+ essbase patches as after that EAS will not connect to the older versions of essbase, and it will need to be a filesystem copy.
As usual there are some new issues with the new release. These are the ones we spotted...