Skip to Content
Technical Articles
Author's profile photo PARTHA GOSWAMI

End-to-End Implementation in SAP BTP (real-world use case scenario)

Hello Everyone,

Hope all are doing good!

Let me tell you some ground level facts..

There are many SAP consultants/customers thinks BTP is all about FIORI, many have perception that it is all about integration and sometimes people think here we can only do innovations, like ML and AI based application.

Actually, there are broader use cases in SAP BTP, you can literally build any type of business application and solutions (be it extension or custom app, integration, process heavy business logics, transactional or batch processing.. anything and everything!)

Here I’m trying to bring my real-world project experience with an end-to-end business application implementation process, as an example – check out the video to get the E2E SAP BTP (Business Technology Platform) use case with solution.

 

Before jumping into the video, you can just read few points which I highlighted below, it will help you to understand the architecture process.

Let’s say, there is a requirement to build a ecommerce application with below features:

  1. Ecommerce user interface is fiori + chatbot (user can place SO by just chatting with bot)
  2. If the order quantity is greater than some threshold limit, it will check the workflow rules and create work item for sales manager
  3. When sales manager approve the excess SO
  4. Sales Order (SO) will get created in BTP HANA cloud as stage layer
  5. Out of business hours during night time, those SO gets into backend SAP S/4 HANA system
  6. Whenever the SO gets created in backend system, user gets notification about it through whatsapp alert
  7. ……keep reading for more features in below sections

Okay, all the above sections are easily doable as per the below diagram, if we have all required APIs available.

 

Diagram1: Create SO directly into S/4 HANA

API%20architecture%20V1

 

Diagram2: Create SO from the HANA cloud stage layer

 

Now, let me point out some more very important features..

      8. Before giving the material information to the users (in FIORI or Chatbot) we need to execute all the below business logics

  • Material availability
  • Discount/Rebate calculations
  • Complex pricing calculation
  • Credit Limit Check

etc..

 

So, for all this above business logic features, APIs might not be right approach.

Why!?🙄

There could be various scenarios where APIs are not always good choice for backend service development. I can highlight some of them as below.

  • There would be lack of required OData API to fulfil all your business need
  • API would available but in discrete manner (to fulfil the business custom functionality, end up with 10-15 APIs)
  • All Standard APIs are not having all the required fields
  • API can be short of required business logic
  • APIs are not efficient for heavy business logics (collect data, looping, apply business) – against the principle of code-push-down
  • APIs are not good at performance if you want to deal with huge data in your app, as it use https protocol
  • Records pull Limitation of API – ex: SuccessFactors 1000 rows per page (The max records returned in the response of OData API is 1000 per page. If more than 1000 results are fetched by the query, then it will create more pages of results, and needed more effort to get and process the records, let’s say for analytical purposes)

So, we can say APIs are efficient in process integration but not always for data integration or business data logics, calculations (custom backend service development)

 

Solution???

We can get the data from our backend system into HANA cloud efficiently using SDI (Smart Data Integration) and build all the business logics on top of it.

Like Below:

Diagram3: This is complete diagram, watch video to get details

 

Please go through the video to get the complete end-to-end picture of these sample business usecase.

Hope this will give many of our fellow consultants and customers a good outlook, how the practical business scenario works in BTP.

And at the same time, would love to receive your feedback.

Thank you!

Assigned Tags

      4 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Anand Athanur
      Anand Athanur

      Hi Partha,

      I would like to clarify the following statement:

      • Records pull Limitation of API – ex: SuccessFactors 1000 rows per call

      It gives the impression that SuccessFactors APIs will limit you to only 1000 rows. That's not correct. If you use server side pagination, each page will fetch you 1000 rows. We have customers with 200,000-400,000 users.

      Thanks.

      Andy

      Author's profile photo PARTHA GOSWAMI
      PARTHA GOSWAMI
      Blog Post Author

      Hi Anand,

      In that use case, we faced difficulties with the API mechanism in our project, specially for analytical application where we needed all resulted data for further business data modeling.

      Updated:

      • Records pull Limitation of API – ex: SuccessFactors 1000 rows per page (The max records returned in the response of OData API is 1000 per page. If more than 1000 results are fetched by the query, then it will create more pages of results, and needed more effort to get and process the records, let's say for analytical purposes)
      Author's profile photo Raheel KHAN
      Raheel KHAN

      Excellent Partha. Great blog. Thanks for sharing.

      Just a though. Along with SAC Sales Analytics / Sales Predictions, it would be also great to show how all of this can also be further shown in an Digital Boardroom. So that would cover the management reporting as well.

      once again thanks for sharing.

      Regards

      Raheel

      Author's profile photo PARTHA GOSWAMI
      PARTHA GOSWAMI
      Blog Post Author

      Hi Raheel,

       

      Good Idea! and thank you for the motivational feedback. 🙂

       

      Regards,

      Partha

      https://www.linkedin.com/in/parthasap/