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 Reports, Desktop Intelligence, and Web Intelligence job servers, the PGS provides 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 Web Intelligence 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 Microsoft 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.
- 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.
- 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
- 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
That is it. You can now run external programs within the PGS. I’m sure there are plenty of other applications for this out there, and just as many practical uses on Unix/Linux platforms as well.