Moving an application tither and yon
Moving applications across environments is part and parcel of practically any CPM vendor’s tools. It’s here in production and I want it to be there migrated back into development. Or the other way around. Or across servers. Or to a laptop (for we consultants). Whether your team does the moving, or your IT department does it, or your managed service provider does it, or if indeed your software vendor’s cloud team does it, the key bit is that someone does it. Also, it could be you who does the moving.
If you think this is hard, or requires many hours, or is fraught with the potential for error (erm, except for the self-harm Yr. Obt. Svt. inflicts upon himself as I stumbled through this), you’re wrong. It’s dead easy with OneStream.
Let’s do this in steps.
Step the first, extract the application for migration
Just a note – the process I’m going to illustrate below will be for metadata (dimensions, CubeViews, security, dashboards, etc.) only. There’s a separate step that extracts data and I’ll cover that in some later post.
Just another note – this is from an honest to goodness customer application and I’ve redacted the application name. Does it make you feel better that I’ve preserved confidentiality or engender mild anxiety that I’m doing this with a live system? Omelettes are not made without breaking eggs. τοῖς τολμῶσιν ἡ τύχη ξύμφορος. Fools rush in where angels fear to tread. Per ardua ad astra. Etc.
With that, let’s log into the source application, aka OneStream XXX Dev.
Export the app – all of it: members, calcs, forms, dashboards, data management jobs, security, work flows, kitchen sink, etc. — all bar the data — by navigating to Application->Load/Extract:
Select “Application Zip File”:
Save it to a file:
We now have a local copy of the application ready for migration.
Re benchmarking: on my not-terribly-quick-but-adequate-enough laptop, exporting that real application took 40 seconds. That’s pretty fast. It was faster in the OneStream XF Cloud, powered by Microsoft Azure.
Step the second, delete the target
There are lots of migration scenarios: just a few objects (or even just one), a cube or two with its dimensions, or replace in total to name a few. You can see some but not all of the options two pictures up.
This example is using a nuke-it-from-orbit approach because what I want is an exact copy of the application. In the world beyond Yr. Obt. Svt.’s laptop, think about a migration to prod that’s been (properly) written in dev or a back migration to dev because you’ve (oops) made significant changes live in production. Hahahahahohohohehehe. No. Seriously, don’t do that.
With the use case of back migration to my development laptop from the customer’s development environment so I can develop (whew), I need to now log out of my OneStream XXX Dev app on my laptop:
And then log into the System Adminstration app. Yes, I’m going to use OneStream to delete OneStream:
Once in the System Administration app, select Applications, then the app in question, and then the delete icon:
You’ll get a warning. As I am a devil may care sort of chap that most (none, really) of you know me to be, I’ll click OK:
It’s gone:
Yeah, I know, you can’t tell because I’ve blurred out the other apps – trust me, it ain’t no more.
Step the third, create the app shell
The application needs a home before it can be imported. I shall create one with the same name as before:
OneStream XF will automagically name the database schema (SQL Server database) using the Onestream_whateveryourappnameiswithoutspaces naming convention. NB – I’m not totally sure that’s the nomenclature OS Development uses but it’s descriptive.
Ah, bugger:
I forgot that deleting an app within XF itself does not actually delete the SQL Server metadata database. Whoopsie.
I’ll just connect into my instance of SQL Server:
Delete the SQL Server database:
Delete the database but for real:
And now I can go back to creating the app. And yes, you can’t see it because there are other Secret Squirrel apps there. Again, it ain’t there no more.
Let’s now create that application but do it the right way:
Ta da, the app creation is complete:
I’ll log out of System Administration and go back into my now completely empty application:
It’s as empty as a beer bottle at a summer picnic:
Step the fourth, import the app
Go to Application->Load/Extract to import the zip export file:
Select the file:
Hit the load icon:
Watch my laptop whirr, click and grind:
And more whirring, clicking, and grinding:
And…we’re done:
Oh dear, Gentle Reader, you can’t see much of anything. Sorry, but I did tell you the application is Eyes Only.
And that as they say is that
Honestly, this is stupidly easy. So easy even I could do it. And it works on the first import.
What more could an infrastructure-allergic geek who wants to migrate an app want? Nothing.
Be seeing you.
This is interesting. I would have expected that the app tables would have to be created with the db configuration manager, but would infer from this that the tables are created during the import of the app after the db deletion. Is this the case?
If it is, could the delete application step in the OS client be skipped, and jump directly to deleting the tables/db, or is a file lock in place or something else that would prevent it?
Jason,
You absolutely can do what you note: migrate the database and then create an application reference. It’s really easy, easier maybe than what I showed.
I’d use this selective (well, I did the whole app — maybe I need to write a selective migration post too) approach if I was migrating just a bit of the application.
So maybe two more posts on this subject? And oh yeah, another (good grief, I should have made this a series) one on migrating data.
Regards,
Cameron