Learn, Practice, and Improve with SAP C_FIORD_2502 Practice Test Questions

Explanation:

In SAPUI5, a view controller follows a defined lifecycle that determines when specific hook methods are called. These lifecycle events allow developers to execute logic at key moments during the creation, rendering, and destruction of a view.

Two valid lifecycle events of an SAPUI5 view controller are onAfterRendering and onExit.

onAfterRendering is called after the view has been rendered and added to the DOM. It is commonly used to access DOM elements, adjust UI behavior, or integrate third-party libraries that require rendered HTML elements.

onExit is triggered when the controller is destroyed, such as during navigation away from the view or application shutdown. It is used to clean up resources, detach event handlers, and avoid memory leaks.

These methods are part of the standard controller lifecycle defined by SAPUI5 and are automatically invoked by the framework when applicable.

❌ Why the Other Options Are Not Correct

A. onbeforeEntry
This is not a standard SAPUI5 controller lifecycle method. Similar-sounding methods exist in SAP Fiori Elements or routing-related hooks, but not in a plain SAPUI5 controller.

B. onRendering
There is no lifecycle method named onRendering in SAPUI5 controllers. The correct method is onAfterRendering.

References
SAPUI5 Documentation – Controller Lifecycle
SAP Help Portal – SAPUI5 Controller Hooks

Explanation:

In SAP Fiori Launchpad, tile types have distinct data source behaviors:

Dynamic Tiles (B) are the only tiles that use a live OData service call to retrieve and update their properties (like title, subtitle, numeric value, etc.) at runtime. They are bound to a data source defined in the catalog.

Semi-Dynamic Tiles (A) have a static configuration but can display a notification (number) fetched from an OData service. Their title and other core properties remain static and are configured in the catalog, not set via OData.

Static Tiles (C) have all properties (title, subtitle, icon) defined statically in the catalog or target mapping. No data service is involved.
Therefore, only Dynamic Tiles use an OData service to set their title and other dynamic properties.

Reference:
SAP Fiori Launchpad documentation for "Tile Types" and "Configuring Dynamic Tiles." The data source configuration for dynamic tiles specifically requires an OData service and a data binding path for properties.

Explanation:

The manifest.json file is the mandatory descriptor file for every SAP Fiori elements application (and SAPUI5 apps in general). It serves as the central configuration file where you define:

Application metadata (ID, version, title, etc.)
Routing and targets (pages, floorplans like List Report/Object Page)
Models (OData service bindings)
SAP Fiori elements-specific settings (e.g., sap.fe section for controls, annotations, table settings, header info, actions)
UI5 dependencies, resources, and launchpad tile configurations
Without manifest.json, the SAP Fiori elements runtime cannot interpret or render the application correctly.

Why the other options are incorrect:

A. package.json
→ This is a Node.js/npm file used for project dependencies, scripts, and build tools (e.g., in SAP Business Application Studio or BAS projects). It is present in modern Fiori projects but not required for configuring the Fiori elements app logic or runtime behavior.

C. settings.json
→ This does not exist as a standard configuration file in SAP Fiori elements or SAPUI5 applications. (It might appear in VS Code workspaces or unrelated tools, but irrelevant here.)

D. config.xml
→ This is used in Cordova/PhoneGap hybrid mobile apps (for app metadata like icons, splash screens). SAP Fiori elements apps are web-based (HTML5) and do not use or require config.xml.

Final rule (short): For SAP Fiori elements apps, manifest.json is the single most important configuration file — all floorplan-specific adaptations, extensions, and runtime settings are done here.

References

SAPUI5 SDK – Manifest (Descriptor for Applications):
→ "The existence of the manifest.json file must be declared... It contains, for example, the app ID, the version, the data sources used..."

Explanation:

The Logic: Ordering by Position SAP Fiori Elements uses the position property within the annotation to determine the visual sequence of elements from left to right (or top to bottom). Even though the code is written with Price (position 30) before Status (position 20), the framework sorts these numerically during metadata interpretation.

10: ProductName (1st Column)
20: Status (2nd Column)
30: Price (3rd Column)

