Modifying a Background Action Scheduling Configuration
Use this procedure to modify the scheduling settings for an async action request. You can perform this procedure on background action requests that have been scheduled but not yet placed on the queue for processing. The scheduling options are the same as those available when you first scheduled a job or async action request, but the options are presented differently and you access them differently. In addition, there are fields displaying more information about the background action request.
To modify a background action request scheduling configuration
-
Access a list of background action requests.
-
If you are not an administrator, select My Actions, and then select the Scheduled Actions tab.
-
If you are an Async administrator, on the Async Administrator main page, select the All Requests tab.
-
- Select an action request to modify.
-
Click the ellipsis button and select Update.
Consider the following fields in the header and Action section:
- Name or Scheduled Action Name
-
This is the name that appears on the My Scheduled Actions list.
- System Request
-
Indicates that this is a delivered type of action request. Do not change.
- Synchronized Group
- The synchronized group, if any, that the request action belongs to.
- Action Type
-
Either LandmarkAction or DocumentAction.
- Data Area
-
Indicates the data area where the action request was initiated. Do not change.
- Active
-
Indicates whether the product line is accepting action requests for processing.
- Actor
-
The actor who initiated the action request.
- Authenticated Actor
-
The same as the actor who initiated the action request unless another actor initiated the action request as a proxy for the actor.
- Submitted as Proxy
-
Indicates that a proxy actor initiated the action request.
- Log DB Session Debug
-
Indicates whether database tier session debug logging has been turned on for this action request.
- Email Address
- Specify the email address of the person, for example, the system administrator, who should be notified about the status of the run. The email will contain the data area name, the request ID, and the trigger ID, which enable you to identify a specific action execution. It will also contain information on actor name, queue name, request name, and the create time of both the request and trigger. You can also enter multiple emails, separated by commas.
- Notification Type
- The notification type to determine when to send an
e-mail: Never, Always, On Failure, or
Action Group.
When set to Always or On Failure (send only if there is a failure), it will create a user notification (which shows in the notification badge at the upper right corner of the screen) to the submitting actor. It will send an e-mail to the submitting actor’s email if one is defined on the actor record and it will send an email to any address entered in the Email Address field.
Action Group is a special notification type for actions that invoke other actions. It means a success notification will be sent when the entire group is done. However, if any action group member fails, a failure notification will be sent. If an action is invoked in the background outside the action group, that action inherits this notification type but starts its own, separate group.
If you have the administrator email configuration parameter defined (config - execjob.failure.email), that address receives failure emails regardless of the above setting.
- Module
-
The module that the action request belongs to.
- Class
-
The class for the action request.
- Action
-
The name of the action to be performed by the action request.
- Data
-
Some types of action requests show the data needed to process the request. If this field is present, as a general rule you should not modify the data.
- Error Processing - Class
-
If present, this displays the class that will be used for processing if an error occurs using the class for the action request.
- Error Processing - Action
-
If present, this displays the action that will be used for processing if an error occurs using the class for the action request.
- Parameters button
-
If there are parameters associated with the action request, click this button to view and/or modify.
-
Optionally, set up execution duration notification. Consider the following
fields:
- Email Address
- Specify the email address of the person who should receive an email if the processing of the action group exceeds the duration specified in the Threshold Minutes field. (An action group can contain a single action or it can contain an invoking action plus the invoked actions). You can also enter multiple emails, separated by commas.
- Threshold Minutes
- The time in minutes that can elapse for the processing of an action group before an email notification is sent. Multiple notifications will be sent if the processing of the action group repeatedly exceeds the threshold before finishing. If the action group fails and is re-queued, then the start time for the duration is reset to the time that processing restarted.
-
If the action is one that supports additional queue mapping fields and you want to use these to configure queue mapping for this action, consider the following fields in the Additional Mapping section. (Additional mapping fields are available for a few general actions which in turn call specific actions in a business class. The additional mapping fields enable you to set up queue mapping based on the specific business class and action, rather than the general one.)
- Mapping Field 1
-
Specify the first queue mapping field.
- Mapping Field 2
-
Specify the second queue mapping field.
-
The Scheduling section contains the following fields, plus the fields
for the action's current schedule type. These will vary depending on the schedule
type.
- Created
-
The date and time that the action request was created.
- Pending Scheduling
-
Indicates that the action request has scheduling that applies in the future.
- Scheduled
-
Internal use only.
- Concurrency
-
Indicates whether a later attempt to run the action request can proceed in an earlier attempt is still running.
- Time To Execute
-
The next date and time that the action request will be processed
- Latest Time To Execute
-
The last date and time that the action request can be processed. This field allows you to set an end date and time for async action requests that are scheduled to run periodically. For example, you could set up an async action request that will run once a week but only until July 1 of the current year.
After this field, the form will also list up to three subsequent dates and times that the action request is scheduled for processing.
- Schedule Exclusion
- If you want to add to the scheduling definition by excluding specified dates, years, times, and so on, select a schedule exclusion template or in the Schedule Exclusion Set field, select a predefined set of exclusion templates.
- Schedule Exclusion Set
- If you want to add to the scheduling definition by excluding specified dates, years, times, and so on, select a schedule exclusion set or in the Schedule Exclusion field, select a predefined exclusion template.
- Schedule by:
-
Click one of the following buttons if you want to view or modify the details for the associated scheduling options.
-
Frequency: Schedule to run at an interval based on the specified number of seconds, minutes, and/or hours. This repeating schedule will run, then add the frequency value to the last run time to determine the next schedule time.
-
Date: Schedule to run for specific dates, by specifying month, year, and time values. The month and year values can also be a range or multiple values. You also specify the time zone that applies.
-
Week Day: Schedule to run for specific days within a week by specifying day, week, month, year, and time values. Ranges and multiple values can be entered. You also specify the time zone that applies.
-
Week Number: Schedule to run for specific weeks by specifying week, day, year, and time values. Ranges and multiple values can be entered. You also specify the time zone that applies.
-
Advanced: Schedule to run using a combination of the previously listed scheduling types.
-
Copy From Schedule Template - Schedule to run based on a selected scheduling template. If you select a template here and later edit the scheduling it will not affect the template itself. Because the values of the scheduling template are copied into the scheduling record, if you later edit the scheduling template, those changes are not applied to this scheduling record.
-
-
Consider the following fields in the Misfire and Retry sections:
- Strategy
-
What to do in the case of a failure or misfire. A misfire is when a background action fails to run on time. Options are:
- Do Nothing: The request will be ignored.
- Run Once: Only one of the missed events, there may be several if scheduled, will be run.
- Run All Processes Scheduled: All of the missed events, there may be several if scheduled, will be run.
- Reporting Mode or Report Options
-
Determines whether or not AsyncActionMisfire records should be created.
-
No Report: Records not created.
-
Report All Processes: Create records for all outcomes.
-
- Threshold Minutes
-
Acceptable timeframe for an action to run before a misfire is determined.
Threshold determines how long of a grace period is allowed before determining that a misfire has occurred. For example, if an action was scheduled to run at 1:30 PM and the threshold time was 10 minutes, it would be considered acceptable for the action to actually run between 1:30 and 1:40 PM. If it has not run after 1:40 PM, this is considered a misfire and misfire processing occurs.
- Continue on Misfire or Continue on Failure to Run
-
Indicate whether you want to continue to process the action request when it fails.
- Number of Retries
-
Indicate the number of times you want the system to try to process the action request after a failure.
- If you have made changes, click Save.