Define a data-triggered action

Data-triggered actions either trigger execution of an event template created by a solution designer in the tool Alfabet Expand or execute a native SQL query defined directly in the data-triggered action.

• Trigger execution of an event

  A solution designer has created the event template in the tool Alfabet Expand. Event management is not yet documented for Alfabet 11 releases. Solution designers can refer to the event management documentation for Alfabet 10.15 to read about definition of event templates.

  1. Go to Configuration > Data-Triggered Actions > Data-Triggered Action Groups.
  2. In the explorer, click the data-triggered action group that should host the data-triggered action and click Data-Triggered Actions.
  3. Click + New > Create a Data Action.
  4. Define the data-triggered action in the editor.

     Mandatory attributes:

     • Technical Name: Define a unique technical name for the data-triggered action.

       Rules for defining technical names

       Technical names should be unique and should not contain white spaces and special characters except underscore and hyphen. They are used to identify configuration objects unambiguously in technical processes.

     • Name: Define a caption for the data-triggered action. The caption will be displayed in the views for defining data-triggered action rules.
     • Action Type: Select Event Template.
     • Event Template: Select the event that shall be executed. Contact your solution designer for more information about events implemented for your Alfabet installation.

     Optional attributes:

     • Description: Enter a description that will inform administrators creating data-triggered action rules about the meaning of the data-triggered action.
     • Qualifying Query: If you define a qualifying query, the data-triggered action is only executed if the qualifying query returns a result. Use the Alfabet parameter @BASE to refer to the current object. The current object is the object that is changed, or created to trigger the action. The Alfabet parameter @BASE is substituted at runtime with the REFSTR value of the current object. @BASE cannot be used if the data changed is triggered by a delete action.

       For example, an event to update application data in Horizzon shall be executed when application data is changed. The following qualifying query checks whether the currently changed application as a Horizzon Id. Only if a Horizzon Id is available, the data can be synchronized with Horizzon, and the event is triggered.

       • SELECT app.REFSTR, app.Name
       • FROM APPLICATION app
       • WHERE app.HORIZZONID IS NOT NULL
       • AND app.REFSTR = @BASE
     • Execute in Background: If the checkmark is selected, the event template is executed in the background, and the user interface is not blocked during execution. For event templates, the checkmark should always be selected.
• Trigger execution of an SQL query

  You are familiar with native SQL query language.

  Statements written in the context of data-triggered actions are update statements which will change the data in the Alfabet database. They should only be defined in a development/test environment to proof that the execution does not corrupt the data in the Alfabet database prior to implementing them in a production environment.

  1. Go to Configuration > Data-Triggered Actions > Data-Triggered Action Groups.
  2. In the explorer, click the data-triggered action group that should host the data-triggered action and click Data-Triggered Actions.
  3. Click + New > Create a Data Action.
  4. Define the data-triggered action in the editor.

     Mandatory attributes:

     • Technical Name: Define a unique technical name for the data-triggered action.

       Rules for defining technical names

       Technical names should be unique and should not contain white spaces and special characters except underscore and hyphen. They are used to identify configuration objects unambiguously in technical processes.

     • Name: Define a caption for the data-triggered action. The caption will be displayed in the views for defining data-triggered action rules.
     • Action Type: Select SQL Query.
     • SQL Query Definition: Define the native SQL query to update data related to the currently changed object data. Use the Alfabet parameter @BASE to refer to the currently changed, created, or deleted object. The Alfabet parameter @BASE is substituted at runtime with the REFSTR value of the current object. @BASE cannot be used if the data changed is triggered by a delete action.

       For example, the following query shall be executed when a user edits the end date of an application. It sets the end data of all information flows to and from the application automatically to the new end date of the application.

       • UPDATE INFORMATIONFLOW
       • SET INFORMATIONFLOW.ENDDATE = APPLICATION.ENDDATE
       • FROM INFORMATIONFLOW
       • JOIN APPLICATION ON (APPLICATION.REFSTR = INFORMATIONFLOW.FROMOWNER OR APPLICATION.REFSTR = INFORMATIONFLOW.TOOWNER)
       • WHERE APPLICATION.REFSTR = @BASE

     Optional attributes:

     • Description: Enter a description that will inform administrators creating data-triggered action rules about the meaning of the data-triggered action.
     • Qualifying Query: If you define a qualifying query, the data-triggered action is only executed if the qualifying query returns a result. Use the Alfabet parameter @BASE to refer to the current object. The current object is the object that is changed, created, or deleted to trigger the action. The Alfabet parameter @BASE is substituted at runtime with the REFSTR value of the current object. @BASE cannot be used if the data changed is triggered by a delete action.

       For example, the query in the example above should only be executed during the planning phase of applications. When an application is active, the end date of the information flows shall not be changed. The query checks whether the application has the object state Plan.

       • SELECT app.REFSTR, app.NAME, app.VERSION
       • FROM APPLICATION app
       • WHERE app.REFSTR = @BASE
       • AND app.OBJECTSTATE = 'Plan'
     • Execute in Background: If the checkmark is selected, the SQL query is executed in the background, and the user interface is not blocked during execution. By default, this option is checked. Only deselect the checkmark for very simple queries like updating of another attribute of the asset currently changed.