Advanced Administrative Topics

In this section:

In addition to the standard administrative options described in this chapter, advanced options and techniques are available to assist in automating security access updates and troubleshooting integration problems. This topic discusses these options and provides additional details on PeopleSoft security integration.


Top of page

x
Automating Security Access Updates

How to:

Reference:

Security resynchronization is one of the functions of the PeopleSoft Administrator. When administering PeopleSoft connections through the Web console, you simply select the Re-Synch link under the Security group, and all of the PeopleSoft data security rules are re-synchronized.

The batch resynchronization utility enables administrators to schedule, through an operating system command, the execution of this functionality without having to manually open the Administrator tool. By scheduling this process nightly (or otherwise; based on business requirements), administrators are not required to perform this function manually, and they can be assured that the data security rules are current as of the last scheduled run.

The utility is comprised of two files. These files are a procedure (pssecsnk.fex) used in executing the resynchronization routine and a t3i script (pssecsnk.t3i), which is the command line input file. By starting the server with the t3i script as an input, the server performs the required security resynchronization without user intervention.

A server can be accessed locally without the use of client software. This functionality can be started in the following two modes:

An administrative user with access to the server can use the server in stand-alone mode to perform any of these functions. If PeopleSoft data must be accessed in any of these processes, you must execute the PeopleSoft authentication routine. Because of the processing within the authentication routine, the creation of a custom startup script is recommended.

The two purposes for the custom script are:

When using the edastart script, temporary files are always written to the current directory. When using edastart without modification, be sure to delete these temporary files from the current directory after execution to avoid unexpected results during run time.



Example: Creating a Custom Server Startup Script for UNIX

The following provides the steps for creating and using a custom startup script in UNIX.

Navigate to the EDACONF/bin directory on your server and create a new script with a text editor. The following script is named pslocal. The numbers on the left correspond to the notes explaining the code.

Note: This example creates a unique directory under the $EDACONF/edalocal directory. The edalocal directory must exist in most operating systems before a directory can be created within it.

    #!/bin/ksh
    #
    parms=$*
    #
    #  Define the Conf Directory 
1.  export EDACONF=/ibi/srv77/wfs 
    #
    #  Create unique temporary directory for running locally 
2.  EDA_PID=$$
    export EDATEMP=$EDACONF/edalocal/$EDA_PID
    rm -rf $EDATEMP
    mkdir $EDATEMP
3.  cd $EDATEMP
4.  $EDACONF/bin/edastart $parms
5.  cd $EDACONF/bin
    rm -r $EDATEMP

The script processes as follows:

  1. The export command defines the EDACONF variable to use. This makes the remainder of the script more flexible and portable.
  2. These four lines define a unique directory based on a PID and UNIX process ID so that all temporary files will be written to a unique location.
  3. The CD command changes the current directory to the new temporary directory.
  4. This line calls the delivered edastart script and parameters passed through the script.
  5. These two lines change the current directory from the temporary space, and deletes the temporary files.

The following is an example of a script similar to the UNIX version but for Windows.

@ECHO ON
setlocal
set EDATEMP=c:\ibi\srv77\wfs
echo %EDATEMP%
mkdir %EDATEMP%\edalocal
cd %EDATEMP%\edalocal
%EDATEMP%\bin\edastart %*
endlocal


x
Procedure: How to Use the PeopleSoft Interactive Agent

The following procedure is for a UNIX environment.

  1. Navigate to the server configuration directory, then to the bin subdirectory.
  2. Execute the Interactive Agent start-up script with the -t option. This is the same for UNIX and Windows platforms
    /ibi/srv77/wfs/bin/pslocal -t

    where:

    /ibi/srv77/wfs/bin

    Is the bin directory under the server configuration.

    When you run

    pslocal -t

    you see information similar to:

    RELEASE = R727704B
    GEN_NUM = 624
    SOURCE_DATE = 09/25/2011 16:22:39
    BUILD_DATE = 09/26/2011 20:06:57
    INSTALLATION_DATE = 9/26/2011 20:32:17
    >>

    At the prompt, you can type commands.

  3. To perform any commands that access PeopleSoft data, first you must run the interactive authentication routine. If this procedure is not run, you receive data access errors. To execute the procedure, type
    >>EX PSLOGIN USERID=PS_Userid, PASSWD=PS_Password

    where:

    PS_Userid and PS_Password

    Is a valid PeopleSoft user ID and password.

You see processing information followed by a FOCUS command prompt. After control returns to the FOCUS command prompt, PeopleSoft data may be accessed with the FOCUS language.

Note: If your configuration has been set up with Trusted authentication, then you are not required to supply the PeopleSoft password. Only a valid user ID is required.



x
Procedure: How to Run Batch Mode Security Resynchronization From the Command Line

