Period Object (PERIOD)

A period object helps you quickly provide the parameters required when you run an object with the Execute Recurring option. The parameters define when and how often recurring executions should run. By defining period objects for typical recurring specifications, you can have a group of templates to help save time and support consistency when you execute recurring tasks. For sample definitions, see Examples of Period Objects.

Object Definition

Object class: Passive object

Object type/Short name: PERIOD

This topic provides information on the following:

• Background/Purpose
• Where You Can Use a Period Object
• Planning and Managing Period Objects
• Execute Recurring While the Object is Running
• Defining a Period Object

Background/Purpose

Executable objects can be run recurrently. When you do, you need to provide several specifications about when and how often it should run. Rather than entering the specifications from scratch each time you start a recurrent execution, you can define the recurrent parameters in a period object and later load those values into your recurrent executions in one step. If needed, you can modify the values for your specific situation, using the pre-defined values as a starting point. Using predefined Period objects helps you start objects with recurring executions faster and more consistently.

Where You Can Use a Period Object

Anywhere that you can execute an object and you choose the Execute Recurring option, that is:

• In the object definition from the Process Assembly perspective
• On the Tasks list in the Process Monitoring perspective
• When you define a sub-task in a workflow

When starting a recurring execution, you can select a period object and load its parameter values. You can use the values exactly as defined in the period object or modify them further as needed before starting the recurring execution.

Planning and Managing Period Objects

When you load a period object into your recurring execution you can still modify all execution-related settings. You can even change the object's title text to better describe your specific recurrence specifications. In this way, think of your period objects as templates.

Use the title to provide a short description of the parameter settings or the purpose of the period object. This will help people find the period object that best suits their execution needs. This title can also appear on the Tasks list and can give people more insight when monitoring the tasks. For example, a period object, PERIOD.WEEK_NIGHTS might have the title "Weekday nightly runs".

Execute Recurring While the Object is Running

You can start a new execution of an object while a previous execution is still running. If you use the Execute Recurring option, the recurrent execution parameters are effective after the current run completes.

Defining a Period Object

A Period object definition is made up of the following pages:

• Standard pages that are always available, no matter what type of object you are defining:
• General
• Version Management
• Documentation
• The object-specific page described here.

When you load a period object into a recurring execution, all the settings from the Period page as well as the descriptive title from the General page are loaded. You can leave them as is or modify them further as needed for specific recurring executions.

Using the setting options in these areas, you can create complex execution schedules, such as a schedule that runs an object every Monday and Friday from July 1, 2015 to June 10, 2020, starting every half hour but only between 12:00 and 20:00 (12:00 and 8:00 PM).

The following list describes the sections on the Period page and what you can define in each.

• Period

  Defines when this period object is valid. When the period ends, no more recurrent executions will be started. Any that have already started will continue to run until they finish.

  A period always begins on a specific calendar day, but it can end in different ways:

  • On a specific date
  • Never
  • After a certain number of executions.

  

  If you change this setting to a specific end date, this has no effect on recurring executions that were already started with the period object. They need to be ended individually.

• Frequency

  • Execute

    Defines when and how often during a day that executions can be started.

    

    Depending on the setting you choose, further options appear to refine the run intervals:

    • at

      Specify a time of day

    • in intervals of every

      Specify fixed time intervals (up to 504 hours= 21 days)

    • after the previous run ends plus

      Specify a buffer time after the end of the previous run (up to 504 hours= 21 days)

  • Between time window

    When you choose intervals or consecutive runs, rather than one time of day, you can also define a time window during the day that the object is started. By default, this is set to all day, specifically, between 00:00 and 23:59 (00:00 AM and 11:59 PM).

    

  • Allow one overlap

    Select this option when you want the next scheduled execution to start even when the previous one is still running. Without this option, the execution would be skipped until the next scheduled time according to the other settings on the Period page.

    

  • Initial Start Time

    This option controls when the first execution starts. The following executions start in the intervals defined in the Frequency section. It is available when the frequency is defined for fixed time intervals or when it is based on a buffer time after the end of the previous execution.

    Usually, when you start a recurring execution with one of these Frequency types, the first execution starts immediately. However, when you select the Initial Start Time option, the first execution does not start immediately when the execution is triggered, instead the first execution waits for the next regular segment of an hour, based on the interval or buffer value. For example, if the interval or buffer is set to 15 minutes, then the execution starts on the next quarter of an hour (that is, hh:15, hh:30, hh:45, or hh:00). All executions after this start according to the rest of the Frequency settings.

    With Execute in intervals of every:

    This is a nice option when you want to execute at intervals, because then the intervals will also start at normal clock-time segments. For example, suppose your period is defined to execute the job in 30-minute intervals, and you start the recurring execution at 9:07.

    Without Option	With Option
    9:07 (immediate start)	9:30 (start at the next half hour)
    9:37 (9:07 (start) + 00:30)	10:00 (9:30 (start) + 00:30)
    10:07 (9:37 (start) + 00:30)	10:30 (10:00 (start) + 00:30)
    and so on	and so on

    

  • With Execute after the previous run ends plus

    This option has little effect when your executions start after a time buffer following the end of the previous run. The first execution will start at a normal clock-time segment, for example not at 9:07 when you started the recurring execution, but at 9:15. However, the rest of the executions will start based on the actual runtime of each run plus the fixed buffer time. This will naturally result in irregular clock-time starts.

• Days

  Restrict the days within the validity period that executions can be started. By default the executions are started every day. However, you can restrict them to start only on certain days of the week, such as only on weekdays and not on weekends.

  

  Or based on one or more Automic calendar conditions, by selecting calendars and specifying whether all, one or no conditions match. This allows you to define more complex and precise days for the executions, such as all days except bank holidays.

  

See also:

Examples of Period Objects