Accenture Enkitec Group E4 Webinar

Wednesday, February 07, 2007

Use of Windows Service Dependency in PeopleSoft

If you run the PeoleSoft Application Server on Windows, there
are advantages to configuring the domains to run as services.
Processes do not run in DOS windows, where they can accidentally
be shut down. They can run with the privileges for a different NT
user. Even if you don't want services to start automatically with
server, it can simply startup scripts to simply use the NET START/STOP
command. Then you might want to define interdependencies between
the services to make sure that dependant services are started in
the right order. Service dependencies are specified by adding the
string value DependOnService to the registry key for the
service in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\
(see Microsoft support note 193888).


The services that start either the application server or process schuler should be made dependent upon the BEA ProcMGR V8.1 (Tuxedo IPC Helper) service, otherwise the domain startup will fail. I have made the PeopleSoft service dependent on both the Oracle database service and the IPC process by making DependOnService a multi-string value.


The Dependencies tab of the service properties window shows which services this service depends upon, and which services depend on this service.


When the PeopleSoft service was made dependant upon the BEA ProcMgr service, the BEA ProcMgr service also reports that the PeopleSoft service depends upon it.


Now, when the PeopleSoft process is started, it will also start the BEA ProcMgr process if it is not already started. Shutting down the BEA ProcMgr service will also cause the PeopleSoft process to shutdown first.


2 comments :

Chris Heller said...

There's a bunch of issues with PeopleSoft running as Windows Services.

* Every appserver and process scheduler in PSHOME is one service. You stop one, you stop them all. Not so great when your dev environment gets stuck on the same server as user acceptance testing.
* The service runner .exe has no idea about what psadmin actually does. It just knows that it runs some process, but doesn't understand anything else about it.
* The service runner .exe has very little knowledge of the Windows Services APIs. It can't tell that the domain(s) are still booting and properly tell Windows that things are starting up. Half the time it ends up proclaiming that the service couldn't start when the appservers are still booting.
* If you set your webserver service to be dependent on the appserver service, Windows will not let you stop the appserver without stopping the web server as well.

What the webserver needs is a little stub service that tests connectivity to the appserver. Then it can wait on that at startup time to make sure that there is an appserver available. That would also help in multi-machine configs, or when you have *nix appservers.

* psadmin resolves %PS_MACH% differently on multi-homed machines when running under a service as compared to running interactively. It will bind to different IP addresses depending on how it was started. A customer of ours got bitten by this recently.

In case you hadn't guessed this is a current pet peeve of mine :-)

We should be able to show some solutions for some of this at the Amsterdam conference in May.

David Kurtz said...

"Every appserver and process scheduler in PSHOME is one service" - which is yet another reason to have different development environments in different PS_HOMEs (The main reason being the ability to roll in PeopleTools patches gradually).

"Half the time it ends up proclaiming that the service couldn't start when the appservers are still booting" - with service dependencies you can set the delay to 0

"If you set your webserver service to be dependent on the appserver service" - I don't recommend that either.