By Cameron Lackpour
What are Stupid EPM Tricks?
To those of you reading (I am writing this in the hope that someone is reading this but who knows?) this, there may be a small question in your mind as to the title. Why oh why oh why would anyone want to read about something stupid? Isn’t there more than enough of that in everyone’s life without actively seeking out more?
I don’t have a late night TV show, but I stole modified the concept to include those EPM tricks, techniques, and concepts that drive me absolutely bonkers till I figure them out. Sometimes they’re obvious on reviewing, sometimes they’re awesome, sometimes they’re an example of a tightly fitted set of cognitive blinders, but in the spirit of David Letterman, they’re all Stupid. (So really they aren’t, but it’s sort of a catchy title and it certainly captures the frustration I sometimes feel. There is actually useful information here.)
Some of my lucky (?) colleagues get these as part of an occasional e-mail blast. Now you are the lucky ones as the best of the Stupid EPM Tricks (so that makes them…marginally stupid?) will now be a feature of the Hyperion SIG’s newsletter.
I hope you do find these useful and get some value from them – they reflect my real world solutions to…Stupid Problems.
Stupid Migration Trick
The 220.127.116.11 and above releases support connecting development and production environments together so life cycle management exports immediately show in the connected environment. In my case we were not allowed to connect these environments. Your friendly Hyperion infrastructure contact can help you with connecting the environments.
I had to do a migration in a challenging environment (aren't all environments challenging to one degree or another, but I digress yet again) and this time the challenge was: no drive mappings between Windows servers. As I was using LCM to migrate out of dev and into prod, this was frustrating -- how oh how would I get the Planning, Shared Services, and Financial Reports artifacts (and the Essbase exported data) out of dev and onto prod? This is an easy one and maybe you saw it coming: Workspace.
Here's the idea: Use Workspace itself to upload a zipped version of the folder to the source Workspace environment, download it to a client machine laptop, and then upload it to the target Workspace. It sounds more complicated than it is.
The big “trick” with this is as follows:
- You must have a username that allows you to log onto the source server via Terminal Services.
- Log on to the box with Terminal Services.
- Zip the LCM export folder(s). Upload to the source Workspace environment as a file.
- Switch back to your client, log onto the source Workspace, and download the zip file to your desktop.
- Log onto the target Workspace on your client and upload the zip file.
- Log onto the target server using Terminal Services.
- Log onto Workspace on that target server.
- Download the zip file into the target
- Unzip the files. They are now ready for import via Shared Services Lifecycle Management.
If there isn't an issue with connecting to dev Workspace from prod, you could even skip steps four and five.
See, I told you, it's Stupid. Even more stupid is not being able to map drives but this client (who shall remain unnamed) really locks things down. Short of involving a special dispensation from IT every time I wanted to migrate an artifact or sticking the files out on the web via Google or Box or something else that would likely get me fired, I couldn't figure how else to do it. One last thing -- for giggles I tried zipping and uploading Essbase data to Workspace -- it took it like a champ. I'm sure at some point Workspace falls over if the import size is really big, but as far as I can tell, it handled this. I do delete the zips when I'm done as there's no point in tempting fate.
And that’s it.
Stupid? Not at all. A trick? You bet, and it practically made me laugh out loud (thus confirming the client’s perception of me as being a wee bit odd) when I figured it out. I hope you enjoyed it as much as I did.