Tutorial - Modeling Progress Corticon Rules to Access a Database using EDC

In the Basic Rule Modeling and the Advanced Rule Modeling tutorials, you learned how to develop and test Corticon rules using a range of Corticon Studio features. You learned how to model rules that processed input data and returned output data.

In many cases, you may want the rules to retrieve data from a database, process it, and/or write data to the database. For example, suppose you wanted to model a rule that receives an aircraft tail number in an incoming request message, and retrieves details about the aircraft type from a database. Or, suppose you wanted to model a rule that writes a record of each flight plan to a database.

Corticon’s Enterprise Data Connector (EDC) enables rules to perform read and write operations on data in a database. In this tutorial, you will learn how to use EDC to model rules that:

  • Read data from a database
  • Add or update data to a database
  • Delete data from a database

This tutorial is designed for hands-on use. We recommend that you install Corticon Studio, and then follow the instructions and illustrations in the tutorial. This tutorial is based on Corticon 6.3.

How database elements map to Vocabulary elements

For rules to read or write to a database, the Vocabulary elements used in the rules must be mapped to elements in the database. The mapping is typically done by an integration developer. However, as a rule modeler, it is useful for you to understand how these elements are mapped.

A relational database is a set of tables. Each table corresponds to an entity in a Vocabulary. A table contains a set of records. Each record is a row in the table. A record is like an entity instance in a Ruletest—it is a set of data values. Columns in the table correspond to attributes in the entity.

media/image1.png

Each table has a primary key which uniquely identifies records in the table. The primary key is one of the columns in the table. For example, each Aircraft record could be uniquely identified by its tailNumber, while each FlightPlan record could be identified by its flightNumber. Each table can also have a foreign key which associates its records with records in a different table. The foreign key is usually the primary key of the other table. For example, the FlightPlan table could have a foreign key named Aircraft_tailNumber, which associates its records with records in an Aircraft table. The relationship between two tables corresponds to an association between two entities in the Vocabulary.

Finally, every database has a schema. A database schema is a blueprint of the database structure. The schema is like the Vocabulary tree. Along with other information, the schema contains the names of tables in the database, the column names, the primary key columns of each table, and information about how the tables are related.

This table summarizes how Vocabulary elements map to database elements:

media/image2.png

Typically, as a rule modeler you are not responsible for mapping the Vocabulary to the database. This is done by an integration developer. Once the mapping is configured, your rules will automatically access the database. It is important for you to understand how your rules will affect the database. You should coordinate with the integration developer who is responsible for setting up the database and mapping the Vocabulary.

In this tutorial, you will model rules that read and write to a database. Before you can do this, you will need to set up the environment by performing tasks normally performed by an integration developer—such as installing the database and configuring mapping between the Vocabulary and the database. Don’t worry, we will walk you through all the steps to set up the environment.