SAP S/4HANA. Extensibility for Customers and Partners June SAP White Paper SAP S/4HANA

Transcription

1 SAP White Paper SAP S/4HANA SAP S/4HANA Extensibility for Customers and Partners June 2015

2 Table of Contents 1. Management Summary 3 2. The Big Picture Side-by-Side Extensibility and In-App Extensibility Transition to SAP S/4HANA 9 3. Side-by-Side Extensibility SAP HANA Cloud Platform New User Interfaces and Extension Applications In-App Extensibility Key User Extensibility User Interface Extensibility Field Extensibility Table Extensibility Business Logic Extensibility Extension Lifecycle Management Lifecycle Management for Side-by-Side Extensibility Lifecycle Management for Key User Extensibility Lifecycle Management for Managed Extensibility in the Cloud Edition Lifecycle Management for Classic Extensibility Lifecycle Management Aspects of Combined Extensibility Options Combined Side-by-Side Extensibility Combined Classic Extensibility Combined Key User Extensibility Combined Managed Extensibility 29 6 Appendix: Recommendations Current Extensibility Categories Report Extensibility Forms and Template Extensibility Managed Extensibility Custom Code Enhancements in the Cloud Classic Extensibility Release Concept for APIs (Whitelisting) 23 2 / 31

3 1. Management Summary Extensibility covers a broad spectrum of topics that allows customers and partners to adapt standard business software to their business needs. It ranges from business configuration; layout adaptation of user interface (UI), forms, and reports; custom fields and logic; integration; and custom terminology and translation to customer-specific applications. Extensibility in the SAP S/4HANA suite can be categorized into two main parts: side-by-side extensibility through SAP HANA Cloud Platform, and in-app extensibility through built-in capabilities. Customers using the side-by-side extensibility approach can use SAP HANA Cloud Platform to build completely new UIs based on the SAP Fiori user experience or integrate with other cloud applications from SAP. They can also build completely new applications and business logic that natively run on the SAP HANA platform or that are loosely coupled to the ABAP programming language back end of SAP S/4HANA. In both cloud and on-premise editions, SAP S/4HANA natively embodies key user in-app extensibility tools, offering the means to change and adapt the UI layout and context, create custom fields and tables, create and extend analytical reports and forms, and change the business logic by adding business logic. For more granular and more powerful extensions in the cloud edition, SAP S/4HANA offers the customer means and processes to perform coded extensibility. This managed extensibility allows the customer to transform parts of the custom coding (written in ABAP) into the cloud while keeping the SAP software lifecycle operation processes stable. To fulfill this requirement, SAP will offer customers and partners an additional service that allows them to use an SAP-hosted development landscape to develop ABAP add-ons that provide a very high level of in-app extensibility. In addition, rules and tools guarantee a clear logical separation of customer and partner enhancements and standard objects. In the on-premise edition of SAP S/4HANA, full flexibility to ABAP through ABAP in Eclipse (a development platform) is guaranteed. This white paper describes the different customer and partner extensibility features and packaging options that will be available for the different deployment options of SAP S/4HANA and explains how they may be implemented. 3 / 31

4 2. The Big Picture Since enterprises want to achieve competitive advantage with optimized business processes, they often rely on customer-specific extensions of their enterprise software. In most cases, companies intend to: Extend the functional scope (by adding custom-specific application logic, creating new business models, integrating other solutions, and so on) Extend the individual reach (by enabling access for more internal and external users, offering mobility solutions, and so on) Both extension types may occur in parallel. For example, a call center solution with customspecific application logic and UI may be built on top of a standard enterprise resource planning (ERP) system, thereby reaching out to a larger number of employees and subcontractors. When implementing software extensions using a traditional approach, many organizations run large implementation projects with significant modifications to the standard enterprise software. At first, the high degree of flexibility may be regarded as a benefit. However, during subsequent phases of the lifecycle of the extensions, modifications may become pitfalls: Since business experts usually do not implement extensions, interaction between the line of business (LoB) and IT often works like a waterfall model for large projects (no interconnected requirements determination and implementation phase) and thus increases time to value. Large effort occurs for tests, validations, and adaptations necessary at every upgrade of the standard software to a new version due to (mostly) hidden dependencies between standard and extensions. The result is slow implementation of requirements from the LoB and delay of adoption of innovations due to the upgrade effort mentioned above. Extensions of software as a service (SaaS) face even more challenges for example, implementing and keeping cost optimization driven by highly scalable processes of data center operations. Certainly, if extensions are completely forbidden, these challenges may not be present. However, an approach without any extensions would mean abandoning an important option to create competitive advantage in a specific area which is unacceptable for successful companies. In other words, enterprises will always need a balance between standardization and differentiation. 4 / 31

