Tchater maintenant avec le support
Tchattez avec un ingénieur du support

Stat 6.3 - 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

Migration Overview

Object Migrations (PeopleSoft)

The previous chapter explained how to archive objects by creating archive sets. This chapter explains how to migrate archive sets between your PeopleSoft 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 PeopleSoft proprietary objects, Stat creates a PeopleSoft project that contains the archived objects. This project is created in a staging database, which is simply a temporary holding bin for objects. Once the objects are staged, Stat completes the migration by pushing the project from the staging database to the target PeopleSoft environment.

There are two places in a CSR window where you can initiate a migration: the Migration Path tab and the Archive Sets tab. Migrations can also be initiated outside CSRs using certain tools and Wizards. Migrations in Stat are not linear; a migration can go in any direction. For example, you can bypass the Development environment and migrate an archive set from the QA environment directly into the Production environment.

* 
NOTE: For a comparison of the various migration tools and techniques supported by Stat, see Appendix: Migration Options .

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 on a migration path as a 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 distributed 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 PeopleSoft proprietary objects and file objects, with the proper security rights you can choose to migrate just the PeopleSoft proprietary 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 PeopleSoft proprietary 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 PeopleSoft proprietary 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 PeopleSoft Proprietary Objects

When an archive set contains PeopleSoft proprietary objects, Stat first moves copies of the archived objects into a staging database, which is simply a temporary holding bin for objects. Stat then creates a PeopleSoft Project, which contains references to the objects in the staging database. At this point, if the CLI Auto-Migration option has been activated for the target environment, Stat completes the migration automatically using the PeopleTools command. Optionally, you can complete the migration by logging in to PeopleTools in the staging environment and manually pushing the project into the target environment.

* 
NOTE: Stat also provides migration support for PeopleSoft proprietary objects that cannot be included in a project. For more information, see Migrating Non-App Designer PeopleSoft Proprietary Objects .

Migrating Data Objects

Data object definitions are archived in the Stat Repository. When you migrate an archive set that contains data objects, Stat copies the data object definitions from the Stat Repository to the target environment. If the data object already exists in the target environment, Stat replaces that object definition with the archived copy using the delete and insert method.

Documents connexes

The document was helpful.

Sélectionner une évaluation

I easily found the information I needed.

Sélectionner une évaluation