Archive

Archive for December, 2007

Three level Rowset Peoplecode

December 26, 2007 9 comments

Here is a typical peoplecode example for reaching the level three reord using rowset peoplecode. 

/* Need to insert a row when a flag = ‘Y’ after graying all other fields in the row in correction mode */
PeopleCode Event : COMPONENT_NAME(Component).GBL.PostBuild(Component PeopleCode)

Local Rowset &TQ_Lvl0, &TQ_Lvl1, &TQ_Lvl2, &TQ_Lvl3;
Local number &insert_row, &lvl_1_row, &lvl_2_row, &lvl_3_row;

&TQ_Lvl0 = GetLevel0();
&TQ_Lvl1 = &TQ_Lvl0(1).GetRowset(Scroll.LEVEL1_SCROLL_NAME);
&insert_flag = “N”;

For &lvl_1_row = 1 To &TQ_Lvl1.ActiveRowCount
   &TQ_Lvl2 = &TQ_Lvl1(&lvl_1_row).GetRowset(Scroll.LEVEL2_SCROLL_NAME);
   For &lvl_2_row = 1 To &TQ_Lvl2.ActiveRowCount
      &TQ_Lvl3 = &TQ_Lvl2(&lvl_2_row).GetRowset(Scroll.LEVEL3_SCROLL_NAME);
      For &lvl_3_row = 1 To &TQ_Lvl3.ActiveRowCount
         &tq_adj_applied = &TQ_Lvl3(&lvl_3_row).LEVEL3_RECORD_NAME.FIELD_NAME.Value;
         If &tq_adj_applied = “Y” Then
            &TQ_Lvl3(&lvl_3_row).MPF_TINQ_LOG.EARNS_END_DT.Enabled = False;
            &TQ_Lvl3(&lvl_3_row).MPF_TINQ_LOG.MPF_ADD_SUBTRACT.Enabled = False;
            &TQ_Lvl3(&lvl_3_row).MPF_TINQ_LOG.MPF_HOURS_TYPE.Enabled = False;
            &TQ_Lvl3(&lvl_3_row).MPF_TINQ_LOG.MPF_HOURS_ADJ.Enabled = False;
            If %Mode = %Action_Correction Then
               &TQ_Lvl3.InsertRow(&TQ_Lvl3.ActiveRowCount);
            End-If;
         End-If;
      End-For
   End-For;
End-For;

Categories: PeopleCode Tags:

PSAE and PSAESRV

December 22, 2007 2 comments

PSAESRV is Application Engine server processes that handles Application Engine requests
PSAE is an executable that executes the application engine request.

PeopleSoft conducted a study and shown that PSAE is just as good as PSAESRV for most practical purposes. If you have an AE job that runs longer than 10 sec, PSAE is equivalent to PSAESRV. PSAE has the added advantage of being recycled at the end of each AE job, cleaning up any outstanding SQL cursors to the database that may have been left behind. Since PSAE recycles after each use, it does not has any possible memory leakage problem that may occupied the precious system memory. In short, PSAE is a cleaner workhorse.

To shutdown PSAESRV, when you configure the Process Scheduler, you can change the default of the PSAESRV instance to 0.
Values for config section – PSAESRV
Max Instances =0
Recycle Count=1000
Allowed Consec Service Failures=2

Categories: PS Admin

sa (system admin) password change

December 20, 2007 Leave a comment

For security reasons, you may have to change sa password frequently in PeopleSoft application. Here are the two ways to change sa password. This change should be done when no users logged into the system. Apart from changing the password, no other configuration change is required in this regard.

1. Using Application Designer : Login to application designer and follow steps mentioned below.

  • Select Tools > Miscellaneous Definitions > Access Profiles.
  • The Access Profiles dialog appears.
  • In the Access Profiles: list, highlight the profile that you want to modify, and click Edit.
  • The Change Access Profile dialog appears.
  • This dialog prompts you for the old password then to type and confirm the new password for the Access Profile.
  • Enter and confirm the new a password.
  • The Access Password is the password string for the ID. Confirm Password is a required field and its value must match that of Access Password.
  • Click OK.

2. The manual steps are as given below

  • Change the ‘sa’ password at database level.
  • Login to Datamover in bootstrap mode and run the below script
  • For PeopleTool in 8.4x
      change_access_password sa1 NEW_SYSADM_PWD;
    For lower PeopleTools version it could be
      set change_access_password sa1 NEW_SYSADM_PWD;

    sa1 is the symbolic id for sa.

Categories: PS Admin

Forgot Password functionality

December 15, 2007 1 comment

Please visit Brent’s PeopleSoft corner blog for complete details.

http://www.erpassociates.com/peoplesoft-corner-wiki/security/forgot-password-functionality.html

Categories: PS Admin, Security

bea.jolt.ApplicationException: TPESVCFAIL

December 14, 2007 1 comment

When you try to log online and you get the following error message:

CHECK APPSERVER LOGS. THE SITE BOOTED WITH INTERNAL DEFAULT SETTINGS, BECAUSE OF: bea.jolt.ApplicationException: TPESVCFAIL – application level service failure

(PeopleSoft Solution ID – 200766418 – PT 8.44)

