Event information

• Location: ReCAP 2021, online
• Date: 19.10.2019
• Site: Event website 🔗
• Title: CAP outside SAP
• Presentation: PDF 🔗

Additional information

• CAP is open in terms of its architecture. It can run on any platform that meets the runtime requirements like Node.js. For the database, an open source driver cds-pg is available. This allows to run CAP apps with Postgres as a database.
• At customers, the view on CAP is focused on SAP centric solutions. This is simply because that’s how it is positioned by SAP. Cost associated with SAP and CAP are therefore higher compared to solutions using e.g. Java and CosmosDB as companies can easily reuse the existing knowledge. CDS knowledge is what you use inside an SAP bubble. It cannot be reused for non-SAP projects.
• CAP comes with a large enterprise ready feature list. Draft enabling, authentication, extensions, etc is what CAP offers on a level you expect when you extend your business processes with it. That level what other tools rarely offer.
• Being able to use CAP for non-SAP projects is a win-win situation. Developers can reuse their skills for other projects, and those projects benefit from the enterprise level of CAP. The resilient problem is the BTP focus that SAP enforces. This makes it rather difficult to use CAP for non-SAP projects.
• Companies employ several professional No-sayers: architects, POs/PMs. Their job is it ensure nothing that is not meeting the IT requirements is selected. In its current state, to those people, CAP is not meeting a lot of those requirements: database support, runtime, security
• This talk is about putting some of those bias to rest. Database support is not only SAP database, but Postgres too. Runtime is not limited to BTP and CloudFoundry. CAP runs nicely on Kubernetes and OpenShift. Security is not limited to CF integration, adaptors for Azure AD or any OpenID Connect can be used. These features can be combined to run CAP on OpenShift with OIDC protected API with a Postgres HA cluster. Or use the Azure Postgres service 🔗.
• A sample process for requesting a company car is used to show that CAP offers benefit even when the process is not using SAP. There is no SAP ERP system involved. CAP is deployed on OpenShift with Postgres in a HA cluster to show that non SAP databases can be used. And finally, for authentication, Auth0 and OIDC for calling a secured API. These scenarios show that the main pain points raised by architecture used to block CAP are wrong. CAP can be used for these solutions. The limitation is not CAP, it is the wrong perception that it only works in a strict SAP centric environment.