5 For many years, SAP has implemented successful processes for scalable and cost-efficient extensions in all product versions. This was a major driver of the large acceptance and adoption of SAP R/3 software, the SAP ERP application, and SAP Business Suite software (for example, by using the SAP NetWeaver technology platform for on-premise extensions of SAP Business Suite). Today, this approach is taken to the next level with SAP S/4HANA: You can apply a tool-based and platform-based methodology, which is scalable for companies ranging from small startups to large enterprises and which intrinsically avoids the drawbacks mentioned above by using the following extensibility qualities: End-to-end tools: Business users, experts, and implementation consultants can easily apply changes in their area of responsibility without risk. Pace-layered IT: Custom extensions are loosely coupled with core business processes; that is, they need tight data, process, and UI integration, but the software lifecycle of extensions is decoupled from stable systems of records. The ecosystem of SAP partners: Customers get support to apply these principles and to implement differentiating solutions. In particular, partners often require a platform as a service (PaaS) for development, distribution, and maintenance of their solutions. 5 / 31

6 2.1 SIDE-BY-SIDE EXTENSIBILITY AND IN-APP EXTENSIBILITY SAP S/4HANA extensibility provides a comprehensive set of tools, platforms, and methodologies to serve the needs of customers and partners with the qualities outlined above. The following main scenarios are outlined below and summarized in Figure Side-by-side extensions based on SAP HANA Cloud Platform: Customers and partners can learn from the outside and weave external content into their solutions. SAP HANA Cloud Platform is the PaaS offering from SAP that offers the broadest end-to-end capability in the market (from SAP HANA to SAP Fiori UX) and access to the broadest set of data sources (from SAP cloud applications to social data). For example, customers or partners can integrate business processes with applications from SuccessFactors or Ariba (both SAP companies), Concur (now part of SAP), or from third parties. They can use SAP HANA Cloud Platform services (cloud portal, mobile documents, and so on) for extended reach and scope. It is also possible to enable an SAP Fiori and mobile user experience for existing solutions. Since SAP HANA Cloud Platform is a fullfledged development platform, they can even build completely new solutions with a loose coupling to SAP back-end systems. SAP HANA Cloud Platform is designed to be 100% compliant with open standards (for example, using open source software from Eclipse and Apache). When using SAP HANA Cloud Platform, you will therefore benefit from a healthy ecosystem of partners that contribute value to existing solutions and services. With this scenario, you can establish best of breed for small and large extensions. By definition, side-by-side extensions are loosely coupled with core SAP systems and therefore support a pace-layered IT. 2. In-app extensions are implemented in the same system (or software stack) as the enhanced application. We can distinguish between: a. Classic extensibility: Customers and partners can extend and even modify SAP S/4HANA software with full access to development tools such as Eclipse or ABAP Workbench (SE80). This exten sibility capability is only available in the on-premise edition of SAP S/4HANA. 6 / 31

7 b. Key user extensibility: Customers usually apply many small changes and extensions, since they want to increase user productivity or implement adaptations of the application logic without changing the major parameters of the respective business processes. In other words, these extensions add value to SAP applications and continue to rely on the full context of the standard implementations with respect to data, process, and UI levels. Frequent examples are add custom fields and tables or change/add business logic (rules, code snippets, and so on). With SAP S/4HANA, you can implement in-app extensions satisfying all extensibility qualities. In particular, end-to-end tools enable business experts to apply changes without risk, as the technical complexity is reduced to a level that corresponds to the business purpose and is stable and fault tolerant similar to standard office applications. Thanks to a strict tool-based approach, these extensions are loosely coupled with core business processes and contribute to a pace-layered IT. This scenario is applicable for the on-premise and cloud deployment options. c. Managed extensibility: In addition to using the key user and side-by-side extensibility capabilities available in all cloud edition deployment models, customers and partners may have a strong need for coded extensibility for SAP S/4HANA, cloud enterprise edition, from within the context of the application. These types of managed extensions have a focus on tight integration with the ABAP-based SAP S/4HANA standard applications and thus are written in ABAP. To fulfill this requirement, SAP will offer customers and partners an additional service to use an SAPhosted development landscape to develop ABAP add-ons that allow a very high level of in-app extensibility, but with a restricted scope so that the operation of the add-ons do not break the cloud operations concept. For example, modifications of SAP objects are forbidden, and access to SAP objects will be allowed only through released whitelisted application program interfaces (APIs) so that the custom and partner code will be lifecycle stable. 7 / 31

8 Figure 1: Overview of the Extensibility Capabilities of SAP S/4HANA for Each Scenario SAP S/4HANA In-app extensibility: Context-aware extensions, focus on tight integration + Side-by-side extensibility with SAP HANA Cloud Platform: Learn from the outside, weave external content into your solutions Other cloud solutions from SAP Third party Key user extensibility Custom fields and tables Analytics and forms extensibility Change or add business rules and business logic (cloud ABAP Web editor) Managed Designed with ABAP programming language to be cloud lifecycle-stable Classic Full access to ABAP (for example, SE80) $ Extensibility based on SAP HANA Cloud Platform Enable an SAP Fiori and mobile user experience Integrate with other cloud solutions (for example, from SuccessFactors and Ariba, both SAP companies) and third-party solutions Take advantage of application services for SAP HANA Cloud Platform (cloud portal, mobile documents, output management, and so on) Use a full-fledged development platform to build extension applications (Java, SAP HANA native development) On premise Cloud $ Paid service in cloud enterprise edition Together, in-app and side-by-side extensibility scenarios offer a successful methodology. Note that they are complementary approaches intended for different use cases and should be considered as enablers to generate competitive advantage in the market. Customers immediately benefit from both scenarios. They can extend their reach and beat the competition by creating a difference with optimized business processes, quicker time to value with faster innovation cycles, and higher flexibility. Partners also win when they use SAP S/4HANA extensibility. They can build a compelling portfolio with the extended scope and reach of SAP S/4HANA. They achieve a high degree of flexibility through open standards and public APIs and benefit from flexible deployment options and investment protection for existing partner solutions. This is especially beneficial since SAP S/4HANA supports a smooth transition from on-premise to cloud computing. Finally, partners can approach a large customer base, since almost all SAP customers create customspecific extensions. 8 / 31

