Develop with Joule in SAP Build Code

ale_biagi · ‎2024 May 16

This blog post is part of a webinar series to show you how to explore the Generative AI capabilities of SAP AI Foundation on SAP BTP, along with proof of concepts in the form of use cases. You will have the opportunity to earn a knowledge badge with the title "Generative AI development with SAP BTP" by taking the first three sessions or replays and passing its associated web assessment

Replay: Develop with Joule in SAP Build Code

Here we will explore Generative AI-based code development using Joule in SAP Build Code with a sample use case, following the Clean Core approach and extending SAP S/4HANA Cloud with side-by-side extensibility.

Here you will find the source code of the final solution developed in SAP Build Code with the assistance of Joule: SAP-samples / develop-with-joule-in-sap-build-code

Why Generative AI-based Code Development matters?

Let’s start by reviewing why Generative AI-based Code Development matters nowadays, especially in the context of the SAP ecosystem.

The Developers Dilemma

A recent research from IDC shows that developers spend only 20% of their time doing what they’re supposed to do: develop high quality business applications. The other 80% are spent performing peripheral overhead activities. This has a huge impact on their productivity.

Developers wear many different hats. Instead of spending their time coding developers are having to spend more time performing tests, implementing CI/CD, fine tuning performance and making sure the application is secure. All of this is necessary to create resilient applications, but in the end all developers want to be more productive and produce applications more efficiently.

Developers are more productive when they have the proper tools at their fingertips, when they can easily access data, and when they can reduce or eliminate tedious tasks.

To make a developer more productive, it comes at a cost. Developers need to implement a solution to handle CI/CD, another tool to access API’s, another tool to do transport management and they are always looking at ways to eliminate repetitive tasks. These are ways to increase developer productivity, but it comes at a cost when looking at solutions that come from multiple vendors to support development.

So, what is SAP doing to help with the Total Cost of Development and the Total Cost of Ownership when looking for application and extension development? That's exactly what we will discuss in the upcoming paragraphs.

How does this dilemma affect the SAP ecosystem?

All of you should have already noticed that the core of SAP’s strategy, lies in the Case for Cloud led by the Cloud ERP and its peripheral cloud solutions, powered by the Business Technology Platform as their foundation and driving force.

Such core strategy is executed through two main global programs:

RISE with SAP: focused on the installed base and private cloud;
GROW with SAP: focused on net new names and public cloud

So, what are the biggest roadblocks and challenges when executing this strategy?

For the cases of brown-field conversion, we noticed that technology-driven organizations have historically built on top of standard functionality to extend the capability to meet business needs. However, continuing to maintain decades-old technology now limits benefits and increases the cost of adopting new technologies.

Organizations cannot drive the next level of business transformation while carrying significant technical debt, because they are slower to innovate, more expensive to run and upgrade, and riskier to operate.

And for the cases of green-field implementation, what would be the challenge, then?

Thinking in terms of a cloud mindset, the concept of fit-to-standard should be applied in most of the cases whenever possible, leveraging the high flexibility provided by cloud solutions regarding configurations and personalization. When it’s not possible, a quick implementation for rapid turnaround of digital transformation should rely on the fast development of new loosely coupled solution extensions.

SAP's approach to fast-paced Cloud ERP innovation

And here is where the Clean Core Concept comes into play!

Such concept is essentially based in four main principles:

First, every solution extension should be built as a loosely coupled service instead of a tightly coupled monolithic application
Then, when building such services, as they’re loosely coupled, they’re supposed to extend the transactions from the backend system instead of modifying them in terms of either data and code
To do so, it’s imperative to strictly consume officially released APIs from the backend system, thus ensuring that changes to the core do not affect extensions as those APIs are maintained by SAP and backwards compatibility is guaranteed. This opens the path for continuous innovation through constant upgrades.
And last, but not least, by building extensions in a multi-tenant approach the extended functionality can benefit several customers with one single code-base.

