Defining the Restaurant, Dish, and Order records

The expanded data model for the application was described at a high level previously. Click on it to enlarge.

As you go into the Records tab of BMC Helix Innovation Studio, and begin building this out, you will need to set certain properties of the record and its fields.  For this project, the properties that will matter are:

• Field Type (specified when you create a new Field)
• Field Name
• Record and field Permissions (roles, not groups)  - assuming you chose to define them earlier:
  • Order Submitter role permission (View and Change)
  • Restaurant Manager role permission  (View and Change)
• Is the field Required?
• Default Value
• Other type-specific constraints.

Most of these are set using the Properties inspector after selecting a field.

Rather than a step-by-step guide to setting these, the desired property values are described in the following tables.The method of setting these is the same as in the first exercise of the tutorial, so you can reference that if you don't know where to start, or consult Creating-the-definitions-for-a-tailorable-Digital-Service-application.

Person

This is the easiest one - it already is defined in the Foundation. You can use it like other Record Definitions.  One thing to keep in mind whenever trying to select Person as a record definition - remember that because this is not defined within your application, you will have to find it under All Records, or the easiest way, by using the search feature of the Record Definition Name pickers in BMC Helix Innovation Studio.

Restaurant

Create the new record definition. Using the record's Properties inspector, set the Permissions list to allow access to the Manage Restaurants and Order Submitter Roles.

Another property to consider here is Should Export Data.  If you turn this on, your data will be exported and included in any install package later on, which is useful if you want Restaurant data to pre-loaded when the package is deployed (usually this is only used for configuration data but this choice is yours).

Here is what it looks like to set the permissions for the record:

Here is an example of setting permissions for a field:

Now, go ahead and set up the fields for Restaurant, following this summary of property values for each one. Some things to note:

• In some cases, the field is "Core" (always there) and doesn't need to be created.
• We will be re-naming the Description field to be used as the Name field required by the data model. The Description field is always present in every Record Definition in BMC Helix Platform, and it is a good idea to find a meaningful use for it, as some human readable (but not necessarily unique) description of each Record Instance.
• You can assign field ID from the range allocated when you signed up for your instance, or let the system generate unique IDs for you.

Dish

Again, create this record definition, and using the record's Properties inspector, set the permission list to allow access to the Restaurant Manager and Order Submitter permission roles. Also, again note that we are renaming the core field Description as Name.

If you are a developer accustomed to building database applications, as you examine this list, you may be feeling that something is missing.  We know that a requirement has been stated that each Dish belongs to exactly one Restaurant.  In a database application, you would probably need to create a "foreign key field" to track that relationship.  With BMC Helix Platform, the ability to define and work with Associations is a built-in feature that should be mostly transparent to you. We will soon get to define these associations, but for now, the important thing to notice is that we don’t ask you as the developer to create and manage key fields.  You should only create fields that represent “attributes” of the record at hand.

Order

As part of the earlier exercise, you already created the Order record definition. With the expanded requirements, we will need to add more fields and make sure their properties are correct.

Set the permission roles for the Order record to allow access to the Restaurant Managers and Order Submitter roles. Note that, at the field level, the permissions are somewhat opposite to Restaurant and Dish, because an Order Submitter (like Maria) works primary on Order while managers work mostly on Restaurant and Dish. You will have to look at each field on a case-by-case basis, however.

For the fields, note that what we created earlier was insufficient for our User Stories so we will adding additional fields now.

As we have seen from the earlier analysis, much of the business logic for this application will revolve around the lifecycle of every order. We can track this in different ways, but for this application, we will keep it simple and continue to use the Status field of the Order. At this point Status should have two options: Submitted and Delivered. We need to track additional states now, including the ability to represent an Order that has been cancelled.  Set the Options accordingly.

Challenge

• Add some additional fields to these records and consider how you might expose them in your UI
• Consider performance of lookups. What indexes might help based on the search patterns you expect?  For example, a UI may be frequently retrieving all the Order records submitted by the current user that are in Delivered state; also Restaurant and Dish both have a Name field that will frequently be searched and sorted. Create the relevant indexes.

What we learned

We have now created the records part of the data model. What's new here is:

• Setting role permissions for records and fields
• Thinking through the lifecycle needs of a record
• Configuring the Display ID format for readability
• Other properties, such as Min, Max, Length, and Default Value
  
  

Now we must define the associations between the records, as this is where much of the behavior of both the business logic, and the UI, will come into play.