9 2.2 TRANSITION TO SAP S/4HANA Figure 2 shows the transition of a customer system from the solution as it is today to the cloud and on-premise editions of SAP S/4HANA. In the cloud edition, existing extensions have to be reimplemented, either with the key user extensibility or managed extensibility in-app extensibility capabilities described below, or side-by-side using SAP HANA Cloud Platform. Access to SAP objects is possible through public APIs only. In the on-premise edition, customers can also use these capabilities, but they still have the freedom to create development objects using the classic development capabilities of the ABAP platform. The motivation for pushing extensions into key user extensibility, managed extensibility, or side-by-side on SAP HANA Cloud Platform is the reduced cost of operations for the customer, in particular the reduced cost of applying SAP software updates (see also next sections). Figure 2: Extensibility Capabilities of SAP S/4HANA for Each Edition in Detail SAP Business Suite SAP S/4HANA In-app extensibility Classic customer and partner development Cloud editions User interface Application Database Extensions Modifications Key user extensibility Managed extensibility (Paid service in cloud enterprise edition) Classic extensibility On premise $ User interface Application Database (SAP HANA ) User interface Application Database (SAP HANA) APP UI DB Side-by-side extensibility on SAP HANA Cloud Platform Public APIs SAP Customer, partner 9 / 31

10 Customers and partners that have analyzed their products and software components according to the above-listed categories and recommendations should also take the following extensibility options assessment into consideration. Figure 3: Extensibility Options Assessment On premise Cloud editions Extensibility options Freedom Influence Scalability Classic in-app (Unicode and SAP HANA enabled code, scope not quarantined) ü û Managed in-app ( ABAP 4 Cloud, * gate check tool) lifecycle stable Key user in-app ( ABAP 4 Cloud in BAdIs, custom fields, rules, configuration) Side-by-side (SAP HANA Cloud Platform: SAP Fiori development, mobile, cloud integration, application services) $ ü ü ü ü ü ü *name TBD Options can be combined: Use in-app extensibility for new fields or tables, business logic (rules, BAdIs), reports, forms, custom code, add-ons Develop new extensions with SAP HANA Cloud Platform (for example, enable an SAP Fiori and mobile user experience or integration with a third party) 10 / 31

11 The assessment shows in general that the freedom/expressiveness, and the possibility to influence the internal process behavior of SAP S/4HANA, decreases from the on-premise edition (yellow), over the cloud enterprise edition (blue), to the cloud edition (blue). The scalability of the extensibility option increases from SAP S/4HANA, on-premise edition (yellow), over the cloud enterprise edition (blue), to the cloud edition (blue). SAP S/4HANA side-by-side extensions provide a maximum of freedom/expressiveness and are not limited regarding integration with any SAP S/4HANA deployment or in-app extensibility option. This is why side-by-side extensibility is the default and option of choice for customers and partners SAP S/4HANA extensions. But the ability to influence the internal transactional process behavior of SAP S/4HANA is limited when using side-by-side extensions. This is why SAP continues to provide a number of SAP S/4HANA in-app extensibility options. This will give customers and partners more choice to implement world-class solutions by extending SAP S/4HANA. For a detailed list of extensibility categories and related recommendations on which extensibility capability to use, refer to the section Appendix: Recommendations. 11 / 31

12 3. Side-by-Side Extensibility Side-by-side extensibility with a PaaS approach based on SAP HANA Cloud Platform has benefits and is recommended whenever customers and partners want to: Integrate SAP S/4HANA business processes with other cloud applications from SAP (for example, SuccessFactors and Ariba offerings) and with third-party applications Develop freestyle extension applications with a high degree of flexibility and using a rich set of services (for example, cloud portal or mobile documents) Design and build an SAP Fiori and mobile user experience for existing solutions (on-premise or cloud) using a browser-based tool (SAP Web IDE) Benefit from a separate software lifecycle (pace-layered IT) Business-related examples of utilizing the side-by-side benefits include: Reaching out to external users and consumers (for example, customer service portal) Enriching standard processes with before and after steps (for example, customer service) Note: As of now, triggering in SAP S/4HANA needs to be done by means of in-app extensibility Bridging applications between cloud and on premise Developing new stand-alone cloud apps 3.1 SAP HANA CLOUD PLATFORM SAP HANA Cloud Platform is SAP s in-memory platform-as-a-service offering. It enables customers, partners, and developers to build, extend, and run next-generation applications on SAP HANA in the cloud. It can be used for extensions of cloud and on-premise applications. With flexible subscription models and optional services for apps, database, and infrastructure, SAP HANA Cloud Platform provides instant access to the full power of SAP HANA. SAP HANA Cloud Platform comprises infrastructure services (for example, cloud operations, data backup, compliance, and service-level agreements [SLAs]), database services provided by SAP HANA (such as in-memory analytics, text search, planning, predictive and stored procedures), and application services (for example, cloud portal, security, document, administration, and development tools). Powerful integration services are available with SAP HANA Cloud Integration technology. SAP HANA Cloud Platform is the default choice for building an extension for any cloud solution from SAP. Developers can use Java, HTML5, or native SAP HANA extended application services combined with the underlying open API layer and powered by SAP HANA. Below you will find a complete list of services for SAP HANA Cloud Platform. 12 / 31

13 Figure 4: Services for SAP HANA Cloud Platform Develop and run New applications On-premise extensions SaaS extensions Application services Security Portal Documents Administration Integration Mobile* Tools Authentication Sites and SAP Fiori launchpad Storage Account management On premise cloud connector Mobile app lifecycle Eclipse plug-in Identity federation Password storage Policies Single sign-on Theming and branding Role-based authorization Content catalog for widgets App integration Access control Versioning Repository and folder management Metadata Members management Quota management Application management Monitoring Extract, transform, load (ETL) Process integration Destination management Device notification Discovery Offline OData Settings exchange Web IDE Software development kits Marketplace Social sign-on Templates Encryption Authorizations Usage analysis Database (DB) services SAP HANA Core DB services Stored procedures Data models Function libraries Full text search Text analytics Planning Predictive Spatial Business rules * Currently in ramp-up Infrastructure services at SAP data centers Certified operations Advanced network security SLA 99.9% Data backup Compliance Integrity Confidentiality 13 / 31

14 3.2 NEW USER INTERFACES AND EXTENSION APPLICATIONS There are two main use cases in SAP S/4HANA where the SAP HANA Cloud Platform will be used as an extension platform. 1. New and adopted user interfaces Often, customers and partners need to do significant structural adaptations to SAPdelivered SAP Fiori user interfaces, or they may even want to create completely new user interfaces on top of the released open APIs. Another important use case is custom- or partner-specific UI theming by use of the UI theme designer. SAP HANA Cloud Platform provides the relevant environment and tools for these use cases. 2. Extension applications In most cases, net-new business processes and scenarios cannot be addressed with in-app extensibility. Side-by-side extension applications are a means to allow the highest possible extension flexibility. In general, extension applications on SAP HANA Cloud Platform consist of static resources and a connection to a back-end system using Representational State Transfer (REST) based and Simple Object Access Protocol (SOAP) based Web services (on premise and on demand). The UI development toolkit for HTML5 (SAPUI5) and SAP Fiori apps with a data connection to an Open Data Protocol (OData) service exposed by the SAP S/4HANA back-end system in the cloud are examples here. To use the full business functionality coming with SAP S/4HANA, selected traditional APIs such as business application programming interfaces (BAPIs) and intermediate documents (IDocs) will be exposed as well. The set of available APIs depends on the SAP S/4HANA deployment options and the activated scope. SAP S/4HANA, on-premise edition, will provide the broadest scope, which is close to the existing SAP ERP Central Component (SAP ECC) scope. SAP S/4HANA, cloud edition, will provide an adapted scope. As of now (Q3/2015) partners or customers can use SAP HANA Cloud Platform as if they were in the classic ERP world for SAP S/4HANA, onpremise edition. They cannot yet use SAP HANA Cloud Platform to extend S/4HANA applications in the cloud editions productively, as some of the capabilities are not finished or released for general availability (for example, missing remote APIs and user or access management). SAP is working on a road map for these topics. If partners or customers want to build SAPUI5 and SAP Fiori apps on SAP HANA Cloud Platform for SAP S/4HANA, we recommend that they build custom OData services in ABAP. SAP S/4HANA integrates with SAP HANA Cloud Platform through the SAP HANA cloud connector that is already preconfigured. Also, SAP Gateway technology, used to expose OData services to SAP HANA Cloud Platform, is already installed and preconfigured in SAP S/4HANA. For complex landscapes, SAP HANA Cloud Integration offers a hub-based approach for integration of SAP and non-sap solutions. 14 / 31

