Chat now with support
Chat with Support

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

Schema Objects

Stat supports locking, archiving, and migrating schema object definitions on Oracle databases version 9i or higher and on Microsoft SQL Server 2005/2008.

* 
NOTE: Oracle and SQL Server database schema objects include a set of predefined true/false parameters that are executed before the definition of the object is captured in Stat. You can change the true/false values of these parameters in the Schema Object Parameters Maintenance table. For more information, see the Stat System Administration Guide, Chapter 4, “General Maintenance Tables.”
Oracle

Stat supports certain schema object definitions for PeopleSoft environments running on Oracle databases version 10 or higher. If you are running PeopleSoft on a supported Oracle database version 10 or higher, you can lock, archive, and migrate schema objects. Stat currently supports the following schema object types:

•
Package Specification
•
Package Body
•
Procedure
•
Function
•
View
•
Trigger
•
Table
•
Index
•
Synonym
•
Sequence
SQL Server

The following schema objects may be archived from and migrated to Microsoft SQL Server 2005/2008 databases:

•
Table
•
Index
•
View
•
Trigger
•
Function
•
Procedure
•
Synonym

Object Locking and Reservations (PeopleSoft)

Object locking is an important part of any change management practice since it coordinates all of the developers’ efforts and prevents work from being overwritten. Stat supports two levels of object locking functionality.

The first level is the locking of the objects in the Stat Repository. This is a logical lock, which means that the lock shows up in the Stat application, but developers can still go directly into PeopleSoft or a file directory and make changes to the object even if the lock on the object isn’t theirs. As long as the developers use a CSR to modify objects, the coordination of development is maintained.

The second level is the physical locking of objects in PeopleSoft environments. This second level of locking is optional. It can be turned on for all the environments and file locations in a service domain or a select few. You can also exclude specific PeopleSoft proprietary object types from the physical locking. Your system administrator and file server administrator configure these options. When activated, physical locking works in conjunction with logical locking.

The following sections apply to locking in general, whether you are using just one or both levels of locking. Specific information about physical locking is found in the sections, “Physical PeopleSoft Locking Option” and “Physical File Locking Option” later in this chapter.

Understanding Object Reservations and Locks

Locks and reservations are issued to the developer assigned to the object, regardless of who actually requested the lock. That person may or may not be the assigned developer. This is a security measure determined by user class rights.

A lock indicates that the assigned developer has exclusive change/edit rights on the object. A reservation indicates that the object is currently locked by another developer and you are waiting for the object to become available. Once the object becomes available, Stat converts the reservation to a lock and notifies the holder of the new lock via email. Remember, the holder of the reservation is the developer assigned to the object in the CSR. If you request the lock but are not the assigned developer, you will not receive an email when the reservation turns into a lock.

Stat supports the Physical Locking for the objects types that can be added to a PeopleSoft Definition Security Group.

For certain objects types, PeopleSoft has the following conditions:

•
You can physically lock SQL objects if they are of the ‘Normal’ variety (as opposed to the types, Application Engine and Record View).
•
You can physically lock Application Package if they are of the top level variety (there are three levels of Application Package objects)

These conditions are dictated by PeopleSoft object security requirements, not Stat. To see if a particular SQL or Application Package object is of the variety that can be physically locked in Stat, look in PeopleSoft and see if they have been included in the object security group.

For a complete list of PeopleSoft proprietary object types that you can logically lock in Stat, see Appendix: Supported PeopleSoft Proprietary Objects .

The Object Locking Process

The Object Locking Process

The object locking process has up to three phases.

Phase 1: Tentative Lock/Reservation

When you associate an object with a CSR, Stat automatically requests a lock for that object in the designated environment(s). Stat checks if there are existing locks or reservations on that object. If a lock or reservation exists, Stat issues a tentative reservation. If not, it issues a tentative lock. The lock or reservation remains tentative until you save the CSR.

Phase 2: Full Lock/Reservation

Immediately after associating objects with a CSR, you should save your work. Upon saving, Stat checks for existing locks or reservations. If a lock or reservation exists, Stat issues a full reservation. If not, it issues a full lock.

The longer you wait to save your CSR, the greater the likelihood you will lose your place in the queue for that object. For example, while you have a tentative lock on an object, another user could add that same object to a CSR and receive a tentative reservation. If the second user then saves his or her CSR before you do, that user receives the full lock for that object, and when you save your CSR, you receive instead a full reservation.

When Stat issues a full lock, it automatically archives a “pre-change” version of the object to the Stat Repository. Archiving objects is discussed in depth in the next chapter.

Phase 3: Reservation Conversion to Lock

The third phase is the conversion of reservations into locks. Stat releases an object lock when the status of the CSR changes to a closed-type status, or when the developer manually unlocks the object or the object is reassigned to another developer. After unlocking an object, the Stat Central Agent then determines if there are any pending reservations on the object. If reservations on the object have been given to more than one user, these reservations are handled in chronological order, based on the time each lock was requested. The Stat Central Agent converts the first reservation in line into a lock and performs any applicable object archiving.

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating