Found 417 results.

PeopleSoft Process Flow Basics

Learn the fundamentals of PeopleSoft Process Flow in this comprehensive guide. Master the basics and optimize your workflow for maximum efficiency.

  • Blog
  • PeopleSoft Process Flow Basics
PeopleSoft-Process-Flow-Basics
August 10, 2023

PeopleSoft Process Flow Basics

 

PeopleSoft Process flow to access a PS application page can be explained:

  • Link interpreted as URL address by Web browser, which includes the name of a Servlet on the Web server.
  • Servlet running in the Servlet engine interprets requests and comes up with a list of objects that are required to build the page.
  • Request for all required objects sent to application server in the form of a Jolt message.
  • Tuxedo receives the Jolt message, and converts it into a service request, which it routes to the appropriate PeopleSoft server process.
  • PeopleSoft process converts service request into SQL statement(s).
  • The version of the object which is required by the request is matched between the database and the physical cache present. If the cache is the latest, it is issued from there otherwise, SQL statement(s) are sent to database for fetching.
  • After the operation, the cache is updated along with its version number.
  • Data requested is supplied by the database.
  • Tuxedo acknowledges the receipt of data and closes connection with the PeopleSoft process.
  • PeopleSoft process constructs HTML code out of object data.
  • Data forwarded by Tuxedo through Jolt requesting Java Servlet.
  • Servlet forwards the HTML page requested by browser.
  • When all objects are in place, the HTML page is forwarded to the Web services.
  • Browser views page.

 

The default screen which comes when you enter the URL resides on Webserver called signin.html. It points to various JavaScript and iScripts. By default, according to your installation of db, it takes the language. Generally, it is English. If you select any other language, you click it on signin.html and it updates JavaScript.

 

When you log in to PIA, first it checks the parameter in the App server Config file to see whether validate sign-on with db option is enabled or not. If yes, it sends your user ID/password as a connection string to db and validates. If no, then from the Config file, connect id and password are fetched and made an internal connection. After it logs in successfully, the OPRID is authenticated in db. It checks the last update time, actlock, encrypted, symbolic id, etc from the PSOPRDEFN table. Then it logs in through the access id fetched from PSACCESSPRFL corresponding to the symbolic id that is fetched from PROPRDEFN with your OPRID. It makes a persistent connection to db.

 

It checks the version in the PSVERSION table to ensure all data is in sync and there are no cache errors. Then it loads the iScript and Lframes, Rframes™, etc. From WEBLIB_NAV_MAIN web library which is assigned to you through a role.

 

This is a mandatory web library to load the PIA. In addition to it, you need to have WEBLIB_PORTAL, WEBLIB_TIMEOUT, WEBLIB_PT_NAV etc to move across PIA and perform basic operations. But these are optional. HTML is generated from Application Packages and iScripts. The page you see after you login in comes from the PT_BRANDING application package. Your profile page comes after it authenticates you in db and makes several db updates. In PSACCESSLOG it makes an entry from the host/Ip address you log in. If other Audits are set, it updates in Audit tables and executes triggers associated to them.

 

In the meantime, the cookie from the application server that your OPRID is authenticated:

http://server:port/servlet_name/SiteName/PortalName/NodeName/content_type/content_id?content_param is the URL format.

 

It checks which PORTAL, NODE you are trying to login. Examples of portal are customer, employee etc. Node is ERP, HRMS, CRM etc. It queries PSPRSMDEFN table to have data validated. It queries all independent entries like content type ex c for component, h for homepage, q for query etc, content id like component and page name and finally your market you use. In our case that is GBL (global).

 

According to your roles in the PSROLEUSER table, it queries all related security tables to find out what implicit permissions you have. It requires PSROLECLASS to sync roles along with a permission list, and PSAUTHITEM to have all the tools, menu, query, and other permissions. It checks the checksum with registry structure according to the PORTAL name you enter in the URL (or by default, the employee is treated) and loads the page according to its visualization. It also checks the personalization of your favorites and worklists before loading the initial page. After loading everything again it checks the PSVERSION to sync the cache.

 

Now if you are logging in through LDAP, the process differs a little. First, it checks the directory connectivity and then goes to the user id/password authentication. Then it executes sign on people code before rendering the user its profile homepage.

 

Now, there are separate component interfaces you need to have access to see on your profile homepage like password change etc. When you click on a menu appearing you in your profile, it first checks the PSPNLBTNDATA table to check its existence and then checks the PSPRSMDEFN and some other registry allocation tables to check its integrity and then checks your privileges to access that menu through a complex query by joining PSROLEUSER, PSROLECLASS and PSAUTHITEM table. Accordingly checking which mode, you have access to the component, it opens it.

 

Author: Suresh Babu

PeopleSoft Services

Implement, Enhance, Update & Support PeopleSoft at Zero Cost!

Read More

Categories