Open the sample's Ruletest, ProcedureApproval.ert. It opens on the Testsheet No Input Data. Click Run to compile and run the rules. The output shows patient and treatment data.
Right-click anywhere in the output column, and then choose Collapse All, as shown:
Now we can see that all the patient records and their treatments were retrieved.
So too for the One Patient and Multiple Patients Testsheets. That is not what we want in this use case.
Looking at the Service Call-out's Query Name, we see that it is AllPatients:
We got what we asked for!
Time for some SQL
That query was really two queries combined:
SELECT * FROM Patient SELECT * FROM Treatment WHERE patientId IN ({Patient.patientId})
Together, the two queries tell ADC to get all the patients and all the treatments for those patients. There are two queries. One query gets the set of Patients, and the other gets the set of Treatments for each patient. All the needed data is retrieved with these two queries and the associations are automatically established in Corticon working memory.
Run test with a different query
Change the Service Call-out's Query Name to IndicatedPatients. Then, return to the Ruletest. When you run the test for the No Input Data testsheet, you get no results. When you run the Testsheet for the One Patient and Multiple Patients Testsheets, you get exactly that one patient and the specified three patients.
The first part of this SQL statement is:
SELECT * FROM Patient WHERE patientId IN ({Patient.patientId})
The curly braces indicate tokens in the query that will be replaced by the data passed to Corticon -- in this case, selecting the patients to process.
In other words, {Patient.patientId} indicates that one or more attributes defined in the vocabulary can be used in the parameterization of your query. These value for each query parameter can be provided in the request message, or set by rules to conditionally fetch data from the database.
