Well, reference documents vanishing from IBM site is no new news. This is what happened with the DBC Technical Reference Guide that was available on the IBM site till last year. I was looking for it a few days ago but couldn’t find it on the IBM site. I thought it was gone along with all the other developerworks articles.
But thanks to Cezar Tipa who had an offline copy and Biplab Das Choudhury who shared it on Linkedin a copy of it is still available.
I downloaded a copy and uploaded it here. You can find a link to the document below.
DBC XML Format for Technical Consultants
Migration manager is a really great tool for migrating configurations from one Maximo instance to another. It does all the validations and tells you of any dependency that you may have missed in the package. Unfortunately it doesn’t tell you that while creating the package but does it while the package is being deployed and I wouldn’t blame migration manager for that. When the package is being created in the source environment, it doesn’t really know where it’s going to be deployed and whether the target environment had all dependencies or not. It’s when the package is being deployed that the migration manager gets to know that the dependencies don’t exist in the target environment and the package errors out. I’ll take an example and explain.
Let say you want to migrate an object from one environment to another. You create a migration manager package for that object which includes all its attributes but not the domains that are associated with those attributes. When you deploy this package to the target environment, it would fail if those domains don’t exist there.
Migration Manager has its own section for mentioning dependencies and most the out of the box migration groups have dependencies already specified.
But I don’t prefer using this dependency functionality of Maximo and here’s why – If you see the images above, Data Dictionary is one of the dependencies for the application migration group which should be the case but what this would do is take the entire data dictionary from the source environment and deploy it in the target environment.
You really wouldn’t want to do that because
- If a developer has created any attribute or domain for testing some functionality and didn’t delete those, they would be migrated too. Worst, if someone changed or removed a class from an OOB attribute or removed the domain associated to it, that would be migrated too. This could break existing functionality.
- And if not any of that, it would unnecessarily take a lot of time for deploying the package since there would be the entire data dictionary from the source that would have to be compared to the existing data dictionary of the target for changes.
Unfortunately if you don’t know about this feature of Migration Manager or you are not careful about it, you might unknowingly migrate certain configuration that were not required.
So it’s better to maintain dependencies by you yourself then having Maximo maintain it for you.
Have a great day!
Development activities may involve creation and modification of artifacts such as domains, objects, escalations, actions, workflows, etc. Once the development has completed, these configurations need to be migrated from the development environment to QA for testing and finally to Prod – to the end user. The number of these environments may vary but the migration process mostly remains the same.
Keeping track of all the development artifacts that are to be migrated can be a hectic task especially if the duration of the development is more than a few days in which case the developer may forget some of the artifacts that he/she had created over time, or if the number of these artifacts is too large.
The typical migration manager approach to migrate the configurations requires building a sql where clause against each object structure in the migration group and creating a migration package which extracts the data using this where clause. This approach requires the developer to identify and organize all the configurations to be migrated.
Another way to keep track of all these configurations is to create a change type migration package which will track all the changes done by the developer on any of the objects of the associated migration group which can then be used to create the package. But this approach will fail if there are multiple developers working on the same environment.
This is where the migration collection application comes into the picture. The developer can create a collection record in the migration collection application and add the configurations to the collection as and when they are created or modified. This way the developer doesn’t have to remember the long list of changes that have to be migrated.
Collections entries can be added in three different ways:
- Manually navigate to target application from the collection record and return with value
- Manually add to collection from directly within the target application – For this to work, in the migration collection application, support for the target application needs to be added. Once support is added, a button appears in the toolbar of the target application to add the current record to the migration collection.
- Automatically capture the changes made by specific users – For this to work, tracking for the target application needs to be enable in the migration collection application. This tracks changes made by a particular user only in the target application, the user that is specified at the time of setting up the tracking.
Once all the configurations have been added to the collection, developer can create a migration package using the content of the collection.