Configuration of the Decision Table

Different decision tables can be set up, each for a separate rule in the workflow. To see how the workflow determines which decision table is to be used, see the previous chapter.

To create a new decision table, right click and select new, to edit an existing one, right click on it and select edit.

Decision Table Properties

Figure 52 Decision Table

Table 52 Decision Table Fields

Decision Table Filters

The next screen shows the conditions against which the object is checked. If a match is found, the action linked to that condition set is executed.

Figure 53 Decision Actions

Each table consists of one or more filters. The object to which the table will be applied is now checked against the first filter and if it matches, the action which is linked to that filter is executed. If it does not match, the next filter in line is checked.

Please note that the filters are not able to process numeric fields such as dates or amounts. The individual filters are configured as follows:

General

In the general tab, the order number has to be selected (it is advised to use a multiple of ten so that later on, extra filters can be added in between without having to renumber all filters. e.g. 15 can be added between 10 and 20 later on)

Next to the general tab, the Decision Action has to be selected. This is the rule or script which has to be executed when the filter matches.

Figure 54 General Filter Information

Condition

On the condition tab, a filter, rule or Groovy script can be entered which must be matched.

Figure 55 Filter

Action parameters

The action parameters define the parameters which are to be applied when the action, associated with this filter is to be executed. (e.g. to which directory a file must be written). For more information, refer to the documentation regarding communication.

Note that the action parameters only contain drop-down lists when this has been programmed into the corresponding decision table category class. (in our example com.trax.message.gui.decision.CommunicationParametersPanel) If there is no class linked to the decision table category, there will only be an empty text field where the parameters and their values can be entered. This means that the parameters must be known to the end-user. Therefore, it is preferable to implement a decision table category class if the end-user is supposed to make modifications to the decision tables. This will help to minimize mistakes and make the system easier to use.

Table 53 Action Parameters

Decision Actions

Decision actions contain either a rule or a script which is executed when their linked entry in the decision table is matched

Figure 56 Decision Actions