SAP® S/4HANA
Extensibility for Customers and Partners
June 2015
s r
es
er
1. Management Summary 3
2. The Big Picture 4
2.1 Side-by-Side Extensibility and
In-App Extensibility 6
2.2 Transition to SAP S/4HANA 9
3. Side-by-Side Extensibility 12 3.1 SAP HANA Cloud Platform 12
3.2 New User Interfaces and
Extension Applications 14
4. In-App Extensibility 16
4.1 Key User Extensibility 16
4.1.1 User Interface Extensibility 17
4.1.2 Field Extensibility 17
4.1.3 Table Extensibility 18
4.1.4 Business Logic Extensibility 18
4.1.5 Report Extensibility 20
4.1.6 Forms and E-Mail Template
Extensibility 21
4.2 Managed Extensibility – Custom
Code Enhancements in the Cloud 22
4.3 Classic Extensibility 23
4.4 Release Concept for APIs
5. Extension Lifecycle Management 25 5.1 Lifecycle Management for
Side-by-Side Extensibility 25
5.2 Lifecycle Management for Key
User Extensibility 26
5.3 Lifecycle Management for Managed Extensibility in the
Cloud Edition 27
5.4 Lifecycle Management for
Classic Extensibility 27
5.5 Lifecycle Management Aspects
of Combined Extensibility Options 28
5.5.1 Combined Side-by-Side Extensibility 28
5.5.2 Combined Classic Extensibility 29
5.5.3 Combined Key User Extensibility 29
5.5.4 Combined Managed Extensibility 29
6 Appendix: Recommendations 30 6.1 Current Extensibility Categories 30
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® program-ming 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.
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 custom- specific application logic and UI may be built on top of a standard enterprise resource plan-ning (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 require-ments 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 com-petitive advantage in a specific area – which is unacceptable for successful companies. In other words, enterprises will always need a balance between standardization and differentiation.
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 scal-able 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.
For many years, SAP has implemented successful processes for scalable and cost-efficient exten-sions in all product verexten-sions. 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 us-ing the SAP NetWeaver® technology platform for on-premise extensions of SAP Business Suite).
2.1 SIDE-BY-SIDE EXTENSIBILITY AND IN-APP EXTENSIBILITY
SAP S/4HANA extensibility provides a compre-hensive 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 summa-rized in Figure 1.
1. 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 inte-grate 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 full-fledged 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.
b. Key user extensibility: Customers usually apply many small changes and extensions, since they want to increase user produc-tivity 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 sat-isfying all extensibility qualities. In particular, end-to-end tools enable business experts to apply changes without risk, as the tech-nical 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 exten-sibility 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 require-ment, SAP will offer customers and part-ners 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, 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.
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 transi-tion from on-premise to cloud computing. Finally, partners can approach a large customer base, since almost all SAP customers create custom-specific extensions.
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
Figure 1: Overview of the Extensibility Capabilities of SAP® S/4HANA for Each Scenario
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
Paid service in cloud enterprise edition
$
Cloud On premise
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)
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) Classic
• Full access to ABAP (for example, SE80)
+
$
SAP® S/4HANA
Managed
• Designed with ABAP® programming language to be cloud lifecycle-stable
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
Classic customer and partner development
Managed extensibility (Paid service in cloud enterprise edition) Key user extensibility Classic extensibility In-app extensibility Cloud editions On premise Extensions Modifications Side-b y-side e xt ensibilit y on SAP HANA Cloud Platf orm
$
Public APIs SAP Customer, partner
APP UI DB User interface Application Database User interface User interface Application Application Database (SAP HANA®)
Database (SAP HANA)
Customers and partners that have analyzed their products and software components according to the above-listed categories and recommenda-tions should also take the following extensibility options assessment into consideration.
Figure 3: Extensibility Options Assessment
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)
$
ü
ü ü
ü ü
ü ü
û
Onpremise editionsCloud
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) *name TBD
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 transac-tional 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.”
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 infrastruc-ture 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, plan-ning, predictive and stored procedures), and application services (for example, cloud portal, security, document, administration, and devel-opment 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.
Figure 4: Services for SAP HANA® Cloud Platform Authentication Identity federation Password storage Policies Single sign-on Social sign-on Security
Sites and SAP Fiori® launchpad Theming and branding Role-based authorization Content catalog for widgets App integration Templates Portal Storage Access control Versioning Repository and folder management Metadata Encryption Documents Account management Members management Quota management Application management Monitoring Authorizations Administration Application services On premise – cloud connector Extract, transform, load (ETL) Process integration Destination management Integration Mobile app lifecycle Device notifica-tion Discovery Offline OData Settings exchange Usage analysis Mobile* Eclipse plug-in Web IDE Software development kits Marketplace Tools Develop and run New applications On-premise
extensions extensionsSaaS
Database (DB) services – SAP HANA
Infrastructure services – at SAP data centers
Certified operations | Advanced network security | SLA 99.9% | Data backup | Compliance | Integrity | Confidentiality Core DB
services proceduresStored Data models Function libraries Full text search analyticsText Planning Predictive Spatial Business rules
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 SAP- delivered 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
coming with SAP S/4HANA, selected tradi-tional APIs such as business application programming interfaces (BAPIs) and inter-mediate 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, on-premise 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
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 provid-ing 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
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, pack-aging, 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.
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 offer-ings 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
Field extensibility (custom fields)
UI extensibility
(hide, move, add fields, change labels)
Key user in-app extensibility scenarios
ansport
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).
4.1.2 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 extensi-bility 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 appli-cations 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.
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 customer-specific 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 authori-zation inherited from the SAP parent), and custom data is deleted when the parent
Table extensions can be created directly in a key user UI as described above for field extensibility.
4.1.4 Business Logic Extensibility
Beyond UI extensibility, which allows the adapta-tion of an applicaadapta-tion’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 ex-ample, on approval) or the possibility of removing process steps or defining additional ones. Addi-tional 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.
4.1.4.1 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 imple-ment enhanceimple-ment options within SAP applica-tions or for events and acapplica-tions 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).
4.1.4.2 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.
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, pixel-perfect reporting, dashboards, and key perfor-mance 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.
4.1.5.1 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
4.1.5.2 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 unas-signing the query to specific roles or users. Thus, the end user can launch it in a generic multidi-mensional 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)
4.1.5.3 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
4.1.6 Forms and E-Mail 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 e-mail template extensibility, only these templates are not bound against OData services but against CDS views.
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 orchestra-tors 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, deploy-ment. 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 edi-tion, 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
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 maxi-mum 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, imple-mentable 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
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 2015. 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.
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 activi-ties 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 side- by-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
5.2 LIFECYCLE MANAGEMENT FOR KEY USER EXTENSIBILITY
For business-critical applications, extensions are typically created and tested before the extension is active for all users in the production environment. Here we distinguish between SAP S/4HANA, cloud edition, and SAP S/4HANA, on-premise edition. In a cloud environment, three core principles are crucial for extensibility objects:
1. All extensibility capabilities offered to customers must continue to work after an SAP software update without manual work; this implies that SAP software updates do not depend on adoptions by the customer. 2. Extensibility objects must never block an
SAP software update.
3. The transport of extensibility objects from the test to the production system is performed by the key user without interaction with the service provider and outside of the maintenance window of the service provider.
To support these core principles, the custom artifacts must comply with the following principles: 1. Custom artifacts must be technically
modification free; they are created as an own object that refers to the base object. 2. Custom artifacts must be technically clash free.
Extensions must not clash with parts of the core objects that are added later on. Further on, extensions of different extending parties must not clash. This requirement is fulfilled by applying a unique namespace that is consid-ered in every layer of the architecture. To sup-port extensions of different extending parties (partners, customers), namespaces require a “layering.” (Note: different extending parties are not in scope for Q1–Q3 of 2015).
3. Custom artifacts use released, stable SAP extension points and APIs only. This has to be enforced by checks on the customer side. On the SAP side, checks must prevent incom-patible changes to objects that are marked as extensible and have been delivered once. A convenient deprecation mechanism must be available.
4. To avoid interference, separate transport channels for SAP software updates and custom transports are required.
In SAP S/4HANA, cloud edition, the lifecycle management will work as follows. In the test environment, a key user performs a key user change in a “sandbox environment.” On “publish,” the changes are activated for other users (all or only selected; this depends on roles). After test-ing (maybe in combination with other changes), the key user can transport the changes to the production environment.
The transport application UI that is provided to the key user will be “in key user language.” The key user can pick custom artifacts for transport that he or she knows of (no “technical” artifacts), and corresponding transport logs and error notification will add meaningful information. If technical errors occur, they result in an incident for the service provider. The transport channel for transports of extensions is separated from the transport channels for SAP software updates to avoid interference between transports.
In the on-premise environment, customers have much greater freedom for development and for setting up the system landscape and quality assurance processes. As a consequence, customers will manage SAP updates and customer transport with “classic” transport tools (correction and transport system).
5.3 LIFECYCLE MANAGEMENT FOR MANAGED EXTENSIBILITY IN THE CLOUD EDITION
For individual customer–managed in-app extensions and for partner-managed in-app extensions that are designed to run on many different SAP S/4HANA customer systems, SAP plans to continue to use the ABAP add-on approach, as it is well known from traditional ABAP development. How future SAP S/4HANA partner add-ons will be packaged and published through SAP HANA App Center is currently in discussion between SAP and its customers and partners. SAP will offer customers and partners an additional service to use an SAP-hosted devel-opment landscape to develop ABAP add-ons. For in-app extensions that will be packaged as ABAP add-ons for deployment of SAP S/4HANA, cloud edition, some support from SAP Cloud Service Center will be necessary.
5.4 LIFECYCLE MANAGEMENT FOR CLASSIC EXTENSIBILITY
For the classic on-premise extensibility scenarios, customers will manage SAP updates and
customer transport with “classic” transport tools (correction and transport system).
5.5 LIFECYCLE MANAGEMENT ASPECTS OF COMBINED EXTENSIBILITY OPTIONS
This section describes some special lifecycle management aspects of combinations of different extensibility options that have not been previously covered. Many end-to-end solutions that run on customers’ SAP S/4HANA systems will be a combination of SAP standard components enriched with different in-app and side-by-side extensibility options.
Note: The following list is not complete. SAP is in the process of identifying and addressing these aspects together with its customers and partners. Note: As for all SaaS applications, it is of utmost importance for all extensibility options for SAP S/4HANA, cloud edition, that customers or partners never stop the maintenance of their underlying SAP runtime platform, be it ABAP, SAP HANA, or Java. Support and maintenance of the extension itself is the owner’s obligation. Together with our customers and partners, SAP is working on support and maintenance tools and processes.
Note: It is desirable that SAP provides one support target for all customer and partner extensibility-related problems, no matter which extensibility option is involved. Customers and partners want one phone number for and Web access to SAP support, an aligned support portfolio, seamless support delivery and escalation processes, as well as end-to-end supportability and lifecycle management. SAP is in the process of finding a
5.5.1 Combined Side-by-Side Extensibility
To test a partner extension on a customer’s SAP HANA Cloud Platform test account that connects to SAP S/4HANA, it must be connected to the customer’s SAP S/4HANA test system (through the SAP HANA cloud connector). The same is true for the customer’s productive SAP HANA Cloud Platform account running the productive (partner) extension and the customer’s productive SAP S/4HANA system.
If a customer uses classic or managed in-app extensibility in combination with side-by-side extensibility, the customer’s SAP HANA Cloud Platform development account must be connected to the customer’s SAP S/4HANA development system. If the customer uses SAP S/4HANA, cloud edition, in combination with SAP HANA Cloud Platform, all cloud systems must be colocated in the same data center to optimize smooth connectivity and authenticity between the SAP HANA Cloud Platform accounts and their connected SAP S/4HANA systems. Note: Customer and partner extensions must not prevent SAP from making corrections and upgrades either on SAP S/4HANA or on SAP HANA Cloud Platform.
Note: Because currently there is no automatic creation of a corresponding SAP HANA Cloud Platform account for each SAP S/4HANA system established, this connectivity requires support from SAP Cloud Service Center.
5.5.2 Combined Classic Extensibility
The lifecycle management of classic extensibility in SAP S/4HANA is equivalent to the well-known extensibility of SAP Business Suite powered by SAP HANA. In addition, it is possible to combine classic extensibility with new SAP Fiori UIs developed with SAP Web IDE based on SAP HANA Cloud Platform. The UI and ABAP development artifacts share the same lifecycle in the ABAP repository. In this scenario, SAP HANA Cloud Platform is used only for design time means.
5.5.3 Combined Key User Extensibility
If a solution integrates key user extensibility with side-by-side extensibility, the key user extension must be transported on the SAP S/4HANA, cloud edition, side from test to production system by an employee from SAP Cloud Service Center or by a customer key user (both using key user tools) independently from the side-by-side extension on the SAP HANA Cloud Platform side (for activation: see previous chapter).
5.5.4 Combined Managed Extensibility
Today, the deployment (installation, update, and upgrade) of managed extensions integrated with a side-by-side extension is always a technically decoupled process, but it can also sometimes be organizationally decoupled as well. The side-by-side extensions on SAP HANA Cloud Platform are “transported” manually through deployment from a local PC to development, testing, and productive SAP HANA Cloud Platform accounts using the Eclipse client software and the SDK
Note: SAP currently does not provide a means for customers and partners to perform an
automatic synchronized transport and activation for this scenario. Because deployment synchroni-zation must be solved by operational means, an automatic implicit activation after deployment by an operations team is not desirable. A purely technical managed extension deployment or technical side-by-side extension deployment does not automatically trigger activation. The business processes do not change after a purely technical deployment on both sides (neither managed extension nor side-by-side extension). The synchronized activation or going-live should be coordinated by a customer’s key user after the successful technical deployment of both parts. To support this explicit activation and going-live scenario, the extension has to provide an activation API (ABAP calls SAP HANA Cloud Platform, or vice versa) to activate the code and to switch on the business process.
6 Appendix: Recommendations
6.1 CURRENT EXTENSIBILITY CATEGORIES
After the overview of the various extensibility capabilities of SAP S/4HANA, the following recommendations provide guidance for the given extension goals. The majority of add-on software products and software components that currently apply to SAP Business Suite can be segmented into several categories. SAP recommends that our customers and partners analyze their products or deployed software components according to these categories if they plan to:
1. Start a transformation process of their existing SAP Business Suite developments toward SAP S/4HANA extensions
2. Implement net-new SAP S/4HANA extensions
The following extensibility categories represent existing partner products that are currently shipped as add-ons to SAP Business Suite, either under the SAP brand or a partner’s brand to many different customers. Most partner products span across these categories. We recommend that partners analyze their existing products to determine which parts fall into which category. SAP expects that these categories will continue to be valid for SAP S/4HANA. The table below gives transformation recommendations for SAP Business Suite add-ons for SAP S/4HANA and net-new SAP S/4HANA extensions.
industry) • Add search or selection parameters, variants
• Fill gaps in the business process, rearrange steps, or create new process steps • Enable business-to-business (B2B) protocol and new APIs with focus on
pre- and postprocess variants and integration • Add a new business process
• Add calculation and process engines
• Integrate with full stand-alone partner applications with own database
I I I S S S Analytics • Perform in-app analytics (default)
• Write back a small amount of results (insights) to trigger follow-up actions • Read (replicate) a massive amount of master and flow data from multiple sources • Conduct specific data collection and aggregation on BI software and SAP HANA® • Perform complex analytics, reporting, simulation, forecasting (for example, for
integrated business planning; fraud detection; governance, risk and compliance) I I S S S Globalization and localization
• Country-specific aggregation, validation, and calculation; forms and reports
• Language-specific content, UI flow adaptations, new fields II
Content • Complex business content (customizing, business data) I
User productivity • Dedicated and strong single-user focus with no to low training
• Encapsulation of standard functionality to hide complexity II External facing
and collaboration
• Same as user productivity but with a dedicated and strong multiuser focus • Specific functionality for external users and systems such as vendors (B2B)
and customers’ customers (business to consumer)
• Integration of social networks such as SAP® Jam™ and LinkedIn
S S S Business
integration • Business specific subscriptions and event filtering • Bulk and batch processing SI Complements • Some SAP software products (for example, financial services and SAP hybris®
solutions) provide only templates that have to be complemented by partner products or individually by customers. Examples include production planning in the SAP ERP and SAP Policy Management applications, SAP Bank Analyzer set of applications, and SAP Insurance Analyzer analytic applications
I
Technological integration
• Deep technological integration on the foundation or framework level (archiving, document services, and so on)
• Shared objects (for example, documents) integrated in many apps; adaptation through configuration
S I
SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE (or an SAP affi liate company) in Germany and other countries. Please see http://www.sap.com/corporate-en/legal/copyright/index.epx#trademark for additional trademark information and notices. Some software products marketed by SAP SE and its distributors contain proprietary software components of other software vendors.
National product specifi cations may vary.
These materials are provided by SAP SE or an SAP affi liate company for informational purposes only, without representation or warranty of any kind, and SAP SE or its affi liated companies shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP SE or SAP affi liate company products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. In particular, SAP SE or its affi liated companies have no obligation to pursue any course of business
outlined in this document or any related presentation, or to develop or release any functionality mentioned therein. This document, or any related presentation, and SAP SE’s or its affi liated companies’ strategy and possible future developments, products, and/or platform directions and functionality are all subject to change and may be changed by SAP SE or its affi liated companies at any time for any reason without notice. The information in this document is not a commitment, promise, or legal obligation to deliver any material, code, or functionality. All forward-looking statements are subject to various risks and
uncertainties that could cause actual results to diff er materially from expectations. Readers are cautioned not to place undue reliance on these forward-looking statements, which speak only as of their dates, and they should not be relied upon in making purchasing decisions.
