Customizing
Version 27 Version 26 39.5.25 39.5.23 39.5.22 39.5.21 39.5.20 39.5.19 39.5.18 39.5.17 German English
Version 27 Version 26 39.5.25 39.5.23 39.5.22 39.5.21 39.5.20 39.5.19 39.5.18 39.5.17 German English

Time-Controlled Triggers MOD009DA6

Introduction

  • Customizer → System Customizer → Triggers → Time-Controlled Triggers

Time-controlled triggers are programmable triggers that are run at defined points in time independent of saving processes and other triggers. Further information on triggers

Information

  • In this module you can create and modify time-controlled triggers.

  • You can also view the trigger history.

Module Structure and Functions

Information

  • Each trigger is displayed in a box which contains all of its data.

  • On the left hand side of the box, general trigger information is displayed of which some may be editable.

  • On the right hand side, the interval settings of the trigger are displayed.

  • At the very right you will find the following buttons:

    • Configure - via this button you can open the Configure User-Defined Interval module in which a user-defined recursion interval can be configured for a trigger.

    • History - via this button you can open the Trigger History module which contains the history records of a trigger.

    • Delete - This button can be used to delete a trigger.

    • Execute - This button can be used to manually execute a trigger once. For this purpose, status, type of recursion, and start time are changed and the trigger history of this trigger is deleted.

Trigger Settings

Information

  • In the Function type listbox, you can specify the language or method of the trigger.

    • The listbox allows the Java, Jython and Python, entries, however, currently only Java and Jython functions are used for time-controlled triggers.

  • In the Function name field the full name of the (static) class method to be run is specified including its path.

  • In the Parameter field you can enter a freely definable string for the method to be executed.

  • In the Status field, the status of the trigger is specified and adjusted automatically by the system.

    • The following Status values are used for time-controlled triggers:

      • 0: Waiting

        • The trigger is currently scheduled to run at another time.

        • This is the default status of any trigger at its creation.

      • 1: Is running

        • The function assigned to the trigger is currently running.

      • 2: Terminated

        • The trigger was terminated without errors and will not be executed again.

      • 3: Failed

        • An error has occurred during the last execution. The trigger will be executed again after server restart.

    • A manual change of the status has no influence on whether a trigger is executed again or not. Its execution only depends on the Activated parameter as well as of the interval settings of the trigger.

  • The Activated parameter determines whether the trigger is executed ( ) or ignored ( ).

    • An triggger is only executed if the Activated checkbox is activated.

  • Below the editable trigger settings, information on the next start time, the last execution and the number of effected executions is displayed.

  • After the last execution, a traffic light is displayed which either indicates successful (green tranche) or incorrect (yellow tranche) execution.

Interval Settings

Information

  • By default, the interval settings consist of the Day, Time, and Recurs fields.

    • Day and Time define the initial start time of the trigger.

    • The Recurs listbox specifies whether and how often the trigger is to recur. The following entries are offered for selection:

Interval

Description

Once

The trigger is executed once at the planned point in time and does not recur.

Hourly

The trigger recurs every hour.

Daily

The trigger recurs every day.

Weekly

The trigger recurs every seven days.

Monthly

The trigger recurs the next month on the same week day, e.g. on the first Monday or on the last Friday of a month.

Yearly

The trigger recurs on the same date in the following year. Triggers on 02/29 only recur in leap years

User-defined

A user-defined interval is specified. This allows for a more detailed configuration.

  • User-Defined interval settings will only be displayed if the User-defined setting has been selected in the Recurs field. The fields in question are output fields (grayed-out) which cannot be edited in this module.

    • In order to edit user-defined interval settings, click on the configure button. The Configure User-Defined Interval module will be displayed in which the changes can be made.

    • Changes which are made in the Configure User-Defined Interval module are directly adopted in the output fields of the trigger record.

Create Time-Controlled Trigger

