Getting an Overview of Extensibility Options

Objective

After completing this lesson, you will be able to explore and Compare the Explore different ways to extend SAP Sales and Service Cloud.

Overview on Extensibility Capabilities

SAP cloud solutions can be enhanced in several ways. Using SAP Cloud Application Studio is one of them and is the focus of this training. But before we deep dive into extending SAP Sales and Service Cloud with SAP Cloud Applications Studio, let's first take a look at the general extensibility capabilities to see the bigger picture.

Extensibility options are often divided into two categories depending on where they are implemented:

In-App: Enhancements run inside the cloud solution and access data based on a framework.
Side-By-Side: Enhancements run outside the cloud solution, hosted in a different place (for example, SAP BTP) and use interfaces to communicate with the cloud solution. Integration concepts are applicable for this kind of extensibility.

Overview of Extension Capabilities

The different capabilities that are often divided into the two categories: In-App and Side-By-Side extensions, depending on where they are implemented:

The In-App extensibility can be differentiated in two approaches:

Key User Tools (KUT)
Are a set of easy-to-use, built-in tools used to customize, and extend the cloud solution with only a few clicks. Most prominent part of the KUT is the Adaptation Mode. This mode can be used to adapt screens, show and hide fields, create new customer-specific fields, and populate them on to other screens. These data changes are carried out in PDF forms or through service interfaces. Click here for further information.
SAP Cloud Applications Studio
is an Integrated Development Environment (IDE) based on Microsoft Visual Studio. It helps to adapt and enhance the solution capabilities, such as creating and integrating new business objects, services, and user interfaces. Click here for more information.

The Side-by-Side extensibility can be divided in two approaches as well:

Mashups and Extension Apps
Mashups are used to integrate data provided by online web services or applications. UI Mashups are the most commonly used types. These are iFrames that display external content seamlessly inside the cloud solutions UI. Click here for further info.
Extension Apps are web applications that are displayed as mashups, or in a separate window to provide additional functionality to users. They can access data of the cloud solution through services, usually the OData protocol.
Kyma
is an open source extension platform that allows you to subscribe to events such as event notifications of the cloud solution. It reacts to those events by performing actions such as executing the business logic. Data can be accessed again through interfaces like the OData services. More information in Event Notifications. Further Information on Extending CX Products in the Kyma Environment.

Comparing Extensibility Approaches

Now that we know what kind of extensibility capabilities there are and what they can look like, let's gather an overview of the pros and cons of each capability and what the typical use cases can be:

Extensibililty Approach	Advantages	Disavantages	Typical Use Cases
Key User Tools	Easy to use. No external tools are necessary. Built into and running inside the cloud solution.	Cannot implement complex business logic.	Add extension fields for storing additional data without business logic and include them in forms or interfaces. Screen adaptations.
Cloud Applications Studio	Business logic can be implemented and is run inside the cloud solution, no other hosting environment necessary. More powerful than KUT. Supports offline features.	Platform-dependent; Creating content needs the IDE, which runs on windows. Development/Programming skills required. Makes tenant management more complex. Versions must be aligned during upgrades, tenant copies etc.	Complex scenarios that require business logic.
Mashups / Extension Apps	Independent from the in-app extensibility framework. Relies on interfaces for data exchange. Makes tenant. Programming skills for HTML5/JavaScript etc. are more common than Cloud Applications Studio.	Needs a place for hosting (for example: SAP BTP), and common authentication between app and cloud solution (SSO) to work properly. App cannot access data on the screen outside of its mashup. Updates through interfaces can only change data in the background. User has to refresh the screen to see changes on the currently loaded object.	Additional functionality that can be encapsulated on a separate screen (even if the screen gets embedded). Gathering additional information for an external follow-up process (gathered data is sent to an external system) .
Kyma	Independent from the in-app extensibility framework. Relies on interfaces for data exchange. Can be used to implement logic that runs in the background. Mass data updates possible.	Updates through interfaces can only change data in the background. Headless. No option for user interaction in the frontend.	Executing logic in an external system after a certain event has been triggered in the cloud solution. For example: updating a document in an external system when the status of an object in the cloud solution has changed.

Comparing In-App Extension Capabilities

When extending the cloud solution with an in-app extensibility approach, it often depends on the complexity of the problem in choosing either Key User Tools or SAP Cloud Applications Studio. Key User Tools are usually the first choice to start with when extending the system. But it's important to know their limits and when SAP Cloud Applications Studio is a better option.

Therefore, we list some typical implementation use cases in the following table together with recommendations on when to use which in-app extensibility approach:

Use Case	Key User Tools	SAP Cloud Applications Studio
Create extension fields and use them in print forms or interfaces.	Easily possible with Adaptation Mode. *	Possible, requires more effort than with Key User Tools.
Create new business objects.	Possible with Custom Object Builder, but with a limited scope.	Possible with all available features. *
Implement business logic.	Possible for very simple use cases with Workflow Rules. Very limited scope!	Possible with ABSL for any kind of complexity. *
Validate inputs before they get saved.	Possible with Validation Rules inside the Adaptation Mode up to a certain extent of complexity.	Possible with all available features and full complexity. *
Request data from external sources.	Very limited scope: Data Mashups.	Possible with all available features. *

Note

* in the table above marks the recommendation for the individual use case.

However, the comparison above is only a suggestion that applies when looking at the use case individually. Most of the time, projects come with a mixture of the above-mentioned use cases that complicates decision-making. While the solution could also be a mixture of Key User Tools and the studio, it is quite common to implement all requirements with the studio once it has been introduced.

Let's look at two more examples to give you a better impression:

Customer-specific fields have been created in the past with Key User Tools. Then, a project with the SAP Cloud Applications Studio was introduced. Now there is a new requirement for validating one of the Key User Tools fields. In this case, it's easier to use the Key User Tools validation as long as the complexity of the validation logic allows it.
An add-on solution is already in place. Now there is a requirement for a new field. The new field does currently not need any logic. However, it could make sense to create the field with the SAP Cloud Applications Studio, because there could be further requirements in the future, like additional logic, complex validation, and so on. The decision would also depend on if the field belongs to the add-on topically.

Next lesson