By envisioning this concept as the backbone for continuously evolved cloud software, SAP has provided several tools and technologies in the last couple of years to make it reality for its customers and partners (such as UI5, the Cloud Application Programing Model framework – both NodeJS and Java – coupled with the SAP Cloud SDK – also NodeJS and Java – and the ABAP Cloud with its RESTfull Application Programming model approach).

All of this has been done so that brown-field ERP migrations can clean-up the backend system core and green-field new implementations do not touch the core.

In the context of S/4HANA extensibility, we have basically two scenarios: Core Solution Extensions (also known as On-Stack or In-App Extensions), which run in the same stack of the ERP and the so called Side-by-Side Extensions, running on BTP. I guess you all have already heard about it, right?

In the On-Stack Extensibility we have the Classic Extensibility, which usually modifies transactions’ code and data, and, consequently, is not clean core.

For a clean core approach with start with the Key User Extensibility provided by an extensive set of core personalization functionalities and, on top of those, we add the so called Developer Extensibility which is achieved through the Embedded Steampunk – that can be described as an On-Stack ABAP environment – leveraging ABAP’s RESTfull Application Programming Model (in short RAP).

For the sibe-by-side extensibility powered by SAP BTP (which is clean core by nature), we rely on the broad spectrum of development tools provided by SAP Build and SAP Build Code (which is the focus of this post), and the BTP ABAP Environment.

The dynamics of Generative AI into SAP ecosystem

Now, coming down to the Generative AI topic, here’s how we envision its dynamics into the SAP ecosystem.

The first thing that will change for customers (and SAP) is that we will use GenAI to Build Code. For customers that have legacy applications the typical strategy is to “do nothing”. Do nothing has the advantage of being low effort, but the downside is that it is high risk. Keeping old school applications rife with technical debt and disconnected to other business processes allows digital natives to leapfrog and disrupt your business. The second approach is to use traditional software development approach powered by humans. This is high effort and high risk: it is also really expensive. The third approach is to infuse Generative AI into software development process which we characterize as medium effort and medium risk. As time goes on our intuition this will become table stakes for all organizations. It is really what sets Generative AI apart from traditional ML in terms of disruption and economic value.

The second thing that is going to change is analytics: Generative AI is going to be table stakes for analytical applications. SAP cleverly acquired Ask Data over 2 years ago, and we are close to fully embedding it into SAC and as a pattern within Joule. We will see incredible capabilities emerge within SAC and other embedded analytical capabilities in the near future.

In enterprise applications Generative AI will emerge as a critical capability that powers automation, assistants, and agents. The most obvious example is Joule as an assistant that will power our major LoBs including Success Factors and SAP S/4HANA Cloud (Public Edition and Private Editions).

In this post we will focus on the first and clearly important vertical. For more information about the Generative AI topic in the SAP ecosystem, please refer to this link.

Overview on SAP Build Code and its Generative AI Capabilities

Since it's general availability announcement on March 27th, a lot of good content has been produced about the outstanding capabilities of SAP Build Code. To avoid "reinventing the wheel" we've compiled a short list of selected blog posts describing the many features of SAP Build Code:

We strongly recommend you read through those posts before proceeding with this one. You can also view the session replay for the live SAP Build Code overview.

The Paradigm Shift of Programming with Natural Language

So, there’s no doubt that Generative AI will bring a new paradigm to the context of software development within the SAP ecosystem by introducing Natural Language into the programming process.

To understand this paradigm shift, let’s picture a simple ERP migration to the cloud scenario where we usually have a bunch of tightly-coupled classic extensions which have to be converted into clean core extensions.

In such context we usually have one or more product or business or process owners (in our case here, Mary) reviewing such extensions and making specifications in natural language.

Mary, then, passes those specifications to John (the developer), who refine them by transforming them into prompts, and, in SAP BTP, there’s the SAP Build Code subscription containing the Joule copilot to which John passes the prompts. Based on such prompts Joule is able to generate the application’s data model, service definition, test data, Fiori elements UI and business logic as well as unit test scripts to test the logic.

