FAB (Fiori App Builder) standards / conventions / best practice guide

We suggest the following conventions / standards when working in FAB:

ABAP Code

For naming standards and conventions in ABAP, please navigate here.

Data model - naming fields

We recommend different naming strategies for naming data model fields, depending on the source/target of the data field in question.

1. When using an OData Service, we recommend matching the name and case of data model field to that of the corresponding field in the OData Service.
2. When using ABAP fields (imported from an SAP Function Module / Screen / BDC / Structure or Table) we recommend matching the name of the data model field to the name in the corresponding SAP source / target field. We recommend keeping the name in UPPER CASE.
3. When defining these during development, we recommend capitalising the first letter of every word - something like:
   MyDataFieldName.

Data model - description fields

We often have two fields where the first field contains a code and the second field (used as a label, description or tool-tip, for example) contains the name / description for the code contained in the first field. To avoid variation (Name vs Description vs Desc vs Descr vs Text vs Xxxx) we recommend always using 'Name'. Therefore:

1. In most instances, we recommend that the two fields should be named the same, but the description field has the word 'Name' appended to the end. For example:

   1. CostCenter and CostCenterName

   2. ControllingArea and ControllingAreaName
      
      

2. In instances where a field is named XxxCode or YyyKey (or similar) we recommend dropping the 'Code' or 'Key' and replacing it with 'Name' for the description field, for example:

   1. CompanyCode and CompanyName

   2. CurrencyKey and CurrencyName
      
      Exception: where the word 'Key' is part of the name, as opposed to simply indication that the field contains a code/key, it may remain part of the description field name:

   3. PostingKey and PostingKeyName

Data model - explicit typing

It is important to remember that the data model is the 'area of exchange' through which data is effectively passed from the front-end to the back-end, and vice versa. During this process, conversion takes place between the data as it is declared in the front-end and the equivalent data as it is declared in the back-end (in ABAP).

Creating your data model field with the correct types ensures that FAB can create the fields correctly for use in both JavaScript and ABAP.

To avoid conversion issues (especially with numbers and dates) where we then have to manually handle conversions in ABAP or JavaScript, we recommend that all fields should be typed explicitly with both ABAP and Javascript types, whenever possible.

The exception to this is where the field should be declared as a text-type field in both the front- and back-end. In this instance, FAB will assume both to be text in the absence of explicit typing.

Component / Element ID - naming 

Please remember that components / elements in your project do not always have to be named explicitly - if no ID is assigned, FAB will assign one at run-time. Where you do want to name these (for readability, for example, or to be able to refer to the component in code) we recommend a flexible approach, using a simple set of rules to determine a 2- or 3-character prefix:

1. Where the component name consists of a single word, use the first 3 characters, all lowercase, as the prefix. Examples:
   Button - but
   Select - sel
   Input - inp
   Panel - pan
   Slider - sli
   :
2. Where the component name consists of a two (2) or three (3) words, use the first character of every word, all lowercase, as the prefix. Examples:
   Grid Table - gt
   Date Picker - dp
   Date Time Picker - dtp
   Upload Collection - uc
   Radio Button - rb
   Object Page Section - ops
   :
3. In the unlikely event that there are clashes between ID's created with this standard, or where the name of he component consists of 4 words, you may consider adding a 4th character to avoid ambiguity. Example:
   Object Page SubSection - opss

Using the above rules to create a prefix and combining it with a descriptive name for a field one will be able to understand, at a glance, what type of component is represented by an ID. For example:

• inpCompanyCode represents an Input field for a Company Code, but
• selCompanyCode represent a Select (dropdown) where a Company Code can be selected from a list.