Using Object Prompts In Migrations
MicroStrategy Object Manager can be a stressful tool. There’s a lot of things going on in the background and always surprises waiting for you in the Conflict Resolution screen where you must decide what moves and what doesn’t. A wrong decision could leave your Production project non-functional or worse, produce incorrect results. Then there’s the New Objects section that seems to get paid by the schema object it moves, as any excuse will force freshly developed tables, facts and attributes into Production before they’re ready. One way that I like to wrangle objects and take control over the migration process is with a little trick with Object Prompts that I’ll show you today.
When doing a migration, you’ll usually start with the highest level object, say a Document, and simply drag it over to your target project. This grabs all of the dependents and moves all of the pieces that are needed. But what happens when you need to move multiple objects from different folders? With the migration process being scary enough, you probably don’t want to juggle multiple migrations, and doing them in a single step would be a lot easier to manage.
What I like to do is add all of the objects I want to move into a single Object Prompt. An Object Prompt accepts any kind of object (Except for Folders, but those will be automatically created based on the destination of the objects). In this way, you can move this single object into Production and it will carry all of it’s contents. It also is a very useful tool for a large group, because the developer who worked on the project can package up everything they need to have moved into an Object Prompt, and the administrator can easily review the contents and perform the migration. If you choose to save the Object Prompt after migration, it provides a quick and accessible migration log. You can view the contents of any particular migration right there in Desktop, or search for dependents on an object and see the times it’s been migrated.
This is a different strategy than Update Packages, which were introduced in 9.0, for a number of reasons. First, I’m a little uncomfortable about saving an Update Package and then performing it at a later time, when the object states could have changed between those two times. When you save an Object Prompt, you’re always getting the latest rules for what should or shouldn’t be transfered at the time of the migration. Also, developers can create an Object Prompt, but they can’t create an Update Package.
Another advantage is that if you’re savvy enough to query the metadata, there’s a wealth of information available about your Object Prompt. For example, if your practice is to place everything that should move into the Object Prompt, then you can check what did move by parsing the Object Manager log file and comparing it to the metadata contents. It’s much easier than it sounds, and once you get into doing this, you’ll find there’s always something more to add to your process, including checking security and even checking that you didn’t forget anything in your Object Prompt by performing your own dependency analysis.
I did a presentation at MicroStrategy World 2010 entitled Improving Object Migration Management with Ease on just how much utility you can get out of a migration process that centers around Object Prompts. If you’re interested in implementing such a system yourself, I’ve provided lots of details at the end of the presentation, including all of the necessary SQL for extracting the information that process uses. The software code is proprietary, but very simple to come up with yourself. I’ve also provided details about what is going on in the frontend and backend, so recreating this system yourself should be simple with some basic programming knowledge.
In a large group, I think this process is an absolute necessity. In a small group, using Object Prompts is a convenience for the administrator to be able to quickly perform migrations in a single step instead of multiple steps.
One last word on migrations: There’s no truth to the old legend of performing migrations in 2Tier. It’s an old superstition from Object Manager related bugs in the 8.0 days that are long since resolved. There was a short time where MicroStrategy Technical Support would recommend performing migrations in 2Tier and then reloading the project, but those days are long gone. Their official recommendation has been to do migrations in 3Tier, which saves the administrator from the hassle of having to reload projects.