Stat 6.3 - User Guide

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.

As with Pre Migration steps, after you successfully migrate an archive set that contains an associated object type or class, or after you migrate to an associated target environment, Stat opens the Post Migration Steps window.

Regarding Pre and Post Migration Steps windows:

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.

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 book, Stat System Administration, Chapter 4, “General Maintenance Tables”.

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

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

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

NOTE: Stat displays an error message if it is unable to execute an automatic step. Also, Stat does not notify you if after it completed the step successfully 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.

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.

Your migration path now shows the base archive set in your Development environment. You can go into the Development environment and begin making changes to the generic application objects.

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

Migration Approvals and Mass Migrations (Generic Applications)

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

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, GenApp 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.

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

TIP: 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.

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.

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.

Approving Migrations

Before you can migrate an archive set into a generic applications environment, you may need to get the migration approved by users authorized to approve migrations into that environment. Conversely, if you have been designated as a migration approver for a particular environment by your system administrator, other users may need your approval before they can migrate archive sets into that environment. Migration approvals are environment-specific. They provide a way for users (typically managers and development leaders) to monitor and control migrations into environments containing sensitive information, such as object definitions that should not be modified or overwritten.

Approval lists can be either required or optional and can include individual users, entire user classes, or a combination of the two. Although system administrators can add user or class to an approval list, be aware that only users that have access to an environment (as determined by system administrators in the User Maintenance table) will be able to approve a migration into that environment or receive email notifications regarding their pending approval. If an approver does not have access to the environment, the migration cannot be approved until either the user is granted access to the environment or their approval is overridden by another user with proper security rights.

TIP: To check whether migrations into a particular environment require approvals or not, see the Approval Required column in the environment table of the Target Environments window.

For more information on migration approvals, see the Stat System Administration Guide, Chapter 4, “General Maintenance Tables.”

IMPORTANT: A migration cannot go forward if just one approver rejects the migration, even if that user’s approval is not otherwise required. Before the migration can occur, either the user or another user authorized to override migration approvals must change their migration approval status from Rejected to Approved or to Pending.

TIP: Double-click an approval record to open its associated CSR.

TIP: With proper security rights, you can also change the status of your own migration approvals.

You can also approve the migration of an archive set in the Target Environments window of the CSR.

TIP: With proper security rights, you can make approvals for other users. You can also unapprove all approvals by clicking Unapprove All. This allows you to deselect the Ready to Migrate check box for the target environment. When you override another user’s approval, Stat records you as the approver, not the user originally assigned to make the approval.

You can view records of migration approvals from the Migration Details window. For more information, see Documenting Migrations (Generic Applications) .

If you want to notify users about migrations that are still pending their approval, you can email a message predefined by system administrators. In the tree list of approvers, select the node representing the user or class that you want to notify and click Email. An email job request is sent to the Stat Central Agent, which processes the request and sends an email to the user you selected or to each member of the selected class. A “@” sign is displayed for that approver node in the Envelope field of the Approval List tab.

NOTE: The Email button is disabled once the approval requirements of a migration have been satisfied.

System administrators can also configure the Stat Central Agent to include links in the reminder message that the recipient can click to approve or reject the migration. This sends an email back to the Stat Central Agent, which processes the response email and changes the approval status to Approve or Reject, depending on which link the approver selected.

NOTE: When an approval status is changed by responding to a reminder message, the Update Date field in the Approval List window will be automatically populated and the Update By field will display the value, Via Email.

Approval notification reminder messages can also be sent for workflow status transfers and Oracle Apps patch applications. For more information, see the book Stat System Administration, Chapter 7, “Email Configuration”.