15 The general process of extending SAP S/4HANA with extensions built on SAP HANA Cloud Platform is as follows: 1. Rapidly build a modern and mobile UI (like SAP Fiori, HTML5 based) on SAP HANA Cloud Platform based on the released SAP S/4HANA services (and optionally through extended in-app capabilities) 2. (Optional) Enhance the solution with advanced mobile capabilities (SAP HANA Cloud Platform mobile services) or by providing them through a portal site (cloud portal) 3. (Optional) Build new application logic on SAP HANA Cloud Platform (SAP HANA extended application services, Java) using SAP HANA Cloud Platform application services 4. (Optional) Integrate with other SAP and non-sap solutions through SAP HANA Cloud Integration 5. (Optional, recommended) Establish single sign-on and reuse users and roles from an existing identity provider 6. Roll out the newly created or enhanced functionality to the users to any device anywhere SAP HANA Cloud Platform provides a set of design time tools to support an efficient development process: 1. SAP HANA Cloud Platform cockpit The SAP HANA Cloud Platform cockpit is the central Web front end for managing all activities associated with an account and for accessing key information about extension applications (HTML5, Java, and SAP HANA extended application services). 2. SAP Web IDE (Integrated Development Environment) SAP Web IDE is a Web-based development tool designed to support the end-to-end lifecycle for SAP Fiori and SAPUI5 applications. It comprises prototyping, development, packaging, deployment, and customer extensions for SAPUI5 applications (including SAP Fiori apps). It provides standard Web development tools such as code editors, wizards, project persistence, and WYSIWYG tooling that are optimized for building responsive SAP Fiori apps with SAPUI5 (including, for example, code completion). SAP Web IDE can be used in SAP S/4HANA as a development environment to extend SAP Fiori apps (for example, to extend controllers, extend or replace views, replace services, add new views to existing projects, implement extension points) and also to build custom SAP Fiori apps. This environment requires no additional installation and provides improved developer productivity by offering highly efficient development tools, end-to-end application lifecycle support, and support for mobile and tablets in one tool. 15 / 31

16 4. In-App Extensibility As stated before, an extension can either be implemented in the same system as the enhanced application (in-app extensibility), or it can be built on a separate extension platform (side-by-side extensibility). Both variants are valid and have their use cases, which are reflected in the offerings of most cloud vendors. The benefits of in-app extensibility are: Better performance (no latency, no data transfer to a side-by-side system) Direct utilization of SAP HANA features (for example, core data service views) Integration into application engines and logic, regardless of their layer, allowing use of the full business scope of these applications within extensions Business-related examples utilizing these benefits include: Any structural enhancements of business data and related reporting Variants of standard processes and business logic (for example, microvertical solutions and localization) Choreography with focus on SAP S/4HANA data and processes 4.1 KEY USER EXTENSIBILITY As a major way to realize extensibility, key user extensibility enables business experts from LoBs, who have no deep technical knowledge, to implement the most important types of customer extensions. For this purpose, use-case-specific tools can be launched directly from the application UI the natural working place of key users. Considering that, the following use cases for SAP S/4HANA extensibility will be realized with in-app extensibility for key users. All these use cases can be implemented by business users, except for code-based behavioral extensibility. Key user extensibility capabilities offered to customers must continue to work after an SAP software update without manual work. In other words, SAP software updates do not depend on adoptions by the customer or partner. Therefore, all extensibility scenarios depend on the availability of related released APIs or anchor points in the to-be-extended SAP application. The list of APIs or anchor points is a work in progress. Figure 5: Features of In-App Extensibility in SAP S/4HANA Key user in-app extensibility scenarios Field extensibility (custom fields) Table extensibility (Custom objects, node extensibility) Business logic extensibility (Code breakouts) UI extensibility (hide, move, add fields, change labels) Report extensibility, new reports Forms extensibility, new reports (Print forms and templates) Key user transport capabilities 16 / 31

17 4.1.1 User Interface Extensibility In the adaptation mode (also called runtime authoring), the business user can adapt the UI layout in a modification-free way: Hide fields in a form, table, or filter Rename labels Move form field or UI block Define new filter and table variants This applies to transactional SAP Fiori UIs and to SAP Fiori fact sheets. Beside these changes, more fields can be added to the UI layout. They can either be SAP fields that are not yet part of the UI or custom-specific fields (see next section) Field Extensibility Field extensibility refers to the capability to add customer-specific fields (custom fields) to a business context of an application (for example, a sales order item or a customer address) in a one-to-one relation. Directly from the UI adaptation mode, a business user in SAP S/4HANA may launch the add field functionality. This guides the user into a simple dialogue, where the field properties can be edited or translated like data type, label or code list values, and texts. After the field has been defined, all necessary software artifacts are generated by the extensibility tool: SAP database tables and application structures are enhanced by using the DDIC extension include concept. Assigned SAP core data service (CDS) views, SAP Fiori search, and OData services are extended as well. As the applications are prepared for this kind of extensibility, they do consider these extension fields in their business logic, so the generated fields can be used directly. It is also possible to find other artifacts that are related to the underlying extended business context (such as more UIs, reports, forms, external interfaces, processes, and enterprise search) and to add the previously defined custom field to these artifacts. When several applications are part of the same business process, they can be extended together. Mapping of the custom fields in processes happens either automatically or can be defined by the business user through simple rules. Note that there are technical constraints for field extensibility. For example, making standard SAP tables too broad might slow down the performance. Also, there is a maximum width for tables on the database. 17 / 31

18 4.1.3 Table Extensibility Table (or node) extensibility denotes the capability of adding customer-specific fields to a business context of an application in a 1:1 or 1:n relation. In contrast to field extensibility, new customerspecific tables are created in the database. This is accompanied by a set of API functionalities supporting create, read, update, delete (CRUD) services through API classes, CDS views, and OData services. Applications prepared for table extensibility integrate the customer-specific table through these APIs in all relevant layers. The feature of table extensibility in SAP S/4HANA will be enhanced step-by-step in the future. Two types of enhancements are possible. 1. New (stand-alone) custom tables that are not child tables of SAP tables could be fed through a UI or data load from other customer systems. These stand-alone tables might be used as code lists, for process control, or as facts or dimensions for analytical purposes. A further enhancement might be to bundle several stand-alone custom tables into a hierarchy, creating a new application with simple business logic. 2. Custom tables could be used to add fields to SAP business contexts in a 1:n relation (for example, hobbies of a customer) or to resolve the technical constraints of field extensibility in case of extensions in a 1:1 relation. In this use case, the custom data behaves like the SAP standard data (for example, the authorization inherited from the SAP parent), and custom data is deleted when the parent is deleted. This use case requires that the SAP applications are prepared for this kind of extensibility. Table extensions can be created directly in a key user UI as described above for field extensibility Business Logic Extensibility Beyond UI extensibility, which allows the adaptation of an application s appearance, and field or table extensibility, which allow the enhancement of the data structure of applications, a further important extensibility capability is required: enhancement of the behavior of applications and processes. Prominent use cases for this capability include data validation, data calculation (for example, supplying default values), and mapping of standard and extension fields within applications and processes. To make processes more flexible, custom-specific checks might be offered (for example, on approval) or the possibility of removing process steps or defining additional ones. Additional examples of use cases are application domain specific topics such as tax calculation or price determination. Technically, business logic extensibility in SAP S/4HANA is realized by application-specific code exits, which can be implemented by customers. 18 / 31

19 Code-Based Implementations As code exit technology (for example, Business Add-Ins, or BAdIs) is the standard enhancement option for ABAP, and since major parts of the SAP S/4HANA core applications are implemented in ABAP, customers and partners are given the option to create enhancement implementations in a lightweight ABAP version running under the working title ABAP 4 Cloud. It is available for the cloud and on-premise editions. Developers and experienced business users (including implementation partners) will be able to provide an implementation for exposed enhancement options in a simple and safe way using a Web-based editor. In this Web-based editor, enhancement options are simple to discover (by UI, by business context, by purpose) and understand (self-explanatory field names, well documented, including code examples). This also implies that the implementation is clearly business related (for example, defining formulas in spreadsheet applications). The Web-based editor also includes features such as syntax coloring, syntax check, code completion, element information, and integrated test support. To ensure that the system stability needed for cloud operations is not hampered, the ABAP feature set is reduced as part of the syntax check. Only expressions, control and flow statements, variables, and tables will be available in the first releases of SAP S/4HANA. Furthermore, code-based enhancements enable access to: Inbound and outbound enhancement option parameters following a global CDS field name catalog Read access through Open SQL to public CDS views Calls to cloud-released APIs Calls to math or string libraries Connectivity to SAP HANA Cloud Platform through the SAP HANA cloud connector (See also Chapter 3 about side-by-side extensibility) The Web-based editor can be used only to implement enhancement options within SAP applications or for events and actions on custom tables (see Section 4.1.3, Table Extensibility ), not to develop new applications (the use case of new extension application development is described in Chapter 3 of this document) Business-Rule-Based Implementations Also for business logic extensibility, the business user should be able to realize as many use cases as possible. As business users are assumed to have a different view on code than business software developers, a rule-based approach is the method of choice. Technically, the business rules framework BRF+ will be used to realize this capability. In a future version of SAP S/4HANA, rule-based extensibility will be integrated in the UI adaptation mode, as described for field extensibility, assisted by a simple dialog. 19 / 31

20 4.1.5 Report Extensibility SAP S/4HANA, cloud edition, provides end-user analytical flexibility. The relevant capabilities address the typical analytical uses cases, from simple lists to multidimensional reporting, pixelperfect reporting, dashboards, and key performance indicator (KPI) based reporting. Analytics is embedded in the same technical stack as the application and into the business processes and can be enhanced directly from the application UI of the productive system without the need for IT experts. For that, specific SAP Fiori apps will guide the user through the entire process, requiring only basic technical knowledge. SAP will provide an initial set of extensible analytics content, which can be extended by customers. Also, new analytics content can be created. The following capabilities are supported Extensibility for Data Sources Data sources will be implemented using open CDS views, turning raw data into reportable data by selecting only those fields from the underlying database tables that are needed. In addition, using filters and calculations, generally needed transformations of the data can be modeled, facilitating the later use of the data. Business users at the customer will be able to create new data sources based on standard data sources by using them in joins, unions, and projections and creating additional restricted (filtered) key figures, calculated measures, and dimensions within existing data sources. Also, it is possible to change existing data sources by adding or removing fields, calculations, or filters Extensibility for Queries, the Standard Settings of Reports and KPIs Based on a data source, a query, which is also implemented as a specific type of open CDS view, will allow further detailing of the list of fields needed for a certain report. Flexibility allows business users to create or change key figures, change field labels, and define filters and layout variants. Closely related to this workflow, SAP will also support the business user in assigning or unassigning the query to specific roles or users. Thus, the end user can launch it in a generic multidimensional reporting app (see next subsection). As queries are also the basis for KPI reporting, the business user will find tools to create or change KPIs. In particular, the business user will be able to create new KPIs or change existing ones and assign them to roles and users. The following features are supported: Select the key figure in the query that holds the numbers Set filters Define visualization options (display the KPI as a number or a chart on the tile) Configure the comparison for example, of actuals versus targets Define drill-down behavior (initial drill-down dimension, chart type for drill-down) 20 / 31

