Hi Akhan. One tricky thing with Job Routing rules is I believe a cache is involved which is refreshed periodically (not sure of exact interval but can research). So, its possible, you created/modified your rule, tested and it didn't work because it had not yet been picked up. A restart of the appserver would cause it to be picked up immediately but obviously that is not something you want to do often.
Since it has been a couple of days since you added the rule, I am wondering if it has started to work now or if you are still hitting the same problem?
Thanks for your reply John. I have set the job to a schedule and run it many times manually after creating the rules and restarting the app servers still no luck.
Job Execution Rules are executed in order, and the first match triggers the routing. Make sure you don't have a higher "catch all" rule that would override the one you made.
There's also a known issue with job execution routing that has been fixed in the Patch 1 release of 8.3 SP2 (8.3.02.407), which you may want to upgrade to asap. The issue however, only concerned Patching Jobs, and the "is instance of" operator in the conditions. Both would completely get ignored no matter what. From the screenshots you posted however, it looks like your jobs are NSH Script Jobs, so this should work...
So check the rule order. To do this, right-click on Job Execution Rules in the Infrastructure Management and click 'Rules Management". The order matters, and you can move rules up and down with the arrows.
Also as mentioned by John, it can take a few minutes for the rules to kick in.
One thing I did in for our organization, was to create a new built-in JOB class property (in the Property Dictionary) called PREFERRED_JOB_SERVER, which is a String enumeration type, and I have created a value for each of my app servers, and a value of "any". The default value is set to "any".
Then in my job rules, I have something like this (in this order):
PREFERRED_JOB_SERVER = job_server_1 ??JOB.PREFERRED_JOB_SERVER?? = job_server_1 PREFERRED_JOB_SERVER = job_server_2 ??JOB.PREFERRED_JOB_SERVER?? = job_server_2 PREFERRED_JOB_SERVER = job_server_3 ??JOB.PREFERRED_JOB_SERVER?? = job_server_3 PREFERRED_JOB_SERVER = job_server_4 ??JOB.PREFERRED_JOB_SERVER?? = job_server_4 PREFERRED_JOB_SERVER = job_server_5 ??JOB.PREFERRED_JOB_SERVER?? = job_server_5 PREFERRED_JOB_SERVER = job_server_6 ??JOB.PREFERRED_JOB_SERVER?? = job_server_6 PREFERRED_JOB_SERVER = any ??JOB.PREFERRED_JOB_SERVER?? = any
Each rule routes to the matching job server, and the any rule routes to all of the job servers.
The beauty of this trick, is that if I want to do maintenance on a single app server and prevent job routing to spawn jobs on it, I can just take if out of the "any" rule and route that server's rule to another server.
To make a job route to a specific server, all I need to do is set that job's PREFERRED_JOB_SERVER property to the app server I want. This trick will only fully work in 8.3.02.407 however due to the bug I mentioned above, but it will still route your NSH Script Jobs properly at your version (we already do that too).
Yanick you are right, there are other rules and I changed the order like you suggested and I am seeing some improvement on where the jobs run but i need to fine tune it more.
I do need some advise though majority of our jobs are either run by Developers and QA Team and they are nsh code deploy jobs. Is there a way I can set up execution rule based on Role? As example If a QA Role team member runs a job it runs on a particular app server?
Good to see you found the source of the problem. Shouldn't be too hard to fine tune. As for your other question, there's no direct way to reference the role or user that executes the job using the JOB class properties.
What you could do however, is either create a copy of the job for each Role, and only give permissions to view and execute the job to the matching role (and bladmins of course). You can then use JOB.NAME as you're doing now or use my custom property suggestion to route those jobs to the same app server.
Alternatively, you could do the same with Role-specific job groups (folders), and use the GROUP*.NAME class property to route underlying jobs to a given app server. Know however that this only works against the name of the immediate parent group, and not the full path of the group, so if you have multiple groups named the same but in different parent groups, this won't work.