Web App Bridge: A different approach for SAP CCO Plugin Development
As a developer of SAP Customer Checkout plugins since 2019 - having built dozens of them, both for and with customers - I have noticed one challenge over and over again: implementing complex workflows on the POS, especially when integrating third-party systems and APIs. After years of working around it, I think I finally have a clean answer: embed a standard Single Page Application directly inside a CCO plugin, talk to the POS over a postMessage bridge, and ship the whole thing as a single offline-capable JAR.
Here's how I got there.
SAP CCO is quite flexible in this area, for example with the existing reusable components, layouts, and the use of GENERIC_POPUP or GENERIC_INPUT. It is possible to implement such plugins while maintaining the look and feel of SAP CCO, making the plugins feel like standard functionality. However, the learning curve is steep and the code can become messy over time, since the plugin interface is vanilla JavaScript without any out-of-the-box support for frameworks like Angular or React.
Sometimes look and feel is not that important to a customer, and a faster implementation of the requirement is the priority. So I asked myself: wouldn't it be great to be able to integrate a standard Single Page Application into SAP Customer Checkout? I already made attempts at this some years ago, trying to add, for example, an Angular application directly to the DOM of the UI - while this is technically possible, it turned out to be too complicated.
Not too long ago I came into contact with plugins for another vendor. They provide an interface to integrate the plugin via an iframe and/or a browser widget. This showed me that while my technical approach was wrong, the idea of integrating a Single Page Application into the POS can be a viable solution!
Integration of Single Page Applications (SPAs) with SAP CCO — the Concept
While traveling from Düsseldorf to Graz by train, I decided to use the roughly 10 hours to find out if I could make the concept work in SAP Customer Checkout.
Technical Concept
The idea is simple: we want to integrate (in this case) an Angular application into SAP Customer Checkout while keeping the original tooling and setup of that application more or less the same. We build the application with the standard tools and then pack it into a plugin for SAP CCO. Then we show it inside an iframe. This way the plugin is offline-capable, and we do not rely on remote web servers.
Communication with the POS APIs — the magic of the postMessage API
Iframes are normally isolated from the surrounding application. However, since around 2008 there has been the postMessage API, which allows for communication between frames under specific security constraints. It is old technology, but it works! We just need to expose the APIs from SAP CCO to the iframe and make them accessible via postMessage commands.
The Proof of Concept — So, does it actually work?
When I arrived back in Germany, I had a working prototype. I was able to make the plugin work while fulfilling the following requirements:
- (Almost) standard tooling and build pipeline of the Single Page Application
- Hot-reload functionality for development
- Access to the SAP CCO APIs, such as the eventBus and the stores (e.g. the ReceiptStore)
- Ability to access remote APIs from inside the SPA
- Ability to use the on-screen keyboard from CCO
- Showing the iframe of the application on the Quick Selection and also as a popup
From the SPA developer's point of view, talking to the POS looks like any other modern async API:
const pos = new POSBridge();
await pos.ready();
// Read POS state
const receipt = await pos.getReceipt();
const locale = await pos.getLocale();
// React to POS events
pos.on('receiptChanged', (receipt) => {
console.log('Receipt updated:', receipt);
});
// Trigger POS actions
pos.pushEvent('SOME_CCO_EVENT', { /* ... */ });That's the whole interface the SPA needs to know about. Under the hood, every call is a postMessage round-trip to the CCO plugin host, which translates it into the appropriate ReceiptStore, eventBus, or store-observer call on the CCO side. The SPA stays framework-agnostic - there is nothing Angular- or React-specific here — and the plugin host stays a thin translation layer.
Potential Applications of this Approach
This approach opens up a whole new class of plugins for SAP Customer Checkout. There are many cases where the integration points to the POS are simple, and the integration does not need to be as tight as with the standard plugin approach.
I have often seen the following pattern:
This can be applicable, for example, to tax-free flows, loyalty programs, or the integration of other third-party applications such as CRM or stock management systems. Imagine a tax-free flow where the cashier scans the receipt, the SPA handles the form-filling and API calls to the tax-free provider, and only the final discount lands back in the receipt - all without having to rebuild that wizard UI in the CCO component model.
If you implement this using the approach described here, it would look like this:
What are the next steps?
I want to make this solution open source. The goal would be to have something like a library that every SAP CCO developer could pull into any SAP CCO plugin project, enabling them to easily implement plugins with their preferred Single Page Application framework. The main task of the library would be to provide wrappers for all relevant SAP CCO APIs and the build system.
What do you think?
Before I commit to building this out as a proper library, I'd love to hear from you:
- What use cases would you tackle with this approach?
- Should the wrapper be framework-agnostic, or would you want dedicated Angular/React/Vue adapters?
- If you've built a tax-free, loyalty, or CRM integration in CCO before - what tripped you up?
Drop me a message, I'd love to talk!