Stat 7.0 - Web User Guide


	NOTE: System administrators can define pre migration steps that are not associated with either an object type or an environment. In this case, the step is triggered for all migrations.

•

If the target environment is also a distribution environment, the distributed environments are listed in italics

•

For mass migrations, the CSR id is also listed on the left side of the window

•

The windows can also be opened from the Environment Status window and from the search results window of the Migration History Wizard

Unlike the Pre Migration Steps window, the Post Migration Steps window is not opened automatically. Instead, post migration steps have a default status of Pending, which means that until the user changes the status of a post migration step to either Complete or N/A (Not Applicable), the migration will have a status of Wait for Post Step in the Migration Console. This is how Stat prompts users to complete post migration steps as intended. Once all the post migration steps have been marked as Complete or N/A, the status of the migration will change to Complete.

Running Custom Command Migration Steps

Automatic steps consist of custom commands defined by your system administrator. For more information on automatic steps, see the Stat System Administration Guide, Chapter 5, “Service Domain-Specific Maintenance.”

To execute an automatic step, click Run. Depending on the step, Stat may prompt you to specify additional parameters.

Custom commands are operating system commands executed by the client server that Stat is running on. When a custom command step is triggered, Stat opens the Custom Command Variables window. Here you can edit the command by adding or replacing parameters as needed, or you can run the command directly.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”.

To edit a custom command migration step:

In the Command with parameters field, enter the command you want Stat to run.

If you want to include parameters in the definition of the command, click the location where you want to insert the parameter and then double-click the parameter you want to insert. When included in a command, parameters are enclosed in double % signs, for example, “%%GL_PWD%%”.

Certain users and servers may have parameters that have been defined exclusively for them, or the value of a particular parameter may be different depending on which user or server it is being applied to. When the Stat Command Editor is first opened, the parameters are listed as they have been defined for the local client server and the current user. If you want to include parameters defined for a different server, click the Server field and select the server you want. Although you cannot select a different user in the User field, when a user executes the command when performing a pre or post migration step, they will have the option of inserting their own parameters or overriding default values.


	NOTE: System administrators can restrict user access to certain servers at the service domain level. The servers displayed in the Server field drop-down list may be limited if the server access of the current user has been restricted. For more information, see Stat System Administration, Chapter 3, “Stat Security.”

If the command you want to execute opens a window, specify if you want the window minimized, maximized, or normal size.

This value is saved and used at run time.

Click Interpret >>.

The Interpreted Command field displays how the command is interpreted by the client server. Null values and encrypted values are enclosed in angle brackets. Encrypted values are not displayed but replaced with asterisks.

(Optional) Verify that you defined the command properly by selecting the server you want to use to test the step in the Server field.


	NOTE: This is for testing purposes only. During execution of the step a user can select a different server.

Click OK.

To run pre and post migration steps:

In the Pre or Post Migration Steps windows, run each automatic step you want Stat to perform, specifying any additional parameters you want.

Select Complete for each step that Stat performs successfully.


	IMPORTANT: Stat displays an error message if it is unable to execute an automatic step. Also, Stat does not notify you if it completed the step successfully but the external application encountered errors. For example, when running the Compile Command step, Stat only knows if the command was executed properly. It does not know if the compile was successful or not. In this case, you will need to check the compile yourself.

Complete any manual steps, or perform them at a later time as required. Then select Complete for each step you perform.


	NOTE: Until a post migration step has been marked as either Complete or N/A (non-applicable or not applied), the migration will have a status of Wait for Post Step in the Migration Console. Once all the post migration steps have been marked as Complete or N/A, the status of migration will change to Complete.

When defining a pre and post migration step, system administrators can specify whether the step should be automatically included for each migration or once per target environment. This prevents Stat from prompting users to run the same step unnecessarily multiple times.

Click OK.

At this point, Stat does one of the following, depending on the type of migration step:

•

In the case of pre migration steps, Stat initiates the migration to the target environment.

•

In the case of post migration steps, Stat displays the Migration Path tab, which shows the base archive set successfully migrated to the Development environment.

Your migration path now shows the base archive set in your Development environment.

The process is the same for migration of all types of archive sets.

Running a migration (PeopleSoft)

To run a migration:


	IMPORTANT: Before you can migrate an archive set into an environment that requires migration approval, one or more authorized users must approve the migration.

Stat Web Client can only perform migrations which have Auto Migrations option enabled. Manual migrations can still be started from the web client. However, when they have reached the PS Pending state, they will have to be finished by the windows client.


	NOTE: Auto migrations of PS proprietary objects which have been started by the Web Client will be processed by the Stat Central Agent. However, migration of PS proprietary objects started in Windows Client are processed by the Windows Client itself. Auto migrations of PS proprietary objects started by the Stat Web Client will never be picked by the Stat Windows Client for processing. Similarly, migrations of PS proprietary objects started by the Windows Client will not be picked by the Stat Central Agent.

(Optional) If you want the Stat Central Agent to process the migration job at some later time, enter the date and time in the Migration Date field.

The field defaults to the current date and time. You can schedule the migration up to 90 days in the future.

(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.

(Optional) In the Description field, enter a unique description of the migration.

The field defaults to CSR ID+Archive ID.

(Optional) Select the Stop on Error option if you want the Stat Central Agent to terminate the migration at the first error it encounters.

System administrators may set this option to be selected or de-selected by default.

(Optional) De-select the class of objects (file objects or PeopleSoft objects) you do not want to migrate.

(Optional) In the Migrate column, de-select the individual objects you do not want to migrate.

If you are migrating to a distribution environment, the window displays the list of active target environments. By default, each environment in the distribution list is selected as a target. However, with the appropriate security rights, you can exclude certain environments from the migration.

(Optional) If migrating to a distribution environment, de-select any environment in the list of active target environments you want to exclude from the migration.

If the archive set contains file objects and the target environment is Development, in the Migrate files to field select one of the following options:

•

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.


	IMPORTANT: If the Development environment is a distribution environment and the archive set has both PeopleSoft proprietary objects and file objects selected for the migration, the option Working cannot be selected. To migrate file objects to Working, deselect the DB Objects option.

At this point, if you are only migrating file objects, you are ready to start the migration and can skip to Step 14. The remaining fields are dithered if there are no PeopleSoft proprietary objects in the selected archive set.

Select a staging database.

IMPORTANT: When migrating archive sets, bear in mind the following:

•

The base language of the staging database must be the same as the base language of the environment that the archive set came from (i.e., the source).

•

If the staging database you selected is currently in use, Stat displays a message telling you who is using the environment. You can retry the environment, select another environment, or if you have the proper security rights, click the Unlock button to unlock the environment. This deletes the other developer’s objects in the staging database and replaces them with yours.

Select one of the following options to name the Stat-created PeopleSoft project:

•

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 Application 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.


	NOTE: The Upgrade and Action values for objects in the archive set are not used when you use a PeopleSoft project contained in an archive set to perform the migration. In this case the Upgrade and Action values are set at the time you archived the project definition and the Upgrade and Action flags set in the archive set are ignored.

•

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: PeopleSoft project definitions are stored in the Stat Repository, and the only way to update a project definition is through the Application Designer interface, which means that even if you change the archive set in Stat by adding or deleting objects, the project definition remains unchanged in Stat.