I was wondering if there is a way (I would assume an EEM policy) to force the checking of the 'Service desk request' propriety checkbox upon job creation/update (Commit)?
What if you use job_template in WCC:
The Job Template Batch Interface lets the administrator of your enterprise create and store job templates containing common property values for specified job types. These templates can then be used in Quick Edit and Application Editor to create new jobs. A job template can be created from a text file, written in a JIL command-like structure that contains a job property name followed by a colon, space, and value (for example, dependency: v(DEFAULT_GLOBAL_VAR), or it can be created from an exported JIL file. The Job Template Batch Interface is run from the Windows command line or UNIX console.
Hello Jean Paul,
Thanks a lot for the info, interesting.
Is it possible to force the usage of these templates for each job creation?
What happens when we modify a job created with such a template? Can the settings that come with the templates be modified later on, in an existing job?
1.) service desk is an optional attribute and honestly one that doesn't need an eEM policy.
2.) templating jobs.. Caveat Usor, the road to **** was paved with good intentions. when creating a template; I have seen people forget why the purpose of the template and use it for everything.. becomes a quagmire.
Trust me i have seen it happen in more companies than one person could ever imagine.
1) At our shop, it is a requirement, as our incident ticket autocut interface is based off of that attribute. Users often forget to have it checked. Our job migration tool validates if this set properly, but in a situation where an important numbers of job are missing it, the migration request get bogged down in back and forth.
Thanks for you input,
Create a validation process to make sure. I have reports that run to make sure similar is done.
Not everyone uses service desk. I actually use the application/group fields since they get sent to SNMP receivers.
Nothing in this message is intended to constitute an electronic signature unless a specific statement to the contrary is included in this message.
Confidentiality Note: This message is intended only for the person or entity to which it is addressed. It may contain confidential and/or privileged material. Any review, transmission, dissemination or other use, or taking of any action in reliance upon this message by persons or entities other than the intended recipient is prohibited and may be unlawful. If you received this message in error, please contact the sender and delete it from your computer.
In our pre-prod environments, already have a script that executes everyday, scanning for jobs that have been running for longer then 90 days, and deactivates their scheduling.
General plan is for me to get something similar set up for the service_desk attribute.
Just wanted to see if there is some 'elegant' EEM-based solution possible.
These might be of some use?
Extra efforts for sure but fits the requirement nicely.
You’re welcome and Good luck!
Just watched the vids. This is some great stuff. Will get cracking on this!
Thanks a lot for the info!
Have a great day,
I agree with Steve, handguns and C are powerful and both can do damage if mishandled.
The videos I created while I was at CA were an attempt to expand upon the limited documentation / examples provided with AutoSys. I tried to simplify as well.
"The lurking suspicion that something could be simplified is the world's richest source of rewarding challenges" - Edsger Dijkstra
I hope the videos are helpful. The JIL exit is slick but not a real popular feature mainly due to the C requirement and associated FUD. It is also not well publicized... not well known.
Anyway, I am not aware of any other resources besides the videos and the examples in the code directory.
Good luck and have fun!
I agree with Steve, the JIL exit is a slick feature. By cumbersome I'm sure Steve means powerful.
I do not anticipate a headache when AutoSys is 64-bit. Very much looking forward to that.
I can guarantee AutoSys will never be fully Java.
I also agree with Steve that with great power comes great responsibility. Ensure your C/C++ code is sharp. Rough edges (bugs) can crash the app server. Test thoroughly.
jil exit is a slick feature, however, it is C as you stated in the video thread. You must make sure that you make it supportable by anyone else that may not know C etc. I was a C programmer decades ago and it can be cumbersome.
I just think for this one use case, it's a pile driver being used to hammer in a nail.
Just remember you will have to maintain it when you upgrade and if/when autosys becomes 64 bit and maybe fully java what will happen to this feature? I always offer this up but the big gotcha is that it has to be in C and also you need to deploy it on all application servers.
Good luck and hope it works out.
Thanks a lot for your assistance and the vids.
Have a good one!
Thanks for all the confirmations.
Yes, roger that on the code, will pay close attention to keeping it clean.
Speaking of code, I found some sample code (autoextvj_sample_lib.c) in /opt/CA/WorkloadAutomationAE/code/, but it is pretty complex (my C is very rusty), as for my needs, and does not fully correspond to what you are showing in your videos. Would you know if there are (or have) some other samples that are a tad more 'light' and straightforward?
Thanks a lot.
P.S. Sorry about all the questions but, except your videos, there is zero documentation from CA on this powerful feature (the only CA doc I found is a KB document pointing to YOUR vid ). From my point of view, this should be remedied.
Have a great day,
This is why I said cumbersome. C is a loaded handgun with infinite bullets and shots to the head.
If your C is that rusty I say create a wrapper process and validate the JIL before it is loaded not during the load.
This way the application server and its functioning are NOT in the equation.
Just my 3 cents
"create a wrapper process and validate the JIL before it is loaded not during the load."
I admit, an interesting idea. Will check out.
How would this wrapper be called by AE?
My pleasure. (you can write it in any language you are comfortable in writing)
And if you do it correctly more portable. Do a preinsert validation check and then walk away.
Would go with Bash.How do I go about to have this wrapper called before each 'Commit'?
You don’t have people updating prod directly do you ?
I figured if you did a lift and shift from lower env or were given the JIL file.
Then before loading it in with jil
You would validate jilfile.
Bash is clunky too Perl or python would be my choice. Perl at the top of the list associative arrays are most useful for this
"Bash is clunky too Perl or python would be my choice. Perl at the top of the list associative arrays are most useful for this."Agree on Perl.
"You don’t have people updating prod directly do you ?"How it works at our shop:1 - Users create their own jobs in DEV/SIT. It's is our only instance where the users are allowed to create/modify jobs.
It is only in this instance the the validation would be required.
2 - The jobs are then promoted using the ACCE migration tool to PAT and PRD/DR.
3 - If a modification/correction is required, user needs to start at the bottom of the promotion path (DEV/SIT), test, and move up again.
So, I assume that there is no way to have the wrapper be called automatically upon/before the user goes for the 'Commit'?
OH you are using ACCE. Sorry to hear :-p
I thought there’s a hook in that product to mandate certain checks.
In this case I would look over the product and check .. it was my understanding you could give a rules file etc.
Hey you are paying that firm how much for ACCE tell them to make that check for you!
If it doesn’t tell them Steve C. says it should (they know me from a previous life) :-D
When considering a wrapper take into account the number of clients (e.g. JIL, WCC). Maintaining a wrapper distributed to a large number of clients can be cumbersome. There are also security concerns... how are you going to keep clever and restless users from tinkering with or bypassing the wrapper?
The JIL exit hooks into the app server so it has the advantage of being more secure while covering all / any clients.
That said, both approaches are valid depending on the use case.
Hopefully this thread helps you make an informed decision.
"OH you are using ACCE. Sorry to hear :-p"Hahaaha! No comment. On top of it all, we were kinda forced to go into the Cloud with it, nightmare...I'm trying to get it moved to VMWare Cloud now, just deployed it in DEV. Two different worlds....not even, universes.
"I thought there’s a hook in that product to mandate certain checks."
Yeah, we got that custom validation set up, and it works good. The ACCE request refuses submission for approval before this service_desk check box is checked. But, it is a mess. The users, most of the time, got only the basic scheduling skills. So...'What is this validation error?', 'Where is this attribute', 'What do I have to do?', etc.That is the main reason I wanted to force this on creation/modification, and where I taught the AE Verification Exit feature would come in handy, as it can seamlessly update/correct the JIL for you.
But then, you got me interested in that wrapper... I guess, even if a very tasty idea, it would not work in my situation?
I think it can I really thought in ACCE you could call a wrapper
Research and find out ..
Will do, sir!Thanks a bunch for your time.
Have a great day!
My pleasure. And you as well!