This could be because of the Peoplsoft Default web profile user ID PTWEBSERVER got locked. Run the below SQL to resolve the above issue.

UPDATE PSOPRDEFN SET ACCTLOCK=0 WHERE OPRID=’PTWEBSERVER’

The PTWEBSERVER account provides the portal servlet with minimal security access, sufficient only to launch the portal environment, but without access to any pages or other PIA objects. This account uses the PTPT1500 permission list.

Also before update the above sql,  make sure that this user, role, and permission list are currently in your database by using the following SQLs.

select * from PSCLASSDEFN where CLASSID = ‘PTPT1500’
select * from PSAUTHSIGNON where CLASSID = ‘PTPT1500’
select * from PSROLEDEFN where ROLENAME = ‘PeopleTools Web Server’
select * from PSROLECLASS where ROLENAME = ‘PeopleTools Web Server’
select * from PSOPRDEFN where OPRID = ‘PTWEBSERVER’
select * from PSROLEUSER where ROLEUSER = ‘PTWEBSERVER’

Categories: PS Admin

Signon PeopleCode modification

December 11, 2007 6 comments

We had a requirement to track unsuccessful login details. PeopleSoft delivered PSACCESSLOG table gives only successful login details. To get unsuccessful login details, I modified PASSWORD_CONTROLS() function in  FUNCLIB_PWDCNTL.PWDCNTL.FieldChangePeopleCode

To do this I created a record ACCESS_DET with OPRID, LOGGINDTTM etc fields. This record stores all unsuccessful log-ins data. Then Open the peoplecode (Record.FUNCLIB_PWDCNTL, Field.PWDCNTL, Peoplecode.FieldChange)  and added the below shown PeopleCode inside the password_controls() function, where the %PSAuthResult value is negative.

      Local Record &ACCESSREC;
      Local SQL &ACCESS_SQL;
     
      &ACCESSREC = CreateRecord(Record.ACCESS_DET);
      &ACCESS_SQL = CreateSQL(“%Insert(:1)”);
     
      &ACCESSREC.OPRID.Value = &USERID;
      &ACCESSREC.LOGIPADDRESS.Value = ” “;
      &ACCESSREC.LOGINDTTM.Value = %Datetime;
      &ACCESSREC.LOGOUTDTTM.Value = “”;
      &ACCESSREC.FF_SUCCESS_FLG.Value = “N”;
      &ACCESSREC.LOGINATTEMPTS.Value = &FailedNum;
     
      &ACCESS_SQL.Execute(&ACCESSREC);
      &ACCESS_SQL.Close();

Related articles in other blogs:

Record Audit

December 7, 2007 24 comments

PeopleTools ver 8.45 

To audit an already exisiting PeopleSoft record, we need to create a record definition and SQL table in which we store audit information. When creating the audit record, remove any attributes such as
PARENT records, Query Security Records, and PeopleCode. The easiest way to create an audit table is to open the record definition of the base record that you wish to audit. Save it as a new record, prefaced with AUDIT_.

Remove the all edit and key attributes from the newly saved record. Also remove any attributes such as
PARENT records, Query Security Records, and PeopleCode. Add to the top of the audit record the following three special audit-specific fields in the same order given below.

  • AUDIT_OPRID
  • AUDIT_STAMP
  • AUDIT_ACTN
  • AUDIT_RECNAME

In most cases you should include AUDIT_OPRID, AUDIT_STAMP, AUDIT_ACTN. The AUDIT_STAMP must be given the attribute AUTOUPDATE. You might also add AUDIT_RECNAME if you are creating an audit table to audit more than one record definition.

Make these fields required and keys. Then build the table. Make sure you can query this table using sql editor.

The purpose of each audit specific field is explained below.

AUDIT_OPRID – Identifies the user who caused the system to trigger the audits—either by performing an add, change, or delete to an audited field.
AUDIT_STAMP – Identifies the date and time the audit was triggered.
AUDIT_ACTN  – Indicates the type of action that the system audited. Possible actions include:

  • A: Row inserted.
  • D: Row deleted.
  • C: Row changed (updated), but no key fields changed. The system writes old values to the audit table.
  • K: Row changed (updated), and at least one key field changed. The system writes old values to the audit table.
  • N: Row changed (updated), and at least one key field changed. The system writes new values to the audit table.

AUDIT_RECNAME –  Identifies the name of the record definition that was audited.

The audit table does not have to include all the columns of the base table. In fact, for performance reasons, it’s best to only include those fields in your audit record that are deemed

Open the record properties for the record you want to audit, Under the Record Audit, we have the following options

Record Name – Specify the user-defined audit record.

Audit Options – following are the audit options to choose for auditing the record.

  • Add –  Inserts an audit table row whenever a new row is added to the table underlying this record definition.
  • Change –  Inserts one or two audit table rows whenever a row is changed on the table underlying this record definition.
  • Selective –  Inserts one or two audit table rows whenever a field that is also included in the record definition for the audit table is changed.
  • Delete –  Inserts an audit table row whenever a row is deleted from the table underlying this record definition.

Now perform online transactions on the audited table, query the audit table to know what is changed and who changed it at what time.

Categories: PT, Security Tags: