Custom applications on the ABAP Platform
Some requirements are not an add-on to the standard but an application in their own right. The question is then not whether, but where: inside the ABAP stack, where data, authorisations and operations already exist — or beside it on SAP BTP.
When the application has to sit close to the SAP data
There are line-of-business applications that are not part of the SAP standard yet would be pointless without SAP data: approval processes referencing documents, case-based applications, special calculations, planning or capture tools. For those, the SAP ABAP Platform deserves a look — the technical basis your SAP system runs on anyway.
The reason is unspectacular but economic: a scalable application server, a well-thought-out authorisation and security concept, transport management, client separation, logging and operations are already there and maintained regardless. Build a separate platform next to it and you pay for all of that a second time — including the interface back to the very data the application is about.
Technically we build with the RESTful Application Programming Model (RAP), CDS views as the data model and Fiori Elements as the user interface. Where existing applications run, we keep supporting the classic technologies too — Web Dynpro and BSP do not disappear just because they are out of the spotlight. For business rules we use BRFplus, for process flows the workflow engine, and for case-based scenarios folder management.
The honest boundary belongs here as well: not everything belongs in the ABAP stack. Where an application mostly holds its own data, relies on external services or is meant to stay independent of SAP release cycles, the route via SAP BTP is the cleaner answer — clean core, in other words. We take that decision with you before the first line of code.
At a glance
- Standalone business applications instead of modification
- RAP, CDS views & Fiori Elements
- Workflow, ad-hoc workflow & folder management
- BRFplus for business rules without coding
- Authorisation and security concept from the start
- Own registered CaRD namespace
What the platform brings
Why building inside the stack often adds up.
- Scalable application server for enterprise and web applications
- Authorisation and security concept already in place
- Transport management, client separation, logging
- Direct access to business data without an interface
- Operations, monitoring and backup are running anyway
What we build with
Current technologies — and the existing ones where they are in use.
- RESTful Application Programming Model (RAP)
- CDS views as the data model, embedded analytics
- SAP Fiori / Fiori Elements as the interface
- ABAP-OO as the foundation
- Web Dynpro and BSP for existing applications
Processes & rules
What a business application needs besides screens and tables.
- Workflow and ad-hoc workflow
- BRFplus for business rules via customising
- Folder management for case-based applications
- Status and authorisation control
- Connection to archiving and document management
When better not
The honest counter-check before building.
- Mostly own data with little SAP reference
- Strong dependency on external services
- Independence from SAP release cycles required
- Then: side-by-side on SAP BTP
- Clean core remains the guideline either way
Approach
From the requirement to an application ready for operation.
- Clarify requirements and data dependency
- Decide ABAP stack or BTP — with reasons
- Design data model, authorisations and process flow
- Implementation with reviews, documentation and tests
- Handover to your team, or maintenance by us
Frequently asked questions
How does this differ from your SAP development?
The SAP Development page is about enhancements on and around the SAP standard: reports, enhancements, interfaces, small tools. This page is about standalone business applications with their own data model and user interface running on the platform — a different cut, the same developers.
Is this not the opposite of clean core?
No — clean core means not modifying the SAP standard, not refraining from building in the stack at all. A standalone application in its own namespace changes no standard code and stays upgradeable. What matters is the clean separation, not the location.
When do you recommend SAP BTP instead?
When the application mostly holds its own data, depends heavily on external services, or is deliberately meant to stay independent of SAP release cycles. Then the side-by-side approach on BTP is the cleaner and, long term, cheaper choice.
Can we continue developing the application ourselves later?
Yes, that is explicitly intended. We develop in our own namespace, document the data model and logic and hand over to your team. Whether you continue yourselves or leave maintenance to us is your decision.
Does this match your project?
Talk directly to our consultants — no detours.