Break loop

The screenshot on the right shows the For each loop used to process the checklist:

• In the Resolver for entities parameter, a Variable resolver accesses the String list provided in the checklist variable, which is iterated over.

• A User callback event action is executed in the action block of the loop:

  • The relevant text value for the iteration from the checklist list should be output in Upper case as the Text for the query.

  • If a query is confirmed with 'Yes', the next question should appear immediately. The action block in the Yes branch (left) therefore does not contain any event actions.

  • If the response is 'No', the processing of the checklist should be aborted. The action block in the No branch (in the center) contains two event actions:

    • The Set value event action saves the current loop index from the $index variable filled by the system in the abortIndex variable so that it is 'remembered' for subsequent processes.

    • The Break loop event action ensures that no further queries are made, but that the event handling is continued with actions below the loop (not in the image).

  • If the Max. wait time (s) expires before a query is answered, event processing should be stopped altogether without an error message appearing. This ensures the Abort event action is in the Timeout branch (right).

• The Resolver for entities for the outer loop creates a common list of addresses from two search results (for Companies/Clients and Addresses) via the Collect values resolver

• The inner loop receives a specific address as a reference object for each iteration of the outer loop, which is linked to either a company or an address book entry.

  • The Resolver for entities of the inner loop uses a Plural typed attribute resolver to list all address contact attributes with the user-defined Subtype 'building' (BUILDING) within the address

    • In the action block of the inner loop, a Concat strings resolver combines information from the parent address (address) and the address data in the address contact (contactAddress) to create a 'building name' for the output.

    • The concatenated text is transferred via a Modify list event action to the 'Unique list' (Set) provided via the buildings variable.

      ►IMPORTANT◄ This variable must have been initialized in advance using the Create instance resolver with the 'Unique list' (Set) type. This list type prevents the addition of duplicates without further precautions.

    • Regardless of whether the current 'building name' was actually added or ignored as a duplicate, the subsequent If then else checks the specified cancellation criterion: An Entity property rule uses the Compare with (Form designer) compare type to determine whether the specified limit matches the current length (length) of the buildings list.

      • If the limit is reached, a Break loop event action is triggered that ends the inner loop.

  • Below the inner loop is another instance of the If then else event action, which is exactly the same as the previous one in terms of content. This second check is necessary so that the outer loop is also aborted when the limit is reached.

    ►NOTE◄ The cancellation criterion for the outer loop does not formally check here whether the inner loop has been cancelled. The check only uses the same cancellation criterion. For the outer loop, it is not possible to distinguish whether the inner loop was aborted or because the address under investigation contains no further buildings. The Break loop action is also executed in both loop levels regardless of whether a further iteration would take place without cancellation. If required, this can also be checked using the Boolean variable $last (see For each loop.

The screenshot on the right schematically shows an event handling with a For each loop event action, in which the custom action event XF_TERMINATOR is triggered for the loop cancellation depending on a cancellation criterion in an If then else event action.

All other event actions are summarized here in Execute with event actions, whose labeling characterizes their significance for the sequence:

• The 'loop actions' in the action block of the loops are executed for each iteration. This also applies to the iteration in which the Break loop is (indirectly) triggered.

• The If then else event action checks an unspecified cancellation criterion as a condition for triggering the custom action event XF_TERMINATOR in the 'Then' branch of the case differentiation. The event handling triggered by this (see below) must contain a Break loop event action so that the iteration of the loop is actually cancelled.

  ►NOTE◄ The Dispatch action event transfers all variables from the call context to the data context for event handling calls, including the loop variables (see For each loop), which can therefore be evaluated in connection with processes when the loop is broken. On the other hand, changed variable values are not written back to the call context, so that the $index cannot effectively be manipulated there simply by assigning a higher value to the variable in the called event handling.

• The '... more loop actions' below are also executed for each iteration. However, they are omitted for the iteration in which the cancellation is triggered.

• The '... more actions' below are always executed after the loop is completed (with or without cancellation).

The screenshot on the right shows the configuration for an event handling that maps the default process for a loop cancellation:

• A Custom action event with the name XF_TERMINATOR is used as the Triggering event.

• A Static rule has been configured as the Validating rule so that the following actions are always executed in response to the XF_TERMINATOR event.

• There are two Actions on passed rule configured:

  • The If then else event action checks whether the Boolean variable $last automatically filled in the loop context contains the value true. This is only the case if it is the last iteration of the parent loop.

    • The 'Then' branch of the case differentiation does not contain any event actions, as nothing should actually happen if the cancellation is triggered in the last iteration of a loop.

    • The 'Else' branch of the case differentiation contains a Show alert event action that issues a notification of the 'Warning' Type if there is a 'significant' break in a loop (before the last iteration). The value configuration for the Message is shown in more detail below.

  • The actual Break loop event action should be executed in all cases. It can therefore be found outside the If then else event action.

►NOTE◄ There is no point in arranging further event actions below because the Break loop event action is not used here in the context of a For each loop. These would never be executed, as the control is returned to the parent loop with the cancellation.

The Message for a 'real' cancellation is defined as shown on the right via the Value from localization resolver, which is used here without real access to the Localization (neither Bundle nor Resource are named):

• The Default value defines an English text with parameters to which Integer values are assigned below based on automatically provided loop variables (see For each loop):

  • The first parameter ({0}) should indicate the iteration in which the cancellation occurred. The value 1 is added to the value of the $index variable via the Simple calculation (+,-,*,/,%) value resolver in order to shift the count to the more human-friendly variant with the starting value 1.

  • The second parameter ({1}) is assigned the $length variable, which specifies the total number of iterations.