Chat now with support
Chat with Support

NOTICE! We are upgrading our support telephone services, implementing Genesys, starting the week of May 19, 2025

Stat 7.0 - System Administration Guide

Overview of Stat Administration Administrative Utilities Stat Security General Maintenance Tables
System Maintenance Service Domain Maintenance Department Maintenance Issue Tracking Maintenance Country Maintenance Customer Maintenance Object Type Maintenance PeopleSoft Environment Connection Maintenance Pre/Post Migration Steps Parameters Oracle Applications Configuration Oracle Applications Connection Maintenance Generic Application Connection Maintenance Schema Object Parameters Maintenance Data Object Maintenance PeopleSoft Search Configurations Stat Report Definition Maintenance Version Control Management Connection Maintenance
Service Domain-Specific Maintenance Configuring the Stat Central Agent Email Configuration Object Security Enabling Web Client to perform PeopleSoft migrations Appendix: Sample Service Domain Configuration Appendix: User Class Rights Appendix: Creating a Staging Database Appendix: Database Tuning Appendix: Oracle Applications File Type Directory Appendix: Ports and Firewalls Appendix: REST Web Services API Appendix: SOAP-Based Web Services API Appendix: Troubleshooting Chart Appendix: Oracle Agent: Stat.conf and log4j2.xml configuration Appendix: Custom Report Files

Present architecture

The Stat central agent changes the status of the current migration to PS Pending. At this point windows client will pick the migration and delegate the actual migration to the app designer (or data mover in specific cases).

Compatibility issues with the current implementation

The web client cannot be a substitute the windows client in the current architecture. Through a web application, we cannot control specific applications on the end user’s machine.

We can simply install the PS tools utilities on the web server aka Stat central agent's machine. However, there are the following issues with this approach

•
Application designer can only be installed on Windows. But SCA can be installed on Windows and Linux. Users with Linux based SCA's wont be able to install application designer on their system.
•
Couping PeopleTools utilities with SCA would also mean that all migration requests will go to a single PT enabled server. This can become a scaling issue in case of large number of parallel migrations.

It is clear that to mitigate the above problems, we will have to come up with an alternate approach. Users will have to have machines (with SSH enabled) where PT tool utilities are installed.

Goals of an alternate approach

•
Users should be able to easily adapt to our new approach.
•
Admins should be able to configure multiple servers dedicated for migration. (Will be clearer on the next section). This will help them scale horizontally.
•
Admins should have the ability to provide each user with multiple servers for migration. However, users will have only one server for each version of PeopleSoft. With the current Windows Client implementation, users can only migrate for one version at a time, unless they change their PS options configuration.
•
Users shouldn't have to re-learn any of the existing feature's workflow.

Alternate Architecture

Alternate Architecture

We can inform Stat about servers where application designer and data mover is present. SCA will create an SSH connection to this server and run the same CLI commands which are run by the Windows Client.

When a migration which has PS proprietary objects reaches PS Pending, it will be picked up by Stat Agent Job which runs every 5 seconds for processing. This job has been added in the AGENT_SYSTEM_JOB Stat repository table and will help to conclude this migration.

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating