Transactional Apps

An SAP Fiori app is transactional when its main purpose is to change business data: create a document, edit it, run an action such as release or reject, and save the result in the backend. Reading data is part of the job, but the app exists to complete a task.

SAP's early SAP Fiori documentation described three application types: transactional apps, analytical apps and fact sheets. In SAP S/4HANA, the fact sheet role is largely taken over by object pages, and the SAP Fiori Apps Reference Library now labels that type "SAP Fiori - Object page / Fact sheet". The classification describes what an app does, not how it is built: a transactional app can be an SAP Fiori elements app or a freestyle SAPUI5 app. An app is transactional because it lets a user finish a business task, not because of the technology behind it.

A typical transactional app in SAP S/4HANA runs through these steps:

1. The user opens the app from a tile or link; the SAP Fiori Launchpad resolves the intent to the app.
2. The app loads the list or object through an OData service.
3. When the user starts editing, many current apps create a draft, so work in progress is saved without posting.
4. On save or on an action such as approve, the OData service calls the backend business logic, which runs checks, authorization and posting.
5. The document status changes in the system of record, and follow-on processes, such as a flexible workflow, can start.

For new development, SAP positions the ABAP RESTful application programming model as the way to build and extend transactional SAP Fiori apps. Older apps use earlier Gateway-based models. Whatever the model, a transactional app is a front end to backend business logic, which is where the rules actually live.

The SAP Fiori Apps Reference Library is the main lookup tool. A practical sequence:

1. Search by business task or by the SAP GUI transaction you want to replace.
2. Filter the application type to "SAP Fiori - Transactional".
3. Check the product version: an app available in the current SAP S/4HANA Cloud release may not exist in an older on-premise release.
4. Read the implementation information: required OData services, business catalogs and business roles.
5. Check the UI technology label, which distinguishes SAP Fiori elements apps from other SAPUI5 apps.

Labels are not exclusive. The Procurement Overview Page (F1990), for example, is classified as both transactional and analytical. For transactional apps, the app type is a useful first filter, not a full description of what an app does.

• SAP S/4HANA Cloud Public Edition: SAP delivers and updates the apps with each cloud release. Customers make them available through business roles and extend them with key-user tools or developer extensibility; changing SAP code is not an option.
• Private Edition and on-premise: the customer activates the apps, their OData services and their launchpad content, and controls when new app versions arrive through upgrades. Classic modifications remain technically possible but work against the clean core approach.
• Database: in SAP S/4HANA every app runs on SAP HANA. In the older SAP Business Suite, transactional apps could run on other databases, while analytical apps and fact sheets required SAP HANA.

Example: Alder Manufacturing on Private Edition must activate the services behind Manage Purchase Orders before buyers can use the tile; a Public Edition customer only assigns the business role. The transactional app is the same concept in every edition; who activates and changes it is what differs.

1. Assuming a standard app covers the whole SAP GUI transaction. Many apps focus on the most common steps. Compare fields and actions against how users actually work before switching them over.
2. Granting the tile but not the backend authorization. Users then see the app but cannot save. Check both launchpad content and backend roles.
3. Checking the app name but not the release. App versions and features differ between releases and editions.
4. Ignoring app successors. Some apps exist in several versions, such as Manage Purchase Orders (Version 2); scope the current one.
5. Treating one app as the whole process. A transactional app completes one task on one business object; the steps before and after it belong to other apps, workflows or people.

Most problems with transactional apps come from scoping and authorization, not from the apps themselves.