The following procedure is for a Windows environment.

  1. Locate the pssecsnk.t3i script in the EDACONF\catalog directory.
  2. Using PeopleSoft Batch-Mode, execute with the security synchronization input script. To execute input scripts with the pslocal script, use the -f option
    c:\ibi\srv77\wfs\bin\pslocal -f c:\ibi\srv77\wfs\catalog\pssecsnk.t3i

    where:

    c:\ibi\srv77\wfs\catalog

    Is the directory location of the t3i file.

For details about securing the script, see Password Security.



x
Reference: Password Security

The t3i script is an ASCII text file that must be edited for your particular environment. It contains two FOCUS execute command lines that:

The syntax is:

< Filename: pssecsnk.t3i >
%CONNECT
%BEGIN
EX PSLOGIN USERID=PS, PASSWD=PS, PSBATCH=X
EX PSSECBAT
%END
%DISCONNECT
%STOP_SERVER

You must modify the user ID and password in accordance with one that is appropriate for your environment. The user ID must be granted access in PeopleSoft.

Since the file is in readable text, the administrator must prevent read/write access for anyone not authorized to access the t3i. The best way to prevent unauthorized access is to use operating system security. Windows and UNIX provide ways to prevent unauthorized access to individual files and entire directories. Contact your operating system administrator for assistance in performing this security step.



x
Procedure: How to Capture Execution Results

Usually, after execution, all temporary work files are deleted immediately. If you must verify work files or see the batch process output file, you can temporarily modify the execution script.

To temporarily prevent the deletion of these processing files, edit the pslocal script found in the EDACONF/bin directory. Insert the appropriate comment character for your environment where the final file deletion step exists.

In UNIX environments, type:

# rm -r $EDATEMP

After the script has been executed, the Administrator can review the execution results. A batch process output file (pssecsnk.t3o) is automatically created in the EDACONF/edalocal directory, with a unique subdirectory for each execution.

For an illustration, see Creating a Custom Server Startup Script for UNIX.



Example: Capturing Execution Results

The following is an example of a successful execution:

< Filename: pssecsnk.t3o >
%connect
%begin
ex pslogin userid=ps, passwd=ps
ex pssecbat
%end
SYSPRINT.SCR
0 NUMBER OF RECORDS IN TABLE=       1  LINES=      1
File doesn't exist
Successful Security Re-synch for Connection: E850A53
 DBNUM: 1 has been re-synchronized, DBA security is: ON
CLOSEALL.ALL
%disconnect
%stop_server

Note: As the user ID and password appear in this output file, the file must be protected by operating system security.


Top of page

x
Troubleshooting Tips

How to:

These troubleshooting tips help if you are getting FOCUS error messages, such as a FOC1302, or if you are seeing SQL errors when you run reports.



x
Procedure: How to Connect to the PeopleSoft Data Sources

The most likely source of difficulty in connecting to your PeopleSoft data source is the data source connectivity. If you are experiencing difficulty connecting to the data source:

  1. Verify that the data source instance is up and running.
  2. Run a client query tool on the server, using the PeopleSoft access ID.
    • If you cannot log in to the data source, there is a problem with the access ID.

      Verify the ID and check to see if the password has changed.

      If the password has changed, then it must also be changed in the PeopleSoft configuration.

    • If you can log in, proceed to Step 3.
  3. Run a few simple queries against the PeopleSoft records that are returning errors.

    If you are not getting any rows back, check to see if the PeopleSoft access ID has read authority on the PeopleSoft records you are accessing.



x
Procedure: How to Verify Security

PeopleSoft enforces all the security mechanisms used by the PeopleSoft Query tool. This includes Query Tree security and row-level security. If you are getting unexpected results, it is possible that your PeopleSoft security has not been configured properly.

To verify that security is being properly enforced:

  1. Verify that the synonym(s) being queried are correct.

    The Administrator can run a report of installed records to verify. If row-level security is the issue, the server-side ACX file should be reviewed and compared to the record definition in PeopleSoft, including the Security Search record.

  2. Create a similar query in PS/Query. The SQL code can be viewed and compared to SQL tracing on the server.
  3. Examine the SQL.

    Does it appear to match the business logic behind the original request? If not, check the syntax behind the original FOCUS code. Perhaps you are using a WRITE instead of a PRINT, or perhaps a WHERE clause has been coded incorrectly.

  4. Run this SQL directly against the RDBMS using a data source query tool.

    If you are getting the expected results, then there may be a problem with the program logic after the data is returned to FOCUS from the RDBMS. Examine COMPUTE/DEFINE statements for logic errors or, if you are using ON TABLE HOLD, there may be a problem in your code.

    If you are getting the same unexpected results, then examine the underlying data. Perhaps some cross-referenced fields are missing, or perhaps row-level security is eliminating essential rows.


iWay Software