21 End Users Personalizing Reports and KPIs Changes done by the key user will affect all users of the queries, reports, or KPIs; the changes done by the end user will be relevant only for this user. The end user will be able to: Personalize the layout for example, sequence of columns, hidden and displayed columns and save the personalization in a personal layout variant Personalize the data selection and save the personalization in a personal selection variant Add simple column-based calculations (+, -, *, /) Perform object-based navigation to other reports and fact sheets or transactions Similarly, for KPIs the end user will be able to: Change the chart type in the drill-down Define own filter settings for the KPI Add a tile showing the result of the applied filter settings on the home page Forms and Template Extensibility Print forms will be maintained through the Adobe LiveCycle Designer. They will be based on OData services, which might be extended in case of field or table extensions according to the user s choice. Checkmarking a print form assigned to an extended business context in the key user extensibility tool will make the extension field available in the field catalog of the corresponding form. A forward navigation to the corresponding editor will open the administration screen for form templates, which in turn will allow the Adobe LiveCycle Designer to be launched. In addition, a key user will be able to create new print forms that may be: Based on an existing data source (OData service) Based on an extended OData service, using existing fields and associations from published CDS views Based on a new data source (OData service) The same applies for template extensibility, only these templates are not bound against OData services but against CDS views. 21 / 31

22 4.2 MANAGED EXTENSIBILITY CUSTOM- CODE ENHANCEMENTS IN THE CLOUD Especially for SAP S/4HANA, cloud edition, the combination of key user in-app and side-by-side extensions already covers a scalable and flexible extensibility approach. But there are several reasons why customers and partners are heading for an extensibility option that provides some more flexibility. 1. Customers and partners often need to better influence SAP S/4HANA applications and process behavior from the outside. This means the SAP S/4HANA ABAP stack sometimes needs to be influenced by external orchestrators such as SAP HANA Cloud Platform through a usually small but necessary in-app extension. This requires more freedom/ expressiveness than is possible with key user in-app extensibility. 2. Many SAP S/4HANA extensions will combine customer or partner in-app extensions with customer or partner side-by-side extensions to enable a viable solution. Here s an example: An insight-to-action scenario combining a side-by-side-based calculation and forecasting with an in-app extension to read data and trigger actions in SAP S/4HANA based on the forecasts from SAP HANA Cloud Platform. 3. Partner in-app add-ons should be offered as well for customers of SAP S/4HANA, cloud enterprise edition Today this goal can be reached only with a combination of classic in-app and side-by-side extensions under the above-mentioned limitations for SAP S/4HANA, on-premise edition, deployment. Thus, there is a strong need for coded extensibility for SAP S/4HANA, cloud edition, in the context of the application with a focus on tight integration. Therefore, SAP is in the process of defining a managed in-app extensibility option for SAP S/4HANA, cloud enterprise edition, together with its customers and partners. These types of managed extensions have a focus on tight integration with the ABAP-based SAP S/4HANA standard applications and thus are written in ABAP. To fulfill this requirement, SAP will offer customers and partners an additional service to use an SAP-hosted development landscape to develop ABAP add-ons that allow a very high level of in-app extensibility. To scale in the cloud, however, it is important that these add-ons do not break the cloud operations concept. Therefore, the add-on code must follow strict rules to be allowed for SAP S/4HANA, cloud enterprise edition. The most critical rules guarantee a clear logical separation of customer and partner enhancements and standard objects. Modifications of SAP objects must be strictly forbidden, as they will lead to customer and partner individual processes that prevent standardization. Access to SAP objects will be allowed only through released whitelisted APIs so that the custom and partner code will be lifecycle stable and so that SAP updates do not lead to the need to adapt custom and partner code, which is vital for cloud operations. 22 / 31

