In Read Only mode, data may be retrieved from the database in order to provide the inputs necessary to execute the rules. But the results of the rules won’t be written back to the database – hence, read-only.

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

The variations that will be explored in Read Only mode are: Finally, the section Effect of rule execution on the database shows that the read-only functions did not change the database but perhaps they should have.

Payload contains a record new to the database, and the entity is not extended to database

Let’s look at a Studio Test with an Input Ruletest (simulating a request payload) containing a record not present in the database. The initial database table dbo.Aircraft is as shown:

Figure 1. Initial state of database table Aircraft

And the Studio Input Ruletest is as shown in the following figure.

Figure 2. Input Ruletest Testsheet with new record, in Read Only mode

We know from our Vocabulary that tailNumber is the primary key for the Aircraft entity. We also know by examining the Aircraft table that this particular set of input data is not present in our database, which only contains aircraft records with tailNumber values N1001 through N1004. So when we execute this Test, the Studio performs a query using the tailNumber as unique identifier. No such record is present in the table so all the data required by the rule must be present in the Input Ruletest. Fortunately, in this case, the required aircraftType data is present, and the rule fires, as shown:

Figure 3. Results Ruletest with new record

Again, since EDC is Read Only for this test, no database updates are made and the end start of the AIRCRAFT table, as shown, is the same as the original state:

Figure 4. Final state of database table Aircraft

Payload contains a record new to the database, and the entity is extended to database

This scenario assumes the rule shown in Sample Rulesheet for Synchronization Examples makes use of an alias extended to the database. By placing the Aircraft Entity in the Scope of Rulesheet, we can right-click on Aircraft and then choose Extend to Database as shown:

See the Rule Modeling Guide chapter "Writing Rules to Access External Data" for more information about this setting. In that guide, you might want to learn about "Optimizing Aggregations that Extend to Database" which pushes these collection operations onto the database.

When our sample rule uses an alias extended to the database instead of the root-level entity shown in Sample Rulesheet for Synchronization Examples, different behavior is observed. When an Input Ruletest or request payload contains data not present in the database, as in test case N1005 above, and the database access mode is Read-Only, the rules engine dynamically merges the input or payload with records in the database table.

Figure 5. Results Ruletest showing merged records

Payload contains existing database record

Now, let’s change our input data so that it contains a record in the database. As we can see in the following figure, the value of tailNumber in the Input Ruletest has been changed to N1003. Also, the value of aircraftType has been deleted. By deleting the value of aircraftType from the Input Ruletest, rule execution is depending on successful data retrieval because the Input Ruletest no longer contains enough data for the rule to execute. Data retrieval is this rule’s “last chance” – if no data is retrieved, then the rule simply won’t fire.

Fortunately, a record with this value exists in the database table, so when the Test is executed, a query to the database successfully retrieves the necessary data.

Figure 6. Ruletest input with existing record
The Results Ruletest, as shown below, confirms that data retrieval was performed.
Figure 7. Ruletest output with existing record
And, finding that the aircraft with tailNumber=N1003 was in fact a 747, the rule fired. But as before, no updates have been made to the database because this Test still uses Read-Only mode. The final database state is as shown:
Figure 8. Final state of database table Aircraft

Payload contains existing database record, but with changes

What happens when, for a given record, the request payload and database record don’t match? For example, look carefully at the Input Ruletest below. In the database, the record corresponding to tailNumber N1003 has an aircraftType value of 747. But the aircraftType attribute in the Input Ruletest has a value of DC-10. How is this mismatch handled?

Studio still performs a query to the database because it has the necessary key information in the provided tailNumber. When the query returns with an aircraftType of 747, the Synchronization algorithm decides that the data in the Input Ruletest has priority over the retrieved data – for the purposes of working memory (which is what the rules use during processing), the data in the Input Ruletest is treated as “more recent” than the data from the table. The state of aircraftType in working memory remains DC-10, and therefore the condition of the rule is not satisfied and the rule does not fire. Even though the database record defines the aircraft with tailNumber of N1003 as a 747, this is not good enough to fire the rule. The other piece of retrieved data, maxCargoWeight, is accepted into working memory and is inserted into attribute maxCargoWeight in the results Ruletest upon completion of rule execution, as shown on the right side of the following figure:

Figure 9. Ruletest with existing record but different aircraft

Let’s modify the scenario slightly. Look at the next Input Ruletest, as shown on the left side off the following image. It contains an aircraftType attribute value of 747, but the AIRCRAFTTYPE value in the AIRCRAFT table of the database (for this value of TAILNUMBER) is MD-11. How is data synchronized in this case?

Figure 10. Ruletest with existing record and same 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 on the right side of the figure above.

Effect of rule execution on the database

In several of the examples above, the state of data post-rule execution differs from that in the database. In Results Ruletest with Existing Record and Results Ruletest with Existing Record, rule execution produced a maxCargoWeight of 250000, yet the database values remained 200000. The application architect and integrator must be aware of this and ensure that additional data synchronization is performed by another application layer, if necessary. When Corticon Studio and Server are configured for Read Only data access, data contained in the response payload may not match the data in the mapped database.