Integration Broker gateway setup with Load Balancer

What should the Gateway URL be and what should the Physical Gateways URL's be?

The gateway URL should actually be the URL of the load balancer, and not any of the web servers hosting the Gateways.

If the load balancer checkbox is checked, then additional field is opened on the page where the URLs for the physical web servers (hosting the gateways) can be listed. These URLs are for information purposes only. There is no load balancing code/logic being triggered as a result of these values. The load balancing logic/code to redirect connections to one of the physical web servers (hosting the gateways) should be in the load balancer.



What happens if the Gateway URL is down, what kind of failover will happen?
If the Gateway URL (Load Balancer) is down, then messaging will not work as it will not be able to direct requests to one of the Physical gateways/web servers. But if one of the Physical Gateways were down, it will just failover to another one. There is no significance of the order in which you add those Physical Gateways.



When hitting the Load Gateway Connectors button, is that only loading connectors for the primary gateway URL? Do they need to do that for each Physical URL also?
You only need to hit the Load button once, provided you have not added or modified any of the connectors on any of the webservers. We are assuming all connectors on any of the web servers are the same and as delivered. When you hit the Load button, we are only going through one Gateway, and loading the connectors from one webserver, then loading them into the database.



When you ping a node, which Gateway is it using?
Load Balancing typically is a Round Robin approach driven by the load balancer, and PSFT does not control which Gateway to use. The way to test each Gateway is to bring down all but one > then ping. Then bring down all but the next Gateway > then ping. etc until all are tested successfully.

Process tables

PS_PMN_SRVRLIST

PS_PMN_SRVRLIST – PeopleSoft Process Scheduler Server List Record.The corresponding information is available also in the PeopleSoft interface on the menu Home>PeopleTools>Process Scheduler>Process Monitor, Server List tab.The table stores the system name that identifies the server (SERVERNAME),the name of server on which the PeopleSoft Process Scheduler Server Agent was started (HOSTNAME), the last time that you refreshed the server list to display the most current information (LASTUPDDTTM),the name of the report node where the Distribution Agent posted all generated reports, logs, or trace files (DISTNODENAME), the status of the Process Scheduler server:Running, Down, or Suspended (SERVERSATUS,SERVERSTATUSDESCR), the CPU threshold percentage value specified in the server definition – CPU usage exceeds this value, the server will not schedule new requests until CPU usage drops below this amount (MAXCPU), memory threshold in percent (MINEM), the disk threshold specified in Process Scheduler configuration file (PRCSTHRESHOLD), the amount of disk space available (PRCSDISKSPACE), server load balancing option (SRVRLOADBALOPTN), the name/version of the operating system of the server (OPSYS) and some other Deamon services related information.

PSPRCSLOCK

PSPRCSLOCK – Peoplesoft Process Scheduler Lock table,contains the number of process scheduler locks (PRCSLOCK) and is used to single thread process requests and to avoid any deadlocks on the PSPRCSRQST table.

PS_SERVERNOTIFY

PS_SERVERNOTIFY – PeopleSoft Process Scheduler Notification table which can be, also, identified and updated from the menu Home>PeopleTools>Process Scheduler>Servers, Notification tab. It records the Process Scheduler name (SERVERNAME), the distribution OPRID -DISTID,the distribution id type -DISTIDTYPE (2-User ID, 3-Role Name), the options of notifying when the process scheduler errors – NOTIFYSERVERERROR, when it is down – NOTIFYWHENDOWN or when it has been started – NOTIFYWHENSTARTD, or when suspended/overloaded -NOTIFYWHENSUSP, or disabled – NOTIFYDISABLED.

PS_SERVERDEFN

