SAP Fiori elements Feature Showcase

This project serves as a demonstration repository for features available in the List Report and Object Page floorplans using SAP Fiori elements for OData V4.

Key areas covered include:

List Report Features

• General Features: Draft configuration, replacing standard UI texts, custom actions, and default sorting/filtering.
• Header Area: Variant management, Live Mode, and advanced filter definitions (e.g., mandatory fields, semantic dates, value helps, and dependent filtering).
• Content Area: Table configurations (types, actions, side effects, CRUD restrictions), multiple views (single/multiple table modes), and various UI enhancements (rating indicators, progress indicators, micro charts, and quick views).

Object Page Features

• General Features: Data field annotations (communication, time/date, multi-line text) and custom actions.
• Header Area: Title/Subtitle configuration, custom actions, and diverse header facets (Address, Data Points, and various Micro Charts).
• Content Area: Form configurations (connected fields, custom content), table enhancements (variant management, personalization, inline creation), and custom sections/subsections.
• Footer Bar: Action determination and custom actions.

A UI.SelectionPresentationVariant combines a selection (filtering) with a presentation (sorting and visualization). It is similar to a SelectionVariant but includes PresentationVariant properties.

• SelectionVariant: Defines the filtering logic.
• PresentationVariant: Defines SortOrder and Visualizations (e.g., which @UI.LineItem to use).
• You can refer to specialized @UI.LineItem collections by using a qualifier in the Visualizations array.

annotate srv.RootEntities with @(
    UI.SelectionPresentationVariant #SelectionPresentationVariant : {
        Text : '{i18n>SelectionPresentationVariant}',
        SelectionVariant : {
            $Type : 'UI.SelectionVariantType',
            SelectOptions : [
                {
                    PropertyName : criticality_code,
                    Ranges : [
                        {
                            Sign : #I,
                            Option : #GT,
                            Low : 0,
                        },
                    ],
                },
            ],
        },
        PresentationVariant :{
            SortOrder : [
                {
                    Property : fieldWithPrice,
                    Descending : false,
                },
            ],
            Visualizations : [
                '@UI.LineItem#simplified',
            ],
        },
    },
);

You can create dependent filters where the options in a value help are restricted by another selected value (e.g., selecting a Country filters the available Regions).

Implementation Patterns:

• Using ValueListParameterIn: Maps a local property (like country_code on the header) to a property in the value help collection. This acts as an input parameter to filter the target collection.
• Using ValueListParameterConstant: Statically filters the value help by a fixed value (e.g., always filtering by country_code = 'DE').
• Multi-Input/Parent Entity Reference: For multi-input fields, you can reference properties from the parent entity in the LocalDataProperty of a ValueListParameterIn parameter.

annotate schema.RootEntities with{
    ...
    region @(Common : {
        Text            : region.name,
        TextArrangement : #TextFirst,
        ValueListWithFixedValues: true,
        ValueList       : {
            Label          : '{i18n>Region}',
            CollectionPath : 'Regions',
            Parameters     : [
                {
                    $Type             : 'Common.ValueListParameterInOut',
                    ValueListProperty : 'code',
                    LocalDataProperty : region_code
                },
                {
                    $Type             : 'Common.ValueListParameterOut',
                    ValueListProperty : 'name',
                    LocalDataProperty : region.name,
                },
                {
                    $Type : 'Common.ValueListParameterFilterOnly',
                    ValueListProperty : 'country_code',
                },
                {
                    $Type : 'Common.ValueListParameterIn',
                    LocalDataProperty : country_code,
                    ValueListProperty : 'country_code',
                },
            ]
        }
    });
});

Object Page sections and subsections can have toggleable side content defined via XML fragments in manifest.json.

Configuration:

• template: The namespace and name of the XML fragment.
• equalSplit: If true, the screen splits 1:1. If false or undefined, the split is 2:1 (favoring the original content).

Triggering Side Content: Use the this.base.getExtensionAPI().showSideContent("[side-content-key]") function within a controller extension or custom action to toggle the visibility. You can also pass a second boolean parameter to set visibility directly instead of toggling.

"customSectionQualifier": {
    "sideContent": {
        "template": "sap.fe.showcase.lrop.ext.SideContent",
        "equalSplit": true
    }
}

