ABAP Development Tools (ADT) provides you with various checks for your CDS models.
Some of these checks are performed automatically when opening a CDS model for display purposes in the CDS editor, when maintaining and activating a CDS model, or on request when triggering them explicitly.
Syntax checks of the ADT editor are executed on the most current model; that is, they consider the latest information, which you’ve just entered. However, most of the checks are performed on the persisted or activated state of the CDS models only. Thus, you have to be aware that the displayed check results might relate to an outdated state.
In general, the findings identified by the checks can have different effects. The results of the checks may indicate severe problems that lead to functional issues at runtime or even to problems that prevent the successful activation of your CDS models. However, the check results may also only indicate potential issues and serve information purposes only.
In the following sections, we’ll show you some findings reported by the CDS parser, which you may be confronted with, and we’ll also present some framework-specific checks.
Syntax Checks
First, let’s create a new CDS view called Z_ViewWithProblemsA. Enter the data as given here.
@EndUserText.label: 'View with Problems - Very Long Label Text'
define view entity Z_ViewWithProblemsA
as select distinct from t000
{
key mandt as KeyField,
'A' as FieldA
}
Immediately after the data is entered, you’ll notice a syntax warning, as shown in this figure.
The syntax warning is displayed at various places in the ADT environment. In the CDS editor, you find the problematic area being highlighted by different means: icons and are displayed on the outermost left and right side of the ADT editor indicating the location of the problem within the source code. In addition, the syntax element, which the finding belongs to, is underlined. A textual description is displayed if you position your cursor on top of this highlighted section or on one of the icons. Furthermore, the Problems tab shows the finding too. Its Resource column provides you with the information about the object, which the message refers to. In our example, this is our CDS view Z_ViewWithProblemsA.
The warning message tells you that you entered a label text that exceeds the predefined limit of 40 characters. This might result in problems for translation, for which some additional space should be reserved. Note that the maximum technical length of the label text annotation @EndUserText. label specified in the annotation definition is 60 characters. Thus, you could ignore this warning because it doesn’t have any direct impact on the activation and functionality of the CDS view itself. Nevertheless, we’ll shorten the label text to View with Problems. After the CDS view definition has been changed, the warning disappears.
Now, add the three annotations @ObjectModel.dataCategory:#CUBE, @Object- Model.representativeKey:'KeyField', and @MyAnnotation.mySubAnnotation: true to CDS view Z_ViewWithProblemsA in accordance with lines 2, 6, and 7 shown in this figure.
Immediately after your input, the CDS editor shows you that the newly added annotations are incorrect by coloring them red. Like in the previous example, the applied check is performed based on the metadata specified in the annotation definitions.
The first error that is signaled results from using enumeration value CUBE, which isn’t specified for annotation @ObjectModel.dataCategory. The second issue is caused by using annotation @ObjectModel.representativeKey on the field level; that is, the annotation is used outside of its permitted scope of application. Finally, the third error results from using annotation @MyAnnotation. mySubAnnotation, which is considered incorrect because it’s not specified in any annotation definition.
Use CDS Editor’s Code Completion Function: The code completion functionality of the CDS editor, which you can trigger by pressing Ctrl + Space, evaluates the CDS annotation definitions. You should use this functionality for avoiding errors resulting from the usage of undefined and unsupported annotation names and values.
Ignore these error messages, and try to activate the CDS view. A modal window appears, informing you that the activation was aborted with errors. As you can see in the next figure, the Problems tab also displays the corresponding error message: DDLS… was not activated. A similar message Activation failed … is displayed in the status line of the ADT environment.
The root cause for an activation problem is often not as obvious as in the presented sample. Instead, more information may be required to locate and finally fix the corresponding issues. In such cases, you should evaluate the activation log. You can open this log by clicking Open ABAP Log in the popup displayed in this figure.
The above figure gives an overview of the result of the activation attempt.
Position your cursor on the See log link to access the details of the activation log. Now press the Ctrl key, and simultaneously click on the link with your mouse. A detailed view of the activation log is displayed.
In this activation log, search for entries that are marked as error. To do this, choose the Show Search Toolbar icon for displaying the search row. In the Find field, enter “error”, as shown in the previous figure. In the illustrated sample, you find the same error messages that were already displayed in the Problems tab shown earlier.
Now, remove the three erroneous annotations from CDS view Z_ViewWith- ProblemsA.
Consistency Checks of Frameworks
Now that we’ve looked at some generic checks implemented by the CDS infrastructure, let’s take a closer look at framework-specific checks. To trigger these checks, activate CDS view Z_ViewWithProblemsA. This results in the finding are presented in this figure.
The displayed information message is generated by the Access Control Management component, as visible in the message text. Note that this message doesn’t affect the activation of the CDS model. Nevertheless, if such a finding is reported for your CDS model, you should check if a CDS access control is missing for avoiding security issues. If no authorization control is actually required at the instance level, you should annotate your CDS view with @AccessControl.authorizationCheck: #NOT_REQUIRED for documenting your decision explicitly.
Activation of CDS Models: The activation of CDS models can only be aborted by checks that are implemented by the ABAP Data Dictionary. Checks that are implemented by frameworks can’t prevent the activation of CDS models. As a result, when activating a CDS model, inconsistencies may arise in the functionality provided by the various frameworks and their derived secondary artifacts. You should therefore always check the problem messages that are raised during the activation of the CDS models and correct their root causes if necessary.
In our case, we annotate CDS view Z_ViewWithProblemsA according to this listing.
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'View with Problems'
define view entity Z_ViewWithProblemsA
as select distinct from t000
{
key mandt as KeyField,
'A' as FieldA
}
After reactivation, the previous finding vanishes.
Replace value #NOT_REQUIRED of annotation @AccessControl.authorization-Check with #CHECK. Upon activation of the CDS view, a warning as shown appears.
The displayed warning informs you that, unlike documented, there is no Example analysis CDS access control for the CDS view. As a result, the current version of CDS view Z_ViewWithProblemsA behaves in the same way as the previous versions; that is, runtime accesses aren’t subject to any instance restrictions.
Set value of annotation @AccessControl.authorizationCheck to #MANDATORY. After activation, you observe the warning illustrated in this figure.
As described by the message text, any data selection from updated CDS view Z_ViewWithProblemsA will result in runtime errors. You can validate this behavior by launching the Data Preview view either via the context menu or by pressing F8. Afterwards, the error from this figure will show up.
Now, restore the consistent state. Annotate the CDS view Z_ViewWithProblemsA with @Analytics.query:true. According to its formal specification, the annotation is used correctly. Therefore, there is no indication for a modeling error right after the annotation was entered in the CDS editor. However, if you now activate the CDS view, you receive error messages in the Problems tab, as shown in this figure.
The illustrated error messages are raised when the annotated CDS model is analyzed by the analytic engine. This is indicated by their addition [Analytics]. Despite these problems, the CDS model has been activated successfully. Consequently, the CDS view can still be used as a data source in ABAP and view building. However, it can’t be used as an analytical query. Therefore, you should remove annotation @Analytics.query:true from CDS view Z_ViewWithProblemsA.
Correct Annotation Errors: Often, incorrect annotations are ignored by the ABAP infrastructure and frameworks. Therefore, you can successfully activate the discussed CDS view and use it for runtime accesses. However, we strongly recommend that you investigate and correct these annotation errors. In this context, you should check whether the corresponding annotations can be omitted or have to be replaced by other annotations. Sometimes it may even be required to change the implemented CDS view logic for realizing the desired functionality.
In addition to the checks of annotations discussed previously, there are also consistency checks for other aspects of the CDS models implemented by the various frameworks. These checks behave in principle in the same way. Therefore, we won’t discuss the corresponding examples here.
If you want to trigger the checks of the ADT editor explicitly, you can click Trigger checks on the Check ABAP Development Object icon below the main menu or press Ctrl + F2.
Severity of Problems: The discussed examples illustrate that the severity of the message (error, warning, or information) doesn’t necessarily correspond to the severity of the problem and the urgency of correction. Therefore, you should always consider warnings and information messages as well when analyzing and troubleshooting problems. However, there are also warnings and information messages that you can’t correct. These messages typically indicate potential issues that you should be informed about, but they might not affect your application and therefore might be ignored. For some of these findings, a pseudo-comment exists (as indicated by the detailed message), which you can set for suppressing the corresponding message.
Editor’s note: This post has been adapted from a section of the book Core Data Services for ABAP by Renzo Colle, Ralf Dentzer, and Jan Hrastnik.
Comments