Why it's B and not C:
The framework does not render fields in the order they appear in the DDL (Data Definition Language) source code; it strictly follows the numerical value assigned to position. Therefore, Status (20) will always jump ahead of Price (30).

Why the others are incorrect:

A (Three fields in a form):
Forms are controlled by the @UI.identification or @UI.fieldGroup annotations. @UI.lineItem is specifically for tables/lists.

C (ProductName, Price, Status):
This ignores the numerical logic of the position attribute and assumes the framework follows the line-by-line order of the code.

D (ProductName only):
All three fields have the @UI.lineItem annotation, so all three will be rendered as columns.

Key Takeaway
Whenever you see @UI.lineItem, think Table Columns. Whenever you see position, remember that lower numbers appear first, regardless of where they are written in the ABAP CDS view.

Explanation:

SAP Fiori applications are designed to be extended in a stable and upgrade-safe manner. SAP provides several supported extension mechanisms that allow customers and partners to adapt standard apps without modifying the original source code.

Creating an adaptation project (Option A)
is a recommended way to extend SAP Fiori apps using SAPUI5 flexibility services. Adaptation projects allow developers to adjust UI behavior, add logic, or adapt metadata while keeping changes separate from the original application. This ensures compatibility during upgrades.

Adding custom view content in a predefined extension point (Option D)
is a standard and widely used extension mechanism in SAPUI5 and SAP Fiori elements. Extension points are explicitly provided by SAP to allow customers to insert custom UI controls or fragments into existing views safely.

Modifying the properties of the view control (Option E)
is also supported through UI adaptation, controller extensions, or flexibility changes. This includes changing visibility, labels, or other properties of controls without altering the original app code.

❌ Why the Other Options Are Not Correct

B. Modify the runtime libraries that are to be loaded
Changing SAPUI5 runtime libraries is not supported and can break the application or future upgrades.

C. Modify the data model to merge data at runtime
Directly modifying the data model at runtime is not a standard or supported extension mechanism in SAP Fiori apps. Data enhancements should be done via backend services or annotations.

References
SAP Help Portal – Extending SAP Fiori Apps
SAPUI5 Documentation – Extension Points

Explanation:

SAP provides specific, supported extension mechanisms for SAP Fiori elements to add custom logic without modifying the standard framework.

B (Use building blocks):
Building blocks are reusable, declarative UI components (like FilterBar, Chart, Table) that can be embedded in a custom page to enrich a Fiori elements app with custom views while maintaining integration.

C (Create apps using the custom page template):
The SAP Fiori tools application generator offers a "Custom Page" template. This creates a freestyle SAPUI5 view and controller within a Fiori elements app, allowing maximum flexibility for scenarios not covered by standard templates.

D (Use controller extensions):
This is the primary method for adding custom controller logic to a standard Fiori elements page (List Report, Object Page). You create an extension file to hook into predefined extension points (e.g., onInit, onBeforeSave) to modify standard behavior.

A is incorrect:
Creating new templates is not a supported customization path. The standard templates (List Report, Object Page, etc.) are fixed. Customization is done within these templates via extensions, not by creating new ones.

E is incorrect:
Using private methods of SAP Fiori elements is strictly forbidden. Private APIs are not stable and can change without notice, breaking your app. Only public, documented extension APIs should be used.

Reference: SAP Fiori elements documentation for "Extension Points" (controller extensions), "Building Blocks", and "Custom Pages". The guidance explicitly warns against using private APIs and directs developers to these supported extension techniques.

Explanation:

Modeling an Fiori Launchpad role follows a mandatory sequence to establish access and structure:

Create Tiles and Target Mappings (D) - Mandatory. Defines the launchable apps (tiles) and their backend connections (target mappings).

Create Catalog (A) - Mandatory. A collection of these tiles that can be assigned to roles.

Assign Catalog to Role (C) - Mandatory. Grants users of the role the authorization to see the catalog's content.

Create Group and Assign Tile (B) - Optional. Groups organize tiles on the user's launchpad home page for usability. Users can also personalize their own view, making this an optional administrative configuration step.

Reference:
SAP Fiori Launchpad configuration guide for role design. The documentation lists the sequence for role modeling, where catalogs and target mappings are mandatory for providing access, while groups are a layout convenience.