What do those Application Properties control?
When you first create a new CA WA DE Application you are presented with the Application Properties dialog box…
image to go here...
This dialog box can also be reached later while maintaining your application by right mouse button clicking in the white space around the job workload objects in the Define perspective and selecting the Properties option (hint: you will need to ensure no job workload object is currently selected for this to work).
Wait for previous generation ensures your application runs serially; that is the current generation of the application has to finish before the next requested iteration (“generation” in CA WA DE terms) is allowed to start. Simply ticking this check box will enable you to trigger multiple iterations of the same application, but only one will run at a time, the rest get queued in the order they were triggered. This makes it easy to trigger several days of an application at once, should there be an issue with the application that has forced it not to be executed for a number of days; each day will then complete in its entirety before CA WA DE allows the next day to run.
Hint: If you know that your application is divided into self-contained components, you might be able to orchestrate the parallel running of subsequent generations of your application by using CA WA DE’s SubApplication capability. This capability dramatically reduces the “catch up” time when running multiple days’ work to bring the processing up to date after a major application failure – see the Taking alternative paths through the job stream.
There will be times when you want to take one of two (or more) paths through a job stream. This topic explores one way of accomplishing this where the job stream is to continue when a job is known to fail and an alternative path needs to be followed. The following job will be used as an example...
image to go here...
The dependency links between the Failing_Job and the successor jobs have been edited (right mouse click on the dependency arrow between the jobs and select Release Conditions from the pop-up menu) and appropriate exit codes have been defined. The following example shows the Release Conditions for the path to Error_path_Job...
image to go here...
As only one of the two successor jobs will run, they both need to be marked as Conditional jobs, so that the job on the path that was not taken will be updated to a BYPASSED status when the application eventually completes, this allows successor jobs to run even though an upstream predecessor has not run successfully. Jobs are marked as conditional by checking the Submit Conditionally box in each job’s General tab...
image to go here...
Finally the Downstream_Work job can be instructed to be released when one predecessor remains by editing the job’s General tab and setting the Release job when “n” predecessors remain field as shown below...
image to go here...
When the application runs and goes down the success path, the downstream_job will run and the entire application will be marked as COMPLETEd and the error_path_job will be BYPASSED. If the application takes the error path, the application will run to the end but the failing_job will remain in a FAILED state for further operator analysis (as shown below). When the operator changes the failing_job’s status to Completed it will allow the entire application to complete and bypass the success_path_job.
image to go here...
If you want to allow the application to complete automatically with no further operator intervention, it will be necessary to insert an alert notification in the failing_job that in turn runs a Javascript that marks the FAILED job as COMPLETE.
Propagate dueout time check box instructs CA WADE to enable anticipated end times and critical path analysis, as well as propagate dueout times in the Application. Propagating dueout times enables you to receive an early warning that jobs in the Application are running late. All that is then necessary is to Edit the time critical job in your application and specify the time that the job would need to complete by; use the Not completed by field in the Time Dependencies tab of the workload object’s properties as follows…
image to go here...
CA WA DE will then propagate dueout times for all the upstream jobs based on historical runtime data. If any of them should run too long and exceed their dueout time, thus potentially impacting the dueout time for the critical downstream job, the problem job will then go into an overdue status. This in turn could trigger notifications in the problem job to send emails, alerts, and/or SNMP traps.
Hint: Ideally you would set this Not completed by time to be some time after the normal average end time for the job, but before the actual SLA/OLA time required by the business. This way you will reduce the number of false alarms due to work taking a little longer than normal, yet still get enough advanced warning that something has potentially gone wrong so that you have time to fix the issue before impacting the SLA/OLA in place with the business.
Require reason for job commands check box allows you to force the user to provide a reason for issuing a command against a job. Usually when a user issues a command against a job in the Monitor Perspective, the user can optionally provide a reason for issuing the command. Ticking this check box makes it mandatory to provide a reason for the specific Application.
Do not trigger if active check box allows you to supress the triggering of an Application that is already running. You might for example use this where an application is being regularly and often triggered, perhaps by transactions arriving via files or data base insertions that then trigger an event. At peak times new events may arrive before the previous event has run its course. This option can be used when the application can cater for the new event in a subsequent triggering of the application, otherwise use the Wait for previous generation check box to serialise the running of this generation of the application.