// In a Controller Extension
toggleSideContent(oBindingContext: ODataContextBinding) {
    this.base.getExtensionAPI().showSideContent("customSectionQualifier");
}

To add a subpage, you must configure two parts in manifest.json:

1. Routing: Add a new route with a pattern matching the child entity navigation and a name.
2. Targets: Define a target of type Component using the sap.fe.templates.ObjectPage template, specifying the entitySet in its settings.
3. Navigation: In the parent entity's controlConfiguration, map the child entity attribute to the new route name.

// 1. Route
"routes": [
    {
        "pattern": "RootEntities({key})/ChildEntities1({key2}):?query:",
        "name": "childEntities1ObjectPage",
        "target": "childEntities1ObjectPage"
    }
],
// 2. Target
"targets": {
    "childEntities1ObjectPage": {
        "type": "Component",
        "id": "childEntities1ObjectPage",
        "name": "sap.fe.templates.ObjectPage",
        "options": {
            "settings": {
                "entitySet": "ChildEntities1"
            }
        }
    }
}
// 3. Navigation Mapping
"navigation": {
    "childEntities1": {
        "detail": {
            "route": "childEntities1ObjectPage"
        }
    }
}

To display parent-child hierarchies using a TreeTable, you must perform three steps:

1. Manifest Configuration: Set the table type to TreeTable and provide a hierarchyQualifier in manifest.json.
2. CDS Annotation: Define the hierarchy using @Aggregation.RecursiveHierarchy. The hierarchyQualifier in the manifest must match the qualifier used here. The ParentNavigationProperty must point back to the same entity.
3. CAP Requirements: Add specific hierarchy properties (like LimitedDescendantCount, DistanceFromRoot, etc.) to your entity and ensure they are queryable in the database. These properties should be marked as non-filterable and non-sortable via Capabilities annotations.

// 1. Define the hierarchy in CDS
annotate srv.OrganizationalUnits @Aggregation.RecursiveHierarchy #OrgUnitsHierarchy : {
  ParentNavigationProperty : superOrdinateOrgUnit,
  NodeProperty             : ID,
};

// 2. Add required properties for Fiori elements
extend srv.OrganizationalUnits with @(
  Hierarchy.RecursiveHierarchy #OrgUnitsHierarchy : {
    LimitedDescendantCount : LimitedDescendantCount,
    DistanceFromRoot       : DistanceFromRoot,
    DrillState             : DrillState,
    LimitedRank            : LimitedRank
  },
  Capabilities.FilterRestrictions.NonFilterableProperties: [
    'LimitedDescendantCount', 'DistanceFromRoot', 'DrillState', 'LimitedRank'
  ],
  Capabilities.SortRestrictions.NonSortableProperties    : [
    'LimitedDescendantCount', 'DistanceFromRoot', 'DrillState', 'LimitedRank'
  ],
) columns {
  null as LimitedDescendantCount : Int16,
  null as DistanceFromRoot       : Int16,
  null as DrillState             : String,
  null as LimitedRank            : Int16,
};

Multiple table mode uses an icon tab bar above the table to switch between views. Each tab represents a distinct view with its own table, toolbar, and variant management.

Key Characteristics:

• Each view must have a unique key in manifest.json.
• You can use @UI.SelectionPresentationVariant to control presentation.
• You can display a different entity set in a tab by providing an entitySet property in the manifest.json path entry. When using a different entity set, counts are shown automatically, ignoring the showCounts setting. Filters from the main entity set are applied to the other entity set if the properties exist.
• Interaction with Single Table Mode: If you use a SelectionVariant in multiple table mode, you can still apply single table mode views. However, if you use a UI.SelectionPresentationVariant, you cannot apply single table mode views.

"RootEntityListReport": {
    "options": {
        "settings": {
            "views": {
                "paths": [
                    {
                        "key": "tab1",
                        "annotationPath": "com.sap.vocabularies.UI.v1.SelectionVariant#variant1"
                    },
                    {
                        "key": "tab2",
                        "annotationPath": "com.sap.vocabularies.UI.v1.SelectionPresentationVariant#SelectionPresentationVariant"
                    },
                    {
                        "key": "tab3",
                        "entitySet": "OrganizationalUnits",
                        "annotationPath": "com.sap.vocabularies.UI.v1.SelectionVariant#activeOrgUnits"
                    }
                ],
                "showCounts": false
            }
        }
    }
}