Finally, using a one-click approach, John can deploy the application to either Cloud Foundry or Kyma.

The Flow of the New Paradigm

Now, let’s take a look into the flow of such process. So, Mary starts by reviewing functionality of legacy on-stack classic extensions in brown-field scenarios or defining new solutions requirements in green-field scenarios. In both cases she prepares the specifications in natural language

Here’s where John come into play, reviewing Mary’s specifications. He, then, performs prompt engineering (now called code generation prompt engineering) to prepare for the solution development.

Next, he enters the prompts in Joule, reviews and accepts (or not) the code, refining the prompts if necessary, does manual adjustments and some additional coding if required (and yes, there’s manual work in the process!), performing unit tests - these three steps are repeated until the desired outcome is achieved - and, finally, john deploys the solution handing it over back to Mary who’s responsible for the final testing and approval.

Development Use Case - Customer Loyalty Management App for Retailers

Well, for this post we designed an inspiring Use Case to showcase the development process with Joule in SAP Build Code in action. This use case is about a customer loyalty program management app for retailers, let’s start by understanding the business scenario:

The business scenario is a customer loyalty program management application for the business partners who make purchases in retailers. It’s a quite simple scenario managed by three personas:

The first one is Mary, an ERP administrator who manages products and business partners in S/4HANA Cloud which provides information to the second persona...
Jane, a loyalty program manager responsible for providing additional loyalty program data and monitoring purchases and redeemed rewards through an S/4 extension.
Finally, there’s Watson, a customer (actually a business partner in S/4) who basically makes purchases of selected S/4 products and redeems the corresponding rewards.

Solution Architecture

Now, let’s see how to design a solution architecture foundation to cover this business scenario:

On one side we have the SAP Business Technology Platform, hosting Cloud Foundry and Kyma run-times and, on the other, there’s the SAP Cloud Solutions with S/4HANA Cloud being one of them.

As previously mentioned, the ERP admin manages products and business partners in S/4HANA Cloud. Our Customer Loyalty solution extension is deployed to SAP BTP (in our case in Cloud Foundry) using SAP HANA Cloud as data persistence and reading Products and Business Partners from S/4HANA Cloud via Destination.

Finally, the Customer Loyalty Manager and the Customer can access the solution through a desktop or mobile device.

The highlighted CAP application is the solution extension that we will develop with SAP Build Code with the assistance of Joule throughout this post.

Fusion Development Approach

This architecture can be alternatively extended to leverage a UI built with SAP Build Apps instead of a standard Fiori UI. In this case, the CAP service is exposed as OData to SAP Build Apps via Destination. This is what we call Fusion Development: a combination of low-code/no-code citizen development with pro-code development.

In this post we will focus on the first approach: Fiori Elements UI.

Demo of the Finished Product

Now, let’s have a look at a live demo of the Customer Loyalty Management application in action:

Build the Use Case with Generative AI-based Code Development

Implementation Steps

Now that we got to know the generative AI-base code development with Joule in SAP Build Code, let’s have a look at the implementation steps that will be examined one by one in detail in the upcoming paragraphs.

We will start with a short demo on how to setup SAP Build Code in your SAP BTP global account
The first block of steps essentially relies on automatic code generation powered by Joule. The steps of this block are:
1. Build and Run the initial base CAP application…
2. Generate NodeJS code for business logic and unit tests…
3. Generate Fiori UI Apps through wizards and enhanced by Joule
The last block is focused on manual coding. Here we will:
1. Manually enhance the app to integrate with S/4HANA Cloud and...
2. Refine the data model and some annotations with manual code.

The above steps are quite well demonstrated in a series of hands-on videos listed below (or you can choose to view the session replay to watch them in sequence):

On-boarding
- Auto Code Generation
  - Build & Run the Initial App
    - Create Project
    - Data Model & Service
    - Data Model Enhancement(New feature in July 2024)
    - Sample Data & Run
  - Generate Business Logic & Unit Test
    - Business Logic
    - Unit Tests
  - Generate UI Apps
    - Generate Fiori Elements App
    - Generate Free Style UI App
- Manual Coding
  - SAP S/4HANA Cloud Integration
  - Manual Enhancement

Best Practices of Code Development with Joule in SAP Build Code

To get the best from SAP Build Code, here are some best practices that can be considered.

As we have seen in the previous demos, the structured guided development process with proven best practices has been innate in SAP Build Code, which we should follow throughout the whole development lifecycle.

The Storyboard allows you to develop applications using graphical editors and wizards. Use the Storyboard as the entry point to all the artifacts of the project.

In terms of UI, SAP Build Code provides the wizard templates for UI App creation, and the awesome graphical page editor for UI annotation. Use these wizards and graphical page editor instead of Joule for UI.

When using Joule in SAP Build Code, here’s a list of some best practices for prompt engineering:

As a rule of thumb for prompt engineering, the more specific, descriptive, and detailed the prompts are, the better are the results they yield.
Use explicit constraints (e.g. when to use simple associations or compositions in entity relationships).
For Data Modelling, please avoid using technical CDS terms in the Data Model description, such as aspect, enumeration, code list etc. which will be filtered by Joule.
Do not include any detail about the application logic in the Data Model, as it will be ignored by Joule.
In the application logic for actions and unit tests, give detailed information on how data is passed into the request.
For unit tests, provide the appropriate data for positive and negative cases to make sure the tests pass accordingly.
Always review the generated code or data, regenerate if necessary, iterate and fine-tune the prompt as much as needed.
And last, but not least, it doesn’t matter how much you try to be the most precise and perfect in your prompts, there will be always situations when editing the code directly will be quite more quicker and effective.

Still in the prompt engineering topic, when you are not sure how to get started on the solution and need some inspirations, here are some tips:

Get inspiration with the target solution name and its entities in Joule (e.g. “Create a customer loyalty management app with customer, purchase and reward redemption entities”). Joule will automatically generate 5 fields for each entity, so you can take it from here to enhance it further.
Alternatively, ask another LLM chatbot (e.g. Prompt Editor of SAP Generative AI Hub, ChatGPT, etc.) to describe the entities relationship of your solution as an inspiration for data model description(e.g. "Describe the the entities relationship model for customer loyalty management solution"), and edit the generated entities relationship if needed. Then pass it to Joule in SAP Build Code as the prompt for generating the data model.Describe Entity Relationship with Prompt Editor in SAP Generative AI Hub

Findings Summary of CAP Development with Joule in SAP Build Code

Here’s a brief summary of findings gathered during the development process of the customer loyalty extension, with short recommendations. You will notice that only the modification of the business logic and its corresponding unit tests is done with pure manual coding. All the rest can be achieved with full or partial assistance from Joule combined with the productivity tools and some possible manual coding. Our conclusion is that SAP Build Code proves in practice that it’s truly capable of turbocharging software development especially in the context of the SAP ecosystem

Findings Summary

Conclusions and Takeaways

These are the main takeaways we foresee when applying this new development paradigm in the context of the SAP ecosystem, by turbocharging software development leveraging SAP Build Code with the assistance of Joule Copilot:

Speed-up migration of legacy on-stack extensions to the cloud following the Clean Core principles
Safeguard technology investments by avoiding vendor lock-in and reducing TCO
Take advantage of a learning opportunity to quickly adopt industry standard technology and the new natural language programming paradigm
Accelerate time-to-market with quick prototyping and monetization of solution extensions
And last, but not least, prepare for fast-paced future innovations peculiar to cloud software either in the backend system and in the extensions themselves

Frequent Asked Questions:

