Maximo Migration Manager Overview

Maximo Migration Manager Overview




Migration Manager Overview

Migration Manager Application

The Migration Manager application is used to migrate configuration content from one product ecosystem to another.

You manage the configuration content that you want to migrate in the form of package definitions and packages. As part of your implementation of a migration course of action, you use the Migration Manager application to define and create the package definitions, and then spread and deploy the packages.

For example, you can migrate configuration from a development ecosystem to a test ecosystem. After testing, you can migrate the configuration to a production ecosystem. The development ecosystem is the source and the test and production environments are targets. You can use this approach during the initial configuration of the product or at any time when you want to change your configuration of the product.

The Migration Manager application has the following tabs:

• The Migration Manager application has the following tabs:
• List: To search the Migration Manager application for package definitions.
• Package Definition: To define, save, approve, and activate package definitions.
• Package Definition Structure: To view the hierarchical structure of a package definition.
• dispensing: To spread a package from a source to a target ecosystem.
• Package: To create, spread, and deploy physical packages.
• Messages: To view detailed messages about the creation or deployment of physical packages.

List Tab

You use the List tab to search the database for a specific record or group of records that meet your criteria. You use the filter fields located above the List table window to go into basic search criteria.

The List tab has an Search Toolbar with the following links:

progressive Search: Select from a list of the following options:

More Search Fields
go into Where Clause
View Search Tips

Save Query: Select from a list of the following options:

Save Current Query
View/Manage Queries
Package Definition Tab

You use the Package Definition tab in the Migration Manager to create package definitions, which are templates for individual packages. A package definition organizes the content to be migrated, and must be produced before other migration activities occur.

Header

The header area identifies the package definition and provides position information.

Migration Groups section

Each row in the Migration Groups section contains the following attributes:

Migration Group – Name of the migration group.

Description – Description of the migration group

In this section, you can add migration groups to or delete migration groups from a package definition.

You can also set conditions for migration objects within a migration group in a snapshot package definition by clicking Set Where Clause.

To view dependent migration groups, click View Details to the left of the Migration Group row.

Dependencies section

The Dependencies section lists the groups that the current migration group is dependent on. The dependencies are the relationships between the inner migration objects in the database. In this section, you can see whether a set of configuration data in a migration group depends on another set of configuration data in a different migration group.

Compiled supplies section

In the Compiled supplies section, you can add or delete information about compiled supplies to or from a package definition.

Each row in this section contains the following attributes:

File Name – Name of the compiled source file.

Description – Description of the compiled source.

Package Definition

Migration Groups and Compiled supplies

Package definitions can contain migration groups and compiled supplies.

Migration groups

A migration group is a collection of related migration objects. A migration object is a group of related business objects (database tables).

You use the Migration Groups application to define and aggregate configuration objects, which simplifies the creation of package definitions.

Compiled supplies

You can include references to compiled supplies in a package definition. A compiled source is any file that is outside the product database, but is part of the Enterprise Archive (EAR) file. Compiled supplies can include many types of files, such as class files, archive files, image files, and similarities files. Compiled supplies are typically in folders of the product installation, but can also be on the local client computer or on a mapped network excursion

If you need to migrate multiple compiled source files, combine them into a single EAR file to simplify the migration course of action.

Header Area of the Migration Manager Tabs

The Package Definition, Package Definition Structure, dispensing, Package, and Message tabs all have a header area to clarify the package definition and provide position information.

The header area has the following fields:

Package Definition Name – The name of the package definition.

Source – The name of the product source ecosystem where you defined the package. This name is a combination of the database great number name, the database identifier, and the database schema name. The source name helps you to clarify where the data comes from. The source name is also used in the name of a package to ensure that every package name is rare.

kind – The kind of package definition. A package definition can be a snapshot or a change. You specify the kind when you create a package definition.

Batch Size – Specifies the number of records to be retrieved at a time when a package is produced. The default value is 100.

Change Role – Specifies a designated role. Only changes made by users in this role are captured by the Migration Manager application when a change package is produced.

position – An indicator of the migration activities that can be performed on the package definition. The position can be WAPPR (waiting for approval), APPR (approved), or LOCKED.

Active – If chosen, indicates that you can create a package from the package definition. For a change package definition, this check box indicates that the event listeners are registered and that the Migration Manager application is capturing change information. An active package definition cannot be alternation. A package definition must be active before it can be used to migrate data.

Change By – The user who last changed the package definition.

Change Date – The date that the package definition was last changed.

Package Definition Structure

Package Definition Structure Tab

You use the Package Definition Structure tab to view a hierarchical representation of the content that can be in the chosen package definition. The hierarchy shows the following information:

– The migration groups in the package definition
– The migration objects and objects structures in each migration group
– The business objects within each object structure
– Any compiled supplies in the package definition

Hierarchy section

The hierarchy section shows the information about the package definition in nested levels. The root entry of the hierarchy is the name of the current package definition.

The root entry can have the following entries:

Migration Groups – The migration groups in the package definition and the migration objects in those groups. This level can also have a Dependencies entry, which shows the migration groups that a particular migration group depends on.

Package Metadata – The metadata that describes the package definition.

Compiled supplies – The compiled source files that are included in the package definition. Each entry shows the absolute path and file name.

dispensing Tab

You use the dispensing tab to associate targets with a package definition and to change or delete these associations.

Distributions section

Each row in the Distributions section has the following attributes:

Target Name – Name of the ecosystem to which the package based on the package definition can be distributed.

Description – Description of the target ecosystem.

kind – The kind of target, either DATABASE or FILE, depending on whether the target is a far away database or a file on a file system.

Database URL or File Path – The database URL or absolute path on a file system that is easy to reach to the application server.

To view details of a dispensing, click View Details to the left of the dispensing row. To delete a dispensing, click Mark Row for Delete to the right of the dispensing row.

Target Details section

The Target Details section includes the following fields:

User Name – User name for the target database.

Schema Name – Name of the database schema.

Change By – The ID of the user that last alternation the dispensing definition.

Change Date – The date and time of the last changes to the dispensing definition.

Package Tab

You use the Package tab to perform the following responsibilities for a package definition:

– Create or delete a package
– spread or redistribute a package
– Download compiled supplies in a package
– Download a package
– Deploy a package
– Close a package

Packages section

Each row in the Packages section includes the following attributes:

Package – Name of the package, which is a combination of the package definition name and the source information.

File Name – The name of the package with the archive file extension. For a package with a database as its target, this field is empty.

position – position of the package.

position Date – The date when the position was applied to the package.

To view detailed information about a particular package, click View Details.

Package Details section

The Package Details section shows the following fields for the chosen package:

Package – The name of the package. The name is a concatenation of the package definition name, source, and date and time of creation, separated by underscores. For example, if the package definition is MyTest, the source is ServerA and the date and time is 10 July 2008, 16:00:00, the package name is MyTest_ServerA_20080430160000.

position – position of the package.

Progress position – Indicates the progress of the package processing in the source or target ecosystem.

File Name – The file name that corresponds to this package if a package file is generated

Direction – Specifies whether the package is outbound (from the source ecosystem) or inbound (to the target ecosystem).

Redistribution Source – The source information from where the package is being redistributed. This value is the combination of database identifier, database schema, and database great number name. These values are retrieved from the database server in the ecosystem from where the package is to be redistributed. The redistribution source is not the original source of the package.

Change By – The user who last changed the package.

position Date – The date and time when the package was last changed.

Readme Information – The information that was entered when the package was produced.

SubTabs

The Package tab has tabs that show more information about the chosen package.

Manifest tab

XML-formatted information that represents the content of the package and the version information. This information is used in the target ecosystem to deploy the package.

position History tab

The position and progress position of the creation and deployment of the package. This tab has the following fields:

position – The position of the package.

Progress position – The progress position of the package.

Memo – Information about the change of position.

position Date – Date and time when the user changed the position.

The Details section shows the following additional fields:

Redistribution Source – Indicates whether the position change was caused by a redistribution of the package. The value shows the ecosystem from where the redistribution was initiated. If the package is not a redistributed package, this field is empty.

Change By – The user who changed the position.

dispensing Tracking tab

Information about the history of the distributions of the package to the target ecosystem. chiefly indicates the success or failure of the distributions This tab has the following fields:

Target – The ecosystem to which the package was distributed.

position – The position of the dispensing.

position Message – A message about the dispensing.

dispensing Date – The date the package was distributed.

The Details section has the following additional field:

Distributed By – The user who distributed the package.

Messages Tab

You use the Messages tab to view messages about package definitions and packages. The messages are produced when packages are produced and deployed. The messages contain progress information or errors.

Message Filter Options section

Use this section to filter the messages. You can select one of the following options:

By Package Definition – Shows all messages for all packages that were produced from the current package definition.

By Package – Shows messages for a single package. If you select this option, specify a value in the Filter Package field to select the package whose messages you want to view.

Messages section

This section shows the messages for the package or package definition. The Messages section has the following fields:

Package – Name of the package.
Message – Text of the message. The message might be truncated in this field.
Message kind – Can be one of the following types: INFO, ERROR, or WARN.
Change Date – Date and time when the message was last alternation.

Message Details section

This section includes the following additional fields:

Message – complete text of the message.
Message Details – Additional details about the message, such as the program stack trace.
Change By – The ID of the user who last alternation the message.

Migration Groups Application

You use the Migration Groups application to organize and group configuration content that you want to migrate. After you set up the configuration content in migration groups, you can include these groups in package definitions in the Migration Manager application. Migration packages can be produced from the package definitions and these packages can then be migrated to another system or ecosystem.

You can work with migration groups that are included with the product (internal migration groups) or you can create your own (user-defined) migration groups.

The Migration Groups application has the following tabs:

List: To search for migration groups.

Mig Group: To create, view, modify, or delete migration groups.

Mig Group Structure: To view in a hierarchy the migration objects that are contained in a migration group.

Migration Groups Application List Tab

Migration Group Tab

You use the Migration Group tab in the Migration Groups application to define new migration groups and their dependencies. You can use these new migration groups in package definitions that you create in the Migration Manager application. The Migration Group tab has the following sections:

Header
Migration Objects
Dependency
Header section

The header section has the following fields:

Migration Group – The name of the migration group.

Migration Group Order – Assign the correct order to migration groups to ensure correct sequential processing of configuration data. If migration groups are not ordered correctly, the deployment of migration packages that contain these groups using the Migration Manager application might fail. For example, if records in migration group B are dependent on records in migration group A, specify the correct ordering to ensure that the Migration Manager application inserts or updates the records from migration group A into the target database before inserting or updating the records from migration group B.

Internal – If this check box is chosen, the migration group is included with the product. The check box is read only. You cannot modify internal groups.

Migration Objects section

The Migration Objects section displays the migration objects in a migration group. You can view the migration objects or add objects to a migration group that you create. Each row in this section contains the following attributes:

Migration Object – The name of the migration object.

Description – The description of the migration object.

Migration Object Order – The order of the migration object within the migration group. Objects are processed in sequential order during the create and deploy responsibilities of the migration course of action. The value must be rare within the migration group. As a default, the next sequential value is stated.

When a package is produced, the Migration Manager application checks the object order to determine the ordern in which the migration object are processed. When a package is deployed, the Migration Manager application first populates tables in the target database with parent records, and then populates related tables with the related child records.

Internal – If this check box is chosen, the migration object is included with the product. You cannot modify internal objects.

To view detailed information about a particular migration object, click View Details to the left of the Migration Object row.

Example of migration object ordering

You can use the BPM (Business course of action Management) migration group to move workflow processes. This migration group contains the following migration objects, which must be processed in the order shown:

DMACTION
DMROLE
DMCOMMTEMPLATE
DMESCALATION
DMWFPROCESS

The order must be followed because a workflow course of action might refer to one or more actions, roles, communication templates, or escalations. Similarly, an escalation might refer to one or more actions or communication templates, and a template might refer to a role.

If these objects are not processed in this order, the migration might fail, because the system might attempt to insert a record into a table before inserting a related and required record into a related table.

Dependency section

The Dependency section lists the groups upon which the migration group that is shown in the header section (the current migration group) is dependent. These dependencies indicate relationships between the inner migration objects in the database.

To view detailed information about a dependency, click View Details to the left of the Dependent Migration Group column in the Dependency row.

Migration Group Structure Tab

Use the Migration Group Structure tab to view a hierarchical representation of the currently chosen migration group, its migration objects, and the business objects of each migration object.

This tab also shows the dependent groups of the currently chosen migration group, the migration objects, and the business objects of each migration object.

When you select this tab, the hierarchy is shown collapsed. Expand the hierarchy by clicking the plus signs.

Object Structures Application

You use the Object Structure tab to clarify the objects and data fields that comprise an object structure. You also use the Object Structure tab to define the following characteristics of the object structure:

Which system application consumes the object structure

Whether you can use the object structure to create, update, and delete object content or to restrict the object structure use to query and to publish object content

Whether you can use the object structure to represent a non-hierarchical structure (flat file data)

The objects you can include in the object structure and the relationships between the objects

The processing ordern for child objects that proportion the same parent object

Migration Of Configuration

Migration task flow

1 Define – the time of action of creating a package definition in your source ecosystem. A package definition defines the boundaries of what product configuration content you want to include in packages based on the definition.

2 Create – Prepare a package example containing the product configuration content based on the package definition.

3 spread – After you create a package, you spread the package to one or more appropriate target environments. You must spread a package to a target ecosystem before you can deploy it to that ecosystem. You can spread to a database target or file target. Distributing to database is useful when migrating data from development to test. Distributing to file is useful when distributing from test to production, where direct access to a production database might be strictly controlled.

4 Deploy – Directly apply the product configurations contained in a package into the target ecosystem. Back up your target database before you deploy a package to that ecosystem. To preserve the integrity of structural changes, you can only deploy one package at a time.




leave your comment

Search

Top