Differences between Rulex 4 and Rulex Platform
This document provides information on all the changes made in the development of Rulex Platform, compared with the existing features in Rulex 4.
Information has been divided into the following sections:
Changes managed automatically by the PRCX-RFL converter during import operations
In Rulex 3.2, the functions currdate and tostring were available to evaluate the current date and to cast the result to string (an intermediate attribute type, different from nominal, which has been removed in Rulex 4). While Rulex 4 exceptionally allows the use of these two functions in the field procvars of module tasks (Execute Process File task or Rulex Process File Source task), in the import operation Rulex Platform converts these two functions to currDate and cast function, respectively.
In Rulex Platform, comment lines before any history rows (the one starting with //DATASET OPERATION) are used to automatically build the visual description. Therefore, their presence is mandatory.
Since in Rulex 4 some operations did not have these comment lines, in Rulex Platform the converter adds them, when needed. Namely:“//DATASET OPERATION\n//REMOVE ROWS” is added to Rulex 3.2 removeRow operation.
“//DATASET OPERATION\n” or “//RULESET OPERATION\n” is added where missing.
In Rulex 4, in the history, the data structure for rules is mentioned as rules. Rulex Platform converter changes it to ruleset to align it with the dataset naming, which was already present in Rulex 4 for data.
In Rulex 4, the status of the history lines is not reset when the task is disconnected from the source task. This may lead to misleading results by using a combination of Import from Task tasks and the computation of part of the history. Therefore, in Rulex Platform the status is always updated when a computed task is disconnected. During the conversion from prcx to rfl, the status of the history lines belonging to not computed tasks are set to ready.
The following options have been removed, as they are mainly unused options of Rulex 3.2 or Bridge options no longer useful in new bridge tasks configuration:
compat32
filenamefrc
delimfrc
alertstart
alertend
alerterror
alertrecipients
alerterrortype
alertduration
alertdurationtn
debugfilename
language
rhostname
report
rportaux
routputname
rinputname
scriptfromfile
rulboundselrows
The converter deletes these options during the import operation, if they are present.
In Rulex 4, graphical drop-down menu options are sometimes associated with string values (for example in the uri option in import/export task), or with numbers (representing the position of the entry in the list). In this last case, if the number of entries is two, also the ‘False/True’ binary entries are permitted, since they are automatically converted to a 0/1 integer. Consequently, adding a new entry to the list can change the position number, thus affecting the execution of the already existing workflows.
For this reason, any drop-down menu option in Rulex Platform is now associated with a list of string values. The converter automatically changes the options according to the table below:
Option name | Position number | New string value |
|---|---|---|
byname | 0 | position |
1 | name | |
cattype | 0 | inner |
1 | outer | |
oplist | 0 | X |
1 | = | |
2 | != | |
3 | < | |
4 | <= | |
5 | > | |
6 | >= | |
17 | substr | |
18 | superstr | |
19 | not_substr | |
20 | not_superstr | |
21 | begin | |
22 | is_begin | |
23 | not_begin | |
24 | is_not_begin | |
25 | end | |
26 | is_end | |
27 | not_end | |
28 | is_not_end | |
29 | damerau_levenshtein_<= | |
30 | levenshtein_<= | |
31 | hamming_<= | |
32 | long_common_substr_<= | |
33 | damerau_levenshtein_> | |
34 | levenshtein_> | |
35 | hamming_> | |
36 | long_common_substr_> | |
37 | is_anagram | |
38 | is_word | |
39 | include_word | |
44 | is_included | |
45 | included | |
40 | primary_phonetic | |
41 | secondary_phonetic | |
42 | some_phonetic_common | |
43 | both_phonetic_common | |
ordimptype/timeimptype | 0 | fixed |
1 | mean | |
2 | median | |
3 | mode | |
4 | minimum | |
5 | maximum | |
6 | minimumchange | |
incrdecr (It is no longer allowed the use of numbers greater than 1 or lower than -1, which lead to inconsistence behavior also in Rulex 4) | -1 | decrement |
1 | increment | |
jointype | 0 | inner |
1 | louter | |
2 | router | |
3 | outer | |
4 | lcomplement | |
5 | rcomplement | |
6 | complement | |
mergetype | 0 | nofill |
1 | left | |
2 | right | |
misspolicy | 0 | normal |
1 | always | |
2 | never | |
inpdisctype | 0 | incremental |
1 | entropy | |
2 | chi | |
3 | width | |
4 | frequency | |
5 | roc | |
outdisctype | 0 | width |
1 | frequency | |
distmethod | 0 | euclidean |
2 | euclidean-norm | |
3 | manhattan | |
4 | manhattan-norm | |
5 | pearson | |
evaldistmethod | 0 | euclidean |
2 | euclidean-norm | |
3 | manhattan | |
4 | manhattan-norm | |
5 | pearson | |
normtype | 0 | nonorm |
1 | attribute | |
2 | normal | |
3 | minmax01 | |
4 | minmax-11 | |
timeunit | 0 | second |
1 | minute | |
2 | hour | |
3 | day | |
4 | week | |
5 | month | |
6 | quarter | |
7 | year | |
impurtype | 0 | entropy |
1 | gini | |
2 | error | |
centroidtype | 0 | means |
1 | median | |
2 | medoids | |
kmeanstype | 0 | standard |
1 | incremental | |
2 | error | |
arsmoothfunc | 0 | log |
1 | box | |
2 | nosmooth | |
shuffletype | 0 | noshuffle |
1 | reshuffle | |
2 | keepshuffle | |
rulewide | 0 | term |
1 | condition | |
2 | rule | |
ruleinterval | 0 | operator |
1 | mix | |
2 | interval | |
treepruning | 0 | no |
1 | complexity | |
2 | reduced | |
3 | pessimistic | |
treeusemissing | 0 | average |
1 | remove | |
2 | include | |
adefiltmode | 0 | maximal |
1 | closed | |
2 | confidence | |
appenddata | 0 | dropinsert |
1 | appendinsert | |
2 | update | |
3 | updateinsert | |
4 | delete | |
nomimptype | 0 | fixed |
1 | mode | |
allonly | 0 | allbut |
1 | only | |
firstlast | 0 | first |
1 | last | |
svmkernel | 0 | linear |
1 | polynomial | |
2 | radial | |
3 | sigmoid | |
assigntype | 0 | random |
1 | smart | |
2 | weight | |
fulldeploy | 0 | all |
1 | requested | |
2 | fair | |
anomaly | 0 | one-class |
1 | anomaly | |
ordroll | 1 | minimum |
2 | maximum | |
3 | summation | |
4 | average | |
5 | median | |
6 | mode | |
7 | standdev | |
8 | absdev | |
nomroll | 1 | minimum |
2 | maximum | |
3 | summation | |
4 | average | |
5 | median | |
6 | mode | |
7 | standdev | |
8 | absdev | |
svmtype (with task category == “svm”) | 0 | c_svc |
1 | nu_svc | |
svmtype (with task category == “svmregr”) | 0 | epsilon_svr |
1 | nu_svr |
The converter automatically applies the table above to change the options coming from Rulex 4 during flow importation. The only option which still keeps its numerical values (even if its graphical representation in Rulex Platform is a drop-down menu) is winauth in Import from Database task and Conditional Import task. This option has still 0/1 or False/True as possible values. This choice was made to reduce the transition effort especially when dealing with possible runtime parametrization.
The following options have been renamed in the transition from Rulex 4 to Rulex Platform
rcode changes to scriptcode
rcommand changes to exepath
In Rulex 4, there are conflicting options for import tasks (for example filename/filelist). The list version is used if it is set, overriding the value of the name version. For this reason, in Rulex Platform the various filename, sheetname, query and tablename options have been removed and only the filelist, sheetlist, querylist and tablelist options are available. The converter moves, when needed, the value inserted in the filename, sheetname, query or tablename in the new list option, by changing it into a list of a single element.
In Rulex Platform, macro code has completely changed from Rulex 4. In Rulex 4, it is written as a list of internal command code (representing the socket language between the Rulex 4 Client and the Rulex 4 Server). In Rulex Platform, the macro code is made of CLI/API commands and it is aligned with the new Rulex Platform API service. The converter automatically casts the old commands of Rulex 4 into the corresponding Rulex Platform ones.
Changes mitigated by the PRCX-RFL converter during import operations through value modifications
Comparison operations (==, !=, <=, >=) executed in formulas or in ifelse functions on nominal columns return different results on None entries when working on Rulex 4 and not on Rulex Platform. The differences are mitigated when converting from Rulex 4 by enclosing these operations in a backward-compatibility function rns, which restores the behavior of Rulex 4. This function must NOT be used in any newly created code, as the new behaviour of Rulex Platform is strongly recommended.
Conditions in Rulex Platform have been greatly expanded in operational possibilities. Now operations can performed directly into condition codes, thus avoiding the need to create many additional support columns.
However, as a side effect, conditions received as input in the RuleToDataset task must now be more specific to avoid conflicts between the old and the new structure. For example, while the condition code PROD_SIZE in {3/Midi} is accepted in Rulex 4, in Rulex Platform the string 3/Midi must be surrounded by quotes to specify that it is a string. The converter takes care of these occurrences by writing the condition in the following form: PROD_SIZE in {“3/Midi”}.In Rulex 4, setting the procvar option to modify one specific variable in a module evaluation leads to a final option reporting the whole list of variables and not only the modified ones. To mitigate this effect, the converter modifies all the procvar options to delete any entry that is equal both in the module task and the parent flow, keeping the ones that are not present in the parent flow.
In Rulex Platform, the Reshape to Wide task will create all the new columns in the same table position of the original long attribute, when more than one Long attributes are selected to be expanded. In Rulex 4, instead, when there is more than one Long attribute, the new columns are still inserted at the end of the whole table, regardless of the position number or the order of the outputs. In Rulex Platform, a dedicated flag has been added to the task and its value is generated by the converter to ensure the same behavior as in Rulex 4 in the imported task.
In Rulex Platform, the module execution operation requires an rfl file as entry point, while Rulex 4 requires a prcx.
In some situations, the options’ names of the module task are defined by using the Runtime Variables task. This makes the update of all the options from .prcx to .rfl more error prone.
For this reason, a dedicated flag has been introduced in the Runtime Variables task and it is set as True by the converter to ensure the conversion of all .prcx extensions into .rfl at runtime during the execution of the task itself.In Rulex Platform, the value of the option "process" in the Import from Task task to specify the current flow has been changed from “-- THIS --“ to “__this__”. When importing a prcx, the converter changes all the options “process“ in the Import from Task task with value “-- THIS --“ into “__this__”.
Rulex4 allowed using in option loopvar values like "@var" and took @var as the iterator instead of its value, while Platform correctly uses the @var value. This difference has been mitigated converting this particular option when importing a prcx.
Changes established to be at low/minor impact not mitigated or corrected by the converter
The module execution has been moved from Python (used in Rulex 4) to GOLD/C in Rulex Platform, aligning these two tasks (Execute Rulex Flow File and Rulex Flow File Source) to the rest of the tasks during the execution process.
As in Rulex 4 all tasks except the module ones must have had their options aligned with their assigned type, in Rulex Platform this inconsistent behavior has been corrected.
In Rulex 4 the casting operations in modules performed with Python allow tasks to work even if the provided values in options are not of the correct type, while this is not possible anymore in Rulex Platform.
However, the impact of this change has been defined as low/minimal.When a module is executed in Rulex 4, the process variables used in the parent flow have the following priority:
1. Parent workflow
2. Module task procvar option
3. Module workflow variablesThis leads the procvar option to be meaningless in most occasions.
In Rulex Platform, the priority behavior has been changed, and it has the following priority:
1. Procvar option
2. Parent flow
3. Module flow variablesThe impact has been studied as minimal since procvar option use is not so frequent in Rulex 4.
In Rulex Platform, while executing modules, the selected loopvar must be defined and then selected only in the parent flow and no longer in the module only, as required in Rulex 4.
This is related to the disaster recovery policy set in Rulex Platform for module computation, which executes the loop iteration in a completely different thread now. This allows the system to recover itself even if a hard crash due to memory consumptions happens.
This change only concerns the iteration of an unclear loop and its impact has been estimated as minimal.In Rulex 4, process variables are calculated before any tasks leading to an evaluation, which in some situations depends on the running time (execution time) of the current process.
In Rulex Platform, to make the whole system more deterministic, the flow variables are evaluated only at the beginning of each computation and then updated only by a Runtime Variable task.
This also leads to an improvement in performance. The impact is only related to functions depending on external factors, such as the currDatetime function.
However, the use of this function in all the studied cases is affected and not supported by Rulex 4 behavior. In Rulex Platform, more deterministic cases will be obtained without any change in the meaningful part of the flow.Starting from 1.1.2-21, the Network Optimizer task has been completely rewritten in Rulex Platform to introduce a native Priority management.
The modification of the optimization routine may lead to differences compared to previous version, even with the same input data and options. However, all these differences lead to the same or to better cost functions, achieving an overall better optimization.Starting from 1.1.2-21, the Network Optimizer task raises an error both when the Destination value doesn’t match with the corresponding Destination Quantity value and when the Cost value related to a Source and Destination pair doesn’t match.
Starting from 1.1.2-21 in the Import from Text File task, when a Text delimiter has been defined, the system recognizes the attributes whose values are included into text delimiters as nominal ones.
In the Import from Excel File task, percentage columns defined in MS Excel files are recognized as percentage attributes. In Rulex 4, percentage columns in MS Excel files were imported as continuous attributes, instead.