23 SAP will provide tools to support the development of new code and the adaptation of existing custom and partner code to help ensure that the required rules are respected. A gate check process at SAP will be established to sign off the add-on content and to help ensure that it can be taken over to the cloud landscape for productive usage. For partner add-ons, there is a new qualification and certification process in SAP S/4HANA. The intent of this new process is to ensure that the new SAP S/4HANA architecture and UI paradigms, as well as aspects of the respective deployment options, are reflected in the partner solutions and therefore support the SAP S/4HANA brand. 4.3 CLASSIC EXTENSIBILITY For many years, customers and partners have extended and modified SAP Business Suite software. This kind of extensibility is called classic extensibility in this paper. In the on-premise edition of SAP S/4HANA, customers and partners still have full access to classic extensibility using development tools such as Eclipse or ABAP Workbench (SE80). Modifications to SAP S/4HANA objects and the use of all SAP S/4HANA objects (besides quarantined objects) are allowed. Quarantined means existing but deprecated and not directly accessible. Thus, this extensibility option combines a maximum of freedom and unlimited expressiveness with the possibility of influencing SAP S/4HANA s process behavior. But the scalability, especially with respect to cloud operations, is very limited. When modifications or the use of ABAP objects that are not on the white list exist, the deployment of classic extensions is limited to SAP S/4HANA, on-premise edition. Note: Customers and partners will be able to build add-ons for SAP S/4HANA, on-premise edition, with classic extensibility. But the use of managed extensibility capabilities will be a recommended option, even for SAP S/4HANA, on-premise edition, to benefit from its expected reduced total cost of ownership. 4.4 RELEASE CONCEPT FOR APIS (WHITELISTING) For API access to the cloud editions of SAP S/4HANA, the following restriction applies: Only cloud-released APIs are accessible an approach called whitelisting. This rule applies to both in-app extensibility (for example, implementable code breakouts for business logic extensibility and APIs available for their custom implementations) and to API access from outside (for example, by side-by-side extensions or third-party systems based on SAP HANA Cloud Platform). It is essential to follow this whitelist approach to ensure the system s integrity (especially during upgrades), to decrease operation cost and incidents, and to speed up innovation delivery to customers. 23 / 31

24 The following types of APIs are available for in-app extensions: BAdIs for code breakouts, ABAP classes, CDS views, and function modules such as BAPIs. The whitelisting approach allows a distinction between general cloud usage (for example, to support custom code by means of managed extensibility) and API exposition to key user tools. For access from outside (for example, for side-by-side extensions based on SAP HANA Cloud Platform), the following types of APIs can be whitelisted: IDocs through SOAP Service-oriented architecture (SOA) services, created manually or generated from BAPIs or other stable remote function modules Manually created OData services Note: UI-oriented OData services are not planned for whitelisting, as they do not have the needed stability due to their UI-related nature. Instead SAP recommends building custom OData services in ABAP. OData services generated from stable APIs for example, CDS views of virtual data models In the first shipments of SAP S/4HANA, very few APIs will be available as whitelisted. In order to react to customer and partner needs, SAP will follow an agile release approach. Customers and partners can request release of APIs from SAP. The requests will be processed within a short time, and when the requested APIs can be released, the enhanced whitelisting containing these APIs will be delivered through the biweekly patches. Note: SAP is in the process of deciding on an API provisioning process, where customers and partners can request a public API from SAP, or where partners can provide a partner-specific API as a partner add-on. The extent to which SAP standard public APIs will be supported by SAP in SAP S/4HANA should be published in the SAP Release Strategy The current proposal (in discussion with customers and partners) is: Support SAP standard public APIs for at least two years. If a new SAP standard public API is created to replace the old one, the old one should be supported for at least one new release. The same rules should apply as well for partner APIs. The partner needs to react to the deprecation of an SAP standard public API within one SAP release. If no new add-on version is provided by the partner that has to react to an SAP standard public API s deprecation, the add-on content (table data, configuration content) is exported and the add-on is revoked or deleted during the upgrade after the deprecation period. 24 / 31

25 5. Extension Lifecycle Management Currently, SAP plans a yearly upgrade of SAP S/4HANA, on-premise edition, and a quarterly upgrade of SAP S/4HANA, cloud edition, with biweekly patches. This preliminary plan can change in the future for both editions in one or the other direction. All customer and partner extensions that are built by using key user or managed extensibility or with side-by-side extensibility are expected to run after each upgrade without customer or partner preupgrade activity. All customer and partner extensions that are built by using classic extensibility have to be tested and maybe adapted by the customer or partner on their own system of SAP S/4HANA, on-premise edition. Especially in the first releases of SAP S/4HANA, cloud edition, customers and partners will require help from SAP Cloud Service Center for different SAP S/4HANA extensibility-related activities, such as whitelisting dedicated APIs, connecting SAP HANA Cloud Platform accounts with SAP S/4HANA systems, or extending SAP Fiori UIs. It is expected that over time, more and more of these SAP S/4HANA extensibility-related activities will be automated or available as self-service for customers and partners. 5.1 LIFECYCLE MANAGEMENT FOR SIDE-BY-SIDE EXTENSIBILITY For individual customer side-by-side extensions, a packaging and publishing process has already been established. The same is true for partners joining through the SAP PartnerEdge program to package and publish their commercial sideby-side extension offerings on the SAP HANA Marketplace site. Deployment of side-by-side extensions is done either by the customer (for customer-specific extensions) or through SAP Cloud Operations Center (for commercial partner extensions). Each customer-specific, side-by-side extension runs as a cloud application in its own virtual machine on a customer s own SAP HANA Cloud Platform account. By using the SAP HANA Cloud Platform cockpit, customers can see which of their cloud applications require support. An alternative scenario is available for OEM partners that provide partner side-by-side extensions running in their own virtual machine on a partner s SAP HANA Cloud Platform account to which multiple customers are subscribed. By using the SAP HANA Cloud Platform cockpit, partners can see which of their cloud applications require support. Using the SAP Application Interface Framework tool to provide a similar mechanism for customer and partner SAP S/4HANA in-app extensions is currently in discussion at SAP. 25 / 31