How Joule for Developers and the ABAP AI SDK Change the Way We Build SAP Apps

In Part 1, we looked at Joule as the new front door to SAP – the place where work starts with a question instead of a tile.

In Part 2, we stepped behind that front door and explored SAP’s agent factory – skills as “thinking-fast” bricks, agents as “thinking-slow” planners, and Joule Studio + SAP Build as the workshop that ties it together.

Now in Part 3, we zoom in on the question many of us quietly ask:

“Where does ABAP fit in this Joule story?
Is it slowly fading out, or is SAP actually doubling down?”

The short answer SAP sent at TechEd Berlin 2025 (especially in session AD104 – Boost your ABAP development with SAP Joule for Developers) is clear:

ABAP is not going away.
It’s becoming one of the main ways we give Joule something intelligent to do.

Let’s unpack what that means in practice.

1. Why ABAP Is Still a First-Class Citizen in SAP’s AI Story

If you only watch generic AI conferences, you might think:

“LLMs → Python → cloud functions → ABAP is legacy.”

SAP’s actions tell a different story:

  • ABAP-specific code models.
    SAP is training models that understand ABAP and CDS patterns instead of treating ABAP like “weird C.” That’s why completions and explanations in Joule for Developers feel surprisingly on-target.
  • ABAP AI SDK + ISLM + AI Core.
    Instead of one-off HTTP calls to random LLMs, SAP wants AI in ABAP to run through AI Core (where models live), ISLM (where they’re registered as intelligent scenarios), and the ABAP AI SDK (how we call them).
  • Joule wired into ABAP tools.
    Joule for Developers shows up directly in ADT, RAP generators, and migration flows — exactly where ABAP developers spend their day.

The subtext is simple: SAP knows the real process logic still lives in ABAP, RAP, CDS, and HANA artifacts. Joule and agents don’t replace that logic; they consume it, as long as we expose it cleanly.

2. Joule for Developers: How It Actually Feels in the IDE

SAP markets Joule for Developers with three verbs: Accelerate, Empower, Transform. Let’s translate that into daily ABAP life.

2.1 Accelerate – less scaffolding, faster “first drafts”

Joule for Developers focuses on making common tasks faster:

  • ABAP-aware code completion.
    Completions are trained on ABAP and CDS, so they understand inline declarations, table expressions, and RAP patterns instead of guessing like a generic coding assistant.
  • “Explain this” for ABAP and CDS.
    You point it at a method, class, or CDS view and get a plain-language explanation. This is especially useful when you inherit code that has survived multiple releases and owners.
  • RAP app generation from natural language.
    You describe a small domain (“library with branches, books, borrowers”), and the RAP generator proposes entities, behaviors, and services. You still adjust, but you don’t start from a blank page.

You remain in charge. Joule doesn’t replace reviews, unit tests, or ATC checks — it just removes some of the boilerplate from your day.

2.2 Empower – ABAP as a client of AI Core (without spaghetti)

The Empower piece is about calling AI models from ABAP in a sane, repeatable way.

Instead of hand-coding HTTP calls to various endpoints, SAP’s preferred flow is:

  • Models (foundation or custom) live in AI Core.
  • They are exposed as intelligent scenarios in ISLM.
  • ABAP calls them via the ABAP AI SDK, passing structured payloads and receiving structured results.

From the ABAP side, that means:

“Call intelligent scenario X with payload Y, get result Z.”

You don’t need to know whether X is an SAP foundation model, a fine-tuned LLM, or your own TensorFlow model — which is exactly the level of abstraction you want in enterprise systems.

3. ABAP as a Tool Provider for Joule Skills and Agents

In Part 2 we said:

  • Skills = deterministic operations (“thinking fast”).
  • Agents = planners that chain skills (“thinking slow”).

ABAP and RAP fit naturally into the skills layer.

3.1 A simple example: scoring sales quotations

Take a concrete use case:

“Score my open sales quotations by probability to convert.”

Behind the scenes, a clean implementation might look like this:

  1. RAP action encapsulates the logic.
    A RAP business object exposes an action that selects relevant quotes, calls an AI model via the ABAP AI SDK, and returns a score or updates a field.
  2. SAP Build wraps the RAP action.
    A Build action or automation calls that RAP service with the right parameters and handles any workflow or approvals if needed.
  3. Joule uses that Build action as a skill.
    In Joule Studio, that Build action is registered as a skill that an agent can call when users ask: “Which quotations are most promising this week?”

