지금 지원 담당자와 채팅
지원 담당자와 채팅

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

Running a Migration (PeopleSoft)

3
(Optional) To plan the migration for an unspecified date, clear the Migration Date check box. Planned migration can be initiated any time later by Stat Windows Client or by an external third party component using a REST API call. See “Appendix: Stat REST Web Services API” in the Stat System Administration Guide.
4
(Optional) In the Description field, enter a unique description of the migration.
5
(Optional) Select the Stop on Error option if you want the Stat Central Agent to terminate the migration at the first error it encounters.
6
(Optional) De-select the E-mail Notification option if a business rule or personal rule triggered by a migration event has been defined for the service domain and you do not want Stat to send email notifications that may be triggered by the migration.
9
(Optional) In the Migrate column, de-select the individual objects you do not want to migrate.
11
Development Env– Select if you want to place the file objects in the source file locations of the Development environment
Working – Select if you want to place the file objects in the developers’ working directories. Only the file objects assigned to each developer get copied into their working directories.
Dev & Working – Select if you want to place the file objects in both the source file locations and the working directories.
13
(Optional) If CLI Auto Migrate has been enabled for the target environment, deselect the Auto Migration if for some reason you do not want Stat to auto-migrate the PeopleSoft proprietary objects.
It is recommended that you leave the Auto Migration option selected. If auto-migration is turned off, you need to manually migrate the PeopleSoft objects to the target environment. This also prevents Stat from executing the DataMover script to migrate non-App Designer objects.
Stat defined project - Select this option if you want Stat to assign a name to the project. Stat-defined project names always use the naming convention, “ST######.”
User defined project - Select this option if you want to assign a name to the PeopleSoft project. Then in the Project Name field enter the name you want.
Project in Archive Set - Select this option if you added a project definition to the archive set and want to re-use the project name. This option is only available if the archive set and the project definition included in the archive set reference all the same App Designer objects. This also applies to subobjects, meaning the option is not available if the parent objects have been removed either from the archive set or the project definition included in the archive set. The project definition included in the archive set can reference subobjects so long as the subobjects' parents are in the project definition and the archive set. For more information on subobjects, see Associating Related PeopleSoft Proprietary Objects .
Reuse project - Select this option if you are migrating an archive set that was previously migrated using the same staging database, and you have not modified the archive set after its original migration. If you select this option, by default Stat restages the project in the staging database. However, you can de-select the Restage objects option if you do not want to wait for the objects to be restaged and you are sure they were staged successfully the last time.
IMPORTANT: If you selected the Project in archive set option, you cannot modify the settings in the Upgrade Options window.
16
Click Migrate.

Auto-Migrating PeopleSoft Projects

If the CLI Auto-Migration feature has been enabled for the target environment (and you did not de-select the Auto Migration option), Stat launches PeopleSoft and tells PeopleSoft to copy the project from staging to target via a command line interface. While this is happening, you may see Application Designer login screen flash on your screen momentarily. For non-App Designer objects, Stat executes the DataMover import script. For more information on CLI options, see Setting Up Your PeopleSoft Connections .

If the archive set contains a PeopleSoft project definition and you have opted to migrate the archive set using a Stat created project, Stat runs the PeopleSoft project copy CLI twice: once for the Stat created project and once for the PS Project in the archive set. The CLI for the PS project only copies the project definition, but it updates the project version appropriately.

If the CLI Auto-Migration feature has not been activated, or if an error or warning occurs during the auto-migration, you must perform the migration manually by logging into the staging database and pushing the project into the target environment. If CLI-Open is configured for the staging environment, Stat opens App Designer in the staging database for you. For more information, see Manually Migrating PeopleSoft Projects .

Manually Migrating PeopleSoft Projects

If the CLI Auto-Migration feature has not been activated (or you de-selected the Auto Migration check box), you must perform the migration manually by logging into the staging database and pushing the project into the target environment.

2
Log in to the PeopleTools Application Designer in the staging environment. Select Tools | Copy Project to copy the project from the staging database to the target environment.

Pre and Post Migration Steps

Pre and post migration steps define certain activities you should perform before and after migrating an archive set. Migration steps are triggered either manually by the user or automatically by the Stat Central Agent.

Pre and post migration steps can be associated with object types, object classes and with target environments. When you initiate a migration with an archive set that includes an associated object type or class, or when you initiate a migration to an associated target environment in either a single or a mass migration, Stat opens a window that allows you to select which pre and post migration steps to run. This window displays a list of recommended steps that should be performed before or after the archive set is migrated.

