- SAP Managed Tags:
On my previous blog, I wrote about “Clean Core within SAP Sales and Service Cloud extensions” and defined the Clean Core Extensibility as the “way of extending SAP systems without messing with the core application”.
But, when speaking about Clean Core extensions, we should not only think of a side-by-side development, yet, we should always think as our first alternative of an in-app extension prior to a side-by-side one.
Every In-App comment you will read in the upcoming paragraphs applies to Sales and Service Cloud v2 products, however, when speaking about side-by-side extensibility patterns, this applies to any other SAP CX or, even, SAP S/4 HANA products (although the way for plugging them will not be the same, the overall concepts would be similar).
Extensibility within Sales and Service Cloud v2
From now onwards, I will refer to ”SAP Sales / Service Cloud v2” simply as “v2”. In v2, customers should always extend the solution through built-in tools when receiving requirements such as:
- adding a custom field without the need of implementing a complete new custom object;
- adjusting field attributes such as the ability of being filterable, searchable, sortable, required, creatable, updatable;
- implementing simple validations;
- implementing simple determinations;
- triggering email or system notifications under certain conditions
Although there are various things that can be achieved through In-App tools, it will happen at some point that business needs to introduce complex logic, or retrieve information from another source or mix various logics, which takes us into the need of a side-by-side enhancement. And that’s the point where we want to get for deep diving on this blog article.
For those who do not have professional development experience, it is possible to build extensions based on SAP Builds. For those who have professional development experience, there are two flavors for developing side-by-side extensions: RAP (RESTful Application Programming) or CAP (Cloud Application Programming). It is not a matter of deciding whether to use RAP (based on ABAP) or CAP (based on Node.js or Java) as both have their own purpose and benefits. We could spend a whole article discussing about this but this is not the aim of this one so we can leave this discussion for another post.
Side-by-side design patterns
Despite v2 being technology agnostic, SAP’s preferred way for extensibility is based on BTP, using SAP Builds for UI extensions and CAP development for server side implementations. But, as all the development patterns are based on web standards (mashups inside iFrames, REST APIs and webhooks for eventing), this enables the users to pick what they like most or what it fits them best!
In comparison to v1's existing setup, oData APIs are not supported for v2.
In the upcoming paragraphs, I will present certain patterns that can be used as construction bricks to construct almost any use case. All the extensions that I will be presenting at a later stage of the article, end up fitting with one of these extension patterns. A few weeks ago, SAP presented “Webcast 3: Introduction to Side-By-Side Customization (with SAP BTP)” which inspired me on writing this article. As pointed out on that webcast, these design patterns should fit for v2, as well as for v1, as we are discussing about SAP BTP development. The difference lies on how to connect each of these extensions with v1 or v2: v1 could trigger it through PDI while v2 could do it through Autoflow. Also, and just to be extremely clear, a BTP extension developed through CAP for v2, won't work straight forward for v1, for example, as each product uses different APIs; while v1 uses oData, v2 uses REST-based APIs. For sure, in the future we could deep dive on a separate blog on how to make an app usable for both, v1 and v2.
Having said this, let's jump into the design patterns:
Pattern #1: Event Consumer
- the overall concept relies on having our v2 system triggering a webhook, which is an HTTP request sent to our BTP application, containing a data payload, which triggers certain action asynchronously
- asynchronous execution which means there is no impact on end-user's performance, the application has "no rush” to do what it needs to do as per this asynchronism
- as per this pattern, even in case the BTP app would fail, users could continue with their daily tasks without these being affected
- CPI is a good choice for this scenario as per the fact that there are no performance requirements when using this design pattern. However, it is also possible to demonstrate this pattern through a Cloud Foundry application.
Pattern #2: External Hook
- the overall concept is similar to BAdIs, custom code is executed in a synchronous manner so user can't continue with his duties until the execution ends
- the performance is key for making things run smoothly; the danger on this pattern is that if the BTP application results faulty or slow, this will have direct impact on the response to the request
- this approach is quite powerful and useful, for example, when dealing with complex validations or determinations that can’t be achieved through in-app tools
- to be released soon by SAP
Pattern #3: External Job
- the overall concept is to use the BTP job scheduling service to trigger certain activities; alternatively, some CPI flows could be also scheduled
- this is useful when needing to adjust information under certain conditions or under certain periods of time, when not able to use scheduled field updates or autoflows (to be released soon for v2)
- asynchronous execution which means their is no impact on end-user's performance
Pattern #4: Mashup
- the overall concept is to integrate BTP applications or simply 3rd party tools into the v2 where v2 could send request parameters in order to get the expected content exposed
- SAP is currently working on making this integration through UI events in addition to sending request parameters; by doing this the UI will be able to connect back and forward with the mashup so, in case you make a change that affects the object you are working on the mashup, this mashup could send an event back to inform the object screen to reload
Real-world use cases
Example #1 - Event Consumer: when a sub-case status is set to "Completed”, if no others exists or if the others are all under "Completed” or "Closed” status, the parent Case should be set to "Completed”.
The overall approach would consist on setting up an Autoflow upon the closure of a sub-Case. This should call a BTP application which, asynchronously, retrieves the parent Case and checks whether this has other related sub-Cases that are not yet completed nor closed. If no others are pending for completion, the parent Case status should be updated to "Completed".
Example #2 - External Hook: when a Case has just been created and is assigned to certain processor, an additional validation should occur in order to see whether that person is the right candidate based on his current workload. In case he is not, it should be re-assigned to a dispatcher or left un-assigned.
The overall logic would consist on triggering the validation upon the setting of the “Assigned To” field, only upon the creation of a Case. The validation will be contained on a BTP application which would call certain APIs for reading the processor of the Cases and ensuring that the limit amount of assignments was not reached. In case it was, the application would return an error message or simply clear out or reassign the Case to a dispatcher processor.
Example #3 - External Job: a daily job that runs every night and, for those Cases which have priority “Urgent” or “Immediate”, have status “Customer Action” and have not been updated for the last 48 hours, its priority should be reduced.
The overall approach would consist on scheduling a job in BTP that triggers the BTP application which retrieves the list of Cases that meet the priority and status criteria and, for each of them, it should be checked that they have not been modified during the last 2 days. If any under this situation, the priority should be decreased.
Example #4 - Mashup: the customer wants its processors to have a common way of working so based on the Case category, a predefined set of activities should be performed. In order to achieve this, a mashup will be embedded and this will present a list of predefined activities. The processor will be able to interact and mark as completed the desired activities of the ToDo list.
The overall logic for achieving this requirement consists on developing a CAP application with its corresponding data model, services and UI for handling ToDo activities and, also, for recording the status for these activities for certain Cases, This BTP application will be embedded as a mashup inside the v2 screen.
Closing message
This is becoming a really exciting, yet, challenging journey where plenty of new things are appearing and where innovative-thinking must be part of every consultant’s toolkit. Also, I strongly suggest everyone to keep up to date with latest BTP, CAP and v2 news as things are changing rapidly!
For those who are currently on v1 and could start creating complex extensions through BTP instead of complex PDI solutions, that would be a great investment as, once you shift into v2, part of the effort would have already be done in the past and it would just be a matter for an additional adjustment.
For those who are already working with v2, enjoy!
What do you think about this article? Are you aligned with these design patterns? Have you already worked with these within side-by-side extensions? I am interested to read your experiences, don't be shy!
4 Comments
