DJ Adams

Markdown previews in lf with leaf

2026-10-07T00:00:00Z

Today I'm finding I'm working Markdown even more, and the delta is mostly in read-mode, rather than write-mode. Reading agent and skill files, intent summaries, product requirement documents and more, especially in the context of Joule Studio.

I use the terminal file manager lf which is very configurable. The configuration mechanisms include a previewer file which is a shell script that calls different tools to preview different file types. Until just now, mine looked like this:

#!/bin/sh

case "$(basename "$1")" in
Dockerfile | *.dockerfile) highlight -O ansi --syntax Dockerfile "$1" ;;
*.jpeg | *.jpg | *.png) exiftool "$1" ;;
*.json) jq -C . "$1" ;;
*) batcat --style plain --color always "$1" ;;
esac

Here, I use specific tools for a small number of content types, and fall back to the default of bat for everything else.

Separately from the lf context I've been using glow to render Markdown in the terminal. It does a lovely job. But running it in the context of another tool like lf is a struggle due to it not sending ANSI codes.

Luckily, I just found leaf, another terminal based Markdown viewer. And with the inline rendering option I can force it to emit ANSI.

So now I've added another line to my case ... esac construct above:

*.md | *.markdown) leaf --inline ansi "$1" ;;

and I can now comfortably read Markdown content, rendered beautifully:

(Yes, that screenshot is deliberately meta).

Exploring Joule Studio skills

2026-10-05T00:00:00Z

The new Joule Studio CLI recently landed, in the form of jl. This is what we use on the command line to initialise a new Joule Studio project. What does that mean? Well, amongst other things, it means:

you work on your project using a coding agent harness such as Claude Code or OpenCode
such agent harnesses know about, and how to make use of skills
for Joule Studio powered development, there is a curated set of skills specifically designed for building enterprise agents and more

Initialising a new project not only creates some harness-specific configuration¹ but also retrieves this set of skills.

Skills retrieved

Here's what that looks like:

# /tmp
; jl init opencode myproj && cd myproj

Fetching system skills...
  ✓ agent (+37 resources)
  ✓ agent-evaluation (+8 resources)
  ✓ agent-extension (+9 resources)
  ✓ data-product (+11 resources)
  ✓ deploy-solution
  ✓ intent-analysis
  ✓ joule-studio-cli
  ✓ mcp-mock-config (+4 resources)
  ✓ mcp-translation-file
  ✓ n8n-workflow (+21 resources)
  ✓ product-requirements-document (+1 resource)
  ✓ setup-solution (+2 resources)
  ✓ specification (+1 resource)
✓ 13 skills initialized in myproj/.agents/skills.

Creating configuration files:
  ✓ myproj/opencode.json — created

OpenCode MCP config initialized: /tmp/myproj
# /tmp/myproj
;

The specific skills retrieved here will depend on various circumstances, you may see a slightly different list.

Browsing the skills

I wanted to explore these skills and get a better understanding of what they were. So I wrote a quick shell script (yes, I wrote it, not AI, to help maintain my cognitive fitness²), which allows me to browse them and get an overview.

Skills overview

The default is to render the skill content like this, in a pager:

Skills detail

If more details are sought, then setting the env var SB_DETAIL will cause the selected skill to be opened in a file browser, to allow viewing and browsing of any related resources, like this:

A brief look at the script

The shell script, sb, now forms part of my personal development environment (PDE) and also uses other tools that I have in there. Here's the script in its entirety:

#!/usr/bin/env bash

set -eo pipefail
declare FILEBROWSER=lf

fm() {

  awk '/^---$/ { if (n++) exit; next } n'

}

pv() {

  local skillfile=$1
  local width=$2

  fm < "$skillfile" \
    | yq -r '"\(.name|ascii_upcase) (\(.metadata.version))\n\n\(.description)"' \
    | fmt -s -w "$width"

}

export -f pv fm

main() {

  local loc="${1:-.}"
  local descwidth=$((($(tput cols) / 2) - 5))
  local selection

  selection="$(
    while read -r skill; do
      echo "$skill" \
        | awk -F/ '{print $4, $0}'
    done <<< "$(find "$loc" -name "SKILL.md")" \
      | fzf \
        --with-nth=1 \
        --preview "pv {2} $descwidth" \
      | cut -d' ' -f 2
  )"

  if test -z "$SB_DETAIL"; then
    glow -p "$selection"
  else
    "$FILEBROWSER" "$(dirname "$selection")"
  fi

}

main "$@"

The general idea is that SKILL.md files are found, passed to fzf for selection and preview³, and then a selected skill can be drilled into as well.

Here are some notes:

The fm function extracts YAML frontmatter which is expected to be found between two --- lines.
The pv function takes a skill file (fully qualified path and name) and also a width, uses fm to extract the frontmatter from it, and then uses yq to extract various values from the frontmatter, emitting them nicely, and line-wrapped to a certain width with the fmt command.

Like this:
```
SETUP-SOLUTION (1.0.0)

Set up the solution structure with a
solution.yaml and assets folder, each
containing an asset with an asset.yaml
file. Used to create a solution, to create
an asset and to set up a multi-asset
solution.
```
These two script-local functions are exported to be available to any subprocesses, useful for when fzf spawns a shell to run the command specified in the --preview option.
The main function will default to the current directory (.) if no location is specified to search for skills in.

It then:
- Calculates a width that is slightly less than half the current terminal width, to send to the fm function so that the skill info fits into fzf's default preview window shape.
- Uses find to search for the full paths of any SKILL.md files, which look like this: ./.agents/skills/setup-solution/SKILL.md.
- Processes these full paths with awk to emit the significant part (setup-solution in this example) to be used in fzf's selection list, and also the entire path, to be used for subsequent processing.
- The resulting output is then passed to fzf to present a simple selection and preview UI, as shown in the video.
- If a selection is made, cut is then used to select the second value that is emitted from fzf (the full path to the selected skill file).
- Finally, either (if the SB_DETAIL env var is set) the the configured file browser⁴ is invoked on the directory, or the Markdown rendered glow is used to render the actual SKILL.md content in paging mode for easy reading.

That's pretty much it. The script may change a little over time, but it works for me now, and removes the friction I had which was stopping me from exploring the detail of these important assets.

Footnotes

At the time of writing, this configuration consists of a section defining an MCP server and how to invoke it. More on that another time, perhaps.
Also, as shell scripts (particularly Bash shell scripts, my favourite) are what agents use to get their work done in many cases, it's always good to stay on top of things to really understand what they're doing.
I'm a big fan of fzf.
I use lf.