PS_SERVERDEFN – PeopleSoft Process Scheduler Definition table, which can be, also, identified and updated from the menu Home>PeopleTools>Process Scheduler>Servers, Definition, Distribution and Daemon tab.This record stores the Process Scheduler name (SERVERNAME),its VERSION, its description (DESCR), the sleep time, in seconds, SLEEPTIME – the time the Process Scheduler stops searching for processes that have entered in its queue for running, therefore once every interval set in the SLEEPTIME, the process scheduler wakes up and looks for processes in”Queued” state.The generraly recommended sleeptime is 30-60 seconds and the maximum allowed is 9999 seconds.The table contains, also, the HEARTBEAT of the Process Scheduler- the interval at which the Process Scheduler Agent checks the status of the server (Running,Suspended,Down), each time this verfication is done the agent updates the field LASTUPDDTTM in the PS_SERVERDEFN record. This prevents the database from accepting more than one Process Server Agent with the same name on one or multiple servers. This table also stores the Maximum number of Application Program Interface (API) aware tasks running concurrently – MAXIAPIAWARE, the Maximum number of non Application Program Interface aware tasks running concurrently -MAXIAPIUNAWARE,the defined operating system -OPSYS (0-DOS,1-NT/Win95 Client,2-NT/Win2000,3-OS/2,4-UNIX,5-VMS,6-MPE/XL,7-OS390,9-OS/400), the distribution node name (DISTNODENAME),the Transfer System Files to Report Repository flag – TRANSFERLOGFILES (1, if checked in the PIA checkbox), the Interval for Transfer Attempt – TRANSFERINTERVAL, Maximum Transfer Retries -TRANSFERMAXRETRY, Server Load Balancing Option -SRVRLOADBALOPTN (0-Do Not Use for Load Balancing,1-Use for Load Balancing),Redistribute Workload Option – REDISTWRKOPTION (0-Do Not Redistribute, 1-Redistribute with same O/S,2-Redistribute to any O/S),the daemon enabled flag – DAEMONENABLED,the daemon servers group -DAEMONGROUP,the daemon sleep time -in minutes-DAEMONSLEEPTIME, the deamon recycle count, which recycles the deamon agent after the set number of iterations -DEAMONCYCLECNT,the deamon Process Instance -DEAMONPRCSINSTANCE, the CPU utilization treshold – MAXCPU and the Memory utilization threshold – MINMEM,both recorded as percentages.

PS_SERVEROPRTN

PS_SERVEROPRTN – PeopleSoft Process Scheduler server Operation times table, available in PT 8.4xx versions, contains the defined Process Scheduler names (SERVERNAME) and their set availability days ( established in the day of the week format with values from 0-6,Sunday is represented by 0, Monday by 1,Saturday by 6 and so on) and the start time/hour of day (STARTTIME) and the time of the day the availability ends (ENDTIME). Both STARTTIME and ENDTIME are stored at the database level as their minute value (eg: the hour 05:00 is represented in the DB as 300,23:59 as 1439 and so on).Also, the content of this table is avialble for editing and viewing from the menu Home>PeopleTools>Process Scheduler>Servers, Operation tab for the specific selected Process Scheduler name.

Process Scheduler monitoring useful script

SELECT S.SERVERNAME, X.XLATSHORTNAME,X.FIELDVALUE,cast(S.MAXCPU as varchar2(3))||’%’ MAXCPU,cast(S.PRCSDISKSPACE as varchar2(15))||’ MB’ PRCS_DISK_SPACE,TO_CHAR(S.LASTUPDDTTM,’DD-MM-YYYY HH:MI:SS’)LAST_UPDATE_TIME
FROM PSSERVERSTAT S, PSXLATITEM X
WHERE X.FIELDNAME = ‘SERVERSTATUS’
AND X.FIELDVALUE = S.SERVERSTATUS

PSPRCSRQST and PSPRCSQUE

PSPRCSRQST and PSPRCSQUE tables – when a user submits a process request to the Process Scheduler a corresponding record will be inserted in the PSPRCSRQST (Process Request) table and afterwards replicated into the PSPRCSQUE table and further acknowledged by the Process Scheduler to be processed. Therefore every “x” seconds (whatever the Sleep time is set your PS environment) 3 retrieve commands get exceuted on the PSPRCSQUE table. While the PSPRCSRQST table is used more with informational purposes to ensure that the correct data is displayed in the Process Monitor tool,the PSPRCSQUE table is the one managing the queue of processes and jobs; modifying this last table is what can detrmine a specific PS job or process to stop. Actually, the parameter that must be affected, at each process instance level, in order to generate the previously mentioned behaviour is  RUNSTATUS and it controls whether or not the job is further processed by the Process Scheduler. DISTATUS is the distribution state and controls whether or not the distribution agent will pick up the job.
In order to avoid diverse Process Scheduler related problems the following tables must be always synchronized: PSPRCSRQST,PSPRCSQUE and PSPRCSPARMS.In conclusion, the values returned by the three count statements must be equal:
select count(*) from PSPRCSRQST;
select count(*) from PSPRCSQUE;
select count(*) from PSPRCSPARMS;
Also, to check if there are any incompatibilities between the fields of the above mentioned 3 tables the the following commands should be issued:
SELECT * FROM PSPRCSQUE Q WHERE NOT EXISTS (SELECT ‘N’ FROM PSPRCSRQST R WHERE R.PRCSINSTANCE = Q.PRCSINSTANCE);
SELECT * FROM PSPRCSQUE Q WHERE NOT EXISTS (SELECT ‘N’ FROM PSPRCSPARMS P WHERE P.PRCSINSTANCE = Q.PRCSINSTANCE);