73
SAP S/4HANA | Extensibility for Customers and Partners | June 2015
22 / 31
© 2015 SAP SE or an SAP affiliate company. All rights reserved.
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
to adapt custom and partner code, which is vital
for cloud operations.
65
SAP S/4HANA | Extensibility for Customers and Partners | June 2015
23 / 31
© 2015 SAP SE or an SAP affiliate company. All rights reserved.
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
during upgrades), to decrease operation cost
and incidents, and to speed up innovation
delivery to customers.
61
SAP S/4HANA | Extensibility for Customers and Partners | June 2015
24 / 31
© 2015 SAP SE or an SAP affiliate company. All rights reserved.
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.
66
SAP S/4HANA | Extensibility for Customers and Partners | June 2015
25 / 31
© 2015 SAP SE or an SAP affiliate company. All rights reserved.
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 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
currently in discussion at SAP.
51
SAP S/4HANA | Extensibility for Customers and Partners | June 2015
26 / 31
© 2015 SAP SE or an SAP affiliate company. All rights reserved.
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.
56
SAP S/4HANA | Extensibility for Customers and Partners | June 2015
27 / 31
© 2015 SAP SE or an SAP affiliate company. All rights reserved.
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).
68
SAP S/4HANA | Extensibility for Customers and Partners | June 2015
28 / 31
© 2015 SAP SE or an SAP affiliate company. All rights reserved.
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
solution for this requirement regarding all SAP
S/4HANA extensibility options.
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.
58
SAP S/4HANA | Extensibility for Customers and Partners | June 2015
29 / 31
© 2015 SAP SE or an SAP affiliate company. All rights reserved.
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
for the platform.
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.
33
SAP S/4HANA | Extensibility for Customers and Partners | June 2015
30 / 31
© 2015 SAP SE or an SAP affiliate company. All rights reserved.
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.
Documents you may be interested
Documents you may be interested
