Action and Different Methods

Action	Method Called	Syntax
Adding a MBO	Add() -- This is called when a new Mbo is added to the Mboset collection	public void add() throws MXException, RemoteException
Deleting a MBO	Delete() --  Mark the object to be deleted with all the normal security checks	public void delete() throws MXException, RemoteException
Duplicating a MBO	Duplicate() -- Duplicate the Mbo	public MboRemote duplicate() throws MXException, RemoteException
Validating a MBO	validate() -- Validate the object	public final void validate() throws MXException, RemoteException
Save a MBO	Save() -- Adds a new Mbo to this set at the beginning, and sets the current Mbo position to the Mbo just added	public void save() throws MXException, RemoteException
Initiating a MBO	Init() -- Called by the framework when the Mbo has been constructed and the MboValues have been initialized	public void init() throws MXException
Application validation	appValidate() -- Pre-save validation method. Programmer can override with specific rules	public void appValidate() throws MXException, RemoteException

Migration Manager Limitations in Maximo

Before going into details of limitations in Migration Manager, let’s look at some basics of Migration Manager in Maximo.

 The Migration Manager is a component of Tivoli’s process automation engine. It is a set of tools used to promote system configurations from a development environment to upper environments.

System configuration is a set of metadata that enables application functionality and controls application behavior in a production environment.

Migration Approach:

 The Migration Manager offers two modes of operation:

Snapshot: The Snapshot mode is literally a view of the system at the point of creating a package.

Change: A change package is based on changes performed by one or more users over a period of time.

Migration Manager Applications

 The Migration Manager applications provide the infrastructure necessary to identify,collect, distribute, and deploy configuration content that evolves through the execution of the production rollout plan.  

There are three applications that enable migration:

 Object Structures: An object structure is a grouping of related business objects (BOs).

Migration Groups: The Migration Groups application is a dedicated migration application used to group related object structures together.

 Migration Manager: Migration Manager is a dedicated migration application that is used to implement the migration process. The Migration Manager application is used to define containers of configuration content. These containers are called ‘packages’ and are destined to carry forward configuration content from one instance of the product to another. Content is placed into packages in the form of migration groups. Using this application, packages can be defined, created, distributed, and deployed.

 Package life-cycle

 Every package has a life-cycle wherein it is:

1. Defined
2. Created
3. Distributed
4. Deployed

Below are Migration Manager Limitations in Maximo :

Although most configuration content can be migrated in most environments, some configuration cannot be migrated. Extra steps are required in some below circumstances:

Actions

To migrate a WFINITIATE action, which initiates a workflow process, the workflow process must be active. Therefore, two deployments are required. Migrate the workflow process and activate it in the target environment first, and then migrate the action.

Action groups

To migrate action groups that are created in the Actions application, you must also migrate all the actions that are in each action group. If you do not migrate the actions, the action groups cannot be used in the target environment.

Base language

A target environment must have the same base language as the source environment. If the target base language is different from the source base language, packages cannot be deployed.

Collection restrictions

Data restrictions for objects and attributes are migrated, but collection restrictions are only partially migrated. Data in the SECURITYRESTRICT table is migrated. Data in the COLLECTIONAUTH table is not migrated.

Crossover domains

To migrate a crossover domain to which an attribute has been added, you must create and deploy two packages. The first package to deploy must contain the attribute but not the domain. The second package to deploy must contain the domain.

Database configuration

In Oracle databases, setting up a system to run with a login user name that is different from the schema owner is a complex manual task and might cause migration errors. To avoid errors, ensure that the system properties mxe.db.user and mxe.db.schemaowner have the same value.

Also for Oracle databases, ensure that the semantics are set to CHAR in all source and target environments. Migrations between environments that have different semantics (CHAR and BYTE) might cause database errors.

Database indexes

For IBM® DB2® databases, indexes might not be migrated.

If a package is deployed and an index exists in the target environment, the index in the package is not deployed. If an index does not exist in the target environment, the index is created. If the index in the package is marked to be deleted, the index in the target with the same table and attribute combination is marked to be deleted.

Charts of accounts

Migration Manager does not migrate charts of accounts (GLs).

Classifications

The following limitations affect the migration of classifications:

Data that is related to the CLASSIFICATION table is not migrated.

You cannot migrate a classification hierarchy in which a parent classification was changed to alter the parent-child classification relationship.

In Snapshot packages, regardless of the selected processing action, a database update is performed for classification records.

You cannot migrate two or more different classifications that have the same hierarchy path.

Conditions on security groups

In some situations you might need to create and deploy two separate Change packages. For example, consider the following scenario:

You have a security group that has a data restriction, and the data restriction references a condition. You create a package for application security and deploy the package to the target environment. You then remove the condition from the security group in the source environment, and delete the condition. You create a new package for application security and deploy the package to the target environment, but an error occurs.

The error occurs because during deployment, the Migration Manager attempts to delete the condition first.

To avoid this error, you must perform the migration in two steps. First, create a Change package that removes the condition from the security group, and deploy the package to the target environment. Then, create a second change package that deletes the condition, and deploy the second package to the target environment.

Different database platforms

A package cannot be migrated between different database platforms if it contains configuration records for objects, attributes, keys, indexes, or sequences. For example, you cannot deploy a package from an Oracle source environment to a DB2 target environment.

Migration Manager issues an error message indicating that it cannot deploy such a package. You can confirm the cause of the error by viewing the manifest of the package. You view the manifest to determine whether the DMMAXOBJECTCFG migration object is part of the package.

Discarded configuration changes

A Change package can listen for database configuration events that occur in the Database Configuration application. Event information (inserts, updates, deletes) are persisted in the event tracking table. If a user discards all the database configuration changes by using the Discard Configuration Changes action, the events that are already captured remain in the tracking table. A migration user might not be aware that the events remain in the tracking table and might proceed to create, distribute, and deploy a package. During deployment, the Database Configuration application can determine that the data provided by the package does not contain changes and does not configure the database. The deployment of such a package does not harm the target environment, but the event tracking entries might be confusing to a user.

Electronic auditing

If you use the Database Configuration application to enable electronic auditing, any electronic auditing tables that are created are not migrated.

Exchange rates

You can migrate exchange rates only if the application servers in the source and target environments are configured to use the same time zone. If the time zones are different, a package might not deploy because of overlapping exchange rate validity periods. You cannot use exchange rates that have overlapping validity periods.

Integration tables

Changes to the Integration module interface tables, default queue tables MXIN_INTER_TRANS and MXOUT_INTER_TRANS, and any customized queue tables are not migrated. If you make any configuration changes in the source database to these tables, you must make the same changes in the target database.

Lookup maps

When you migrate lookup maps for new business objects, the migration of a single package that contains both the lookup map records and the business object records fail. The migration fails because the lookup map is processed first and depends upon the business object, which is not processed yet.

To work around this limitation, define two Change packages: one to capture the new business object and another to capture the lookup map. Migrate the business object Change package first.

MAXVARS table

The source and target environments must have identical MAXVARS tables. Ensure that you use the same installation and upgrade procedures in the environments so that the tables are identical.

Organizations

After deployment of a package, a newly created organization in a target environment is inactive. It is inactive because a newly created organization cannot be activated without a clearing account (GL). The association of a GL account with an organization is a manual post-deployment step.

Restricted attributes

If an attribute is restricted by the Database Configuration application in a target environment, and an override of the restriction is not set up at the object structure level, the value of the attribute is not deployed.

Security settings

The following limitations apply to the migration of security settings:

If you use LDAP, do not use the Migration Manager application to migrate user IDs. Use the LDAP server and tools to manage user IDs.

When user IDs are migrated to a target environment, the passwords are reset and sent to the users in an email message. To receive the email message, the email server must be set up in the target environment. Additionally, the users must have configured email addresses in the target environment. The password sent in the email is a temporary password. The temporary password expires when the user logs in for the first time, at which time the user must reset the password. Use the mail.smtp.host system property in the System Properties application to set up the email server. The value for the property is the name of the host running the SMTP mail server.

Password hint questions and answers are not migrated.

Data in the MAXUSERSTATUS and LOGINTRACKING tables is not migrated.

The product user data that is stored in the MAXUSER table is migrated. However, the corresponding native database user data that is stored in the data dictionary of the database is not migrated. If you want to maintain the product users as database users in the target environment, you must create the database users corresponding to the product users. You must also grant database access to these users. You can create the database users and grant them database access by selecting Database Access from the Select Action menu in the Users application.

The following information in security groups is not migrated:

Labor authorizations

Limits and tolerances

Purchase general ledger

Status history

Storeroom authorizations

User storerooms are not migrated. You must ensure that the storerooms are the same in the source and target environments.

Start centers

Only the start center templates can be migrated. After you migrate a start center template, you can apply the template to an appropriate start center.

System properties

Only system properties that meet specific conditions are migrated when you use the DMMAXPROP migration object.

To be migrated, a system property must meet the following conditions:

The property is user-defined.

The property is not configured for a file override with a value in the maximo.properties file.

The property value is tagged with COMMON and does not have an instance-specific value.

Always configure the system-defined system properties in a target environment.

System XML files

Migration Manager does not support migration of user interface system XML files between product environments. System XML files include lookups.xml, menus.xml and library.xml. These XML files are not application-specific. They store common user interface components or resources. Use the Application Designer application to manage the export and import of these system XML files.

Ticket templates

The following limitations affect the migration of ticket templates:

When you deploy a ticket template that references a job plan, the job plan must exist in the target and have a status of ACTIVE. If the status of the job plan is not ACTIVE, the deployment of the ticket template will fail.

When you deploy a ticket template, a new autokey value is generated for the record by default. If this behavior is unsuitable, you must customize the DMTKTEMPLATE object structure.

If you migrate ticket templates by using Change packages, you must activate the package definition before any ticket templates are created or updated. After the Change package is deployed, you must reset the event tracking records for the package definition in the source environment.

To migrate ticket templates that have activities and activity specifications, a classification must be associated with the template.

The status of ticket templates is preserved. For example, if a template is active in the source environment, the template is also active in the target environment after migration.

User and person records

If a person record is inactive and its related user record is also inactive, a deployment error occurs. The person record must be active for it to be added to a user record. To work around this limitation, migrate the person records, activate them in the target environment, and then migrate the user records.