Below given are the important records used in the tree manager.
PSTREEDEFN -- Tree Definition and Properties
PSTREEDEFNLEVELS -- Tree Levels
PSTREEBRANCH -- branches of the tree
PSTREENODE -- Contains the nodes of the tree
PSTREELEAFPSTREELEVEL
Sunday, February 22, 2009
Records used in Tree Manager in HCM
Saturday, June 7, 2008
Messaging Server (Pub/Sub) settings
This document is designed to specifically explain configuration parameters for the Peoplesoft Messaging Server (aka PUB/SUB)
This document is intended for technical users, installers, system administrators, and programmers who implement, maintain, or develop integration points for your PeopleSoft system. To take full advantage of the information covered in this document, we recommend that you have a basic understanding of how to use PeopleSoft applications, system administration, and basic server technology. You should also have a basic familiarity with PSADMIN.
Contents of this paper:
· Specifically, this paper is a compilation of published Peoplebooks, GSC Solutions and additional information. The intent is for clarification of the "official" documentation, such as PeopleBooks and Installation Guides.
· New topics that do not appear in the "official" documentation.
PeopleBooks Recommended Reading:
· PeopleSoft Integration Broker
· PeopleSoft Integration Broker Peoplebook > Configuring the Messaging System.
· PeopleSoft Server Tools Administration > Working With PSADMIN Menus
· PeopleSoft Server Tools Administration > Understanding Application Server Domain Parameters
Introducing the PeopleSoft Messaging Server
PeopleSoft Messaging Services exist on the application server and are the heart of the Integration Broker. Before using Integration Broker, you must configure and start the Messaging Server, aka PUB/SUB. Although the server processes devoted to your messaging system are all part of the larger application server domain, they comprise a distinct set of processes that aren’t involved with the ordinary transactions associated with PIA connections.
Six processes of two different types, dispatchers and handlers, are combined in pairs to produce the messaging servers needed for transmitting messages throughout your messaging system. Each messaging server is a different type. A set of three — a publication broker, a publication contractor, and a subscription contractor — constitute the messaging server set required by Integration Broker. Following is a listing of the generic names for the processes:
PeopleSoft delivers default PUB/SUB services with _dflt added to the above naming convention. For example PSBRKDSP_dflt. It is recommended that you use these services unless you have a specific need for dedicated handlers.To boot PUB/SUB use PSADMIN to configure your domain and simply answer Y to the following question at the end of the configuration process:
Command to execute (1-7, q) : 4 Do you want the Publish/Subscribe servers configured (y/n)? [y]:y
servers as the default messaging services will handle all basic messages.
Please see the PUB/SUB TUNING section of this guide for recommended values and explanations of psappsrv.cfg values
More information about managing the application server can be found in the PeopleSoft Server Tools Administration Peoplebook.
Additional Information available in Peoplebooks under: Home > PeopleBooks Library > PeopleSoft Integration Broker > Configuring the Messaging
Messaging Server Processes:
There are a variety of server processes devoted to application messaging. If you are not implementing the application messaging technology then you may skip through the delivered, default server processes. The delivered server processes are:
· PSBRKDSP
· PSBRKHND
· PSPUBDSP
· PSPUBHND
· PSSUBDSP
· PSSUBHND
These server processes act as brokers, dispatchers, and handlers of the messages in your messaging system. For the purposes of this paper we will divide these into two categories: Dipatchers and Handlers.
Configuring Messaging Servers in PSADMIN:
This section provides overviews of messaging server configuration, dispatcher parameters, and handler parameters.
Understanding Messaging Server Configuration
Once you create dedicated messaging servers, you must configure their dispatcher and handler processes so they boot when you start the application server. You configure these processes using PSADMIN just as you do any other server process that runs on the application server. Before you attempt to configure additional messaging server processes, you should be familiar with the other server processes that run on the application server.
As stated earlier, two types of server processes comprise each messaging server: a dispatcher and a handler. Each process type requires you to set a different set of parameters. Most of the parameters are similar to other server processes, such as PSSAPPSRV, but some parameters are specific to messaging servers.
Understanding Dispatcher Parameters
There are three generic process types that are the basis for all dispatcher processes:
· PSBRKDSP — the publication broker dispatcher.
· PSPUBDSP — the publication contractor dispatcher.
· PSSUBDSP — the subscription contractor dispatcher.
The following parameters apply to all three process types.
Recycle Count
Specifies the number of times each dispatcher process will be executed before being terminated (intentionally) by the system and then immediately restarted.
Servers must be intermittently recycled to clear buffer areas. The time required to recycle a server is negligible—occurring in milliseconds. Recycle Count does not translate into a native Tuxedo parameter in the PSAPPSRV.UBB file. Instead the value is stored in memory and is managed by the system.
Allowed Consec Service Failures
This option allows for dynamic server process restarts in the event of service failures.
To enable this option, enter a number greater than zero, and to disable this option enter 0. The default value for this parameter is 2. The value you enter is the number of consecutive service failures that will cause a recycle of the server process. This is a catchall error handling routine that allows a dispatcher to terminate itself if it receives multiple, consecutive, fatal error messages from service routines. Such errors should not occur consecutively, but if they do it indicates that the server process needs to be recycled or cleansed. A “Retry” message appears when the number of service failures you specified occurs.
Handler Status Checkcount
Handler check count is used to determine how often the dispatcher should look to get the number of associated handlers.
The value of Handler Status Checkcount is the number of cycles that the dispatcher will perform before reading the MIB and getting the number of associated handlers. This comes into play when the number of handlers change (add more, some crash etc.) by having the proper count , the dispatcher can queue up messages to the handler more efficiently. Also if there are no handlers, then the dispatcher will not queue up any publications causing the application server log to fill up.
For 8.4 it is simply used to determine if there are any handlers, and if not don't send the message to the handler. This is to eliminate any the informational messages in the appserv.log if the handlers are down. For 8.42 it is used to merely look at see if any associated handler is booted. Going forward 8.43 it will be used as one of the determinate of how much work should the dispatcher send out at one time.
Scan Interval
Specifies the number of seconds between scans of the work queue when idle.
The scan interval is necessary to detect messages published from two-tier connections, because when a message is in the queue the broker server doesn’t receive a notice of the publication. A scan interval is required to make sure that two-tier messages get processed in a timely manner. The scan interval is analogous to the Process Scheduler polling the Process Request table. In addition, the scan interval detects messages that have been resubmitted after an error, for example. Decreasing the scan interval will decrease latency for two-tier publishes and error recovery
Ping Rate
Used for PSPUBDSP only.
After this many seconds of inactivity, the server will scan the database queues and restart any stalled/crashed items. The scan rate and Ping rate (as percentage) will determine the actual interval for pinging any unavailable remote nodes (algorithm used: Attempts * Ping Rate * Scan Inteval).
Maximum Ping Interval
The maximum Ping Interval (in Hours) is the maximum interval between subsequent attempted pings of any unavailable remote nodes.
Memory Queue Refresh Rate
PeopleSoft Integration Broker maintains current asynchronous messaging queues in system memory for quick access. On rare occasions these cached queues can become corrupted, at which point they must be refreshed from the Integration Broker data tables. The likelihood and frequency of cache corruption depends on a combination of factors specific to your messaging system. If you need to periodically refresh the in-memory queues, you can use this parameter to tailor the frequency of the refresh to fit your situation.
Each dispatcher on your system has its own queue. For each queue you set the rate equal to the number of dispatch attempts that must occur before the queue is refreshed. The refresh occurs only when the specified number of dispatch attempts is reached for a given message channel. For example, with a memory queue refresh rate of 8, multiple channels could have up to seven dispatch attempts each without triggering any refresh. The following settings are also significant:
· A setting of 0 disables the refresh altogether. This is the default value.
A setting of 1 triggers a refresh immediately after every dispatch attempt, effectively disabling memory caching.
Restart Period
Specifies the number of seconds between restart attempts on Started items in the work queue.
An item which stays in Started state for more than a few seconds might be stalled — for example, the service request might have been lost, or the handler might have crashed. Decreasing the restart period will reduce the latency for recovering stalled items with a status of Started. However, under high load, items might stay in the Started state longer than normal for valid reasons — all the handlers might be busy, and the handler service request for the item might be queued at the Tuxedo level. Setting the restart period too low will result in redundant restarts — the dispatcher will dispatch the item again, even though the original request is still in the Tuxedo queue. A small number of extra restarts is benign, but at higher volumes, the unnecessary restarts can fill up the queue and block real requests. The formula for a reasonable value for the Restart Period is: ((incoming requests per second) / (# of handlers)) * (average processing time per request)
For example, if you have an incoming rate of twenty per second, and you have four handlers, each handler will be busy processing one item and will have four others waiting in the queue. A new item will have to wait for the currently processing item, plus the four enqueued items, before it will be processed. If each item takes 10 seconds to process, the new item will stay in "started" status for approximately 50 seconds before the handler works on it. If it stays in "started" status longer, it's likely that the request to the handler has been lost, and the item should be restarted.
Understanding Handler Parameters
There are three generic process types that are the basis for all handler processes:
· PSBRKHND — the publication broker handler.
· PSPUBHND — the publication contractor handler.
· PSSUBHND — the subscription contractor handler.
The following parameters apply to all three process types.
Min Instances
Specifies the number of handler server processes started at boot time.
Max Instances
Specifies the maximum number of handler server processes that can be started or spawned.
Service Timeout
Specifies the number of seconds a handlers waits for a service request before timing out.
Service Timeouts are recorded in the TUXLOG and APPSRV.LOG. In the event of a timeout, the handler terminate itself and Tuxedo automatically restarts the process.
Recycle Count
Specifies the number of times the system executes each server before PeopleSoft intentionally terminates the process.
Server processes must be intermittently recycled to clear buffer areas. The time required to recycle a server is negligible—occurring in milliseconds. Recycle Count does not translate into a native Tuxedo parameter in the PSAPPSRV.UBB file. Instead the value is stored in memory and is managed by PeopleSoft.
Allowed Consec Service Failures
This option allows for dynamic server process restarts in the event of service failures.
To enable this option, enter a number greater than zero, and to disable this option enter 0. The default for this parameter is 2. The numerical value you enter is the number of consecutive service failures that will cause a recycle of the server process. This is a catchall error handling routine that allows a handler to terminate itself if it receives multiple, consecutive, fatal error messages from service routines. Such errors should not occur consecutively, but if they do it indicates that the server process needs to be recycled or cleansed. A “Retry” message appears when the number of service failures you specified occurs.
Max Retries
Specifies the maximum number of times the server should attempt to restart a failed action.
This parameter prevents a bad item from continuously crashing a handler process — its counter is incremented when the handler sets the status to "working," but before it actually starts processing the item.
Understanding Integration Broker Parameters
The following parameter applies to the Integration Broker technology.
Min Message Size for Compression
The Min Message Size for Compression parameter enables you to configure the threshold of message before the system compresses the message.
Local Compression
The integration engine compresses and base64 encodes messages destined for the PeopleSoft listening connector on its local integration gateway, based on a setting for the application server domain in the PSAPPSRV.CFG file, which you can configure using the PSADMIN utility. The setting is a threshold message size, above which messages will be compressed. PSADMIN presents the setting as follows:
Values for config section - Integration Broker
Min Message Size For Compression=10000
Do you want to change any values (y/n)? [n]:
The value is the message size in bytes; the default value is 10000 (10 KB). You can specify a setting of 0 to compress all messages.
Minimum and Recommended Values.
Specific application server tuning needs vary by customer site based on volume and server capacity. Requests for tuning issues and assistance should be addressed to Peoplesoft Consulting. However, some specific information is available below:
PSAPPSRV should have a minimum of 3 instances booted when starting Pub/Sub.
PSBRKDSP/HND settings should be sized up. A minumum of 3 instances should be used for all application messaging scenarios.
For one particular customer I recommend increasing the PSBRKHND settings to 10/10. Same with the PUB and SUB handler settings: set min/max of 10/10. Other customers have used as many as 20 instances for PSSUBHND. This is generally a tuning issue, and settings vary greatly from site to site.
Recycle count: A single handler is restarting itself after this number services (this is not the number messages, but the number of calls from the tuxedo service). Setting this too low can create performance problems. When a service recycles itelf, all requests must wait for the handler to come back up and re-submit. It is generally recommended using 10,000 to 100,000 for this value. If you recycle your application server or pub/sub services regularly a value of 0 can be used.
Restart Period. Since restart period controls how long before a started item will be resubmitted, dispatcher requests may be resubmitting themselves over and over again resulting in a higher queue number. This can be adjusted by changing Restart Period=5 to a higher number. Customers will need to play with this and monitor results, but setting this to 120 would be better than the delivered 5 second interval, especially when using a lower value recycle count.
This document is intended for technical users, installers, system administrators, and programmers who implement, maintain, or develop integration points for your PeopleSoft system. To take full advantage of the information covered in this document, we recommend that you have a basic understanding of how to use PeopleSoft applications, system administration, and basic server technology. You should also have a basic familiarity with PSADMIN.
Contents of this paper:
· Specifically, this paper is a compilation of published Peoplebooks, GSC Solutions and additional information. The intent is for clarification of the "official" documentation, such as PeopleBooks and Installation Guides.
· New topics that do not appear in the "official" documentation.
PeopleBooks Recommended Reading:
· PeopleSoft Integration Broker
· PeopleSoft Integration Broker Peoplebook > Configuring the Messaging System.
· PeopleSoft Server Tools Administration > Working With PSADMIN Menus
· PeopleSoft Server Tools Administration > Understanding Application Server Domain Parameters
Introducing the PeopleSoft Messaging Server
PeopleSoft Messaging Services exist on the application server and are the heart of the Integration Broker. Before using Integration Broker, you must configure and start the Messaging Server, aka PUB/SUB. Although the server processes devoted to your messaging system are all part of the larger application server domain, they comprise a distinct set of processes that aren’t involved with the ordinary transactions associated with PIA connections.
Six processes of two different types, dispatchers and handlers, are combined in pairs to produce the messaging servers needed for transmitting messages throughout your messaging system. Each messaging server is a different type. A set of three — a publication broker, a publication contractor, and a subscription contractor — constitute the messaging server set required by Integration Broker. Following is a listing of the generic names for the processes:
PeopleSoft delivers default PUB/SUB services with _dflt added to the above naming convention. For example PSBRKDSP_dflt. It is recommended that you use these services unless you have a specific need for dedicated handlers.To boot PUB/SUB use PSADMIN to configure your domain and simply answer Y to the following question at the end of the configuration process:
Command to execute (1-7, q) : 4 Do you want the Publish/Subscribe servers configured (y/n)? [y]:y
servers as the default messaging services will handle all basic messages.
Please see the PUB/SUB TUNING section of this guide for recommended values and explanations of psappsrv.cfg values
More information about managing the application server can be found in the PeopleSoft Server Tools Administration Peoplebook.
Additional Information available in Peoplebooks under: Home > PeopleBooks Library > PeopleSoft Integration Broker > Configuring the Messaging
Messaging Server Processes:
There are a variety of server processes devoted to application messaging. If you are not implementing the application messaging technology then you may skip through the delivered, default server processes. The delivered server processes are:
· PSBRKDSP
· PSBRKHND
· PSPUBDSP
· PSPUBHND
· PSSUBDSP
· PSSUBHND
These server processes act as brokers, dispatchers, and handlers of the messages in your messaging system. For the purposes of this paper we will divide these into two categories: Dipatchers and Handlers.
Configuring Messaging Servers in PSADMIN:
This section provides overviews of messaging server configuration, dispatcher parameters, and handler parameters.
Understanding Messaging Server Configuration
Once you create dedicated messaging servers, you must configure their dispatcher and handler processes so they boot when you start the application server. You configure these processes using PSADMIN just as you do any other server process that runs on the application server. Before you attempt to configure additional messaging server processes, you should be familiar with the other server processes that run on the application server.
As stated earlier, two types of server processes comprise each messaging server: a dispatcher and a handler. Each process type requires you to set a different set of parameters. Most of the parameters are similar to other server processes, such as PSSAPPSRV, but some parameters are specific to messaging servers.
Understanding Dispatcher Parameters
There are three generic process types that are the basis for all dispatcher processes:
· PSBRKDSP — the publication broker dispatcher.
· PSPUBDSP — the publication contractor dispatcher.
· PSSUBDSP — the subscription contractor dispatcher.
The following parameters apply to all three process types.
Recycle Count
Specifies the number of times each dispatcher process will be executed before being terminated (intentionally) by the system and then immediately restarted.
Servers must be intermittently recycled to clear buffer areas. The time required to recycle a server is negligible—occurring in milliseconds. Recycle Count does not translate into a native Tuxedo parameter in the PSAPPSRV.UBB file. Instead the value is stored in memory and is managed by the system.
Allowed Consec Service Failures
This option allows for dynamic server process restarts in the event of service failures.
To enable this option, enter a number greater than zero, and to disable this option enter 0. The default value for this parameter is 2. The value you enter is the number of consecutive service failures that will cause a recycle of the server process. This is a catchall error handling routine that allows a dispatcher to terminate itself if it receives multiple, consecutive, fatal error messages from service routines. Such errors should not occur consecutively, but if they do it indicates that the server process needs to be recycled or cleansed. A “Retry” message appears when the number of service failures you specified occurs.
Handler Status Checkcount
Handler check count is used to determine how often the dispatcher should look to get the number of associated handlers.
The value of Handler Status Checkcount is the number of cycles that the dispatcher will perform before reading the MIB and getting the number of associated handlers. This comes into play when the number of handlers change (add more, some crash etc.) by having the proper count , the dispatcher can queue up messages to the handler more efficiently. Also if there are no handlers, then the dispatcher will not queue up any publications causing the application server log to fill up.
For 8.4 it is simply used to determine if there are any handlers, and if not don't send the message to the handler. This is to eliminate any the informational messages in the appserv.log if the handlers are down. For 8.42 it is used to merely look at see if any associated handler is booted. Going forward 8.43 it will be used as one of the determinate of how much work should the dispatcher send out at one time.
Scan Interval
Specifies the number of seconds between scans of the work queue when idle.
The scan interval is necessary to detect messages published from two-tier connections, because when a message is in the queue the broker server doesn’t receive a notice of the publication. A scan interval is required to make sure that two-tier messages get processed in a timely manner. The scan interval is analogous to the Process Scheduler polling the Process Request table. In addition, the scan interval detects messages that have been resubmitted after an error, for example. Decreasing the scan interval will decrease latency for two-tier publishes and error recovery
Ping Rate
Used for PSPUBDSP only.
After this many seconds of inactivity, the server will scan the database queues and restart any stalled/crashed items. The scan rate and Ping rate (as percentage) will determine the actual interval for pinging any unavailable remote nodes (algorithm used: Attempts * Ping Rate * Scan Inteval).
Maximum Ping Interval
The maximum Ping Interval (in Hours) is the maximum interval between subsequent attempted pings of any unavailable remote nodes.
Memory Queue Refresh Rate
PeopleSoft Integration Broker maintains current asynchronous messaging queues in system memory for quick access. On rare occasions these cached queues can become corrupted, at which point they must be refreshed from the Integration Broker data tables. The likelihood and frequency of cache corruption depends on a combination of factors specific to your messaging system. If you need to periodically refresh the in-memory queues, you can use this parameter to tailor the frequency of the refresh to fit your situation.
Each dispatcher on your system has its own queue. For each queue you set the rate equal to the number of dispatch attempts that must occur before the queue is refreshed. The refresh occurs only when the specified number of dispatch attempts is reached for a given message channel. For example, with a memory queue refresh rate of 8, multiple channels could have up to seven dispatch attempts each without triggering any refresh. The following settings are also significant:
· A setting of 0 disables the refresh altogether. This is the default value.
A setting of 1 triggers a refresh immediately after every dispatch attempt, effectively disabling memory caching.
Restart Period
Specifies the number of seconds between restart attempts on Started items in the work queue.
An item which stays in Started state for more than a few seconds might be stalled — for example, the service request might have been lost, or the handler might have crashed. Decreasing the restart period will reduce the latency for recovering stalled items with a status of Started. However, under high load, items might stay in the Started state longer than normal for valid reasons — all the handlers might be busy, and the handler service request for the item might be queued at the Tuxedo level. Setting the restart period too low will result in redundant restarts — the dispatcher will dispatch the item again, even though the original request is still in the Tuxedo queue. A small number of extra restarts is benign, but at higher volumes, the unnecessary restarts can fill up the queue and block real requests. The formula for a reasonable value for the Restart Period is: ((incoming requests per second) / (# of handlers)) * (average processing time per request)
For example, if you have an incoming rate of twenty per second, and you have four handlers, each handler will be busy processing one item and will have four others waiting in the queue. A new item will have to wait for the currently processing item, plus the four enqueued items, before it will be processed. If each item takes 10 seconds to process, the new item will stay in "started" status for approximately 50 seconds before the handler works on it. If it stays in "started" status longer, it's likely that the request to the handler has been lost, and the item should be restarted.
Understanding Handler Parameters
There are three generic process types that are the basis for all handler processes:
· PSBRKHND — the publication broker handler.
· PSPUBHND — the publication contractor handler.
· PSSUBHND — the subscription contractor handler.
The following parameters apply to all three process types.
Min Instances
Specifies the number of handler server processes started at boot time.
Max Instances
Specifies the maximum number of handler server processes that can be started or spawned.
Service Timeout
Specifies the number of seconds a handlers waits for a service request before timing out.
Service Timeouts are recorded in the TUXLOG and APPSRV.LOG. In the event of a timeout, the handler terminate itself and Tuxedo automatically restarts the process.
Recycle Count
Specifies the number of times the system executes each server before PeopleSoft intentionally terminates the process.
Server processes must be intermittently recycled to clear buffer areas. The time required to recycle a server is negligible—occurring in milliseconds. Recycle Count does not translate into a native Tuxedo parameter in the PSAPPSRV.UBB file. Instead the value is stored in memory and is managed by PeopleSoft.
Allowed Consec Service Failures
This option allows for dynamic server process restarts in the event of service failures.
To enable this option, enter a number greater than zero, and to disable this option enter 0. The default for this parameter is 2. The numerical value you enter is the number of consecutive service failures that will cause a recycle of the server process. This is a catchall error handling routine that allows a handler to terminate itself if it receives multiple, consecutive, fatal error messages from service routines. Such errors should not occur consecutively, but if they do it indicates that the server process needs to be recycled or cleansed. A “Retry” message appears when the number of service failures you specified occurs.
Max Retries
Specifies the maximum number of times the server should attempt to restart a failed action.
This parameter prevents a bad item from continuously crashing a handler process — its counter is incremented when the handler sets the status to "working," but before it actually starts processing the item.
Understanding Integration Broker Parameters
The following parameter applies to the Integration Broker technology.
Min Message Size for Compression
The Min Message Size for Compression parameter enables you to configure the threshold of message before the system compresses the message.
Local Compression
The integration engine compresses and base64 encodes messages destined for the PeopleSoft listening connector on its local integration gateway, based on a setting for the application server domain in the PSAPPSRV.CFG file, which you can configure using the PSADMIN utility. The setting is a threshold message size, above which messages will be compressed. PSADMIN presents the setting as follows:
Values for config section - Integration Broker
Min Message Size For Compression=10000
Do you want to change any values (y/n)? [n]:
The value is the message size in bytes; the default value is 10000 (10 KB). You can specify a setting of 0 to compress all messages.
Minimum and Recommended Values.
Specific application server tuning needs vary by customer site based on volume and server capacity. Requests for tuning issues and assistance should be addressed to Peoplesoft Consulting. However, some specific information is available below:
PSAPPSRV should have a minimum of 3 instances booted when starting Pub/Sub.
PSBRKDSP/HND settings should be sized up. A minumum of 3 instances should be used for all application messaging scenarios.
For one particular customer I recommend increasing the PSBRKHND settings to 10/10. Same with the PUB and SUB handler settings: set min/max of 10/10. Other customers have used as many as 20 instances for PSSUBHND. This is generally a tuning issue, and settings vary greatly from site to site.
Recycle count: A single handler is restarting itself after this number services (this is not the number messages, but the number of calls from the tuxedo service). Setting this too low can create performance problems. When a service recycles itelf, all requests must wait for the handler to come back up and re-submit. It is generally recommended using 10,000 to 100,000 for this value. If you recycle your application server or pub/sub services regularly a value of 0 can be used.
Restart Period. Since restart period controls how long before a started item will be resubmitted, dispatcher requests may be resubmitting themselves over and over again resulting in a higher queue number. This can be adjusted by changing Restart Period=5 to a higher number. Customers will need to play with this and monitor results, but setting this to 120 would be better than the delivered 5 second interval, especially when using a lower value recycle count.
Sunday, May 25, 2008
PeopleSoft Pure Internet Architecture
The PeopleSoft Internet Architecture (PIA) is a server-centric component architecture that enables secure end user access to PeopleSoft applications. Its components include the following:
• Internet Access Device
• Web Server
• Application Server
• Database Server
Each component fulfills a unique niche within the system, all of which are described in the PeopleSoft Internet Architecture Components lesson of this course.
With PIA there is no "traditional" client. Workstations simply need to have a supported browser installed. No other applets or connectivity software is needed on the workstation that runs the browser because all processing occurs at the server level. Dynamic HTML, rendered by the Application Server, is passed to the Web Server and sent on to a supported browser interface.
PeopleSoft Integration Technologies:
•Application Messaging - System-to-system communication.
•Component Interfaces - Transactions from external systems to PeopleSoft.
•Application Engine - Used in batch application processing.
•File Layouts - Used for integration with legacy systems.
PIA supports pure internet access for all PeopleSoft applications. It enables you to take advantage of all of the PeopleSoft intranet and internet solutions, as well as the PeopleSoft Integration Technologies, such as Application Messaging.
These technologies streamline integration of PeopleSoft applications with other PeopleSoft applications, custom internal systems, eMerchants, and customer trading partner systems. By supporting the open flow of information between systems, the PeopleSoft Integration Technologies provide true internet- based system integration.
The PeopleSoft Internet Architecture delivers intuitive, high-performance, HTML-based thin client applications that run on any machine with internet access. PIA deploys all transactions through a web browser.
Benefits of Browser-Based Deployment
•Minimizes the Training Effort
•Reduces Application Deployment Costs
•Lowers Client Hardware Requirements
•Allows Extensive Portability
There are two basic access methods with the PeopleSoft Internet Architecture:
(1) Directly, through a delivered homepage dedicated only to PeopleSoft applications, or
(2) Through a portal that may contain non-PeopleSoft content references.
Both of these deployment options are further discussed in the PeopleSoft Development and Deployment lesson of this course. Both options provide the benefits listed above of browser-based deployment.
Minimizes the Training Effort:
• Simple access
• Intuitive web look and feel
Less training is needed because most people with access to computers are very familiar with the look and feel of web pages, and know how to navigate within web browsers like Yahoo! and Amazon.com. End users just click a hyperlink to enter the PeopleSoft applications.
Reduces Application Deployment Costs:
• HTML-based for low bandwidth access
• HTML and JavaScript deployed to the browser
• No client installations required
Browser-based applications are easily deployed to end users.
By placing a hyperlink in an email or on a corporate website, users can access the applications just like they access any other website.
The cost of deploying browser-based applications is close to zero.
Lowers Client Hardware Requirements:
• Robust, scalable server-centric architecture
• Supports thousands of concurrent users
Because the browser-based applications put very small demands on the client machine, the end user does not need a high-end, expensive computer to use PeopleSoft applications. This means lower costs to customers, as they will not need to upgrade their client machines in order to use the latest PeopleSoft release.
Allows Extensive Portability:
• Web browser independence
• Client operation system independence
HTML browser-based applications are very portable across client operating systems. As long as the end user has a currently supported browser that is JavaScript 1.1 compliant, access to PeopleSoft applications can be through a Windows, Mac, Linux, or Unix client machine. From an end user's perspective, browser-based application deployment of PeopleSoft applications is cost-effective and easy to use.
Because PIA is completely server-based, client machines to this architecture can be nearly any kind of internet-enabled device, including:
• Web browser running on a PC or Macintosh
• Wireless device or cell phone
• External or third-party system
These devices use the standard internet technologies: HTTP, HTML, WML, and XML.
A web browser running on a workstation (client) using the HTTP protocol is the most common internet access. The browser does not download any applets nor does it require any plug-ins. Rather, a servlet installed on the Web Server facilitates all browser connections to the Application Server through JOLT.
When the browser sends a request to the Web Server, it is forwarded to the Application Server.
The Application Server sends only the following back to the browser:
• HTML
• JavaScript
• Cookies
The client workstation is free of any processing responsibility because there are no PeopleSoft executables on the client. This is why PeopleSoft Internet Architecture is termed an "architecture without a client."
With PeopleSoft Internet Architecture, only a single sign-in is needed between PeopleSoft databases. This is possible by leveraging Web Browser cookies that store a unique access token for users when they are initially authenticated. The token in the browser cookie is used to re-authenticate users when they connect to other PeopleSoft systems. This way, a user does not have to go through the sign-in process again. The browser cookie is stored in memory and never written to disk. It is encrypted by the Web Server and check-summed to prevent snooping and tampering.
As you can see, there is no "traditional" client involved in PeopleSoft Internet Architecture. The system sends pure HTML to a supported browser interface, while all processing occurs at the server level.The Web Server must be Java-enabled so that it can run the PeopleSoft-delivered Java Servlets that are installed as part of PeopleSoft Internet Architecture. One of these is the Portal Servlet, which relays all inbound and outbound transaction requests for the browser.
Using JOLT, the Web Server communicates browser requests to the Application Server. The pure HTML that the Application Server generates is formatted and presented in the browser by the Portal Servlet.
Together the Web Server and the Application Server make up the middle-tier of PIA; however, the Application Server does most of the work.
The Application Server is the core of PeopleSoft Internet Architecture. It handles messages from the Web Server through JOLT and executes all PeopleSoft business logic. In addition, it maintains the SQL connection to the Database Server for both browser requests and for the PeopleSoft development environment. PeopleSoft uses TUXEDO to manage database transactions.
At execution time, the Application Server fetches the most recent application definitions from the Metadata Repository of the Database Server. The Application Server caches the definitions in memory and executes the business rules, based on the definitions. Definitions such as pages, are created using the Application Designer tool in the PeopleSoft 8 development environment.
The Application Server consists of numerous PeopleSoft services and server processes that handle transaction requests. One of these server processes, PSAPPSRV, performs all application processing for a PeopleSoft internet session and generates the HTML to be displayed in the browser. For example, it is the PSAPPSRV process of the Application Server that builds and loads the pages which are then transmitted to the browser, as requested, through the Web Server.
As you can see, the Application Server is truly the heart of PeopleSoft Internet Architecture.
Just as in the PeopleSoft three-tier architecture, with the PeopleSoft 8 Internet Architecture, information is stored on the Database Server in three types of tables: System Catalog Tables, PeopleTools Tables, and PeopleSoft Application Data Tables. Each table type contains specific information that is related to running PeopleSoft applications.The PeopleSoft database is the repository for all information that is managed by PeopleSoft applications. Not only is application data stored in the database, but the PeopleSoft metadata is also maintained in the database. Metadata is what drives PeopleSoft Internet Architecture. Because PeopleSoft architectures have always been metadata-driven, PeopleSoft has been able to make the leap from client/server to internet-based applications without having to completely rewrite existing applications.
Several internet-related definitions were enhanced in PeopleTools 8.4 to enable full internet application development. These are the HTML Catalog, images, and style sheets. Just like fields, records, pages, menus, and other definitions, these definitions are stored in the PeopleTools Tables of the Database Server, and are fully upgradeable.
Multiple Application Servers can be connected to a single Database Server, which simultaneously handles the Application Server connections and development environment connections
Subscribe to:
Posts (Atom)