The Peoplesoft Application Server - Oracle Tuxedo
Tuxedo (Transaction Under UNIX Extended for Distributed Operations): PeopleSoft uses a part of that Tuxedo provides- Application-to-Transaction-Moitor- Interface (ATMI). Tuxedo Application Server domain is a collection of processes and Shared Memory Segments and Queues.
Tuxedo Components:
TUXDIR=path to tuxedo directory (e.g. /Tuxedo/tuxedo10gR3_VS2005)
Bulletin Board(BB): It is the heart of Application Server. It is a Shared Memory Segment containing information about servers, services and their loads and priorities, clients and transactions (Tuxedo Transactions)
Bulletin Board Liason (BBL): When a tuxedo domain is booted (by tmboot utility), the bulletin board liason process is started. It reads tuxedo configuration file (PSTUXCFG) and establish and maintains the bulletin board or Managment Information Base(MIB), some message queues and 2 semaphores.
Bulletin Board is used as a form of database by the application server processes to determine how they should behave.
WSL and WSH (Workstation Listener and Workstation Handler )
WSL is a tuxedo process that listen on a particular IP address and ports for requests of connection from client (tuxedo client process). A client is any of the Peopletools windows client processes that operates in a three tier mode. WSL spawns at least one WSH process and the client is then assigned a port on a WSH. It can be configured to start further handlers on demand. There can be multiple WSL as well as WSH processes in a single domain.
Jolt Components: Jolt is used by Peoplesoft to connect to web client which is written in Java, to the application server. Requests from Java clients are passed through the Jolt server into the Tuxedo domain.
Jolt pooling: The web server makes a connection to an application server using Jolt. Jolt is a Java API that manages and allows requests to Oracle TUXEDO services via a JSL. The Jolt API is embedded within the web server and is accessible from a servlet. A servlet basically connects to the Tuxedo using a session pool manager, which assigns a session which is then connected to the application server. JoltPooling is one configurable parameter to configure a Jolt session pool between TUXEDO and the web server.
JoltPooling or Jolt session pooling enables web server connections to be shared between user sessions. It is enabled by default and it reduces the usage of system resources by sharing the user connection by pooled sessions such as threads and file descriptors…etc.
You control session pooling by modifying the joltPooling parameter in the web.xml file under webserver domain.
JSL and JSH (Jolt Server Listener and Jolt Server Handler)
Jolt servers listen for network connections from clients, translate Jolt messages and submit and retrive requests to and from Tuxedo application. JSL handles initial Jolt client connection, spawns a JSH process and assigns a JSH to the Jolt client. The JSH manages the network connectivity, executes service request on behalf of the client, and translate Tuxedo buffer data into Jolt buffer and vice-versa.
JREPSRV - The Jolt Repository Server: Jolt Repository is a database where TUXEDO services are defined. JREPSRV retrives the Jolt service definitions from the Jolt repository by translating Java classes to Tuxedo service requests and returns the service definitions to JSH. It also updates or adds Jolt service definitions and translates Java classes to Tuxedo service requests.
JRAD - Jolt Relay Adapter: A tuxedo application server but it does not include any TUXEDO service. It is used to redirect the connection from web server to the application server. Jolt Relay is transparent to Jolt clients and Jolt servers. A Jolt server can simultaneously connect clients(Intranet clients) directly to the Jolt server and via the Jolt Relay (Internet clients).
This is configured only on need basis as it impacts the performance. Jolt relay provides additional security and is configured in environments where security is of utmost importance. In such an environment webserver is installed on a separate machine than application server and just one port per domain need to be opened at application server machine where in traditional deployment opens between 4 to 6 ports on app server machine for JSH connections. The JRAD is configured on application server domain and listens for JRLY messages on its LISTEN port and transfers the message to the JSL or JSH.
A PIA Transaction: Here are the steps
1- The PIA servlet runs in a JVM in the webserver. Each peoplesoft user (end user) is assigned to a thread in JVM, which is operators peoplesoft session. The thread connects to the application server via the Jolt Server Listener on the JSL port and the thread is then assigned to a JSH. The client then closes the connection to JSL and thenafter only communicates with the assigned JSH.
2- Java class request is received from the servlet.
3- The JSH need to know which Tuxedo service corresponds to this Java class so it enqueues a request for the JREPSRV.
4- JREPSRV picks up the request and looks up the java class in the JREPOSITORY database (a flat file) to find the tuxedo service that maps to the java class.
5- JREPSRV returns the tuxedo service name to the JSH via JSH queue.
6- JSH interrogates the BB to determine which servers are advertising the service and queues leading to this service i.e. the queue the request should be placed on.
7- JSH now enqueues the message requesting that service on an appropriate queue.
8- The related server process polls for the service requests on that queue, dequeue that request and executes the peoplesoft code associated with that service.
9- This server process may need to read or update the physical files that cache the PeopleTools' objects while processing the service request.
10- JSH process has a return message queue, when the service is complete, the server process enqueues the return message on this queue(JSHQ) that leads back to the JSH process that sent the request.
11- The JSH process polls and dequeue the return message from the JSHQ.
12- JSH sends the return message back to the client that has been waiting for a response.
* The processing a request by WSL is similer to above except- the workstation station client contacting the WSL on the port specified in configuration and using Tuxedo Connect String.
Similary WSL assigns a WSH to the client, and WSH looks up the service on the BB as like JSH.
Tuxedo Queues:
- A queue is created for each instance of the tuxedo command line utility - tmadmin and the queue is deleted whne the instance is terminated.
- BBL process has one queue. It receives messages from PSWATCHSRV and tmadmin.
- A queue is created for each of the application server processes (e.g. APPQ, SAMQ etc.). These queues are used to send and receive request messages from handler processes to the server processes.
- There is one queue for each WSH and WSL, and similarly one for each JSL and JSH.
There are 3 memory segments in a Tuxedo domain-
- The bulletin board (BB) created by the BBL process.
- A small shared memory segment created by WSL. It is used by WSL and WSH processes to communicate with each other.
- JSL similarly creates a small shared memory segment for interprocess communication.
PIA Servlet: This is the client of application server. When a webserver is booted, it starts a JVM that runs a Servlet Engine. Various PIA servlets are then registered with this servlet engine.
PIA coonects to the application server as follows-
1) HHTP request for PIA servlet are received by the webserver listener and are routed to the servlet. When a PIA session is established, a new servlet thread is created. This thread is operator's session and is stateful. An in-memory cookie is sent back to the browser and that cookie is then sent to the webserver with subsequent HTTP requests to identify the user's servlet thread.
2) Each servlet thread makes a persistent connection to the application server via JSH process. The JSL ports are specified in servlets configuration file - configuration.properties. All of the HTML, JavaScripts and graphics are generated by the application server and are sent back to the servlet in a single message from Tuxedo.
3) The servlet unpacks the message writing the static files to physical file system that is referenced by the webserver. The main HTML page is sent back via the webserver thread to the client.
4) Th emain HTML page sent back to the client browser may contain references to static files. If those files have not already been cached locally, the browser will make further HTTP requests for those files that will be served by the webserver without further reference to the servlet.
PTWEBSERVER: Application user for peoplesoft database. Initial authentication of webserver with application server is done using this user.
Application Server Administration
Application Server Performance Tuning
Posts
Ajeeth Singh, Description of the PIA transaction is very good to understand but i am not able to understand 6th step onwards below description (particularly 6th step). could you please give me the explanation about this step
ReplyDeletewith regards,
durga prasad
A PIA Transaction: Here are the steps
1- The PIA servlet runs in a JVM in the webserver. Each peoplesoft user (end user) is assigned to a thread in JVM, which is operators peoplesoft session. The thread connects to the application server via the Jolt Server Listener on the JSL port and the thread is then assigned to a JSH. The client then closes the connection to JSL and thenafter only communicates with the assigned JSH.
2- Java class request is received from the servlet.
3- The JSH need to know which Tuxedo service corresponds to this Java class so it enqueues a request for the JREPSRV.
4- JREPSRV picks up the request and looks up the java class in the JREPOSITORY database (a flat file) to find the tuxedo service that maps to the java class.
5- JREPSRV returns the tuxedo service name to the JSH via JSH queue.
6- JSH interrogates the BB to determine which servers are advertising the service and queues leading to this service i.e. the queue the request should be placed on.
7- JSH now enqueues the message requesting that service on an appropriate queue.
8- The related server process polls for the service requests on that queue, dequeue that request and executes the peoplesoft code associated with that service.
9- This server process may need to read or update the physical files that cache the PeopleTools' objects while processing the service request.
10- JSH process has a return message queue, when the service is complete, the server process enqueues the return message on this queue(JSHQ) that leads back to the JSH process that sent the request.
11- The JSH process polls and dequeue the return message from the JSHQ.
12- JSH sends the return message back to the client that has been waiting for a response.
Nice material to understand the peoplesoft all senarios
ReplyDelete