Although recommended pre and post migration steps are added by default to the migration, you can exclude any step from the list. You can also change migration step order, update pre migration step status, and run pre migration steps. Once a pre migration step is run, it cannot be excluded from the migration. Pre migration steps can only be run before the migration is started. Post migration steps can only be run after the migration is successfully completed. The same is true for updating post migration status.

When a pre migration step completes with an error, the entire migration halts with “Waiting for Pre-Step” status. When a post migration step completes with an error, then migration halts with “Waiting for Post-Step” status. When a step completes with an error, you can fix the issue or manually update the migration step status to “Complete” or “Canceled.” This will trigger the Stat Central Agent to continue the migration.

To set a pre migration step status to “Complete,” manually select the step and then select Complete from the Update Status drop-down list. Then click the Update button beside it.
To view the pre migration step command log, select a step and click the View History button. This opens the Migration Step History window, which displays a record of each time Stat successfully executed the command. These records display the date and time the step was run, the user who ran it, and what parameters were used.
To view the log for the step, click Log. To print the history table, click Print. To export it to a file format, click Export.

Click the Migrate button after you finalize with pre and post migration steps.

Automatic steps consist of predefined custom commands executed by Stat. These steps will be automatically triggered and executed by the Stat Central Agent.

For more information on automatic steps, see the Stat System Administration Guide, Chapter 5, “Service Domain-Specific Maintenance.”

When this step is triggered, Stat uses your PS operator ID and password to log in to the PeopleSoft environment (by default, the target environment of the migration) and runs the selected .dms file. Before executing the step, however, Stat displays the DataMover Variables dialog box. Here you can specify a different environment, which .dms file you want to run, and the location of the script files. For a default location, Stat appends the subdirectory “\script” to the PeopleSoft Home Directory (PS_HOME) defined in the PeopleSoft Configuration Manager.

The default script location is based on the registry entry for the version of PeopleSoft that you were last working in.

After specifying the variables you want, click Run to execute the step. You can run this step for each .dms file included in the migration, or you can run this step for the same file but in a different environment or script location.

You may run manual pre migration steps before the migration has been initiated in the Select Pre and Post Migration Steps to Run window. Custom commands are operating system commands executed by the Stat Central Agent. To run a pre migration step, select the step and click the Run button. This action opens the Pre Migration Step dialog where you can review the command and command options, interpret the command, and run the step by clicking the Run button. After the migration is initiated, the steps can be run from the Migration Console.

When defining a command, system administrators can include predefined parameters and user and server-based parameters that have been defined in Stat. This provides a convenient way to specify values commonly invoked by operating system commands, such as server names and download directories. In addition, parameters offer a way to secure sensitive information by encrypting values that you do not want visible to users, such as passwords.

Predefined parameters specify values used to login to a target environment during a migration (database name, user name and password), whereas user and server-based parameters generally invoke values specific to the users and file servers defined in Stat. Also, certain parameters may be defined so that their values are different depending on which user or server they are being applied to. For more information on pre and post migration step parameters, see the Stat System Administration Guide, Chapter 4, “General Maintenance Tables”.

The Create Project Build Script step is a post migration step applicable for PeopleSoft versions 8 and higher only. When this step is triggered, Stat uses your PeopleSoft operator ID and password to log into the PeopleSoft environment that is the target of the migration and creates the build script for the project that was used during the migration. Stat uses the PeopleSoft command line statement to accomplish this and the build settings from the Windows registry to generate the SQL script for Create or Alter. The build script is placed in the location specified for build settings in your PeopleSoft configuration.

When this post migration step is triggered, Stat automatically launches the PeopleSoft COBOL Compile program, either CBLBLD for NT or pscbl.mak for Unix. Your system administrator defines the default server and variables required to run the compiler. For Unix, these variables include the PeopleSoft home directory and the Cobol Compile directory. For Windows servers, these variables also include the drive and directory where the compile is to take place. If you want to specify a different server and variables, you can do so in the Cobol Compile Variables dialog box, which Stat opens when you click Run.

After specifying the variables you want, click Preview to see how the object will be compiled. If satisfied with the results, click Run to execute the step.

Stat executes a Cobol Compile post migration step on a mainframe server as follows:

Stat changes the directory based on the values in the Directory and Cobol Compiler Location: Drive and Root Directory fields of the File Server Maintenance table.
If the Directory field has a value, it is displayed in the PS Home field on the Post Migration step window. This field cannot be modified on the Post Migration step window.
The Cobol Compiler Location:Drive and Root Directory value is displayed in the Cobol Compiler field on the Post Migration step window. This field can be modified when the step is run.

When running the step, Stat executes the login sequence as follows:

9
관련 문서

The document was helpful.

평가 결과 선택

I easily found the information I needed.

평가 결과 선택