Chat now with support
Chat with Support

Stat 6.0 - User Guide

Introduction to Stat Connecting to Stat Change/Service Requests Stat Consoles Tasks and Time Entries Stat Projects Search Engines Reports and Graphs Personal Rules Object Tools and Wizards Change Management for PeopleSoft
Object Management (PeopleSoft) Object Archives (PeopleSoft) Object Migrations (PeopleSoft)
Change Management for Oracle Applications
Object Management (Oracle Applications) Patch Management Object Archives (Oracle Applications) Object Migrations (Oracle Applications)
Change Management for Generic Applications
Object Management (Generic Applications) Object Archives (Generic Applications) Object Migrations (Generic Applications)
Appendix: Troubleshooting Chart Appendix: Migration Options Appendix: User-Specific Parameters Appendix: Supported PeopleSoft Proprietary Objects Appendix: Stat Reports

Object Migrations (Oracle Applications)

The previous chapter explained how to archive objects by creating archive sets. This chapter explains how to migrate archive sets between your Oracle Applications environments.

Migrating objects updates your environments with the most recent version of those objects, or, if necessary, lets you roll back your environments to earlier versions.

In Stat, migrating file objects entails moving them to designated source file directories or developers’ working directories. For data objects, this means migrating them from one environment to another.

There are two places in a CSR where you can initiate a migration: the Migration Path tab and the Object Management tab. Migrations in Stat are not linear; a migration can go in any direction. For example, in the sample migration path shown below, you could bypass the Development environment and migrate an archive set from the Base environment directly into Production.

System administrators can set up Stat to support auto-migrating archive sets to multiple environments distributed over a network. This is done by designating particular environments within a migration path as distribution environments and then associating them with lists of interrelated environments. This way, when you migrate an archive set to a distribution environment, Stat automatically migrates the archive set to all the associated environments as well. This spares you the time-consuming task of migrating an archive set to each environment separately and is especially helpful when a migration path calls for more environments than the limit of nine that can be represented graphically.

When you migrate an archive set that contains both data objects and file objects, with the proper security rights you can choose to migrate just the data objects in the archive set, just the file objects, or both. System administrators can enforce that certain users only migrate file objects while others only migrate data objects.

Migration Overview

The previous chapter explained how to archive objects by creating archive sets. This chapter explains how to migrate archive sets between your Oracle Applications environments.

Migrating objects updates your environments with the most recent version of those objects, or, if necessary, lets you roll back your environments to earlier versions.

In Stat, migrating file objects entails moving them to designated source file directories or developers’ working directories. For data objects, this means migrating them from one environment to another.

There are two places in a CSR where you can initiate a migration: the Migration Path tab and the Object Management tab. Migrations in Stat are not linear; a migration can go in any direction. For example, in the sample migration path shown below, you could bypass the Development environment and migrate an archive set from the Base environment directly into Production.

System administrators can set up Stat to support auto-migrating archive sets to multiple environments distributed over a network. This is done by designating particular environments within a migration path as distribution environments and then associating them with lists of interrelated environments. This way, when you migrate an archive set to a distribution environment, Stat automatically migrates the archive set to all the associated environments as well. This spares you the time-consuming task of migrating an archive set to each environment separately and is especially helpful when a migration path calls for more environments than the limit of nine that can be represented graphically.

When you migrate an archive set that contains both data objects and file objects, with the proper security rights you can choose to migrate just the data objects in the archive set, just the file objects, or both. System administrators can enforce that certain users only migrate file objects while others only migrate data objects.

Synchronizing Your Development Workspace

It is good practice to synchronize your development workspace with your base archive set. This ensures that you are making changes to the correct version of the objects. This is true of all your environments. As you make changes, you should create interim archive sets that document those changes and then migrate them to the appropriate environments. The migration process is virtually the same, regardless of the type of archive set.

The development workspace is where you make the changes. For data objects, this is the Development environment. For file objects, it can be either the Development environment’s source file locations or the assigned developers’ working directories. It is recommended that each developer make changes to file objects in their own working directories so that the changes can be documented and controlled. System administrators can enforce that developers modify objects only in either their working directories or in the source file locations.

Migrating File Objects

When an archive set contains file objects, the file archives are stored in the Stat Repository. When you migrate the archive set to an Oracle Applications environment, Stat copies the file archives from the Stat Repository to the source file locations defined for the target environment. If the file objects already reside in any of these source file locations, Stat replaces each existing instance with the archive copy. If the files exist in none of the source file locations, Stat either copies the files to all the source locations defined for the target environment or copies the files to the designated default location. These options are set up by system administrators when configuring the target environment.

To migrate file objects in an archive set to the developers’ working directories, you migrate the archive set to the Development environment. Stat gives you the option of migrating the file objects to the Development environment’s source file locations, the developers’ working directories, or to both. To migrate an archive set taken from the Development environment to the developer’s working directories, or vice versa, the migration must be initiated from the Object Management tab, not the Migration Path tab.

If two or more environments on a migration path share the same source file locations for a particular file type, whenever you migrate an archive set that contains file objects of that type to one of the environments, by default the file objects are also migrated to any other environment that shares the same source file locations. For example, if the Development environment and Quality Assurance environment share the same source file locations for COBOL file objects, and you migrate an archive set containing a COBOL file object to Development, Stat documents that the same file object was also migrated to Quality Assurance. This eliminates the time consuming process of having to perform multiple migrations in order to document the migration of the same file objects to each environment on the migration path.

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating