The entire process flow to access a PeopleSoft application
page can be explained in 13 steps.
1. Link
interpreted as URL address by Web browser, which includes the name of a servlet
on the Web server.
2. Servlet
running in the servlet engine interprets request and comes up with a list of
objects that are required to build the page.
3. Request for
all required objects sent to application server in the form of a Jolt message.
4. Tuxedo
receives the Jolt message, and converts it into a service request, which it
routes to the appropriate PeopleSoft server process.
5. PeopleSoft
process converts service request into SQL statement(s).
6. 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.
7. Data
requested is supplied by the database.
8. Tuxedo
acknowledges the receipt of data and closes connection with the PeopleSoft
process.
9. PeopleSoft
process constructs HTML code out of object data.
10.Data
forwarded by Tuxedo through Jolt requesting Java servlet.
11.Servlet
forwards the HTML page requested by browser.
12.When all
objects are in place, HTML page is forwarded to the Web services.
13.Browser views
page.
The default screen which comes when you enter the URL
resides on webserver called signin.html. It points to various javascripts 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
javascripts.
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_parm
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 signon-peoplecode 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.
If it is a search record, search page, according to your
permission (display, update display, correct history), it opens it. If you
update any page, it temporarily stores them in database buffer cache and then
pushes them into db after you click the save button. But, on clicking the save
button, all the codes that are written in the save button will be executed. It
includes all validations in saveprechange, savepostchange and other events.
Few important Definitions:
ConnectID - people, which is used only for initial
connection to check connectivity. Even if you make a three tier connection, the
application server makes a two tier connection with db by checking with connect
id first.
AccessID - sysadm. It is used to perform all the select,
update and all sort of sql operation with db according to your access
privileges internally by system. It looks like OPRID performs all the
operation, but actually db does not recognize any OPRID for sql select/updates.
Accroding to our usage, sql is generated and executed by accessid. This is not
the case before PeopleTools 8. There all OPRIDs were db users ids. They
perform the sql operations.
OPRID- user. It is used for login, audit & all sort of
activity to do and to isolate the user at application level.
SymbolicID - It is used to uniquely identify accesid in
PSACCESSPRFL table. We can have more than one accessid in a table. So, to use
them, we need to have more than one symbolic id in that table. According to the
symbolic key, OPRID can use the AccessID. [Remember accessid can only execute
in db not OPRID] Certain accessids are revoked certain features in db. So,
those activities cannot be performed by an OPRID which is assigned that
specific accessid.
TUXEDO - Transaction Under Unix Extended Distributed
Operations - We in Poplesoft only use ATMI(Application to Transaction
Monitoring interface) feature of TUXEDO. We use it for messaging,
administrating and monitoring transactions. It is written in C++. Hence, it has
compatibility to execute any native code. Hence, it can execute C, C++ as all
internal transaction(semaphore creation, context switching, spawning,
validation and parameterising) happens in these languages.
JOLT- The PIA works in java. But, internal system works in
C++. To sync, JOLT works as a web interface extension for TUXEDO. It is Java
Online Transanction. It takes inputs from Tuxedo and converts to java native
code and renders in webserver. The HTML generation happens there according to
the code being generated by application server. That is served to web browser
by java servlets.
Note : I cant recall where I got this from but felt worth to share it here.