During our webinar sessions, there are quite a number of questions have been raised. Here summarize the the most frequent asked questions and answers.

Q1: Can we use Joule to refactor an existing CAP project?

Answer: [Updated on July 30 2024] Yes, the feature of Refactoring existing CAP code using generative AI is already delivered in Q2 of 2024.
It allows developers using Joule to generate SAP Cloud Application Programming Model (CAP) data models, application logic, and unit tests to:

Add or remove an entity
Add, modify, or remove the properties of entities
Create or remove associations between entities
Get more support on a service projection definition

Please find more detail in this blog post.

Q2: Can the classic CAP NodeJS application(not generated by Joule) leverage the productivity tools such as Story Board, Page Editor etc.?

Answer: As of 14 May 2024, the productivity tools is now only available in SAP Build Code. However, it will be also available in SAP Business Application Studio for classic CAP NodeJS Application development, which is planned for Q4 2024. Please check here for more detail.

Q3: Can I use Joule in SAP Build Code for CAP Java Application development?

Answer: As of 14 May 2024, only CAP NodeJS Application development is supported with Joule in SAP Build Code. However, CAP Java Application development is planned in Q1 2025. Please check here for more detail.

Q4: How can I jump start with SAP Build Code?

Answer: Please follow this developer tutorial to have a test drive with SAP Build Code.

Q5: What license do I need to use SAP Build Code? Do I need SAP Generative AI Hub in my SAP BTP Global Account for it?
Answer: You will just need the license and entitlement of SAP Build Code in your SAP BTP account to use it. No extra license required.

SAP Build Code is available on Trial and the Free-tier plan of SAP BTP for free evaluation, and commercially available through SAP BTPEA and Pay-As-You-Go for production. For partners, it is also available in TDD license.

Q6: What are the differences between SAP Build Code and SAP Business Application Studio?

Answer: SAP Build Code is built on top of SAP Business Application Studio with generative AI capabilities for code generation, guided development and end-to-end unified development experience of SAP solution and extension. It offers unparalleled efficiency and effectiveness in application development.

Q7: What is the future of SAP Business Application Studio? We have seen the evolution of SAP Web IDE, then SAP Business Application Studio, Now SAP Build Code.

Answer: SAP Business Application Studio remain as a separated product for development of classic CAP application, Fiori application, mobile application development etc. It will be also evolved and improved overtime. For example, The productivity tools such as Story Board, New Fiori Template Wizard and Page Editor will be also available in Business Application Studio to improve the developer efficiency and experience. However, the generative-AI capabilities are exclusively available in SAP Build Code. Please check its roadmap for more detail.

Q8: When should I choose SAP Build Code? And When should I use ABAP side-by-side or On-stack extensibility for Clean Core development?

Answer: It is not a simple answer, which depends on the use case and technical capability of the team. Here you have use case pattern of SAP S/4HANA Cloud extension in high-level.

On-Stack Extensibility:

Adapt SAP Standard applications(UI, Custom Field, Custom Data Model) through public extension point
Full-stack application or new integration in embedded steampunk with public local API

Side-by-Side Extensibility:

Full-stack application: single tenant, multi-tenant SaaS, hub scenario.
Mobile applications
Process Automation among multiple systems

Please to go through Extension Architecture Guide for more details.

Q9: Will be similar generative-AI capability available for ABAP?
Answer: Yes. Similar generative-AI capability is planned for ABAP Cloud. Please stay tuned.

Q10: Is it Clean Core only applicable with side-by-side extensibility? How about On-Stack extensibility?Answer: Not, Clean Core can be through both On-Stack extensibility and Side-by-Side extensibility.

Q11: Is there any plan to make extension development easier for SAP S/4HANA Cloud with SAP Build Code?
Answer: There are some features planned in SAP Build Code about closer integration with ABAP, such as:

Additional Material

In this final section, we have compiled additional materials you can check, in order to deepen your knowledge on this topic: