SAP Custom Applications
SAP out of the box covers most business processes — but every organisation has requirements the standard system does not reach. Custom applications built on SAP's technology stack close these gaps without compromising the core, breaking upgrade paths or creating unsupportable workarounds. 2iSolutions builds custom SAP applications — from classic ABAP and Fiori extensions to cloud-native CAP applications on BTP and proprietary products that run across industry sectors.
The custom application landscape — six capability domains
Every custom SAP application sits in one of six capability domains — each with its own development paradigm, deployment target and extension model. Choosing the right domain for a requirement is the first architectural decision; choosing the wrong one creates maintenance debt.
Six custom application domains — what we build in each
Each domain has a different development paradigm, runtime target and maintenance model. The right domain choice depends on whether Clean Core is required, how tightly the extension must couple to the SAP core and whether the application will run on-premise or in the cloud.
ABAP Custom Development
Classic and object-oriented ABAP — reports, function modules, BAPIs, BADIs, enhancement spots and user exits. The foundation of every S/4HANA on-premise and private cloud extension and the deepest integration layer available.
- Custom reports, ALV grids, smart forms
- BADIs and enhancement spot implementations
- Object-oriented ABAP design patterns
- Performance-optimised ABAP for HANA
SAP Fiori & UI5 Applications
Custom Fiori applications built on SAPUI5 — from extending standard Fiori apps to building new transactional and analytical apps for processes that have no standard Fiori equivalent. Mobile-ready, role-based and integrated with SAP Launchpad.
- Custom freestyle UI5 applications
- Fiori Elements — OData-driven rapid development
- Standard Fiori app extensions (adaptation)
- SAP Launchpad integration and tile configuration
CAP & RAP Applications on BTP
Cloud Application Programming (CAP) model on BTP for side-by-side extensions — cloud-native apps that connect to S/4HANA via APIs without modifying the ABAP core. RAP (ABAP RESTful Application Programming) for ABAP-side OData services consumed by Fiori Elements.
- CAP Node.js and Java on BTP Cloud Foundry
- RAP business objects and Fiori Elements UIs
- GROW with SAP Clean Core extensions
- S/4HANA API consumption via Integration Suite
Integration Suite Development
SAP Integration Suite iFlow development — connecting SAP to external systems (banks, GSTN, logistics partners, e-commerce platforms, CRM, custom APIs). Both real-time and batch integration patterns, with monitoring and error handling built into every interface.
- SAP Integration Suite iFlow development
- REST, SOAP, IDoc, SFTP, EDI adapters
- Bank connectivity (SBI, HDFC, ICICI format)
- e-Invoice / e-Way Bill IRP integration
Workflow & Process Automation
Custom approval workflows, business rules and process automation — on SAP Business Workflow (ABAP-based) for on-premise, and SAP Build Process Automation on BTP for cloud deployments. Replacing email-based approvals with traceable, SLA-governed automated processes.
- Multi-level approval workflow design
- SAP Business Workflow (ABAP) development
- SAP Build Process Automation (BTP)
- Condition-based business rules engine
Embedded Analytics & Custom Reports
CDS view development for embedded Fiori analytical apps, AMDP for HANA-native calculations, custom SAP Analytics Cloud stories on live S/4HANA data and output management — Adobe Forms, SmartForms and SAPScript for regulatory and business documents.
- CDS views — Fiori analytical apps
- AMDP — HANA-native calculations in ABAP
- SAC stories on live S/4HANA data
- Adobe Forms, SmartForms, output types
Four products built on SAP BTP — available to 2iSolutions clients
Beyond bespoke client development, 2iSolutions has built four proprietary applications on SAP BTP — addressing industry-specific gaps that S/4HANA standard does not cover out of the box. These are production applications running in live client landscapes, maintained and enhanced by the team that built them.
DealerConnect
A dealer and channel partner management portal built on SAP BTP — providing dealers, distributors and channel partners with a self-service portal for order placement, scheme tracking, statement views and claim submission, connected to S/4HANA in real time.
- Dealer order placement with real-time S/4HANA stock visibility
- Scheme and trade promotion visibility per dealer
- Dealer statement — outstanding, credits, claims
- Claim submission and status tracking
- Mobile-ready — field sales and dealer access on smartphone
ShopConnect
A shop floor MES (Manufacturing Execution System) application on SAP BTP — connecting production operators to S/4HANA PP production orders, capturing real-time confirmations, quality results and material consumption directly from the shop floor without a full SAP GUI session.
- Production order confirmation — operation by operation
- Material consumption recording at the production line
- Quality inspection result capture — GR / usage decision
- Shop floor work queue — priority ordered by production plan
- Barcode / QR scan integration for material identification
SupplierConnect
A supplier collaboration portal on SAP BTP — giving suppliers a self-service interface to view and confirm purchase orders, submit ASNs, upload invoices and track payment status against their deliveries, all connected live to S/4HANA Procurement.
- PO acknowledgement and delivery date confirmation
- ASN (Advance Shipment Notice) submission
- Invoice upload against confirmed GR
- Payment status and outstanding statement view
- Vendor performance scorecard — delivery, quality, compliance
ServiceConnect
A post-sale service and warranty management application on SAP BTP — managing service requests, warranty claims, service centre assignment, spare part logistics and customer communication from the point of sale complaint through to resolution and cost recovery.
- Customer service request logging with product serial number
- Warranty eligibility check against S/4HANA sales history
- Service centre assignment and technician scheduling
- Spare part request against S/4HANA MM stock
- Warranty claim cost recovery — credit note generation
Tools and platforms — what we build with
SAP custom development has evolved from a single ABAP IDE to a multi-platform engineering environment. Every layer has a specific role; choosing the wrong layer for a requirement creates maintenance overhead and upgrade risk.
Clean Core and the extension model: For GROW with SAP (public cloud), SAP enforces Clean Core — all extensions must be built via APIs on BTP, not by modifying ABAP directly. For S/4HANA on-premise or private cloud, ABAP modification is technically available but we follow Clean Core principles by default — using BADIs and enhancement spots, not core modifications — to keep upgrade paths clean and support costs manageable.
How we scope, build and deliver custom applications
Custom development without a specification is custom guesswork. Our five-phase delivery model — from requirement to production release — treats every custom application as a mini-project with its own quality gates.
Requirement
Functional spec — exact business requirement, SAP standard gap confirmed, extension point identified
Design
Technical design — domain selected (ABAP/CAP/Fiori), data model, API design, UI wireframes for end-user apps
Build
Development in DEV landscape — unit tested by developer, code review by senior developer before QA transport
UAT
User acceptance testing in QA — business user tests against spec, defects tracked, sign-off required before production
Deploy & Document
Production transport, user training if needed, technical documentation updated, change recorded for future upgrade review
What we document for every custom object
- Business requirement and gap analysis
- Technical specification — design decisions documented
- Extension point used and why (BADI / API / CAP)
- Affected standard SAP objects and tables
- Known upgrade impact — actions at next SPS or version upgrade
- Test cases — scenarios used in UAT
Custom code quality standards we apply
- ABAP Test Cockpit — clean check on every object
- No ABAP core modifications — BADIs and enhancement spots only
- SELECT-optimised for HANA — no table scans in custom code
- No hardcoded system parameters — configurable via Customising
- Error handling — no silent failure in custom programmes
- Naming conventions — Z/Y namespace, documented prefix
What makes our custom development practice effective
Functional Understanding Before Code
Custom development without functional understanding produces technically correct programmes that solve the wrong problem. Every custom application engagement begins with a functional consultant confirming the business requirement, verifying that SAP standard does not already cover it and documenting the gap that the development will address. Code written against a confirmed gap does not need to be re-done when the business realises mid-build that standard SAP does it differently.
Clean Core — Upgrade-Safe Extensions
Custom ABAP that modifies standard SAP objects breaks at the next support package or version upgrade — requiring rework with every SAP update. Our development standards mandate BADIs, enhancement spots and SAP-published APIs as the extension mechanism — never direct modification of standard code. The result: custom code that survives upgrades without rework, and a custom code register that accurately predicts upgrade impact before every SPS.
HANA-Optimised ABAP
ABAP written for a traditional database is frequently the source of performance issues after migration to HANA — not because HANA is slow, but because HANA requires different query patterns. Row-by-row processing in ABAP loops, nested selects and ABAP-layer aggregation are performance anti-patterns on HANA. Our ABAP development uses set-based operations, HANA push-down via AMDP and CDS views — the same optimisation approaches we apply to SAP performance engagements.
Four Proprietary Products — Proof of Capability
DealerConnect, ShopConnect, SupplierConnect and ServiceConnect are not prototypes or demo applications — they are production systems running in live client landscapes, maintained and enhanced by the team that built them. The same team that builds a client's custom Fiori portal has built and is operating a dealer portal used by thousands of dealers in a live production environment. This is a different depth of custom application capability than a development practice without live proprietary products in production.
Managed Under AMS — Not Abandoned Post-Delivery
Custom applications delivered and then abandoned create maintenance problems when SAP is upgraded, when business requirements change and when bugs surface in edge cases that testing did not cover. All custom development delivered by 2iSolutions is managed under our AMS practice — the same team that built the application monitors it, maintains it through SAP upgrades and enhances it as business requirements evolve. The development team does not leave after go-live.
Full-Stack Team — One Engagement
A complex custom application typically spans ABAP backend, OData service, Fiori UI and Integration Suite connectivity — multiple technical domains that are usually separate teams in large system integrators. Our full-stack SAP development team covers all domains in a single engagement — the ABAP developer who designed the backend service and the UI5 developer who built the front end are the same team, communicating internally rather than across separate vendor contracts.
SAP custom applications from a Gold Partner with 21 years of ABAP depth and four live proprietary products
ABAP, Fiori/UI5, CAP on BTP, Integration Suite and workflow — custom applications built on every layer of the SAP technology stack, maintained through upgrades and operated under our AMS practice.
SAP custom applications: frequently asked questions
Common questions from development leads and IT managers evaluating custom SAP application scope.
Custom development is justified when: the business requirement cannot be met by SAP standard configuration (not just by a different configuration approach the team is unfamiliar with); the gap is business-critical and cannot be managed via a manual workaround; or the volume of transactions makes a manual workaround operationally infeasible. Before approving custom development, we confirm that SAP standard — configured correctly — does not already cover the requirement. The most common cause of unnecessary custom development is configuring SAP to match legacy system behaviour rather than learning how SAP standard addresses the same business need. Custom development is appropriate for genuine process gaps; it is expensive and maintenance-intensive when used to replicate legacy habits.
ABAP development runs inside the SAP ABAP application server — it has direct access to all SAP data and business logic, is the most powerful extension mechanism and is appropriate for S/4HANA on-premise and private cloud deployments. CAP (Cloud Application Programming model) on BTP runs in the cloud — it connects to S/4HANA via published APIs, is the mandatory approach for GROW with SAP (Clean Core enforcement) and is preferable when the extension needs to run independently of S/4HANA upgrades or when it needs to connect to multiple systems. The RAP (ABAP RESTful Application Programming) model is a middle ground — ABAP development that follows Clean Core principles, producing OData services consumed by Fiori Elements. Most complex custom applications use all three layers: ABAP or RAP for the backend, Fiori/UI5 for the front end, and Integration Suite for connecting to external systems.
Custom ABAP that uses BADIs, enhancement spots and published SAP APIs — never modifying standard SAP objects directly — survives upgrades without code changes in the vast majority of cases. SAP guarantees the stability of BADI interfaces and published APIs across versions. Direct modification of SAP standard objects (using correction instructions or core modifications) requires manual rework at every upgrade because SAP cannot guarantee the modification survives. Our custom code register documents every custom object, the extension mechanism used and the upgrade impact category — so when an S/4HANA version upgrade is planned, we can predict which custom objects need review before the upgrade runs, rather than discovering issues during the upgrade execution.
Yes — our proprietary BTP products (DealerConnect, ShopConnect, SupplierConnect, ServiceConnect) are designed to integrate with any S/4HANA or ECC landscape via SAP Integration Suite APIs. They do not require a greenfield implementation or a RISE deployment. Integration is via published S/4HANA APIs for procurement, sales, production and service processes — the same APIs available in all current S/4HANA releases and, via BAPI adapters, in ECC 6.0 landscapes. A deployment engagement covers BTP provisioning, API integration to your S/4HANA, user configuration and UAT. The products are maintained and updated by 2iSolutions; clients receive updates on a subscription basis without re-engaging a development team.
GROW with SAP enforces Clean Core — custom extensions cannot be deployed in the S/4HANA Cloud ABAP core. Custom Fiori applications for GROW deployments are built on BTP using CAP (backend) and SAPUI5 (front end), consuming S/4HANA Cloud APIs via Integration Suite. The application runs on BTP; S/4HANA handles data and business logic through its published API surface. For standard Fiori app extensions (adapting existing Fiori apps rather than building new ones), SAP Fiori Adaptation Project tooling supports key-user extensibility within the Clean Core boundary — adding fields, hiding elements and changing labels without code. Complex Fiori customisations that go beyond key-user extensibility are built as new CAP-based apps on BTP, not as modifications to the standard Fiori apps in the cloud system.
Every custom development request is scoped from a written functional specification — a document that describes exactly what the programme must do, what inputs it takes, what outputs it produces and what edge cases must be handled. We do not estimate from a verbal description; verbal descriptions produce estimates that are wrong in proportion to how much the developer's understanding differs from the requester's intent. The functional specification is reviewed by both the functional consultant (confirming the business requirement) and the technical developer (confirming it is implementable and the approach). The estimate covers development hours, unit testing, code review, QA transport and UAT support — not just the coding hours. Estimates are fixed-scope, not time-and-materials where possible; where scope cannot be fixed (research-intensive or technically uncertain requirements), we define a time-boxed investigation phase before committing the full estimate.
Have a custom SAP application requirement — or want to explore DealerConnect, ShopConnect, SupplierConnect or ServiceConnect?
A scoping conversation confirms whether the requirement is a configuration gap or a genuine development need, which SAP development domain is the right fit and what a realistic estimate looks like. For proprietary products, a demonstration can be arranged with your own S/4HANA test data.