UPDATED: Added a step 3 below in the process to set up the environment to be able to run programs.

I love the Program Job Server (PGS). I really really do. I think that it is often overlooked as a solution in creating BI scheduling workflows. Just like the Crystal, Deski, and Webi job servers, the PGS also leverages all the cool scheduling features that the other job servers do...everything from notifications to using server groups.

So why is it so useful, you might ask? It can run programs external to SAP Business Objects, either something like a VB app or Java, as well as other scripts from your server. This is awesome. Not to shamelessly plug Sherlock AGAIN, but this is one of the keys to running Sherlock within the BOBJ architecture as well.

Consider other scenarios if you will. You have a very complex job flow that triggers Webi and Crystal reports from a file event. How are you deleting that file? A simple .bat file to delete the trigger file, scheduled through the PGS can take care of that based on the successful completion of everything else. Here's another big one. Ever tried to use the Data Integrator (DI) scheduler? Yikes. This is a great, inexpensive case for using the PGS to manage your DI schedules in tandem with your BOBJ job schedules. Just integrate your CMS into DI in the admin console and choose it when scheduling in DI. It will create the PGS entry for you, thereby giving you all the same controls mentioned above.

From a Windows server perspective (really, since this is the generally the standard) there are just a few major requirements to get you up and running with the PGS.

1. Ensure that your services are running under a domain account, or if you don't care about ever touching other domain resources, at the very least, a privileged local account.
2. In the local server policy, load this account up. If you don't know how to, consult your friendly neighborhood Windows Admin. But...I will give you a hint. Under the policy editor, browse to Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignments. The privileged account really needs:
   • Act as part of the operating system
   • Allow log on locally
   • Create a token object
   • Log on as a batch job
   • Log on as a service
   • Replace process level token
3. Within the CMC, you must explicitly grant the system the ability to run these objects through the PGS.  It's really a piece of cake and ommitted in my first draft of this blog post:
   • Go to the CMC under the Applications menu
   • Select the CMC, right click, and choose Program Object Rights
     
   • Select the appropriate object type you want to allow to be run