SAPUI5 Engineering

SAP UI5 Development Services

SAPUI5 is the JavaScript framework underneath every SAP Fiori app. When a requirement outgrows what annotations can express, you need engineers who know the framework itself — its MVC structure, its models, its routing, its lifecycle and its testing tools.

CssInfotech builds custom SAPUI5 and OpenUI5 applications, extends standard SAP apps without breaking upgradeability, and modernises ageing UI5 projects onto current UI5 Tooling and TypeScript.

MVC + XML viewsMaintainable, testable structure
OData & JSON modelsTwo-way binding done properly
OPA5 + QUnitAutomated UI regression tests
UI5 ToolingModern build and CI pipelines

SAPUI5, OpenUI5 and Fiori — How They Relate

These three terms get used interchangeably, and that confusion causes real scoping mistakes. Here is the distinction we work from.

SAPUI5 is the framework

SAPUI5 is a JavaScript UI framework with an MVC architecture, a large library of enterprise controls, built-in data binding to OData and JSON sources, internationalisation, accessibility and theming. It is shipped and supported by SAP as part of your SAP licence.

OpenUI5 is the open-source core

OpenUI5 is the Apache-licensed open-source version of the same framework. It lacks a handful of SAP-specific libraries — notably the smart and analytical controls — but is otherwise identical. It is the right choice for non-SAP applications that need to look and behave like your SAP landscape.

Fiori is the design system

SAP Fiori is the set of design guidelines, floorplans and interaction patterns. You implement Fiori using SAPUI5. An app can be built in SAPUI5 and still be poor Fiori if it ignores the guidelines — which is exactly what we see in a lot of inherited codebases.

Our SAPUI5 Development Services

Whether you need one complex screen or a long-term development team, our UI5 work is engineered to be maintained by someone other than the person who wrote it.

Custom UI5 Applications

Freestyle apps where standard floorplans do not fit the process.

  • Clean MVC structure with XML views and typed controllers
  • Flexible Column Layout, wizards, planning grids, dashboards
  • Routing and deep linking with proper browser history support
  • Component-based architecture ready for launchpad embedding

Custom Controls & Libraries

Reusable building blocks that keep your app portfolio consistent.

  • Custom controls extending sap.ui.core.Control
  • Shared UI5 reuse libraries distributed across projects
  • Chart and visualisation integration
  • Corporate theming via the UI Theme Designer

Data Binding & OData

Most UI5 performance complaints trace back to model handling.

  • OData V2 and V4 model configuration and batching
  • JSON, Resource and local models for offline-friendly state
  • Expand, filter and paging strategy for large datasets
  • Draft handling and optimistic concurrency

Extending Standard SAP Apps

Change SAP apps without forking them.

  • Adaptation projects and UI5 flexibility (key user adaptation)
  • Controller and view extensions on standard apps
  • Fiori elements extension points and custom sections
  • Upgrade-safe extension patterns documented for your team

Testing & Quality

UI5 has excellent test tooling. Very few projects use it.

  • QUnit unit tests for controllers, models and formatters
  • OPA5 integration journeys covering real user flows
  • Mock server setup so tests run without a backend
  • ESLint, code review standards and CI integration

UI5 Modernisation & Upgrades

Bring legacy UI5 projects back onto a supported footing.

  • Migration from deprecated APIs and legacy bootstrap
  • Grunt / SAP Web IDE projects moved to UI5 Tooling (ui5-cli)
  • TypeScript adoption for large or long-lived codebases
  • UI5 version upgrade impact assessment and remediation

Key Features of the UI5 Apps We Build

These are engineering standards on every UI5 engagement, not optional extras we quote separately.

  • Responsive by construction — built on the UI5 device model, tested on real hardware
  • Internationalised from day one — all text in i18n property files, never hard-coded
  • Accessible — keyboard navigation, ARIA roles and screen reader labels
  • Launchpad-ready — packaged as components that deploy to any launchpad host
  • Test-covered — QUnit and OPA5 suites that run in your build pipeline
  • Version controlled — Git or abapGit with reviewable, documented commits
  • Performance budgeted — bootstrap, payload and render times measured, not assumed
  • Documented — architecture notes and handover material your team can act on

Our UI5 Development Process

Short iterations with a working app in front of business users early, because UI requirements are almost never right on the first description.

  1. Requirement & UX workshopWe map the user task, the data behind it and the interaction pattern, then agree whether this is a freestyle build or an extension of something standard.
  2. Architecture & scaffoldingProject generated with Fiori tools, folder structure, models, routing, i18n and test harness set up before feature work begins.
  3. Iterative buildTwo-week sprints against a mock server first, so UI progress is never blocked by backend availability.
  4. Backend integrationReal OData services wired in, batching and paging tuned, error handling and draft behaviour hardened.
  5. Test & reviewQUnit and OPA5 suites, cross-browser and real-device checks, plus a code review against our UI5 standards.
  6. Deploy & hand overDeployment to the ABAP repository or Cloud Foundry, launchpad registration, and a documented handover with architecture notes.

Our UI5 Technology Stack

We work with the current SAP-recommended toolchain, and we are comfortable maintaining older projects while we migrate them onto it.

Framework & language

  • SAPUI5
  • OpenUI5
  • JavaScript (ES6+)
  • TypeScript for UI5
  • XML views
  • Fiori Elements
  • Smart controls
  • sap.m / sap.ui.table / sap.f

Build, test & tooling

  • UI5 Tooling (ui5-cli)
  • SAP Fiori Tools
  • SAP Business Application Studio
  • VS Code
  • QUnit
  • OPA5
  • Karma
  • ESLint
  • Git / abapGit

Backend & deployment

  • OData V2 / V4
  • ABAP RAP
  • CAP
  • SAP Gateway
  • Cloud Foundry
  • MTA deployment
  • SAP Build Work Zone
  • BTP Destination service

Why Clients Choose Our UI5 Team

UI5 is a web framework. Teams that treat it as "SAP screens" produce code that nobody can maintain. We approach it as serious frontend engineering.

1

Frontend engineering rigour

Structured MVC, separated concerns, formatter and model unit tests, linting and code review. The result is a codebase your own developers can pick up.

2

We write the tests

OPA5 journeys covering your critical user flows mean the next UI5 version upgrade is a build run, not a manual regression marathon.

3

Extension over modification

We extend standard SAP apps through supported flexibility mechanisms rather than copying them, which is what keeps you upgradeable.

4

Honest build-versus-standard advice

If a Fiori elements app with annotations will do the job, we say so — even though a freestyle build would bill more hours.

5

Rescue and remediation experience

A good share of our UI5 work is fixing inherited projects. We are used to reading undocumented code and stabilising it without a full rewrite.

6

Flexible engagement

Fixed-scope projects, dedicated developers embedded in your team, or a retained bucket of hours for enhancements and fixes.

SAPUI5 Development FAQs

What is the difference between SAPUI5 and OpenUI5?

OpenUI5 is the open-source Apache-licensed core of the framework; SAPUI5 is the commercial distribution that adds SAP-specific libraries such as the smart controls, analytical table and Fiori elements. If you are building on SAP data inside your SAP landscape, use SAPUI5 — you are already licensed for it. OpenUI5 makes sense for standalone apps outside the SAP estate.

Can SAPUI5 apps consume non-SAP APIs?

Yes. UI5 has a JSON model and standard AJAX support, so any REST API works. In practice we route external calls through an SAP BTP destination or the Cloud Connector so credentials never sit in frontend code and CORS is handled server-side.

Do you use TypeScript for UI5?

For large or long-lived applications, yes. SAP ships official type definitions and TypeScript catches a whole category of binding and API errors at build time. For a small single-purpose app the setup overhead is usually not worth it, and we will say so.

How do we keep custom UI5 apps working after a UI5 version upgrade?

Three things: avoid deprecated and private APIs, keep an OPA5 test suite that exercises real user journeys, and pin your UI5 version explicitly rather than tracking the latest release. We set all three up as part of a build engagement.

Can you work alongside our in-house SAP team?

That is our most common arrangement. We typically own the frontend and OData layer while your ABAP team owns backend business logic, working from a shared service contract agreed up front. We can also embed developers directly into your sprints.

Our previous UI5 app is slow. Can that be fixed without a rewrite?

Usually, yes. In most cases the cause is over-fetching in the OData model — missing batching, unbounded expands, or no paging — rather than the UI code. We start with a short performance audit that identifies the actual bottleneck before proposing any work.

Related SAP Services

UI5 development sits next to these services in most of our engagements.

Need SAPUI5 Engineers Who Write Maintainable Code?

Send us your requirement or point us at an existing UI5 project. We will come back with a technical assessment, an approach and a realistic estimate — no obligation.