Configuration

In the configuration for the rule, the same parameters define which flag is checked:

The optional Job name parameter is determined by a Resolvers whose return value is interpreted as a string unless it is 'no value' (null).

The optional Job owner parameter is determined by a Resolvers whose return value is interpreted as a data object.

The Single run job executed? rule compares the Job name as a string and the Job owner as a data object to determine whether or not a particular flag has been set previously by the Mark single run job executed event action (with corresponding values for these parameters) in the course of the transaction.

►NOTE◄

• Since both parameters are optional, the rule can also be used without parameter values (or with the values null/null). It will be passed if the event action Mark single run job executed was also executed with the parameter values null/null.
  
  

• The crucial factor for the match at the Job name parameter is an exact match of the return value of the value resolver converted into a string. For example, an integer (e.g. a Long value from an id field of an entity) can be compared with a string of digits provided as text. If 'decimals', dates/time, etc. are to be compared with e.g. texts provided as 'literal', the formatting must be chosen exactly to match the output format of the respective value within a Show alert (Popup) event action.
  
  

• How data objects are compared in the Job owner parameter depends on the object type:
  
  

  • If an entity or an attribute of an entity with a system-managed ID (id) is specified as a Job owner, then the rule checks whether the data object referenced as the Job owner is identical to the data object referenced in the Mark single run job executed event action. On the one hand, this means that the rule still 'recognizes' an entity even if its data has been changed since the event action Mark single run job executed was executed. On the other hand, this also means that two 'cloned' instances are considered mismatched even if they contain identical data for the same entity. No deep comparison (see Equals) is performed. This effect is apparent e.g. when trying to assign entities from the login context (see Session based (Resolvers)) as Job owner. The value resolvers for User of session, Company of session and Role of session create a new 'clone' of the respective entity with each call, so that the returned data objects are never identical, although they represent the same entity and are also evaluated as 'equal' in a 'deep comparison' (see Equals).
    
    

  • If a freely defined data object (e.g. a 'client object') is assigned as the Job owner, then the matching process evaluates all the data contained in the object (i.e. its hash value). The Single run job executed? rule is passed only if the current object data exactly match the state when the flag was set via the Mark single run job executed event action. Whether it is actually the same object instance (see also Create instance) is irrelevant, as long as all characteristics match.

►NOTE◄ The Single run job executed? rule is often 'negated' in practice (see '!' in the screenshot; for details see Not rule), since the event actions below should typically be executed exactly when the rule does not apply.

In the screenshot, the Job name parameter is defined as static text (with the value 'TS_UPDATE'), while the Id (unique internal identifier in the id field) of the reference object in the rule data context is used as the Job owner. If a transaction involves several reference objects, a unique flag is checked for each reference object in this way.

Example

A specific example of using the Single run job executed? is described on the help page for the Mark single run job executed event action.