A community graph for people and things - onedevatlas

2026-10-01T00:00:00Z

Mike Zaschka, speaker, developer and active member of the community, has just announced "onedevatlas", which feels to me like something we need but didn't realise it.

The SAP community has produced various catalogues of tools and libraries in the past, and these have been great. But perhaps in today's age, where it's easier than ever to create new software, the need for awareness and knowledge of the tools and libraries that are being built, and of the people building them, is greater than ever. Moreover, the way such interlinked data can be maintained and consumed is perhaps also coalescing in parallel with how graphs of information are now core components of agentic computing. RDF anyone?

I am minded to think about the difference between previous catalogues, and today's ambitions with onedevatlas, as being similar to how it was between Yahoo! - a predominantly human-maintained catalogue of resources on the Web - and Google - which subsequently came along with a sledgehammer of a search engine that did away with the need for explicitly curated structure.

Seeing how Mike navigates between nodes and across arcs (yes, I did choose those words specifically) in his demo video, gives us a glimpse at what's promised. I for one am intrigued.

Mike's asking for feedback, so what are you waiting for?

Postscript

Mike followed up with some thoughts on what vehicle might be cool to use to explore the space. Mike's original demo video reminded me of Elite, the classic space trading video game first published for the BBC Micro (I had one) in 1984, with this spaceship:

I'd choose that :-)

CAP September 2026 release

2026-09-24T00:00:00Z

The September 2026 release of CAP is out. This is the first minor release following the major release upgrade in June of this year, and brings CAP Node.js to 10.1 and CAP Java to 5.1.

It's "only" a minor release, but goodness me there's a lot of great stuff. Let me take you through some of the highlights, which are split into different categories.

CAP Native AI

First there's the CAP Native AI category, which has come about mostly because there's been so much work in this area. After all, CAP is the foundation for much of our AI business solutions and central to our AI North Star architecture:

A new guide

It's been almost a full-time job keeping track of all the progress, and keeping our corresponding research and learning in line with what's being developed. Luckily there's an early incarnation of a new top-level guide called Native AI, which covers all the important topics:

Vector embeddings: natively supported by HANA, an essential mechanism for AI-powered searching, matching and recommendations (particularly useful in UIs).
MCP: a fundamental building block of today's agentic era, enabling agents to embellish their context and actually effect things in the wider world. The MCP adapter plugin is now GA, by the way!
A2A: like MCP, agent support in CAP is a mere annotation away, plus optional Markdown based skills and guardrails in this case. What's more, in addition to the mocking we're familiar with, we get a mocked LLM with the agents plugin plus a super useful UI for interaction. All out of the box, following CAP's classic developer-first approach. The agents plugin is in Gamma status right now.

You may wish to check out our current Hands-on SAP Dev live stream series on CAP in the age of AI which covers these topics and more.

There's even a section of this new guide that's all about integration with Joule; in the spirit of the release early, release often philosophy popularised by the one and only Eric S. Raymond in his essay The Cathedral and the Bazaar, it's a very early and raw release, just hinting at the structure and content to come.

A scenario to try out all the AI concepts

Going back to talk of agents, it's sometimes hard to conjure up a realistic-enough scenario to kick the tyres with, but CAP has you covered too with the XTravels Sample for AI; it's not too simple as to be underwhelming, but not overly dry and boring either. It allows us to explore lots of different concepts and protocols, such as subagency, delegation, A2A and MCP, as well as the more classic ideas of reuse, data APIs and more.

Much love for vector embeddings

While some features might come to CAP Node.js first, and then to CAP Java, or vice versa, things are generally eventually consistent. CAP-native support for vector embeddings is one such feature, already supported for CAP Java but now also for CAP Node.js.

The Vector Embeddings guide has also had an overhaul, which is where we can find the details of how to get embeddings working locally with SQLite which doesn't have native support for them. In a classic "magic made simple" way, the CAP team have done a serious amount of heavy lifting and configuration for us to emulate what's required. Kudos to the team.

Keeping our AI overlords happy

In my not so humble opinion, the CAP documentation, affectionately and unofficially known as "Capire", stands out as a great example of what we should all be striving for with respect to sharing knowledge, know-how and best practices.

The audience for this knowledge is not just limited to us humans, far from it. One way that we make great strides forward in agentic computing is to make sure our agents know what to do, and how to do it ... in the best possible way.

Agent skills are useful, for sure, but in the same way that we have stop-gap measures to cover the last mile between the scope of any given language model pre-training and the reality today, skills cover the delta between what we consider now as best practice, and what was the previous status quo in that regard.

To that end, it's more important than ever that documentation remains accurate and concise, and tells us - humans and LLMs alike - what to do and how to do it best, and in a way that is readable (and token-friendly too).

And so the team has made machine-friendly representations of the resource that is Capire, with the content and a sitemap in what is the lingua franca between humans and their AI overlords - Markdown.

For more on resources & representations, see 'Conneg' and the duality of weblogs and also Coffeeshop screencast: HTTP conneg, resource representations and JSON.

The CDS language family

The next category within which we find updates in the September 2026 release is the CDS language family. Briefly:

Boolean expressions are now wrapped in a CASE WHEN construct for HANA SQL, as bare predicates aren't permitted in the list of elements for selection.
It's now possible to extend views that already have a conditional clause; the new condition is combined with AND.
When using nested inline projections, we can now use the key keyword; typically this is needed when the key elements need to be extended to inside the projection to provide the uniqueness required.

These are minor but really nice improvements to the life of a domain expert or modeller, allowing us more flexibility and power as we continue to shift left, avoid bloat and moving parts, and - above all - fight the lazy agentic pattern of verbose and unnecessary generation of almost-immediate technical debt.

CAP Runtimes

Following the same category pattern as in the release notes, we now come to the runtimes category, for Node.js and Java.

In fact, before we bifurcate, there's a feature in this minor release that applies to both runtimes, relating to fuzzy search, a fault-tolerant search feature of SAP HANA Cloud. Results are now sorted by match score, unless that order is overridden by an $orderby parameter in the query.

Node.js

Beyond the pretty amazing new feature that provides support for vector embeddings with SQLite in a Node.js context, there's also a further move towards an ever more lighter weight of dependencies. This is especially relevant in today's world of software supply chain attacks, and an ever smaller surface area is always desirable.

For more on this, see Daniel Hutzel's keynote at reCAP this year.

To this end, and powered by the Node-native Fetch API that was embraced in the CAP Node.js runtime earlier this year, and which has allowed the team to shed a whole load of dependencies already, the reliance on the SAP Cloud SDK is also further reduced, down to a subset of destination types.

Basically, there are some authentication types such as OnPremise that are not supported yet - but for all the others, the Fetch-API plus CAP Node.js is all we need.

Java

There are quite a few updates for the Java runtime, including:

Support for the OData v4.01 JSON batch request format; v4.01 is the latest version in the OData family of standards and the move from multipart/mixed is welcome, as far as I'm concerned :-)

To learn more about OData, you might want to take a look at the OData Deep Dive mission.
When building a query, we can use the excluding() method to avoid having to specify a long list of the elements wanted, instead specifying a short list of the elements that are not wanted.
When building for hierarchy views (such as in Fiori Tree Tables) the @cds.default.order annotation can be used to specify the desired sort order of siblings.
The CDS Maven plugin used for CDS-related build steps has undergone some optimisations, for faster builds, a fast mode for the watch goal, and static implementation generation for faster reflection-free access.

Tools

Did someone say tools and the CLI? I'm here for that. First, shell completion, which has been around for a while, but has had a complete overhaul in this September 2026 release. The upshot is that it's much faster, more responsive and puts less stress on your shell as it works. Pretty awesome. Shell completion is available for Bash, Zsh, fish ... and even PowerShell!

Completions are available for the commands, options and then (where relevant) files and directories - completion for these is via standard shell mechanisms, which is great.

And it's nice to see IntelliJ getting lots of love - version 3 of the CDS plugin for that IDE now supports CDS 10, and has some nice new formatting options too.

Plugins

We're almost done, but we can't forget all the work that goes into the CAP plugins, can we? While they're not part of the core (the clue's in the name, right?) they can be essential components in our projects, and many of them are maintained by the CAP team themselves.

Here's a list of plugins that have had updates in this release:

The ORD plugin - which is now also open source 🎉 - now supports generating Open Resource Discovery definitions for lots of protocols, including OData and MCP.
The Attachments plugin now supports single attachments, instead of the standard list construct. There are also some major release properties that you need to pay attention to, in both runtimes.
The Notifications plugin for the Node.js runtime has been overhauled, and for Java there's an initial Alpha release too.
Last but not least, there's a new n8n¹ plugin, also in Alpha, for both runtimes. This plugin lets us trigger n8n workflows directly from CAP.

Wrapping up

For a minor release, that's pretty spectacular, I'd say. You can check out all the release notes, which themselves have links to further reading, in the usual place, and it's also worth keeping an eye on the 2026 Changelog too.

Happy learning!

Footnotes

The name "n8n" is a meta-contraction of "node[auto]mation".

Making OAuth 2.0 auth code flows work between containers and their host OS

2026-09-22T00:00:00Z

The example here relates to using the jl CLI, the command line tool for Joule Studio.

Unless otherwise stated, activities described here all happen in the container.

Starting the authentication flow

To use jl in a project, we need to first authenticate with a Joule Studio backend, using jl login, specifying the sign-in URL obtained from our Joule Studio "Develop > Authorizations" settings:

Here's what it looks like when jl login <url> is invoked (details elided for obvious security reasons, and lines split for readability):

; jl login "https://api.eu12.studio.joule.cloud.sap/cli/v1?appTid=bafe9663-...
&issuerUrl=https%3A%2F%2Fagy....accounts400.ondemand.com
&clientId=ad445849-..."

Opening browser to log in to https://agy....accounts400.ondemand.com ...
If the browser does not open, copy the URL below and open it manually.

  https://agy....accounts400.ondemand.com/oauth2/authorize
  ?response_type=code
  &client_id=ad445849-...
  &redirect_uri=http%3A%2F%2F127.0.0.1%3A43963%2Fcallback
  &code_challenge=tW6537dp_...
  &code_challenge_method=S256
  &state=uJW...
  &scope=openid+offline_access
  &app_tid=bafe9663-...

This is the start of a three-legged OAuth 2.0 login flow.

Visiting the URL

Assuming that there's no browser in the container to invoke, we'll need to explicitly select the URL and visit it manually, using a browser at the host OS level (macOS in my case).

If we look closely at the URL we'll see it includes a redirect_uri parameter which indicates the URL that we are to be redirected to once authentication in the browser has happened.

Here's that redirect_uri parameter and value from the URL above:

redirect_uri=http%3A%2F%2F127.0.0.1%3A43963%2Fcallback

and here's what it looks like without URL encoding:

redirect_uri=http://127.0.0.1:43963/callback

This particular value (specifically the port number) will be used in examples that follow.

How the flow works

The idea is that the jl login process spawns a temporary HTTP server which starts listening on that specific socket (i.e. localhost, or 127.0.0.1, plus the random port 43963), expecting a callback to a URL that thus starts http://127.0.0.1:43963/callback.

That callback comes via the browser, in that once the actual authentication process has been completed successfully in the browser (at the authorization server, api.eu12.studio.joule.cloud.sap), the HTTP response is a redirect, sending the browser to the redirect_uri (http://127.0.0.1:43963/callback) with various parameters - that convey information from the authorization server - added on to the end.

This set of parameters includes one called code which has the authorization code that jl needs.

Here's an example of what such a complete callback URL looks like (again, with some values elided, and lines split for readability):

http://127.0.0.1:43963/callback
  ?code=u7LpLuRfiutemU4GdWUbMH80E_...
  &iss=https%3A%2F%2Fagy....accounts400.ondemand.com
  &state=uJW...

Once the browser accesses that callback URL, the code and the other parameter values from the authorization server are effectively "received" by the temporary HTTP server, which is part of jl login, and are stored, completing the flow.

The problem

But the temporary HTTP server is running only in the container (where jl login was called), and the random port is not published from the container out to the container runtime's host.

And as the browser operation is in the context of the host OS, the redirection will fail (as there is nothing listening on localhost at that random port at the host OS level):

and thus the whole authentication flow will not be completed.

The solution

So we need to create a temporary tunnel from the host OS into the container, so that the browser can reach that HTTP server in there.

We might think to influence the jl login part by somehow supplying a fixed PORT value which will be used instead of it picking a random one, a value that we know about in advance and can have set up to have been published from the container.

Unfortunately:

we need to do this before we even create the container

there is no facility to specify this to jl login anyway¹

Using SSH remote port forwarding

To create a tunnel, we can use SSH's remote port forwarding, with the -R option.

The -L option creates a tunnel going from local² to remote, whereas the -R option creates one from remote (the host OS) back to local (the container), which is what we need in this case.

The port we need to specify on setting up the tunnel is the random port that was assigned in the creation of the temporary HTTP server (43963 in this example).

But that port is quite hard to make out from that long URL.

Extracting the redirect_uri port from the URL

So we can add some magic on to the end of the jl login <url> command to use tee to capture the output to a file, and then use process substitution to process what contents would normally be written to that file, using more shell commands, like this:

jl login <url> \
  | tee >(grep -Po '(?<=%3A)\d{5}')

The grep command option -P specifies we want to use Perl Compatible Regular Expressions (PCRE) and -o says that we just want the match, nothing else. The (?<=...) construct is a lookbehind assertion, the \d is a "digits" character class, and the {5} is a specific count of how many of that class we're trying to match.

In other words, "look for a string of 5 digits that are immediately preceded by %3A (the URL encoded version of the colon (:)) and emit just those 5 digits".

For example:

jl login "https://api.eu12.studio.joule.cloud.sap/cli/v1?appTid=..." \
  | tee >(grep -Po '(?<=%3A)\d{5}')

emits not only the regular output, like this (long URL has been split over multiple lines for readability):

Opening browser to log in to https://agyx....accounts400.ondemand.com ...
If the browser does not open, copy the URL below and open it manually.

  https://agyx....accounts400.ondemand.com/oauth2/authorize
  ?response_type=code
  &client_id=...
  &redirect_uri=http%3A%2F%2F127.0.0.1%3A43963%2Fcallback
  &code_challenge=...
  &code_challenge_method=S256
  &state=...
  &scope=openid+offline_access
  &app_tid=...

but also, thanks to the | tee >( ... ), emits this:

Creating the tunnel

At this point, we can open up a new shell session in the container (e.g. a new pane in tmux) and run:

ssh -R 43963:localhost:43963 <username>@host.docker.internal

where <username> is your host OS user (the username on macOS in my case).

Authenticating

Once we've successfully SSH'd to the host OS, and have the host OS prompt, the tunnel exists.

We can now click the URL and the authentication flow will work correctly, taking us first to the authentication server, then redirecting us successfully via the tunnel back to the temporary HTTP server initiated by jl login, and the authentication information will be stored:

✓ Logged in to https://api.eu12.studio.joule.cloud.sap/cli/v1.
  (session expires 9/24/2026, 1:18:14 AM)

Success!

Wrapping up

The different layers presented by containers and their host OSes, especially in OAuth flow scenarios like this, can be tricky, but understanding what's happening, and using standard tools to address the situation, turns out to be quite straightforward.

Footnotes

I've looked :-)
Here, "local" refers to the container, i.e. where ssh is invoked.

Notes on simple agentification of a CAP service

2026-08-25T00:00:00Z

Baseline

The plugin for building agents based on the A2A protocol is here.

I start with the simple bookshop project and add the plugin:

gh repo clone capire/bookshop \
  && cd bookshop \
  && npm add @cap-js/agents

Agentification

I apply the @agent annotation to the CatalogService in srv/cat-agent.cds:

using { CatalogService } from './cat-service';

annotate CatalogService with @agent;

The @agent annotation was added recently so this step is not needed now, except to illustrate how simple it is to add, and where we might consider doing that, i.e. separately.

Startup and development mode

I start up a CAP server and ask for debug level output for the agents component:

DEBUG=agents cds watch

and observe the log output:

[agents] - Adapter initialized { service: 'CatalogService' }
[cds] - serving CatalogService {
  at: [ '/odata/v4/browse', '/rest/browse', '/hcql/browse', '/a2a/browse' ],
  decl: 'srv/cat-service.cds:3',
  impl: 'srv/cat-service.js'
}

http://localhost:4004/a2a/browse is an A2A JSON-RPC endpoint that is expecting POST requests
http://localhost:4004/a2a/browse/.well-known/agent-card.json is the agent card
http://localhost:4004/a2a/browse/preview/ is a helper preview page that provides a chat UI

In this default (development) mode, the plugin will mock an LLM, sending a response like this to a chat message:

[Mock LLM] This is a mocked response from @cap-js/agents development mode. No real LLM was invoked.

Tool result: count: 5 data[3]{createdAt,modifiedAt,ID,author,title,genre,stock,price,currency}: "2026-08-25T12:44:18.880Z","2026-08-25T12:44:18.880Z",201,Emily Brontë,Wuthering Heights,Drama,12,"11.11",£ "2026-08-25T12:44:18.880Z","2026-08-25T12:44:18.880Z",207,Charlotte Brontë,Jane Eyre,Drama,11,"12.34",£ "2026-08-25T12:44:18.880Z","2026-08-25T12:44:18.880Z",251,Edgar Allan Poe,The Raven -- 11% discount!,Mystery,333,"13.13",$

Connecting to a real LLM

Connecting to an actual LLM is described on the plugin's Connectivity page.

I have access to an AI Core instance by means of a service key in a file called aicore.json in the project's parent directory. I also know that the orchestration facilities that are needed are not in the default resource group, for that instance, but in a resource group called "codejam-genai".

Set the AICORE_SERVICE_KEY env var

Assigning the service key JSON data to the environment variable AICORE_SERVICE_KEY will allow the plugin to make the connection.

I use jq's --compact-output (-c) to remove whitespace and have the entire JSON value as one string:

export AICORE_SERVICE_KEY="$(jq -c . ../aicore.json)"

Specify the LLM type and resource group

I need to specify the resource group "codejam-genai", and for that I can use some plugin configuration, specifically cds.requires.llm.resourceGroup. As I'm going to be specifying a child of the llm node here, I should be sure to explicitly specify the value for the kind too (based on the way configuration merging takes place). This makes sense anyway as resource groups are somewhat AI Core specific.

There's already a .cdsrc.yaml file in the project with a cds.requires.auth node, so I add the configuration to the end, so it looks like this:

cds:
  requires:
    "[production]":
      auth: mocked # as a sample app run with mocked auth also in production
    llm:
      kind: 'aicore'
      resourceGroup: 'codejam-genai'

Restart

After restarting the CAP server (the "watch" mode ignores YAML file changes right now) the response to the chat message is from a real LLM, and looks like this:

Hello! How can I help you today? I can assist you with browsing books, checking availability, or placing orders through the CatalogService. Feel free to ask anything! 😊

Here's what is emitted in the CAP server log, too:

[agents] - request {
  conversation: '-',
  service: 'CatalogService',
  method: 'message/send',
  text: 'hi'
}
[agents] - Initializing LLM { model: 'anthropic--claude-4.6-sonnet', deepAgent: false }
[agents] - completed {
  conversation: '407e65ad',
  service: 'CatalogService',
  duration: '3.9s'
}

Summary

This is just the basics, scratching the surface. The plugin also has support for defining an agent's identity, behaviour and skills in Markdown, plus a human-in-the-loop feature. There's plenty of more advanced facilities too.

But for now, so far so good!

Balancing context size and callable tool metadata with CAP's MCP adapter

2026-08-23T00:00:00Z

CAP supports the Model Context Protocol, and treats it beautifully as "just another protocol". The support comes in the form of the @cap-js/mcp plugin, which has these feature flags:

{
  "cds": {
    "mcp": {
      "per_action_tool": false,
      "prefix": false,
      "format": "cql"
    }
  }
}

In this post I want to explore the per_action_tool setting.

Sample service

To illustrate, let's use the classic capire/bookshop sample project which, amongst other resources, has a service defined in srv/cat-service.cds like this:

using { sap.capire.bookshop as my } from '../db/schema';

service CatalogService @(path:'browse') {

  /** For displaying lists of Books */
  @readonly entity ListOfBooks as projection on Books {
    *, currency.symbol as currency,
  }
  excluding { descr };

  /** For display in details pages */
  @readonly entity Books as projection on my.Books {
    *, // all fields with the following denormalizations:
    author.name as author,
    genre.name as genre,
  } excluding { createdBy, modifiedBy };

  @requires: 'authenticated-user'
  action submitOrder ( book: Books:ID, quantity: Integer );
}

// Serve via OData, HCQL and REST
annotate CatalogService with @odata @hcql @rest;

The service has:

entities ListOfBooks and Books
an unbound action submitOrder (for which authentication is needed)

We'll begin by adding the MCP adapter plugin to the project like this:

npm add @cap-js/mcp

Extending the service definition

Extending the definition slightly will help us dig in and understand the different approaches that we can control with per_action_tool.

To keep things simple, let's just add content to the existing srv/cat-service.cds.

First, let's add a doc comment to the submitOrder action, so it looks like this:

  @requires: 'authenticated-user'
  /** Place an order for a given book, specifying quantity required */
  action submitOrder ( book: Books:ID, quantity: Integer );

Now let's define another action in the service, by adding this at the end of the file:

extend service CatalogService with {
  /** Return the total value of all stock */
  action stockValue ();
}

Finally, let's actually add the @mcp annotation, on a further line at the end of the file:

annotate CatalogService with @mcp;

A running CAP server

We'll be running a CAP server, started with DEBUG=mcp cds watch, throughout the explorations here; the log output that we need to know about looks like this:

[mcp] - Adapter initialized { service: 'CatalogService' }
[cds] - serving CatalogService {
  at: [
    '/odata/v4/browse',
    '/rest/browse',
    '/hcql/browse',
    '/mcp/browse'
  ],
  decl: 'srv/cat-service.cds:3',
  impl: 'srv/cat-service.js'
}
[mcp] - registering MCP services: [ 'CatalogService' ]
[cds] - server listening on { url: 'http://localhost:4004' }

This tells us that the MCP adapter is accessible at http://localhost:4004/mcp/browse.

Inspector

To assist exploration, let's use the MCP inspector tool, which can be operated in GUI, TUI or CLI mode. We'll use the CLI mode here to keep things simple.

The basic inspector CLI call to connect to and interact with the MCP server provided by the MCP adapter looks like this:

npx @modelcontextprotocol/inspector \
  --cli
  --header 'Authorization: Basic YWxpY2U6Cg==' \
  --transport http \
  --server-url http://localhost:4004/mcp/browse

plus some actual method, with the --method option.

We're sending an auth header - the encoded value is alice: (there's no password) as alice is one of the users available by default in the mocked authentication strategy which is in effect by default when running in development mode - see Local-first dev with CAP Node.js - mocking auth. This is to address the authenticated-user pseudo-role requirement for the submitOrder action later.

Tools list

By default, the MCP adapter offers up to three tools per service annotated with @mcp, in response to the tools/list request.

We can see this with the inspector, using the basic CLI call plus --method tools/list:

npx @modelcontextprotocol/inspector \
  --cli
  --header 'Authorization: Basic YWxpY2U6Cg==' \
  --transport http \
  --server-url http://localhost:4004/mcp/browse \
  --method tools/list \
  > tools.json

This returns quite a bit of output, in JSON, so we're redirecting that to a tools.json file, where we can use jq to explore it separately.

Let's first reduce the JSON response to simply see what the tool names are and how they're described:

jq '[.tools[]|{(.name):.description}]|add' tools.json

Echoing Perl's TMTOWTDI tradition, one could also achieve the same result with the jq expression .tools|map({(.name):.description})|add.

This produces:

{
  "describe": "Describe the data model of CatalogService service. Returns an overview of all entities and actions with descriptions. Specify 'entity' to get element details, or 'action' to get parameter details.",
  "query": "Query any entity in CatalogService service.Ensure to first use the `describe` tool to discover an entity's available fields.",
  "call": "Call an unbound action or function in CatalogService service. Use describe to discover available actions and their parameters."
}

The describe and query tools are fairly standard and nearly always supplied (except when the caller has no access). The call tool, returned when there are actions or functions available, is the focus of this post and of the per_action_tool setting.

The generic call tool

Let's dig in to the details supplied with the call tool. With:

jq '.tools[]|select(.name=="call")' tools.json

we see this output:

{
  "name": "call",
  "description": "Call an unbound action or function in CatalogService service. Use describe to discover available actions and their parameters.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "action": {
        "type": "string",
        "enum": [
          "submitOrder",
          "stockValue"
        ],
        "description": "The action or function to call"
      },
      "parameters": {
        "description": "Parameters for the action. Use describe to see available parameters.",
        "type": "object",
        "properties": {},
        "additionalProperties": {}
      }
    },
    "required": [
      "action"
    ],
    "$schema": "https://json-schema.org/draft/2020-12/schema"
  },
  "annotations": {
    "readOnlyHint": false,
    "destructiveHint": true,
    "idempotentHint": false,
    "openWorldHint": false
  }
}

If we stare at this for a moment, we see that it's rather generic.

Moreover, the description includes instructions that require the use of the describe tool first, before working out which (if any) call can be made. The info we have in our doc comments ("Place an order for a given book, specifying quantity required" and "Return the total value of all stock") aren't even surfaced here.

All we have is a simple enumerated list of action names in inputSchema.properties.enum.

Per-action tools

Let's now contrast that "describe" + "query" + single "call" tool set, with what we get if we set the MCP adapter plugin's per_action_tool feature flag to true. We can do that in many ways; let's keep things simple and add a mcp.per_action_tool property to the .cdsrc.yaml file that already exists in the project, like this:

cds:
  mcp:
    per_action_tool: true
  requires:
    "[production]":
      auth: mocked # as a sample app run with mocked auth also in production

When we restart the CAP server, and make a tools/list request again, we get the same response detail for the describe and query tools, but the detail for the actions available looks completely different.

Let's examine the JSON output again. First, with .tools|map({(.name):.description})|add we can see the tools and their descriptions:

{
  "describe": "Describe the data model of CatalogService service. Returns an overview of all entities and actions with descriptions. Specify 'entity' to get element details, or 'action' to get parameter details.",
  "query": "Query any entity in CatalogService service.Ensure to first use the `describe` tool to discover an entity's available fields.",
  "submitOrder": "Call action submitOrder in CatalogService",
  "stockValue": "Return the total value of all stock"
}

This time, instead of the generic call tool, we get individual tools, complete with unique descriptions (from the doc comments).

Also, note that the simple call tool info earlier didn't have any parameter detail for either of the actual actions; instead, there was an instruction to "use describe to see available parameters".

But now, for each callable action, all the parameter details are available. Let's look at the details for the submitOrder action, with .tools[2]:

{
  "name": "submitOrder",
  "description": "Call action submitOrder in CatalogService",
  "inputSchema": {
    "type": "object",
    "properties": {
      "book": {
        "type": "integer",
        "minimum": -9007199254740991,
        "maximum": 9007199254740991
      },
      "quantity": {
        "type": "integer",
        "minimum": -9007199254740991,
        "maximum": 9007199254740991
      }
    },
    "$schema": "https://json-schema.org/draft/2020-12/schema"
  },
  "annotations": {
    "readOnlyHint": false,
    "destructiveHint": true,
    "idempotentHint": false,
    "openWorldHint": false
  }
}

The included inputSchema describes the two properties required (book and quantity).

So in this case, no pre-action-call discovery step is needed, no extra describe step need be executed just to find out what these actions are, whether they might be useful and how to call them.

Comparing the options

Which option is better? per_action_tool: true or per_action_tool: false? Well, that depends of course. There's a balance to be had.

Returning a single generic call tool, merely flagging that there's a facility to make calls to specific actions and functions, with a simple list of them, makes for quite a concise response. This in turn means that the size of the context where this is stored remains relatively small. But the downside is that there are going to be extra roundtrips required to accomplish anything meaningful, as a describe call is necessary to find out more.

Describing separate call-type tools means that the context is potentially going to get much larger, if there are many actions and functions available. However the upside is that they're likely immediately comprehensible and usable.

The MCP adapter plugin team has taken the decision to default to "safe" and simple, to avoid exploding the context size unexpectedly, which makes sense. In other words, the default is per_action_tool: false.

Only you can make the decision to change the value for that feature flag, based on your service definitions, and other circumstances. Certainly if you only have a small number of actions, then it's worth considering turning on the per_action_tool flag. But if you have many, you may wish not to.

But now at least you know what the flag does, why, and how it affects things.

Further info

This topic is also covered in Part 3 of CAP in the age of AI.

Knowledge and netiquette in today's AI era

2026-07-29T00:00:00Z

I'm walking in the cool mornings at the moment, as the problem with my right knee is preventing me from running right now, which is driving me bonkers.

View from the narrowboat stern this morning just before I set off on the walk.

On the walk this morning, I listened to a couple of episodes from two great podcasts I'm subscribed to - Hanselminutes and Soft Skills Engineering.

Knowledge engineering and lifecycle management

In Stack Overflow for the Agent Era - with VP of Product Alex Lato, Scott Hanselman talks to Alex Lato about how Stack Overflow is evolving, driven by, and perhaps driven towards, the agent substrate. It's a fascinating conversation between two experienced folks, and well worth a complete listen. What I took from this conversation is that we may see a new knowledge-related discipline emerging, or at least a stronger focus in that direction.

Scott and Alex talked a lot about knowledge provenance, reliability, attribution and ranking, which made me wonder about what knowledge engineering, perhaps knowledge lifecycle management, might look like today and tomorrow. This knowledge, and how agents source, relay, condense, combine and share it, is originally from the hard work of folks on Stack Overflow and in other communities sharing what they know, but how will that evolve when the layers of reuse coalesce over time?

One other fascinating aspect that Alex shared, and Scott picked up, is that in Stack Overflow's new venture here, agents, and their activities, are ultimately and strongly tied to human "owners", with the provenance - but more importantly reputation - that is part of that association.

Netiquette and how our connections are changing

In Soft Skills Engineering's Episode 520, hosts Dave Smith and Jamison Dance are entertaining and fun to listen to as usual, and the word "netiquette" is brought up in the context of what one should and should not do in today's era of AI assisted work.

Netiquette was originally an umbrella term for how to behave in the brave new world of Internet-based communication - for example how and when to use the To:, Cc: and Bcc: in email correspondence (on which I have thoughts too), when to reply, and how formal, or not, one should be, in various situations. That concept of "how to behave" surfaces in this conversation again where Dave and Jamison talk about their (and others') experiences with folks copy-pasting wads of generative AI output to each other, sometimes without even reading it themselves.

Following that train of thought, they reach a conclusion that is not an entirely pleasant one, that the LLM facilities we have at our fingertips today is causing the death of the human connection, a connection that originally evolved (in our tech workplaces) almost as a by-product of collaborating on design and code, to get it right. When we have LLMs do a lot of that for us, where's the context in which we maintain that loose but essential human connection - the shared jokes, the gently snarky but well-meaning asides?

If you're not subscribed to these podcasts, I recommend you remedy that today!

Timeless principles, agnostic design and the power of CAP's abstractions

2026-07-24T00:00:00Z

I wrote recently about Hexagonal Architecture, alternatively known as Ports & Adapters, in Book Overflow and two architectural patterns in CAP. The core idea is based on having a deliberately agnostic approach to mechanisms, resources and services beyond - located in the outer concentric circles, as it were - a given core service.

Think of this in a similar way to "late cut" integration, where the actual location, shape of, and connection to a required service is left until the last minute.

The agnostic design approach is not new, and indeed as Daniel mentions in his keynote, has in the past been referred to as "minimal assumptions", which crops up in various disciplines, including statistics & data analysis, where it conveys the approach of "deriving valid conclusions using the fewest possible restrictive parameters"¹.

This approach brings many advantages, not least the ability for CAP developers to enjoy a tight and rapid development loop, where local-first is the mantra, and mocking plus remote proxies are key enablers.

Moreover it allows us to shift left the important business of design, including auth, consumption nuances and extended domain design, exactly because we can shift right the dirty work of connectivity and gnarly setups.

But that's only one half of the story. The other half is that, right from the get-go, we're ready to adapt and adopt new services, or different endpoint locations, because we haven't tightly coupled our app or service design with a specific technology or protocol.

The wonder of cds.service.bindings

To illustrate this, I want to convey the wonder of one of Daniel's live demos in the keynote. Indeed, this blog post was triggered by something very specific, when Daniel accessed cds.service.bindings in the cds REPL.

I have talked about the local service binding registry (~/.cds-services.json) and explained its purpose, in many places, including:

CAP local development (workshop)
Service integration with SAP Cloud Application Programming Model (CodeJam)
A hands-on tour of CAP (CodeJam)

Let's break down what we mean by "local service binding registry":

local: it's local to my machine, both highlighted and constrained by the location of this file, the developer user's home directory² - you can't get much more "my machine" specific than that!
service: required services, that are likely going to be remote in a production scenario
binding: information that is needed to be able to connect and authenticate with such services, such as URL & credentials, often collected into a destination in production scenarios
registry: a sort of table of contents, or list of what's currently available

Such a local registry is at the heart of how agnostic design's innermost set of concentric circles (the local machine) can function in CAP.

Seeing Daniel retrieve this binding information directly in the cds REPL was a magic moment for me. It both elevated the combined concepts I've mentioned above, plus made the registry content tangible and thus worthy of attention.

Exploring the first two circles

Let's explore the two innermost circles³, the ones within the local machine.

 +--------------------------+
 |     external process     |
 | ************************ |
 | * +------------------+ * |
 | * | separate process | * |
 | * |  +------------+  | * |
 | * |  | in-process |  | * |
 | * |  |            |  | * |
 | * |  +------------+  | *<---- local machine
 | * +------------------+ * |
 | ************************ |
 +--------------------------+

We can run a single CAP server, that will serve one or more services, via one or more protocols. That's denoted by the core "in-process" circle in this diagram here. When we have a required service without service bindings available, these are mocked also by the same CAP server.

At this point I often refer to the help text for the --with-mocks option for cds serve which goes like this (emphasis mine):

Use this in combination with the variants serving multiple services. It starts in-process mock services for all required services configured in package.json#cds.requires, which don't have external bindings in the current process environment. Note that by default, this feature is disabled in production and must be enabled with configuration features.mocked_bindings=true.

We can run multiple CAP servers on the same machine, choosing different ports⁴. From the perspective of the "in-process" innermost circle, the next circle out, marked "separate process", represents these other CAP servers.

This "local machine" universe, combined with CAP's local-first affordances, is exactly what we need to experiment with agnostic design here.

This demo follows roughly the same path as Daniel took in his keynote, with some slight variations.

Start monitoring the local service binding registry

It's helpful to see what happens as things progress, so let's use one terminal window to keep an eye on the local service binding registry's contents. Here's how I would do it:

touch ~/.cds-services.json \
  && watch -c jq -C . ~/.cds-services.json

I use touch first to make sure the file exists before trying to monitor it; this command will create the file, empty, if it doesn't. If it has already been populated with information from previously running CAP servers (that have since been stopped) then it may already contain some empty registry structure that looks like this:
{
  "cds": {
    "provides": {},
    "servers": {}
  }
}

Create a simple CAP project A

First, let's create a simple tiny-sample facet based CAP project "A" then immediately launch a cds REPL and have the CAP server start up⁵:

cds init --add tiny-sample proj-A \
  && cds repl --run proj-A

Log output like this will be emitted:

Adding facet: tiny-sample

Successfully initialized CAP project
Continue with: code proj-A

Welcome to cds repl v10.0.3
[cds] - using bindings from: { registry: '~/.cds-services.json' }
[cds] - loaded model from 1 file(s):

  proj-A/srv/cat-service.cds

[cds] - connect to db > sqlite { database: ':memory:' }
  > init from proj-A/db/data/CatalogService.Books.csv
/> successfully deployed to in-memory database.

[cds] - using auth strategy { kind: 'mocked' }
[cds] - serving CatalogService {
  at: [ '/odata/v4/catalog' ],
  decl: 'proj-A/srv/cat-service.cds:1'
}
[cds] - server listening on { url: 'http://localhost:33475' }
[cds] - server v10.0.3 launched in 209 ms
[cds] - [ terminate with ^C ]

------------------------------------------------------------------------
Following variables are made available in your repl's global context:

from cds.entities: {
}

from cds.services: {
  db,
  CatalogService,
}

Simply type e.g. CatalogService in the prompt to use the respective objects.

So far, so (very) good. Notice that the CAP server is started on a random port, which is the default behaviour when running in a REPL context (as it's effectively more of a "throwaway" server that might be spun up to run some tests against).

Notice also that there's a service called CatalogService that's available.

Check the local service binding registry

In the registry, we now see something like this:

{
  "cds": {
    "provides": {
      "CatalogService": {
        "endpoints": {
          "odata": "/odata/v4/catalog"
        },
        "server": 58557
      }
    },
    "servers": {
      "58557": {
        "root": "file:///tmp/proj-A",
        "url": "http://localhost:33475"
      }
    }
  }
}

This tells us (and any CAP server running in the same binding context, i.e. this local machine) that there's a service called CatalogService that is provided. There's information on what the endpoints are, and what protocols these endpoints speak, and also the URL. In other words, this is the binding context for the CatalogService that is listed as being provided (note the cds.provides property that contains it)!

Connect and consume CatalogService locally

Within the REPL, if we now have a quick look at the CatalogService, we see that it's an instance of the ApplicationService class, effectively a locally available service:

> CatalogService
ApplicationService {
  handlers: [EventHandlers],
  name: 'CatalogService',
  options: [Object],
  kind: 'app-service',
  ...
  path: '/odata/v4/catalog',
  '$linkProviders': [Array]
}

We can consume that service directly, whereupon we'll get the result we probably expect:

> await CatalogService.read(`Books`)
[
  { ID: 1, title: 'Wuthering Heights', author: 'Emily Brontë' },
  { ID: 2, title: 'Jane Eyre', author: 'Charlotte Brontë' },
  { ID: 3, title: 'The Raven', author: 'Edgar Allen Poe' },
  { ID: 4, title: 'Eleonora', author: 'Edgar Allen Poe' },
  { ID: 5, title: 'Catweazle', author: 'Richard Carpenter' }
]

We can be explicit and connect to the service, a "required" service, like this, too:

> catsrv = await cds.connect.to('CatalogService')
ApplicationService {
  handlers: [EventHandlers],
  name: 'CatalogService',
  options: [Object],
  kind: 'app-service',
  ...
  path: '/odata/v4/catalog',
  '$linkProviders': [Array]
}

We effectively get the same ApplicationService instance, and can use it in the same way:

> await catsrv.read(`Books`)
[
  { ID: 1, title: 'Wuthering Heights', author: 'Emily Brontë' },
  { ID: 2, title: 'Jane Eyre', author: 'Charlotte Brontë' },
  { ID: 3, title: 'The Raven', author: 'Edgar Allen Poe' },
  { ID: 4, title: 'Eleonora', author: 'Edgar Allen Poe' },
  { ID: 5, title: 'Catweazle', author: 'Richard Carpenter' }
]

Consume the provided service from elsewhere

We don't even need to set up a second project to require (consume) this provided service, we can just start a second cds REPL session and do everything there.

While keeping the current cds REPL session open, let's start a second cds REPL session in a new terminal window. This should represent a distinctly separate CAP consumer context and so let's start this second cds REPL session completely separate from the proj-A/ area to emphasise that point. Daniel used his home directory for that, so let's do that too:

cd ~ && cds repl

Fetch the service bindings

In the session that we get, which is announced like this:

Welcome to cds repl v10.0.3
>

we can access the service bindings, like this:

await cds.service.bindings

This fetches the service bindings from the registry and makes them available in the current process:

[cds] - using bindings from: { registry: '~/.cds-services.json' }
Bindings {
  provides: {
    CatalogService: { endpoints: { odata: '/odata/v4/catalog' }, server: 58557 }
  },
  servers: {
    '58557': { root: 'file:///tmp/proj-A', url: 'http://localhost:33475' }
  }
}

We even see that log line familiar to us from our cds watch sessions, being explicit about from where the bindings are being fetched:

[cds] - using bindings from: { registry: '~/.cds-services.json' }

Connect to the service

Like we did in the other cds REPL session, let's now use cds.connect.to:

> cs = await cds.connect.to('CatalogService')
RemoteService {
  handlers: [EventHandlers],
  name: 'CatalogService',
  options: [Object],
  kind: 'odata',
  ...
  requestTimeout: 60000,
  csrf: undefined,
  csrfInBatch: undefined
}

This time, it's not an instance of the ApplicationService class, it's an instance of the RemoteService class!

Send a query to the service

What's more, we can interact with that service ... as if it were local:

> await cs.read(`Books`)
[
  { ID: 1, title: 'Wuthering Heights', author: 'Emily Brontë' },
  { ID: 2, title: 'Jane Eyre', author: 'Charlotte Brontë' },
  { ID: 3, title: 'The Raven', author: 'Edgar Allen Poe' },
  { ID: 4, title: 'Eleonora', author: 'Edgar Allen Poe' },
  { ID: 5, title: 'Catweazle', author: 'Richard Carpenter' }
]

Wham!

Wrapping up

Going back to the concentric circles, this is a effectively an example of the two that are within the confines of the local machine. One, the provided service, exists as if it were remote (with a URL) in the eyes of the consuming service (or REPL context here).

CAP's adoption of minimal assumptions in service provision and consumption is so complete that the lines become blurred between local and remote, thanks to the power of remote proxies that do the heavy lifting of query transport across the wire for us.

This really is hard evidence of one of CAP's "magic made simple" moments, and is explained further in the CAP-level Integration section of the Bookshop topic in Capire.

Footnotes

See Non-Linear Regression with Minimal Assumptions
The symbol for a user's home directory is the tilde (~). I'm guessing some of you know why it's this symbol, but for those of you who don't, have a look at the keyboard of the ADM-3A terminal, specifically in the top right. Bill Joy, erstwhile employee of Sun and perhaps more importantly creator of both vi and the C Shell (csh), used an ADM-3A and it was in the C Shell where the tilde came to represent a user's home directory.

Also on that same key is the caret (^), which also represents "home" (beginning of a line) in regular expression dialects. Coincidence? I think not! :-)
OK, it may not have escaped your notice that these are not circles. Just pretend they are.
It's the concept of a socket that we must bear in mind, which is the combination of protocol, address (hostname / IP) and port. But that's a story for another time.
We can actually just specify the project location as a single argument and the same thing will happen: cds repl proj-A.

reCAP 2026 talk resources

2026-07-15T00:00:00Z

At reCAP this year, I was honoured to share a talk slot with Patrice Bender, a good friend and adjacent colleague from the CAP Compiler team, and cohost / copresenter on the Hands-on SAP Dev mini-series on the core expression language in CDS.

The talk was titled Expressions and Abstractions - Two Developer Superpowers in CAP, with the following overview:

Today we need to be more efficient and concise than ever, stop writing code we don't need to, and avoid tasks that slow down our development loops, letting the framework do the heavy lifting for us. In this session we'll demonstrate two different affordances that enable that. First, we'll show the power of expressions, what they are, how and where they can be used, and why you should know about them. Then we'll show how mocking abstracts us from the tedium and ceremony, allowing us to iterate fast on data, auth, messaging and remote services during development.

Whether you watched the talk at reCAP in person, or remotely, please consider filling in the short feedback form. Thanks!

Here are some resources relating to the two parts.

Expressions

The demo resources used in this part of the talk are available in the repo cxl-bookshop that is an extended bookshop you can clone, open in cds repl, and use to try everything shown live.

The talk is based on the 7-part Hands-on SAP Dev mini-series Under the hood: CDS Expressions in CAP, with our written notes accompanying it, starting with Part 1. For the reference, including syntax diagrams that show what an expression can contain, see the CXL topic in Capire.

Abstractions

The demo resources used in this part of the talk are available in the repo cap-nodejs-local-first-development.

The Local-first dev with CAP Node.js series of blog posts covers mocking of data, auth, remote services and messaging.

The blog post CAP service authentication at design time and in production covers the restrict_all_services setting.

In the content for the CodeJam A hands-on tour of CAP there are deep and detailed dive exercises on mocking auth and mocking messaging. At the end of each of these exercises are plenty of links to further information including resources in Capire.