To avoid the problem of post-rule execution data mismatch, EDC may be set to Read/Update mode. In this mode, Corticon Studio and Server can update the database so that data changes made by rules are persisted. This avoids the post-execution synchronization problem we encountered with Read-Only EDC mode, but must be used very carefully since rules will be directly writing to the database.
We’ll use the same batch of examples as before to discuss the synchronization performed by Studio and Server when set to Read/Update mode for a Ruletest by selecting Ruletest > Testsheet>Database Access>Read/Update from the Studio’s menubar (the Ruletest must be the active Studio window).
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 334. 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 335. 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 336. 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 337. 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 338. 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 339. Ruletest with Existing Record
Figure 340. 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 341. Ruletest with Existing Record
Figure 342. 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.