From Joule’s perspective, your ABAP logic is just a reliable, well-typed tool.
From your perspective, long-standing ABAP know-how becomes reusable intelligence in the agent ecosystem.

3.2 Why ABAP/RAP are a good match for skills

ABAP is actually very strong as a skills provider:

  • RAP services and actions are explicitly typed, which LLM-based agents love.
  • Authorization checks and consistency rules sit naturally in ABAP.
  • You are close to the transaction truth in S/4 (no shaky replicated copies).
  • You can hide complex HANA logic or PAL/APL calls behind a stable API.

So a big part of “ABAP in the age of Joule” is simply this:

Take the ABAP logic you’re proud of
and expose it as small, agent-friendly skills.

4. AI-Assisted Migration: ABAP + Joule for ECC → S/4

Another area where ABAP and Joule meet is custom code migration.

You already know the current story:

  • ATC and the Custom Code Migration App flag incompatible code.
  • You read simplification items and manually figure out what to change.

With Joule in the picture, SAP’s direction is:

  • Explain findings in business language.
    Instead of “Field MATNR changed, please adapt code,” you get an explanation like: “This report groups sales by product using the old 18-character MATNR.
    In S/4, materials use a 40-character MATNR, so selections, joins, and outputs must be adapted to the new model.”
  • Suggest patterns for common adaptations.
    For recurring issues, Joule can propose code patterns or adaptation steps that you then review and adjust.

You still own the final decision, but Joule can reduce the cognitive load when you’re staring at hundreds of findings.

For many teams, this is a safe place to start experimenting: you’re not touching live business processes yet, but you’re already seeing whether AI explanations actually save time.

5. A Lightweight Roadmap for ABAP Teams

Instead of a long checklist, I suggest a very compact roadmap for ABAP teams in the Joule era:

  • 1) Try Joule for Developers on a real but small task.
    Pick one RAP object or CDS view and test: completions, “explain this,” generator support. Note where it truly helps and where you still prefer manual work.
  • 2) Identify 2–3 ABAP services that could become skills.
    Look for actions or reports that already deliver real value to business users. Ask: “If this were a skill Joule could call, what problem would it solve faster?”
  • 3) When you touch AI, go through AI Core + ISLM + ABAP AI SDK.
    Even for a simple LLM call, try to follow the SAP pattern. That way, whatever you build now can later plug into Joule agents without refactoring.

This is less a project plan and more a direction of travel: move ABAP artifacts toward being first-class tools in the AI and agent landscape.

6. Conclusion – Where Joule Stands Today, and Why ABAP Still Matters

If we stitch together the TechEd 2025 sessions from Joule and ABAP, Joule currently looks like this:

  • A cross-application assistant layer (Joule Action Bar, role-based assistants) that sits across SAP solutions and ties into Microsoft 365.
  • A growing ecosystem of skills and agents you can trigger through conversations or events and workflows.
  • Joule Studio as the place to design and manage those agents, tools, and grounding sources.
  • SAP Build as the automation engine underneath: workflows, RPA, events, approvals.
  • New capabilities like Deep Research, which move Joule from Q&A into “explain + compare + recommend.”

On the developer side, the “last fetches” for ABAP tell a consistent story:

  • Joule for Developers plugs into ABAP tools to help with scaffolding and understanding legacy logic.
  • ABAP AI SDK + ISLM + AI Core provide a standard path to call AI models from ABAP without custom plumbing.
  • AI-assisted migration features let Joule explain and gradually suggest patterns for adapting custom code to S/4.

My personal conclusion is simple:

Joule is getting smarter and more central every release,
but it’s only as useful as the skills and data we give it.

ABAP and RAP are still how we express a large part of that business logic.
If we treat our ABAP artifacts as skills for agents, and we plug AI through AI Core + ABAP AI SDK, we’re not spectators in SAP’s AI story — we’re core contributors.

For an “old” language, that’s a pretty good place to be.

If you want to trace these ideas back to the source, most of them came from SAP TechEd Berlin 2025 sessions AD104, AI823, AI105, and AD202v. Together they tell one story: ABAP is very much alive inside Joule’s AI future.