- 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 request 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 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, 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’s 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 the JavaScript’s.
When you login to PIA, first it checks the parameter in appserver Config file to see validate sign on with db option is enabled or not. If yes, it sends your userid/password as a connection string to db and validates. If no, then from 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 lastupddatetime, acctlock, encrypted, symbolicid etc from PSOPRDEFN table. Then it logs in through the accessid fetched from PSACCESSPRFL corresponding to the symbolic id that is fetched from PROPRDEFN with your OPRID. It makes persistent connection to db.
It checks version in PSVERSION table to ensure all data is in sync and no cache errors. Then it loads the iScript ‘Lframe’,’Rframe’ etc. From WEBLIB_NAV_MAIN weblibrary which is assigned to you through a role.
This is a manadatory weblibrary to load the PIA. In addition to it, you need to have WEBLIB_PORTAL, WEBLIB_TIMEOUT, WEBLIB_PT_NAV etc to move accross PIA and perform basic operations. But, these are optional. The html is generated from Application Packages and iScripts. The page you see afer you login, that comes from PT_BRANDING application package. Your profile page comes after it authenticates you in db and makes several db updates. In PSACCESSLOG it makes 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 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 pagename and finaly your market you use. In our case that is GBL(global).
According to your roles in PSROLEUSER table, it queries all related security tables to findout what all implicit permissions that you have. It queires PSROLECLASS to sync role along with permission list, PSAUTHITEM to have all the tools, menu, query and other permissions. It checks the checksum with registry stucture according to the PORTAL name you enter in URL (or by default employee is treated) and loads the page according to its visualisation. It also checks your personalisation to your favorites and worklists before loading the initial page. After loading everything again it checks the PSVERSION to sync 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 userid/password authentication. Then it executes signonpeoplecode before rendering the user its profile homepage.
Now, there are separate component interfaces you need to have access to see them on your profile homepage like password change etc. When you click on a menu appearing you in your profile, it first checks PSPNLBTNDATA table to check its existance 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
suresh.babu@kovaion.com
