One of the primary use cases for the SAP Cloud Platform is extending commercial applications – whether on-premise or cloud – providing a platform to create business process or organisation specific functions alongside a core application. This approach requires a development environment to create the extension and a way to connect to the applications being extended. September 2018 saw the full release of two new services on the SAP Cloud Platform: SAP Cloud Platform ABAP Environment to help organisations with established SAP development teams create extensions and SAP Cloud Platform Open Connectors to ease extending non-SAP solutions.

SAP Cloud Platform from the start had open standard development containers in the shape of the Java service, which was followed by JavaScript and then the open flexibility to choose a language via CloudFoundry. Given this existing flexibility – why add a further, propriety language in ABAP? The key reason is SAP want customers to move from SAP ECC on-premise to SAP S/4HANA on cloud.

Mark Williment

Mark Williment

Head of Technology

SAP Cloud Platform ABAP Environment

Many long-term SAP customers have large, established ABAP development groups, who can assist with this move. SAP S/4HANA implements industry best practice processes and an ideal model is that organisations adopt these, rather than creating specific processes via custom development. This differs somewhat from what happened in on-premise ECC, where many organisations have accumulated custom code in ECC over many years.

A typical migration from ECC to SAP S/4HANA involves a large element of business change – adapting the business to the industry best practice processes in SAP S/4HANA. However, for most organisations, there will be a tail of functions unique to their business that require development. The model with S/4HANA is to build integrated extensions, not customise S/4HANA (indeed it’s not possible with public cloud models).

SAP Cloud Platform is SAP’s preferred place to create and run these extensions, and building them has always been, and remains, possible in Java on SAP Cloud Platform. So where does the ABAP Environment come in? For many organisations, the move to S/4HANA will be non-trivial, and making the most of established skills and knowledge in an organisation will help with its success.

When it comes to creating extensions that are specific to an organisation – the developers who understand the very organisation specific processes that are candidates for extensions are often in those well-established ABAP development teams. Therefore, the ABAP Environment allows them to bring that knowledge to a S/4HANA migration without at the same time learning a new programming language.

What the SAP Cloud Platform ABAP Environment is definitely not – is a container to drop all a companies existing on-premise custom ABAP into. Firstly, it breaks the model of adopting and using as much “standard” as possible in S/4HANA – more pragmatically, the SAP Cloud Platform ABAP Environment presents a cut-down ABAP API, that can interface to S/4HANA via APIS. For example, direct file system or UI control is not allowed.

The focus is to use the ABAP RESTFul programming model to create a service tier for Fiori apps. It does not replace the existing languages available on the SAP Cloud Platform, they remain and should continue to be the default where there is not a need to leverage existing ABAP skills or code. There’s a very good FAQ from SAP that addresses these in more detail.

SAP Cloud Platform – Open Connectors

A long established use case for the SAP Cloud Platform has been extending the SuccessFactors Software as a Service (SaaS) product. To support this – SAP provides a rich API into SuccessFactors and standard authentication methods. Loosely coupled apps are created on the SAP Cloud Platform that interacts with SuccessFactors via these APIs.

Increasingly organisations use a rich set of SaaS products, from multiple vendors, most of whom offer APIs. Therefore, a similar approach can be taken to extend any SaaS product – create an app on SAP Cloud Platform then utilise the data and services in the SaaS via API. But this requires developers to understand the APIs, data models and security models of each SAP.

What SAP Cloud Platform Open Connectors do is provide a mapping layer that standardises models across different products, so developers can understand one model and utilise multiple SaaS products, even creating extensions that span them. For example, there are connectors to Outlook, multiple CRM, multiple commerce, and multiple marketing solutions – you can quickly see how an extension that provides one user interface that combines communication, customer transaction data, and customer marketing data might be useful.

There are two markets for this product – development teams working on extensions specifically for an organisation that matches that organisation’s landscape of SaaS products. The second is companies offering extension solutions in the SAP App Center – where these use external, non-SAP services, which can be developed against the Open Connector model – and then easily fitted to multiple customer environments.