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

Running a Migration (Oracle Applications)

To run a migration:
1
Open the CSR window and do one of the following:
•
In the Migration Path tab, click and hold your cursor over the source environment for the archive set and drag and drop it in the target environment.
•
In the Archive Sets tab, click Archive Sets to display the Archive Sets table. Then drag and drop the archive set you want from the table to the target environment's tree node.
* 
IMPORTANT: Before you can migrate an archive set into an environment that requires migration approval, one or more authorized users must approve the migration. For more information, see Migration Approvals and Mass Migrations (Oracle Applications) .
Stat opens the Migration window.
2
(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.
3
(Optional) In the Description field, enter a unique description of the migration.
The field defaults to CSR ID+Archive ID.
4
(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.
5
(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.
This option is selected by default and is displayed only if one or more Migration Notification business or personal rules have been defined for the service domain. Fore more information, see Defining Personal Rules .
6
(Optional) Select the Maintenance Mode option if you are on Oracle Applications version AD.I and want Stat to put the environment in Maintenance Mode when migrating objects.
The Maintenance Mode field is disabled if you are on an earlier version than AD.I. For more information on Maintenance Mode, see your Oracle Applications documentation.(This option does not apply to R12.2 environments.)
7
Select the archive set you want to migrate.
The window displays a list of archive sets that you can migrate from the selected environment. If you initiated the migration from the Archive Sets tab, the list displays only the archive set that you dragged and dropped onto the target environment.
By default, all the objects in the archive set are selected for the migration. However, with the appropriate security rights, you can exclude either all the file objects or all the database objects from the migration. You can also exclude individual objects.
8
(Optional) De-select the class of objects (file objects, setup, or schema objects) you do not want to migrate.
9
(Optional) In the Migrate column, de-select the individual objects you do not want to migrate.
* 
NOTE: If an Oracle Apps file object type is flagged as a database script, the Stat Oracle Agent executes these objects using sqlplus during a migration. The Oracle agent only looks at the return code from sqlplus to determine if the migration was successful or not. The following statement should be included with all scripts to instruct sqlplus to return a non-zero return code if errors are encountered:
SET VERIFY OFF
WHENEVER SQLERROR EXIT FAILURE ROLLBACK;
WHENEVER OSERROR EXIT FAILURE ROLLBACK;
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.
10
(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.
11
If the archive set contains file objects and the target environment is Development, select one of the following options in the Migrate file to field:
•
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. If the archive set does not contain any file objects or the target environment is not Development, this option is dithered with a value of “NA.”
12
If the target environment is version R12.2, select the file system to which you want to migrate file objects in the Edition field.
Options include Run, Patch, or Both.
* 
NOTE: R12.2 application tier file system has 2 copies of all files. A “Run File System” where all the services are currently running from, and a “Patch File System” where all patches are applied in a patch cycle. A patch cycle starts when the prepare phase of adop is run and the “Run File System” is copied to the “Patch File System.”

Stat archives file objects from the current Run Edition.The Edition field is only displayed if the target environment is R12.2 or higher.

13
Click Migrate.
At this point, Stat may prompt you to select and order the pre and post migration steps (if any) that have been defined for the target environment or for the objects or object types in the archive set.
14
Select pre and post migration steps, as necessary.
For more information, see Pre and Post Migration Steps .
15
After selecting the pre-migration steps, click the Migrate button.
Stat opens the CSR Migrations Console, which shows that the migration job has been submitted to the Stat Central Agent. The Agent either begins processing the migration immediately, or if you scheduled the migration, at the date and time you specified. For more information, see Migration Console .
16
If you are only migrating file objects, Stat copies the file objects into 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 performed either manually by the user or automatically by Stat. The steps are meant to promote adherence to development standards and are not mandatory or enforced.

Pre and post migration steps can be associated with object types, object classes and with target environments. This means that 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 the Pre Migration Steps window. This window displays a checklist of recommended actions that should be taken before the archive set is migrated.

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

Regarding Pre and Post Migration Steps windows:

•
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:
1
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.”
2
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.
3
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.
4
(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.
5
Click OK.
Viewing Migration Step History

To view the history of any automatic step, select it and click History. This opens the Post 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 the 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.

To run pre and post migration steps:
1
In the Pre or Post Migration Steps windows, run each automatic step you want Stat to perform, specifying any additional parameters you want.
2
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.
3
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.
4
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.

Migration Approvals and Mass Migrations (Oracle Applications)

Stat provides advanced version control and change management support in the form of migration approvals and mass migrations:

•
Migration approvals provide a way for system administrators to maintain data integrity in PeopleSoft environments. Before you can migrate an archive set into an environment that requires migration approval, one or more authorized users must approve the migration.
•
Mass migrations allow a user to group multiple archive sets and migrate them as a single unit to the same environment. There are two ways to perform a mass migration, either by flagging individual archive sets as candidates for a mass migration, or by specifying an application release label assigned to certain archive sets within the service domain.

Marking Archive Sets for Migration

When you want to perform a migration that requires approval, or you want to flag an archive set for a mass migration, the first step is to mark the archive set for migration. This is done either by individually selecting the Ready to Migrate option on the Archive Sets tab of the CSR window, and then selecting the environment(s) that you want to target, or by marking multiple archive sets in the Ready to Migrate window.

* 
NOTE: The security right, OraApp Archive Set - Ready to Migrate, allows you to mark an archive for a migration even if you do not have the user class rights to perform migrations. This way, users that have migration rights can migrate your archive set for you.
Marking Individual Archive Sets
To mark an archive set for a migration:
1
On the CSR the archive set belongs to, open the Archive Sets tab in the CSR window.
2
In the Archive Set table, select Ready to Migrate for the archive set. Then click Apply.
3
Click Migration Target.
This opens the Target Environments window. Here you can specify the environment(s) to which you want to migrate the archive set.
4
In the table on the right side of the window, select Migrate for each environment that you want to designate as a target environment.
* 
NOTE: In the table displayed in the right section of the Target environments window, distribution environments and their associated distributed environments are designated by small blue and yellow icons, respectively. When you select the Migrate check box for a distribution environment, all the environments on its distribution list are selected as well. Also, you cannot select a distributed environment without selecting its distribution environment as well.
5
Click Premigration List to view a checklist of any actions you should take before migrating the archive set.
For more information on pre migration steps, see the section, Pre and Post Migration Steps .
6
Click OK or Apply to save your work.
The archive set appears in the Mass Migration window for the target environment, and the approval requests, if any, are generated and sent out to each user authorized to approve the migration.
* 
NOTE: If you later decide you do not want to migrate to a particular environment, deselect it in the Target Environments window. When you click OK or Apply, any approval requests that were generated the first time are deleted.
Marking Multiple Archive Sets

The Ready to Migrate window displays all the archive sets that have not yet been individually marked for migration and which share the same release label and environment on the migration paths of their respective CSRs. After you specify the target environment and release label, Stat retrieves all the qualifying archive sets that have not been marked for migration. Retrieved archive sets are marked for migration by default. You can unmark any archive set you do not want marked as Ready to Migrate.

To mark multiple archive sets for migration:
1
Select Migration Management | Archive Sets - Ready to Migrate.
2
In the Module field select the change management module you are using.
3
In the Service Domain field select the service domain of the archive sets.
4
In the Environment field select the migration target environment of the archive sets.
Stat retrieves archive sets that share the selected environment in the migration paths of their respective CSRs.
5
In the Release field select a release label.
6
Stat retrieves archive sets that have been assigned to that release. Release labels can be minor or major and are defined by system administrators.
* 
NOTE: A Minor release is considered a branch of its parent release. This means that when you select a minor release label, Stat retrieves all the archive sets assigned the parent release labels as well. For example, using a typical version sequence, if you select the release label 2.2.1, Stat also retrieves archive sets assigned its parent release labels, 2.2 and 2.0.
7
(Optional) Deselect Ready to Migrate for any archive set that you do not want to be marked for migration.
8
Click OK.
Documents connexes

The document was helpful.

Sélectionner une évaluation

I easily found the information I needed.

Sélectionner une évaluation