Table /BTI/TE_RE_STEP is where all the simple/multilevel steps used by the Rules Engine are configured.
| Field | Description |
|---|---|
| Step ID | Unique name of the Step. |
| Parent Step ID | Used when you are creating a child step that forms part of a parent step (eg when you have an AND logic parent step consisting of two child steps. Note that the Parent Step also needs to be defined as a seperate Step in this table, and you must configure this first. |
| Step Type | See list of available Step Types below. |
Step Types
The following details the available Step Types that can be configured in /BTI/TE_RE_STEP (the most common types are detailed at the top).
| Step Type | Description |
|---|---|
| FORMFIELD | This can be used to evaluate a value in a standard or custom field on a Transport Form. Note: Step type FORMFIELD cannot be a child node to ALLTASKS / ANYTASK. |
| TASKFIELD | This can be used to evaluate a value in a standard or custom field on a Business Task. Note: Step type TASKFIELD can only be a child node to either ALLTASKS or ANYTASK |
| PROJFIELD | This can be used to evaluate a value in a standard Project field. Note: Step type PROJFIELD needs to be a child node of TASKPROJECT. |
| ALLTASKS | This can be used to evaluate whether ALL of the Business Tasks assigned to a Transport Form satisfy the child condition. This has been added for the benefit of a few long-term ActiveControl customers that associate a Transport Form with more than 1 Business Task (although this is generally not something Basis Technologies recommend in newer versions of the product due to the concept not working well with newer capabilities such as Partial Testing). |
| ANYTASK | This can be used to evaluate whether ANY of the Business Tasks assigned to a Transport Form satisfy the child condition. Similar to ALLTASKS, this has been added for the benefit of a few longterm ActiveControl customers that associate a Transport Form with more than 1 Business Task. |
| AND | This can be used to evaluate several steps as an AND scenario, whereby all the steps must be TRUE for the result to be TRUE. In this instance, the parent step would have the AND Step Type, and the child steps would each have their own condition. Note: Step type AND must have at least 2 child nodes |
| OR | This can be used to evaluate several steps as an OR scenario, whereby if any of the steps is TRUE, then the result is TRUE. In this instance, the parent step would have the OR Step Type, and the child steps would each have their own condition. Note: Step type OR must have at least 1 child nodes |
| NOT | This can be used to evaluate several steps as an NOT scenario. Note: Step type NOT must have at least 1 child nodes of either AND or OR Please refer to this Knowledge Article for an example of a NOT step type configuration. |
| ALWAYSTRUE | This can be used when you always want the result to be TRUE. A common use case for this is in ALLGROUPS approval process. Please refer to this FAQ for an example configuration of this scenario. |
| CHECKSTEP | This is used in conjunction with Reusable Steps. |
| RISKCHECK | This can be used to evaluate whether a transport contains risk objects, similar to what was possible in /BTI/TE_SKIPCP previously. Note that only the relational operators (eg =, <> ) can be used as conditions against this step type. |
| CONTEXT | This Step Type should be used for Fields which are neither on FORM or TASK. For example, it can be used in conjunction with TARGET or LOCATION conditions in /BTI/TE_RE_STEPC. |
| CUSTOM_STEP_TYPE | This can be used by customers wanting to create Custom Step Types – see here for further information. |
Post your comment on this topic.