In Read/Update mode, Decision Services can update the database so that data changes made by rules are persisted. That avoids the problem of post-rule execution data mismatch experienced in Read Only, but must be used carefully (especially when testing from Studio!) since rules will be writing to the database.

Open the project's Ruletest, and then set the menu option Ruletest > Testsheet > Database Access > Read/Update.

The variations that will be explored in Read/Update mode are:

Payload contains a new record not in the database

Once again, the Studio Ruletest Input is shown in the following figure.

As before, no such record is present in the table so all the data required by the rule must be present in the Input section. Fortunately, in this case, the required aircraftType data is present, and the rule fires, as shown:

Figure 1. Ruletest with new record

Since the EDC mode is Read/Update, a database update is made and the end state of the Aircraft table, shown below, is different from its original state.

Figure 2. Final state of database table Aircraft

We can see that the database and the Ruletest Results (simulating the response payload) contain identical data for the record processed by the rule – no post-execution synchronization problems exist.

Payload contains existing database record

Now, let’s revisit the Input Ruletest shown in Input Ruletest with Existing Record. Setting this Test to Read/Update mode, it appears as shown:

Figure 3. Ruletest with existing record

The Output section of the Ruletest confirms that data retrieval was performed. And, finding the retrieved aircraft was (and still is) a 747, the rule fired.

Unlike the Read-Only example, the database has been updated with the new maxCargoWeight data. The final database state is as shown:

Figure 4. Final state of database table Aircraft

Payload contains existing database record, but with changes

To better illustrate how the following examples affect the database when run in Read/Update mode, we will return the database’s Aircraft table to its original state, as shown:

Figure 5. Original state of database table Aircraft

When the following Ruletest is executed, we know from our experience with Read Only mode that the rule will not fire. However, notice in Final State of Database Table Aircraft that the database record has been updated with the aircraftType value (DC-10) present in working memory when rule execution ended. And since the value of aircraftType in working memory came from the Input Ruletest (having priority over the original database field), that’s what’s written back to the database when execution is complete. The final state of the data in the database matches that in the Results Ruletest upon completion of rule execution, as shown in the Results Ruletest:

Figure 6. Ruletest with existing record
Figure 7. Final state of database table Aircraft

As before, let’s modify the scenario slightly. The Ruletest Input shown in the next figure now contains an aircraft record that has an aircraftType value of 747, but the aircraftType value in the database’s Aircraft table (for this tailNumber) is MD-11. Let’s see what happens to the database upon Test execution:

Figure 8. Ruletest with existing record
Figure 9. Final state of database table Aircraft

Once again, when a data mismatch is encountered, the data in the Input Ruletest (simulating the request payload) is given higher priority than the data retrieved from the database. Furthermore, the data in the Input Ruletest satisfies the rule, so it fires and causes maxCargoWeight to receive a value of 250000, as shown above. Unlike before, however, the new maxCargoWeight value is updated in the database.