Procedure

  • Press F4 or click on the Insert button to insert a new trigger record.

  • Allocate a function type and function name.

    • Currently, only the Jython and Java function types are supported for time-controlled triggers.

  • Optionally you can make an entry in the Parameter field.

  • Enter Day and Time of the initial execution of the trigger.

  • In the Recurs field, set how often the trigger is to be executed by making a selection from the listbox.

    • If the recursion of the trigger is to be defined more precisely:

      • Select the User-defined entry.

      • Save.

      • Open the Configure User-Defined Interval module by clicking on the Configure button.

        • Enter a number below the Recurs every heading and enter a Unit in order to define the interval between the recursions of the trigger.

        • Optionally activate the checkboxes of the weekdays below the Recurs on heading in order to restrict the execution of the trigger to particular days.

          • On the weekdays for which the checkboxes are activated, the trigger can be executed.

        • Define below the Ends heading when the trigger is to be terminated, i.e. when the recursions of the trigger are to be suspended.

          • The Never ends checkbox is activated by default.

          • If the trigger is to be terminated on a particular date, activate the Ends on checkbox and specify the date.

          • If the trigger is to be terminated after a particular number of executions, activate the Ends after checkbox and store the number of desired executions.

  • If the trigger is to be active directly, mark the Activated checkbox.

    • A trigger is only executed if the Activated checkbox is activated.

  • Save.

Details

run_module and run_module_persistent_session functions

Information

The customizing.events.module.run_module and customizing.events.module.run_module_persistent_session functions are used to simply configure time-controlled or startup triggers.

Procedure

  • Store one of the functions in the Function name field.

  • In the Parameter field, store the module (2nd parameter) and the user (1st parameter) with which the module is to be executed.

  • You can use the optional 3rd parameter to specify a timeout in seconds that determines for how long the system should wait for the module.

  • The individual parameters should be separated by semicolons, e.g. PLSYSTEM;009DVW;20


Note

  • The clientless session user must be entered in the Parameters field for all triggers that use the functions mentioned and that are to execute the module call in the clientless session. In the PLANTA standard system it is PLSYSTEM.

Standard Triggers

The following triggers are made available by PLANTA by default:

Nocturnal Replanning

Carries out a nocturnal replanning (calculation of all planning objects).

Anonymize resources left

Data of Persons left such as name, first name, e-mail address, etc. are pseudonymized.

The configuration is made in the customizing via listbox category 00000502. Here, you can enter the data items to be pseudonymized. The following parameters are defined per data item:

  • Category: Python ID of the data item

  • Number 4 digits: Pseudonymization code

    • 1: ID. Here, the Python ID of the table which corresponds to the resource ID from 467 is entered. The HQL search_record is constructed based on this Python ID

    • 2: pseudonymize, causes the DI to be filled with a random value

    • 3: empty, important for, e.g., e-mail fields

  • Number 9 digits.: Table ID to which the DI with this Python ID belongs

In pseudonymization, IDs (codes) of persons/resources are changed via the Change Person/Resource ID function. In the case of an implementation of individual records with person data you therefore have to make sure that the DT and ID data item in question are additionally included in the mapping for Change Person/Resource ID.

The technical person ID is not changed during pseudonymization. The sex of all pseudonymized persons is set to "male" by default.

Jira Hybrid synchronization

Pulse Hybrid synchronization

Are used for the automatic synchronization of PLANTA project data with external systems (synchronization with PLANTA pulse and synchronization with Jira).

The respective trigger is automatically activated when the API-URL is defined for the corresponding external system.

Send automatic e-mails for resource requests

Is used to inform the responsible department manager/project manager when resources are requested or approved/rejected when using the Resource request function..

The trigger is automatically activated when the global Resource requests active setting is set to "1" or "2".

Delete archived planning objects

Deletes archived projects which are older than 10 years and which are not assigned to any portfolio and do no contain any external links.

Start underposting correction

Is required for the automatic correction of underpostings. The trigger initiates a module (009DSP) every night, which in turn executes the Python code that checks whether an underbooking correction is to be carried out on this day. For detailed information on the automated correction of underpostings/overpostings, please click here.

LDAP Import

Carries out a nocturnal user import (at 4.30 am) via LDAP.

Notification function for missing bookings

If this trigger is activated, the missing bookings for the working days of the previous week are checked every Monday. If the working hours are exceeded by the hours of presence, the person concerned is informed by e-mail or, if activated, via adaptive cards.

Notification function for missing status report

If this is trigger activated, the system checks whether all projects in the current month have a released status report. For projects without a status report, the project manager is informed by e-mail or, if activated, via adaptive cards.

Clean up Python Warn Log

Deletes warnings in the Python Warn Log module that are at least 30 days old.

Notes

  • In general, triggers are deactivated by default and can be activated by activating the Activated checkbox. Some triggers are automatically activated if the underlying function is activated.


See also: Programmable Triggers