Checking the Semantic Key
As shown in the figure, in an RAP data model, the key of a database table is often made up of the client field and a UUID field, whose value is assigned automatically by the RAP runtime when you create a new instance of the business object. This field combination is sufficient to ensure that the system can identify each record in the table uniquely. However, as well as this technical key, each object also has a semantic key - in this case the combination of airline and flight number, which must also be unique according to the business logic. In order to ensure the uniqueness of this field combination, you must implement your own check in the form of a validation.
You declare validations in the behavior definition of the CDS view entity, and implement them in the behavior implementation class.
Input Checks in the App
As well as checking the semantic key, there are other checks that you need to perform. For example, although the generated app allows you to create, read, update and delete data, it does not yet contain any consistency checks. Consequently, you can create flight connections for airlines that don't exist, or where the departure and destination airports are the same.
To prevent this from happening, you define further validations in the behavior definition, and implement them in the behavior implementation class.
Creating Message Texts
Before you create the validation, you must create the texts that you want to display. You do this using a message class. A message class is a collection of up to 1000 messages that belong to a particular application area. As shown in the figure, each text has a number which identifies the message uniquely within the message class.
To create a new message class, choose File → New → Other… and type message into the filter field. Double-click the Message Class entry in the hit list, then enter a package, name, and description for the new message class. Choose Next.
Assign the message class to a transport request and choose Finish.
Messages can also contain placeholders, which are replaced with concrete values when the message is displayed. Placeholders are denoted by the ampersand symbol followed by a number. You can use up to four placeholders in each message.
Defining the Validation
To define a validation, you add a validation declaration to the behavior definition of your business object. In this example, the validation should be performed whenever the user saves a data record, and this could be either when they create the record or if they subsequently change it.
When you define the validation in the behavior definition, a warning tells you that the corresponding method does not exist. Use a quick fix (key combination Ctrl + 1) to add the method to the behavior implementation. The behavior implementation is a local class within your behavior pool. The method definition contains the addition FOR VALIDATE ON SAVE, which identifies it as the implementation of the validation. It has an importing parameter KEYS. This is an internal table containing the keys of the created or changed objects. You use these to read the actual data that the user has entered.
The addition FOR Connection~CheckSemanticKey links the method with the validation CheckSemanticKey from the behavior definition. Here, Connection is the alias name of the view entity Z_I_CONNECTION.