Scheduling Background Actions

Use this procedure to schedule the running of any background action. This includes jobs, job streams, and any instance or set action that can be scheduled.

How the process of scheduling starts depends on what is being scheduled. For jobs and job streams, you start by selecting a job or job stream from the Jobs or the My Jobs tab of the Job Console, and then selecting Actions > Run Selected Job. For instance or set actions, the scheduling will be available often if you select an action on a form. When the Schedule form appears, if you leave the Schedule Type as Run Now and click OK, the background action is sent immediately to the queue. If you select a different Schedule Type, you can then proceed with defining the scheduling.

If you schedule a job or schedulable action to be processed at a later time, at any time up until the request is submitted to the queue the user can modify the scheduling options. For information on how to modify scheduling options, see Modifying a Background Action Scheduling Configuration.

The steps below assume you are using the Web UI. If you are using the Infor Rich Client, you are presented with multiple forms depending on your selections. In the Web UI, additional fields will be added to the current form based on your selections.

To schedule a background action:

  1. Create the basic definition. Specify this information:.
    Scheduled Action Name
    A name for the schedule entry.
    Notify Recipient - Email Address (Optional)
    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.
    Notify Recipient - 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.

    Execution Duration Notification - Email Address
    Specify the email address of the person who should receive an email if the processing of the action group exceeds the duration specfied 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.
    Execution Duration Notification - 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.
    Run Action Concurrently
    Whether the job can run concurrently. If you select No Concurrency, then at most one execution event (trigger) can be processed at any given time from the request. This is only relevant if the request is scheduled repeatedly.
  2. Provide scheduling details. Specify this information:
    Schedule Type
    How to schedule the background action.
    • Run Once - Schedule to run only once as soon as possible.
    • By 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.
    • By Date in Month - 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.
    • By 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.
    • By 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 - Schedule to run using a combination of the previously listed scheduling types.
    • Copy From Template - Schedule to run based on a selected scheduling template. Note that you can later access the background action in My Actions and edit the scheduling without affecting the template itself. Also, when you select a scheduling template, its values are copied into this scheduling record. Thus, if you later edit the scheduling template, those changes are not applied to this scheduling record.
    After you select a scheduling type other than Run Once, the form will display additional fields so that you provide the scheduling details.
    First Time To Run
    • If you specify a value and a schedule is specified, the background action will first run at the time specified, and then run according to the schedule.
    • If you specify a value and the schedule type is Run Once, the background action will first run at the time specified and be complete.
    • If you leave this field blank and a schedule is specified, the background action will run according to the schedule.
    • If you leave this field blank and the schedule type is Run Once, the background action will schedule to run once immediately and be complete.
    Latest Time To Run
    The latest time to try to process the background action. The action is considered complete once this time has passed.
    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.
  3. Configure the strategy to use when failures occur. Specify this information:
    Strategy
    What to do in the case of a failure or misfire. A misfire is when a background action fails to run on time. The available 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.
    Report Options
    What reporting to do in the event of a failure. Valid entries are No Report and Report All Processes. The reports created are AsyncActionMisfire records.
    Threshold Minutes
    In the event that the background action does not run on time, the number of minutes after the scheduled execution time before it is considered a failure.
    Continue On Failure to Run
    Whether to continue processing after a failure. If false and a misfire occurs, the background action is considered complete and no future executions will be scheduled.
    Number of Retries
    The number of times to retry an individual execution of the background action in the event of a failure. Automatic retries of an execution instance only occur under the specific case of a record being changed out from under the execution, that is, a looked up record has become stale or modified before this process attempts to change it.
  4. Click OK.
Related topics