SAP Community - Ajay Soreng

🟠 CAP Tools – What's New and Hot

2025-09-11T15:30:58.954000+02:00

Learn what's hot and new in CAP tools, like

- IntelliJ IDEs support
- Linter checks for custom code
- CLI enhancements for debugging, deployment, repl, and more

SPEAKER: Christian Georgi

We hope you enjoyed exploring how CAP Devtoberfest session "CAP Tools – What's New and Hot"

Please find the Devtoberfest validation tutorial for the CAP track, Week 3

Devtoberfest validation tutorial question will be available by EOD after the 4rd CAP Devtoberfest session today.

You can find it here : https://developers.sap.com/tutorials/devtoberfest2025-cap-week3-session-validation.html

🟠 Best Practices in CAP

2025-09-11T20:45:01.235000+02:00

In this session Daniel Hutzel - CPO and founder of CAP - will explain how to use CAP. And how to not use it... 🙂

We hope you enjoyed exploring how CAP Devtoberfest session "Best Practices in CAP"

Please find the Devtoberfest validation tutorial for the CAP track, Week 3

Devtoberfest validation tutorial question will be available by EOD after the 4rd CAP Devtoberfest session today.

You can find it here : https://developers.sap.com/tutorials/devtoberfest2025-cap-week3-session-validation.html

Re: CodeJam Request | Pune| Q1 2026- Build AI services using the SAP Cloud Application Programming M

2025-09-16T07:42:04.989000+02:00

Hi Ashutosh,

Thanks for the request. We will plan for the CodeJam in Q1 2026 for Pune.

Thanks and Regards, Ajay

Re: SAP CodeJam Request - Pune, India - May 2026

2026-03-16T08:12:12.191000+01:00

@max_vandam Thanks for the request. I will discuss further for the planning in the mail.

Re: Request to Host SAP CodeJam – Nagarro, Gurgaon

2026-03-30T08:52:05.590000+02:00

Hi Ashutosh,

I have sent you the meeting invite for the planning discussion.

SAP Cloud Application Programming Model with SAP HANA Cloud at Tarento Technologies - 6th September

2026-04-02T15:17:06.610000+02:00

It was an eventful day at SAP CodeJam kindly hosted by Tarento Technologies India in Bengaluru.

We thank the participants for taking a day out to spend it doing the CodeJam exercises. It was a great sight seeing the SAP Developer Community coming together, learning and networking. We had some pretty tough technical infrastructure related challenges. But it was a great team collaboration where collectively the group met the days goals in the end. Kudos to all the participants. Special thanks to @SumanthVedantam27 and @Kalyani662 for hosting the event.

https://community.sap.com/t5/sap-codejam/sap-cloud-application-programming-model-with-sap-hana-cloud/ec-p/13788891#M557

🇮🇳 Event-driven integrations with SAP Integration Suite, advanced event mesh (Hyderabad, India)

2026-04-22T11:47:12.553000+02:00

Registration is closed for this event. The first 25 participants will receive a confirmation email 2 weeks before the event and the rest of the participants will be added to a waiting list and will be considered in case of dropouts.

This SAP CodeJam instance will be about Event-driven integration using SAP Integration Suite, advanced event mesh. Join us for this event of developer networking and hands-on learning in Hyderabad, India.

We will achieve an integration scenario like the one in the diagram below by the end of the CodeJam.

If you are interested in knowing what we will develop during the event, check out the Event-Driven Integrations with SAP Integration Suite, Advanced Event Mesh GitHub repo - https://github.com/SAP-samples/event-driven-integrations-codejam. The repository contains the details of the integration scenario we will go through during the event.

Prerequisites

Bring your own laptop with power adapter and have a supported Web browser of either Google Chrome or Microsoft Edge. Other browsers are not supported.
It can be helpful to bring a tablet or second laptop, if you have, to have the instructions on a separate screen.

Location and Date

This is an in-person event only (not virtual) and is planned for Tuesday, June 23, 2026, from 09:30 - 16:00 local time in Hyderabad, India (IST). The language of the event and the content will be English.

Event Address: Bosch Global Software Technologies Private Limited, Sattva Knowledge Park, Tower 1, 14th to 19th Floor Raidurg Village, Serilingampally Mandal Ranga Reddy District, Hyderabad, Telangana, 500081

Google Maps: https://maps.app.goo.gl/jdstx227U4YHzABb6

The event is kindly being hosted by Bosch Global Software Technologies Private Limited – THANK YOU!
The instructor is SAP Developer Advocate @ajay_soreng

There are essential prerequisites that every attendee must complete before arriving at the event location. You can find the prerequisites here: https://github.com/SAP-samples/event-driven-integrations-codejam/blob/main/prerequisites.md.

If you wish to attend, please indicate that using the "Yes" button in the Will you be attending? box on this page. Please note that spaces are limited - we can only accommodate 25 attendees for this event.

In that context, if you indicate that you're attending and later realise you can't, please remove your name so that others get a chance instead. Thanks!

🇮🇳 Build AI services using SAP CAP and Generative AI Hub (Gurugram, India)

2026-04-24T09:39:56.541000+02:00

This SAP CodeJam event is on the topic of Build AI services using the SAP Cloud Application Programming Model, SAP AI Core and Generative AI Hub. It is beneficial if you have some basic knowledge about JavaScript as we are using the SAP Cloud SDK for AI with the JavaScript variant.

Please note that this is an advanced SAP CAP CodeJam and it requires participants to have basic understanding of the SAP Cloud Application Programming Model.

This CodeJam introduces attendees to aspects of exposing generative artificial intelligence (GenAI) capabilities to execute tasks using a given business context.

During this event, you will become acquainted with the theory behind GenAI, SAP AI Core, SAP AI Launchpad, and learn how to use the SAP Cloud Application Programming Model to expose AI capabilities through your own OData service.

While working through the exercises, you will become comfortable creating CDS-based service definitions and integrating them into the SAP Business Technology Platform (BTP) and SAP AI Core Foundation Models.

Prerequisites

Bring your own laptop with power adapter and have a supported Web browser such as Google Chrome or Firefox installed on your laptop.
It can be helpful to bring a tablet or second laptop, if you have.
We will be using the primary environment as described in the prerequisites here https://github.com/SAP-samples/codejam-cap-llm/blob/main/prerequisites.md#prerequisites

Location and Date

This is an in-person event only (not virtual) and is planned for Thursday, May 21st, 2026 from 09:30 - 16:00 local time in Gurugram, India. The language of the event and the content will be English.

Event Address: Nagarro Software Private Limited, Plot 6B, Sub. Major Laxmi Chand Rd, Maruti Udyog, Sector 18, Sarhol, 122015 Gurugram, Haryana, India

Google maps location: https://maps.app.goo.gl/wwyLK7WG3Jk2Y9qw7

The instructors are SAP Developer Advocates @ajay_soreng and @shrinivasan_neelamegam
Thank you Nagarro Software Private Limited for hosting this event.

Please note that spaces are limited! We can only accommodate 35 attendees. If you want to attend, register by clicking the Yes button in the Will you be attending? section above to the right. About two weeks before the event, you will be asked to confirm your attendance via email.

For more information on SAP CodeJam events, head over to the SAP CodeJam group.

🇮🇳 Build AI services using SAP CAP and Generative AI Hub (Gurugram, India)

2026-04-30T08:06:41.592000+02:00

Please note that this is an advanced SAP CAP CodeJam and it requires participants to have basic understanding of the SAP Cloud Application Programming Model.

This CodeJam introduces attendees to aspects of exposing generative artificial intelligence (GenAI) capabilities to execute tasks using a given business context.

Prerequisites

Bring your own laptop with power adapter and have a supported Web browser such as Google Chrome or Firefox installed on your laptop.
It can be helpful to bring a tablet or second laptop, if you have.
We will be using the primary environment as described in the prerequisites here https://github.com/SAP-samples/codejam-cap-llm/blob/main/prerequisites.md#prerequisites

Location and Date

This is an in-person event only (not virtual) and is planned for Friday, May 22nd, 2026 from 09:30 - 16:00 local time in Gurugram, India. The language of the event and the content will be English.

Event Address: WeWork Two Horizon Centre, 5th Floor, Two Horizon Centre, 5th Floor, DLF, DLF Phase 5, Gurugram, Haryana 122009.

Google maps location: https://maps.app.goo.gl/B3LYKZoQxKMGhLby8

The instructors are SAP Developer Advocates @ajay_soreng and @shrinivasan_neelamegam
Thank you MINDSET Consulting for hosting this event.

Please note that spaces are limited! We can only accommodate 25 attendees. If you want to attend, register by clicking the Yes button in the Will you be attending? section above to the right. About two weeks before the event, you will be asked to confirm your attendance via email.

For more information on SAP CodeJam events, head over to the SAP CodeJam group.

Re: May 2026 Developer Challenge — Week 1: Getting familiar with the events

2026-05-13T12:45:45.119000+02:00

My submission for week1 . Sent the event via Business Event Generator app and received via Solace AEM broker.

Another one via try me feature. I choose solace because SAP Integration Suite AEM is solace under the hood.

Re: May 2026 Developer Challenge — Week 2: Connecting to the broker and consuming events

2026-05-15T13:33:50.301000+02:00

I took a generic non sap flow to start with the Business partner generator application ==> solace AEM ==> solace message queue ==> RDP (event consumed here and sent to webhook )==> https://webhook.site/ (event finally reached here)

I tried the last part with n8n trial but currently faced some challenges. I still try that again.

event payload in consumer webhook.siteCloud event via Business Partner appRest delivery point

Re: 🇮🇳 Event-driven integrations with SAP Integration Suite, advanced event mesh (Hyderabad, India

2026-06-15T10:45:02.969000+02:00

Hi @pavankalyansiriki thanks for reaching out. As of now the seats are full. We will get back if there is any withdrawal/cancellation.

Re: 🇮🇳 Event-driven integrations with SAP Integration Suite, advanced event mesh (Hyderabad, India

2026-06-22T12:23:41.825000+02:00

Hi @adf CodeJam event has limited seats. The email to the first 25 participants was already sent by the host.

🇸🇬 Build AI services using SAP CAP and Generative AI Hub (Singapore)

2026-07-01T09:54:28.349000+02:00

Please note that this is an advanced SAP CAP CodeJam and it requires participants to have basic understanding of the SAP Cloud Application Programming Model.

This CodeJam introduces attendees to aspects of exposing generative artificial intelligence (GenAI) capabilities to execute tasks using a given business context.

Prerequisites

Bring your own laptop with power adapter and have a supported Web browser such as Google Chrome or Firefox installed on your laptop.
It can be helpful to bring a tablet or second laptop, if you have.
We will be using the primary environment as described in the prerequisites here https://github.com/SAP-samples/codejam-cap-llm/blob/main/prerequisites.md#prerequisites

Location and Date

This is a free in-person event and is planned for Wednesday, August 26, in Singapore from 10:00 AM to 4:00 PM local time. The event's language and content will be in English.

Event Address: SAP Asia Pte Ltd.30 Pasir Panjang Rd, Singapore 117440, Located in: Mapletree Business City.

Google Maps: https://maps.app.goo.gl/6ZEMBPXsthyshYH2A

A huge thank you to Mark9 Solutions for hosting this event.
The instructors are SAP Developer Advocates @ajay_soreng and @shrinivasan_neelamegam
In collaboration with Sanjog Tiwari, Customer Success Lead — AI, Data & Platform, SEA Team

Please note that spaces are limited! We can only accommodate 30 attendees. If you want to attend, register by clicking the Yes button in the Will you be attending? section above to the right. Approximately 2 weeks prior to the event, you will receive an email to confirm your attendance, along with further instructions and details.

For more information on SAP CodeJam events, head over to the SAP CodeJam group.

🇮🇳 Build AI services using SAP CAP and Generative AI Hub (Bengaluru, India)

2026-07-01T10:09:38.778000+02:00

REGISTRATION IS NOW CLOSED FOR THIS EVENT - We will send confirmation emails to first 35 attendees a couple of weeks before the event and we will manage a waitlist, in case some of the RSVPs are unable to make it to the event.

Please note that this is an advanced SAP CAP CodeJam and it requires participants to have basic understanding of the SAP Cloud Application Programming Model.

This CodeJam introduces attendees to aspects of exposing generative artificial intelligence (GenAI) capabilities to execute tasks using a given business context.

Prerequisites

Bring your own laptop with power adapter and have a supported Web browser such as Google Chrome or Firefox installed on your laptop.
It can be helpful to bring a tablet or second laptop, if you have.
We will be using the primary environment as described in the prerequisites here https://github.com/SAP-samples/codejam-cap-llm/blob/main/prerequisites.md#prerequisites

Location and Date:

This is a free in-person event and is planned for Tuesday, August 18, in Bengaluru from 9:30 AM to 4:00 PM local time. The event's language and content will be in English.

Event Address:

Bosch Global Software Technologies

360° Business Park, Electronic City Phase I, Electronic City, Bengaluru, Doddathoguru, Karnataka 560100

Google Maps: https://maps.app.goo.gl/18xB6jTQbUoyEMhp8

Special thanks to Bosch Global Software Technologies for hosting this event.

The instructors are SAP Developer Advocates @ajay_soreng and @shrinivasan_neelamegam

Please note that spaces are limited! We can only accommodate 35 attendees. If you want to attend, register by clicking the Yes button in the Will you be attending? section above to the right. Approximately 2 weeks prior to the event, you will receive an email to confirm your attendance, along with further instructions and details.

For more information on SAP CodeJam events, head over to the SAP CodeJam group.

🐍 July Developer Challenge — Snake & Ladder with SAP CAP Status Transition Flows

2026-07-01T15:14:27.093000+02:00

SAP Developer Challenge - Snake & Ladder with SAP CAP Status Transition Flows

Welcome to the July 2026 SAP Developer Challenge — a 4-week hands-on series where you build a multiplayer Snake & Ladder game as a fully functional SAP CAP service, powered by CAP Status Flows (@flow.status).

The Scenario

We will be building the backend engine for an online Snake & Ladder game. Each player's position on the board is a state — and every move, snake bite, and ladder climb is a status transition modelled using CAP's @flow.status annotations.

By the end of July, you'll have:

A running CAP Node.js service with CDS entities and status-flow bound actions
A multiplayer game engine with turn management, dice rolls, snake/ladder triggers, and CAP events
A SAP Fiori UI displaying the live board — participants just plug in their service URL
Integration with the CAP MCP server to let an AI assistant drive moves via natural language

What Makes This Interesting

CAP's @flow.status feature gives you out-of-the-box:

Pre-validation — a @from: [#Playing] annotation rejects any action called in the wrong state (HTTP 409), no custom code needed
Automatic state transitions — @TO: #Finished updates the entity after your action returns
History tracking — @TO: $flow.previous restores the previous state (perfect for a snake bite that temporarily blocks a player)
Fiori integration — buttons in the UI are automatically enabled/disabled based on the current status

Snake & Ladder maps directly onto this model: a player's turn is a state machine, and every square is a potential transition trigger.

Challenge Format

Each week a blog post is published on SAP Community with the task, hints, and code guidance. Submit your answer as a reply comment on that week's blog post.

Week Dates Title Core Topic Blog Post

1	6–12 Jul	Model the Board	CDS entities, status enum, `@flow.status`	link
2	13–19 Jul	Roll & Move	Bound actions, `@from` / `@to` transitions	link
3	20–26 Jul	Multiplayer & Events	Turn management, CAP events, snake/ladder logic	link
4	27–31 Jul	Fiori UI & CAP MCP	Board UI, MCP server	TBD

Prerequisites

Node.js 20+
@sap/cds-dk installed globally: npm install -g @sap/cds-dk
VS Code with the SAP CDS Language Support extension
Basic familiarity with CAP (entities, services, cds watch)

No prior knowledge of CAP status flows is required — Week 1 introduces everything from scratch.

The Board

The game uses a classic 10×10 board (squares 1–100). Key squares:

Ladders (climb up)

Bottom Top Effect

2	38	Big early boost
8	31	Good start
15	26	Small step up
21	42	Mid-board jump
28	84	The long ladder — almost wins it
36	44	Short gain
51	67	Solid advance
71	91	Late-game boost
78	98	So close to victory

Single-Headed Snakes (slide back)

Head Tail Severity

99	7	Devastating — one square from the finish
76	20	Major setback
43	18	Mid-game punisher

Double-Headed Snakes (two biting ends, one shared tail)

These special snakes have two heads on different squares that share a single tail. Landing on either head square sends you to the same tail square.

Head 1 Head 2 Shared Tail

89	72	50
54	63	34
40	47	3

The double-headed snake maps to CAP's @from: [#Head1, #Head2] — the same transition triggered by multiple entry states.

Reusable Board UI

A ready-made HTML/JS board will be provided later. Participants plug in their CAP service URL and see the live board — no frontend coding required for the challenge.

Resources

🐍 July Developer Challenge Week 1 — Model the Board

2026-07-01T15:14:58.896000+02:00

Week 1 — Model the Board

Challenge series: Snake & Ladder Developer Challenge | Week 1 of 4 Dates: 6–12 July 2026

The Setup

Every game needs a board. Before any snake can bite or ladder can lift, you need a data model that captures the state of a game — players, positions, and crucially, whose turn it is and what can happen next.

This week we will build the CDS foundation: entities, a status enum, and your first @flow.status annotation. No game logic yet — just clean modelling and a running CAP service.

What You'll Build This Week

A new CAP Node.js project: snake-ladder
CDS entities for GameSession, Player, and BoardSquare
A TurnStatus enum with the game states
Your first @flow.status annotation
Seed data: a 10×10 board with all snakes and ladders pre-loaded
A running service at http://localhost:4004

Prerequisites

Node.js 20+
@SAP/cds-dk installed globally:

npm install -g @sap/cds-dk

VS Code with the SAP CDS Language Support extension. Check Initial Setup for more details how to do a local setup.

Background: CAP Status Flows in 60 Seconds

CAP's @flow.status feature turns a regular enum field into a controlled state machine. You annotate:

The entity with @flow.status: FieldName to designate which field drives the state machine
Bound actions with @from: [#StateA] to declare which states allow that action
Bound actions with @TO: #StateB to declare the target state after the action runs

CAP handles the rest automatically:

Validates the current state before the action runs (returns HTTP 409 if wrong state)
Updates the status field after the action completes
Generates Fiori annotations to enable/disable buttons based on current state

No custom validation code. No manual status updates. The framework enforces the rules.

Step-by-Step

1. Initialise the CAP project

cds init snake-ladder --nodejs
cd snake-ladder
npm install
code .

2. Create the data model

Create db/schema.cds:

namespace snakeladder;

// ── Status enum — the heart of the state machine ──────────────────────────
type TurnStatus : String enum {
  Waiting;    // Session created, not yet started
  Playing;    // It's this player's turn — roll the dice!
  Moving;     // Dice rolled, player token is being moved
  Blocked;    // Player hit a double-headed snake — skips next turn
  Finished;   // This player has reached square 100 and won
}

// ── Board square — pre-loaded with snake/ladder data ──────────────────────
entity BoardSquares {
  key square      : Integer;        // 1–100
      snakeTo     : Integer;        // 0 if no snake on this square
      ladderTo    : Integer;        // 0 if no ladder on this square
      isDoubleHead: Boolean default false;  // true if this is a double-headed snake mouth
}

// ── Game session ──────────────────────────────────────────────────────────
entity GameSessions {
  key ID          : UUID;
      name        : String(100);    // e.g. "Friday Afternoon Game"
      createdAt   : Timestamp;
      startedAt   : Timestamp;
      finishedAt  : Timestamp;
      winner      : Association to Players;
}

// ── Player — one row per player per session ───────────────────────────────
@flow.status: TurnStatus
entity Players {
  key ID          : UUID;
      session     : Association to GameSessions;
      name        : String(100);
      @readonly
      position    : Integer default 1;      // current square (1–100)
      @readonly
      TurnStatus  : TurnStatus default #Waiting;
      turnOrder   : Integer;                // 1 = goes first
      lastRoll    : Integer;               // last dice result
}

Why @flow.status on Players? Each player is an independent state machine. Their TurnStatus transitions independently — one player is Playing while others are Waiting.

3. Create the service

Create srv/game-service.cds:

using { snakeladder } from '../db/schema';

service GameService {

  entity GameSessions as projection on snakeladder.GameSessions;

  @flow.status: TurnStatus
  entity Players as projection on snakeladder.Players actions {

    // Week 2 will implement these — declare them now so the model is complete
    @from: [ #Waiting ]
    @to: #Playing
    action startTurn();

    @from: [ #Playing ]
    @to: #Moving
    action rollDice() returns Integer;

    @from: [ #Moving ]
    @to: #Waiting                  // transitions to next player in Week 3
    action confirmMove();

    @from: [ #Moving ]
    @to: #Blocked                  // double-headed snake bite
    action blockPlayer();

    @from: [ #Blocked ]
    @to: $flow.previous            // restores pre-block status
    action unblockPlayer();

    @from: [ #Moving ]
    @to: #Finished
    action winGame();
  }

  entity BoardSquares as projection on snakeladder.BoardSquares;
}

4. Add seed data

Create db/data/snakeladder-GameSessions.csv:

ID,name,createdAt,startedAt,finishedAt,winner_ID
a1b2c3d4-0001-0000-0000-000000000000,Demo Game,2026-07-01T09:00:00Z,,

Create db/data/snakeladder-BoardSquares.csv:

square,snakeTo,ladderTo,isDoubleHead
1,0,0,false
2,0,38,false
3,0,0,false
4,0,0,false
5,0,0,false
6,0,0,false
7,0,0,false
8,0,31,false
9,0,0,false
10,0,0,false
11,0,0,false
12,0,0,false
13,0,0,false
14,0,0,false
15,0,26,false
16,0,0,false
17,0,0,false
18,0,0,false
19,0,0,false
20,0,0,false
21,0,42,false
22,0,0,false
23,0,0,false
24,0,0,false
25,0,0,false
26,0,0,false
27,0,0,false
28,0,84,false
29,0,0,false
30,0,0,false
31,0,0,false
32,0,0,false
33,0,0,false
34,0,0,false
35,0,0,false
36,0,44,false
37,0,0,false
38,0,0,false
39,0,0,false
40,3,0,true
41,0,0,false
42,0,0,false
43,18,0,false
44,0,0,false
45,0,0,false
46,0,0,false
47,3,0,true
48,0,0,false
49,0,0,false
50,0,0,false
51,0,67,false
52,0,0,false
53,0,0,false
54,34,0,true
55,0,0,false
56,0,0,false
57,0,0,false
58,0,0,false
59,0,0,false
60,0,0,false
61,0,0,false
62,0,0,false
63,34,0,true
64,0,0,false
65,0,0,false
66,0,0,false
67,0,0,false
68,0,0,false
69,0,0,false
70,0,0,false
71,0,91,false
72,50,0,true
73,0,0,false
74,0,0,false
75,0,0,false
76,20,0,false
77,0,0,false
78,0,98,false
79,0,0,false
80,0,0,false
81,0,0,false
82,0,0,false
83,0,0,false
84,0,0,false
85,0,0,false
86,0,0,false
87,0,0,false
88,0,0,false
89,50,0,true
90,0,0,false
91,0,0,false
92,0,0,false
93,0,0,false
94,0,0,false
95,0,0,false
96,0,0,false
97,0,0,false
98,0,0,false
99,7,0,false
100,0,0,false

Double-headed snake logic: Squares 40, 47, 54, 63, 72, and 89 all have isDoubleHead: true. Pairs (40,47), (54,63), and (72,89) share a tail. Your Week 2 move handler will use this flag to apply the correct snakeTo destination.

5. Run and verify

cds watch

Open http://localhost:4004. You should see GameService with endpoints for GameSessions, Players, and BoardSquares.

Test the board data is loaded:

GET http://localhost:4004/odata/v4/GameService/BoardSquares?$filter=snakeTo gt 0

You should see all 9 snake-head squares returned.

How to Submit

Reply to the Week 1 blog post on SAP Community with a comment containing:

Your db/schema.cds — paste as a CDS code block
Your srv/game-service.cds — paste as a CDS code block
A screenshot of http://localhost:4004 showing the GameService endpoints
One sentence explaining your choice of TurnStatus enum values — did you add any of your own?

What's Next

In Week 2 — Roll & Move, you implement the bound actions. You'll write the rollDice handler, apply snake and ladder logic, and see CAP automatically enforce the @from / @TO transitions — returning HTTP 409 when a player tries to roll out of turn.

Resources

🐍 July Developer Challenge Week 2 — Roll & Move

2026-07-12T20:29:00.014000+02:00

Week 2 — Roll & Move

Challenge series: Snake & Ladder Developer Challenge | Week 2 of 4 Dates: 13–19 July 2026

The Setup

You have a board. You have a player state machine. This week we will make it move.

This week you implement the bound action handlers that power the game: dice rolling, position calculation, and snake/ladder logic. CAP's @flow.status machinery will automatically enforce that moves only happen in the right state — your job is to write the business logic inside each handler.

By the end of this week you can play a full single-player game from the command line using plain OData calls.

What You'll Build This Week

Handler implementations for rollDice, confirmMove, blockPlayer, unblockPlayer, and winGame
Snake and ladder position resolution (including double-headed snake logic)
HTTP 409 proof: demonstrating that calling an action in the wrong state is rejected by CAP
An end-to-end single-player run reaching square 100

How CAP Enforces State Transitions

Before your handler code runs, CAP checks the current TurnStatus of the player entity against the @from annotation on the action. If the status doesn't match, CAP returns:

HTTP/1.1 409 Conflict
{
  "error": {
    "code": "409",
    "message": "Action 'rollDice' is not allowed in current status 'Waiting'"
  }
}

No code from you. No if (status !== 'Playing') throw .... The annotation does it.

After your handler returns (without throwing), CAP updates the status field to the @TO value. Again — no code from you.

This is the key insight of the week: your handler only contains business logic, not state management.

Step-by-Step

1. Create the service implementation file

Create srv/game-service.js:

const cds = require('@sap/cds')

module.exports = class GameService extends cds.ApplicationService {
  async init() {

    const { Players, BoardSquares } = this.entities

    // ── startTurn ─────────────────────────────────────────────────────────
    // @from: [#Waiting]  →  CAP validates status before this runs
    // @to: #Playing      →  CAP updates status after this returns
    // No business logic needed — CAP's @flow.status handles the transition.
    this.on('startTurn', 'Players', async (req) => {
      // Intentionally empty: the @from/@to annotations do all the work.
    })

    // ── rollDice ──────────────────────────────────────────────────────────
    // @from: [#Playing]  →  CAP validates status before this runs
    // @to: #Moving       →  CAP updates status after this returns
    this.on('rollDice', 'Players', async (req) => {
      const player = await SELECT.one.from(Players).where({ ID: req.params[0].ID })
      if (!player) return req.error(404, 'Player not found')

      const roll = Math.ceil(Math.random() * 6)
      let newPosition = player.position + roll

      // Can't overshoot square 100 — must land exactly
      if (newPosition > 100) {
        await UPDATE(Players).set({ lastRoll: roll }).where({ ID: player.ID })
        const needed = 100 - player.position
        return req.reject(409, `Need exactly ${needed} to finish. Rolled ${roll}. No move.`)
      }

      // Resolve snake or ladder on the new square
      const square = await SELECT.one.from(BoardSquares).where({ square: newPosition })
      let finalPosition = newPosition
      let event = null

      if (square?.ladderTo) {
        finalPosition = square.ladderTo
        event = { type: 'ladder', 'from': newPosition, 'to': finalPosition }
      } else if (square?.snakeTo) {
        finalPosition = square.snakeTo
        event = square.isDoubleHead
          ? { type: 'doubleSnake', 'from': newPosition, 'to': finalPosition }
          : { type: 'snake', 'from': newPosition, 'to': finalPosition }
      }

      // Persist position and last roll
      await UPDATE(Players)
        .set({ position: finalPosition, lastRoll: roll })
        .where({ ID: player.ID })

      // Emit domain event so subscribers (Week 3) can react
      if (event) await this.emit('BoardEvent', { playerID: player.ID, ...event })

      // Use req.reply() — not return — to pin the response value before CAP's
      // @flow.status after-handler runs. A plain `return` gets cleared by the
      // flow machinery, producing HTTP 204 instead of the expected 200 + body.
      req.reply({ roll, position: finalPosition, event: event?.type ?? 'normal' })
    })

    // ── confirmMove ───────────────────────────────────────────────────────
    // @from: [#Moving]  →  normal end of a turn, hands off to next player (Week 3)
    // @to: #Waiting     →  player waits for their next turn
    this.on('confirmMove', 'Players', async (req) => {
      // Week 3 will add turn rotation here.
      // For now: just let CAP apply @to: #Waiting
    })

    // ── blockPlayer ───────────────────────────────────────────────────────
    // @from: [#Moving]  →  called when player lands on a double-headed snake
    // @to: #Blocked     →  player skips their next turn
    this.on('blockPlayer', 'Players', async (req) => {
      // Business logic: the position was already updated in rollDice.
      // This action just transitions state — CAP handles the @to: #Blocked update.
      req.info('Player is blocked and will skip their next turn.')
    })

    // ── unblockPlayer ─────────────────────────────────────────────────────
    // @from: [#Blocked]   →  called at the start of a blocked player's next turn
    // @to: $flow.previous →  CAP restores the status to whatever it was before #Blocked
    this.on('unblockPlayer', 'Players', async (req) => {
      // CAP's $flow.previous does the work — no code needed here.
      // The player's status returns to #Waiting automatically.
    })

    // ── winGame ───────────────────────────────────────────────────────────
    // @from: [#Moving]  →  called when player.position === 100
    // @to: #Finished    →  player has won
    this.on('winGame', 'Players', async (req) => {
      const player = await SELECT.one.from(Players).where({ ID: req.params[0].ID })
      if (!player) return req.error(404, 'Player not found')

      // Mark the session as finished with this player as winner
      await UPDATE('snakeladder.GameSessions')
        .set({
          finishedAt: new Date().toISOString(),
          winner_ID: player.ID
        })
        .where({ ID: player.session_ID })

      await this.emit('GameWon', { playerID: player.ID, sessionID: player.session_ID })
    })

    return super.init()
  }
}

If you notice rollDice action response looks different from how it was defined last week.

Lets adapt it as shown in srv/game-service.cds

  @from: [ #Playing ]
  @to: #Moving
  action rollDice() returns { roll: Integer; position: Integer; event: String; };

2. Add the domain events to your service CDS

Add these to the bottom of srv/game-service.cds:

// Domain events — emitted by handlers, consumed in Week 3
event BoardEvent {
  playerID : UUID;
  type     : String;   // 'ladder' | 'snake' | 'doubleSnake'
  from  : Integer;  // 'from' is a CDS reserved word — escape with ![]
  ![to]    : Integer;
}

event GameWon {
  playerID  : UUID;
  sessionID : UUID;
}

An error is intentionally introduced in the snippet above with the hint.

3. Test the state machine manually

Start the server:

cds watch

First, create a player using the REST API or the Fiori Launchpad at http://localhost:4004. Then test the status flow:

Note on service path: CAP derives the OData path from the service name. GameService maps to /odata/v4/game (lowercase, stripped of the "Service" suffix). All example requests below use this path. You can confirm the mounted path in the cds watch console output: serving GameService { at: '/odata/v4/game' }.

Step 1 — Start a turn (transitions Waiting → Playing):

POST http://localhost:4004/odata/v4/game/Players(ID=<your-player-id>)/startTurn
Content-Type: application/json
{}

Expected response: HTTP 204 No Content (empty body). This is correct — startTurn has no return type, so CAP applies the @TO: #Playing transition silently. Verify the state changed with a GET:

GET http://localhost:4004/odata/v4/game/Players(ID=<your-player-id>)?$select=TurnStatus

You should see "TurnStatus": "Playing".

Step 2 — Roll the dice (transitions Playing → Moving):

POST http://localhost:4004/odata/v4/game/Players(ID=<your-player-id>)/rollDice
Content-Type: application/json
{}

Expected response: HTTP 200 with the dice roll, new position, and board event:

{
  "@context": "$metadata#GameService.rollDiceType",
  "roll": 4,
  "position": 38,
  "event": "ladder"
}

The event field is "normal", "ladder", "snake", or "doubleSnake". The position is the final square after any snake or ladder has been applied — so you can read the outcome directly from the action response without a follow-up GET.

Why req.reply() not return? CAP's @flow.status machinery runs an after-handler that updates the status field. If you use a plain return, that after-handler clears the response value and the client gets HTTP 204 No Content instead. Calling req.reply({...}) pins the response before the flow handler runs, so the body reaches the client.

Step 3 — Prove the 409 rejection:

Without calling confirmMove first, try to call rollDice again. CAP will return:

HTTP/1.1 409 Conflict
{
  "error": {
    "code": "409",
    "message": "Action 'rollDice' is not allowed in current status 'Moving'"
  }
}

This is the framework working exactly as designed. Screenshot this — it's your Week 2 submission evidence.

Step 4 — Confirm the move (transitions Moving → Waiting):

POST http://localhost:4004/odata/v4/game/Players(ID=<your-player-id>)/confirmMove
Content-Type: application/json
{}

Expected response: HTTP 204 No Content (empty body). confirmMove has no return type — the empty response is correct. Verify with a GET that TurnStatus is now "Waiting".

4. Test the double-headed snake

Manually set a player to position 88 (one roll away from square 89, a double-headed snake head):

PATCH http://localhost:4004/odata/v4/game/Players(ID=<your-player-id>)
Content-Type: application/json
{ "position": 88 }

Note: position is @readonly in the service — for testing, update it directly via the db entity or temporarily remove @readonly.
remove @readonly from srv/game-service.cds for testing, and note that patching @readonly fields fails silently with HTTP 200.

Then start a turn and roll — if you roll 1, you land on 89 (a double-headed snake head). Your position should move to 50 (the shared tail). The BoardEvent event should fire with type: 'doubleSnake'.

Follow up by calling blockPlayer to transition to #Blocked, then unblockPlayer to see $flow.previous restore the state.

The `$flow.previous` Moment

When you call unblockPlayer and see the status return to its previous value automatically — that's CAP's state history at work. No code, no stored "previousStatus" field. The framework tracks it.

Note: $flow.previous restores whatever status the entity held before the transition to #Blocked. In this flow, blockPlayer is called from #Moving, so unblockPlayer restores #Moving — not #Waiting. The game loop then calls confirmMove to finish the turn. If you call blockPlayer from a different status in future extensions, $flow.previous will restore that one instead.

Stretch Goal

Add a skipTurn action that can be called when a player is #Blocked, as an alternative to unblockPlayer, that uses @TO: $flow.previous as well but also increments a turnsBlocked counter on the player:

@from: [ #Blocked ]
@to: $flow.previous
action skipTurn();

this.on('skipTurn', 'Players', async (req) => {
  const player = await SELECT.one.from(Players).where({ ID: req.params[0].ID })
  await UPDATE(Players)
    .set({ turnsBlocked: (player.turnsBlocked || 0) + 1 })
    .where({ ID: player.ID })
})

How to Submit

Reply to the Week 2 blog post on SAP Community with a comment containing:

Your srv/game-service.js handler implementations (paste as a JS code block)
A screenshot showing the HTTP 409 response when calling rollDice in the wrong state
A screenshot or OData response showing your player's position after landing on a snake or ladder
One sentence: what happens if you call winGame on a player whose position is not 100? How does your implementation handle it?

What's Next

In Week 3 — Multiplayer & Events, you add a second player, implement turn rotation, and wire up a CAP event subscriber that automatically advances the game state when a move is confirmed.

🐍 July Developer Challenge Week 3 — Multiplayer & Events

2026-07-20T13:35:35.720000+02:00

Week 3 — Multiplayer & Events

Challenge series: Snake & Ladder Developer Challenge | Week 3 of 4 Dates: 20–26 July 2026

The Setup

A single-player Snake & Ladder game is a solitaire puzzle. The real game is multiplayer — taking turns, watching opponents climb ladders, celebrating when a snake bites someone ahead of you.

This week you add a second player, implement turn rotation, and wire CAP events so the game state advances automatically. You'll also use the CAP MCP server to let an AI assistant watch the game — describing what happened on each turn in natural language.

What You'll Build This Week

Turn rotation: confirmMove activates the next player automatically
A GameSession state machine (separate from Player status)
A CAP event subscriber that drives turn handoff
A TurnLog entity recording every move for replay
CAP MCP server connected to the game — so an AI can query board state and narrate moves

Background: CAP Events as the Turn Engine

CAP events let services communicate without tight coupling. Your GameService emits a BoardEvent when a player moves. A subscriber — in the same service or a separate one — reacts to that event and advances the game.

CAP messaging key facts :
this.emit(eventName, data) inside an action handler automatically fires after the DB transaction commits — no manual outbox needed for in-process events.
This week uses in-process eventing (same cds watch process). If you later split into microservices, add file-based-messaging to package.json and your handler code stays unchanged — only the config changes.

This is the architecture for multiplayer:

Player calls rollDice
  → CAP validates @from: [#Playing]
  → Handler runs: calculates new position, emits BoardEvent
  → CAP applies @to: #Moving
  → Player calls confirmMove
  → CAP validates @from: [#Moving]
  → Handler emits TurnComplete event
  → CAP applies @to: #Waiting
  → TurnComplete subscriber: logs the turn (next-player activation already done inside confirmMove)

No polling. No setInterval. The event graph drives the game.

Step-by-Step

0. Upgrade to the latest CAP version

Before adding Week 3 features, upgrade your project to the latest @SAP/cds. CAP 10 brings performance improvements, refined flow-status behaviour, and updated MCP support.

If you skipped Week 2's CDS 10 note: cds init --nodejs in CDS 10 generates "type": "module" in package.json. The handler code in these guides uses CommonJS require(). If your server crashes with ReferenceError: require is not defined, remove "type": "module" from package.json. Running npm install @sap/cds@latest also removes it automatically.

npm install @sap/cds@latest @cap-js/mcp@latest @cap-js/sqlite@latest

Verify the versions installed:

cds --version

You should see @SAP/cds at 10.x or higher. Restart cds watch — if the service starts cleanly, you're ready.

Global CLI: The cds command comes from @sap/cds-dk. Keep it in sync:
npm install -g @sap/cds-dk@latest

1. Add the `TurnLog` entity

Add to db/schema.cds:

// ── Turn log — full history of every move ─────────────────────────────────
entity TurnLog {
  key ID          : UUID;
      session     : Association to GameSessions;
      player      : Association to Players;
      turnNumber  : Integer;
      diceRoll    : Integer;
      fromSquare  : Integer;
      toSquare    : Integer;
      eventType   : String(20);   // 'normal' | 'ladder' | 'snake' | 'doubleSnake' | 'win' | 'blocked'
      timestamp   : Timestamp;
}

Also update the Players entity in db/schema.cds to add these two fields needed by the confirmMove handler:
prevPosition  : Integer default 1;    // position before last dice roll
lastEventType : String(20);           // event from last roll: normal|ladder|snake|doubleSnake

Add it to srv/game-service.cds — inside the service GameService { } block, before the closing brace:

entity TurnLog as projection on snakeladder.TurnLog;

And add the TurnComplete event — also inside the service block so it appears in OData $metadata and the MCP describe tool:

event TurnComplete {
  sessionID    : UUID;
  playerID     : UUID;
  nextPlayerID : UUID;
  turnNumber   : Integer;
}

2. Implement turn rotation in the handler

Update srv/game-service.js — replace confirmMove and add the TurnComplete subscriber:

Before implementing confirmMove: Your Week 2 rollDice handler must store two additional fields during the UPDATE(Players) call. If you haven't already, add these to the .set({...}) block in rollDice:
prevPosition: player.position,     // position BEFORE the move (used for TurnLog)
lastEventType: event?.type ?? 'normal'  // ladder/snake/doubleSnake/normal
These are read by confirmMove when writing the TurnLog entry.

// ── confirmMove ─────────────────────────────────────────────────────────
// After this returns, CAP sets status → #Waiting.
// We then find the next player and set them to #Playing.
this.on('confirmMove', 'Players', async (req) => {
  // Players and TurnLog are already destructured at the top of init()
  const player = await SELECT.one.from(Players).where({ ID: req.params[0].ID })
  if (!player) return req.error(404, 'Player not found')

  // ── Check win condition before handing off ──
  if (player.position === 100) {
    // Delegate to winGame — correct CAP bound-action call syntax
    await this.send({ event: 'winGame', entity: 'Players', params: [{ ID: player.ID }] })
    return
  }

  // ── Log this turn ──
  const [{ n: count }] = await SELECT`count(*) as n`.from(TurnLog)
    .where({ session_ID: player.session_ID })
  const turnNumber = (count || 0) + 1
  await INSERT.into(TurnLog).entries({
    ID: cds.utils.uuid(),
    session_ID: player.session_ID,
    player_ID: player.ID,
    turnNumber,
    diceRoll: player.lastRoll,
    fromSquare: player.prevPosition,            // pre-roll position stored by rollDice
    toSquare: player.position,
    eventType: player.lastEventType ?? 'normal', // event type stored by rollDice
    timestamp: new Date().toISOString()
  })

  // ── Find next player in turn order ──
  const players = await SELECT.from(Players)
    .where({ session_ID: player.session_ID })
    .orderBy('turnOrder')

  const idx = players.findIndex(p => p.ID === player.ID)
  // Skip finished players — guard counter prevents infinite loop if all finish simultaneously
  let nextIdx = (idx + 1) % players.length
  let guard = 0
  while (players[nextIdx].TurnStatus === 'Finished' && guard++ < players.length) {
    nextIdx = (nextIdx + 1) % players.length
  }
  const next = players[nextIdx]

  await this.emit('TurnComplete', {
    sessionID: player.session_ID,
    playerID: player.ID,
    nextPlayerID: next.ID,
    turnNumber
  })

  // Activate next player — use direct UPDATE, not the flow action,
  // because we're already inside a handler
  await UPDATE(Players)
    .set({ TurnStatus: 'Playing' })
    .where({ ID: next.ID })
})

// ── TurnComplete event subscriber ─────────────────────────────────────────
// NOTE: this.after() on custom events receives (handlerResult, req) — the
// first argument is undefined (no return value from the event). Use req.data.
this.after('TurnComplete', async (_results, req) => {
  const data = req.data
  console.log(`[TurnComplete] session=${data.sessionID} nextPlayer=${data.nextPlayerID} turn=${data.turnNumber}`)
})

3. Add a session-level `startGame` action

Players need a way to transition a session from "lobby" to "in progress". Add to db/schema.cds:

type SessionStatus : String enum {
  Lobby;      // Accepting players, not yet started
  InProgress; // Game is running
  Complete;   // A player has won
}

@flow.status: SessionStatus
entity GameSessions {
  key ID          : UUID;
      name        : String(100);
      @cds.on.insert: $now
      createdAt   : Timestamp;
      startedAt   : Timestamp;
      finishedAt  : Timestamp;
      winner      : Association to Players;
      @readonly
      SessionStatus : SessionStatus default #Lobby;
}

Add to srv/game-service.cds actions on GameSessions:

@flow.status: SessionStatus
entity GameSessions as projection on snakeladder.GameSessions actions {

  @from: [ #Lobby ]
  @to: #InProgress
  action startGame();

  @from: [ #InProgress ]
  @to: #Complete
  action endGame();
}

Also verify startTurn is still in your Players actions from Week 2. If you rebuilt your service file, make sure it includes:
@from: [ #Waiting ]
@to: #Playing
action startTurn();
In the multiplayer flow, startGame sets the first player directly to Playing, and confirmMove advances turns via direct UPDATE — so startTurn is not strictly required for multiplayer turn rotation. However, it's still useful for manual testing and for single-player Week 2 scenarios. Keep it in your service definition.

Implement startGame in game-service.js:

// Players, BoardSquares, TurnLog are already destructured at the top of init()
// Make sure your top-of-init destructure includes ALL three:
// const { Players, BoardSquares, TurnLog } = this.entities
this.on('startGame', 'GameSessions', async (req) => {
  const sessionID = req.params[0].ID

  // All players start in Waiting — set the first in turn order to Playing
  const players = await SELECT.from(Players)
    .where({ session_ID: sessionID })
    .orderBy('turnOrder')

  if (players.length < 2) {
    return req.reject(400, 'A game needs at least 2 players to start.')
  }

  await UPDATE(Players)
    .set({ TurnStatus: 'Playing' })
    .where({ ID: players[0].ID })

  await UPDATE('snakeladder.GameSessions')
    .set({ startedAt: new Date().toISOString() })
    .where({ ID: sessionID })
})

Also add the endGame handler. This action is triggered by the @flow.status machinery (it transitions SessionStatus to #Complete automatically), but it must also set finishedAt:

this.on('endGame', 'GameSessions', async (req) => {
  await UPDATE('snakeladder.GameSessions')
    .set({ finishedAt: new Date().toISOString() })
    .where({ ID: req.params[0].ID })
})

4. Test multiplayer turn rotation

Create a session with two players and start the game:

Tip: Omit the ID field in POST bodies — CAP auto-generates a UUID. Copy the returned ID from each response to use in subsequent requests.

POST http://localhost:4004/odata/v4/game/GameSessions
Content-Type: application/json
{
  "name": "My First Multiplayer Game"
}

POST http://localhost:4004/odata/v4/game/Players
Content-Type: application/json
{
  "session_ID": "<session-ID-from-above>",
  "name": "Alice",
  "turnOrder": 1
}

POST http://localhost:4004/odata/v4/game/Players
Content-Type: application/json
{
  "session_ID": "<session-ID-from-above>",
  "name": "Bob",
  "turnOrder": 2
}

POST http://localhost:4004/odata/v4/game/GameSessions(<session-ID>)/startGame
Content-Type: application/json
{}

Now Alice should be #Playing and Bob should be #Waiting. Roll for Alice, confirm her move, and Bob should automatically become #Playing.

Note on service path: CAP maps GameService to /odata/v4/game. Replace GameService in all URLs with game. See the Week 1 note for details.

Verify by checking both players' statuses after confirmMove:

GET http://localhost:4004/odata/v4/game/Players?$filter=session_ID eq '<session-ID>'

5. Connect the CAP MCP Server

The CAP MCP server exposes your GameService as tools that any MCP-compatible AI assistant (Claude Code, Claude Desktop, Opencode) can call. The AI can query board state, roll dice, narrate turns — all via natural language.

Install

npm add @cap-js/mcp

That's it. No extra configuration needed. @cap-js/mcp auto-detects CAP services during cds watch.

Annotate GameService

Add @McP to your service declaration in srv/game-service.cds, plus @title and @description on entities and actions so the AI understands the game domain:

This shows only the annotations to add — keep your existing action definitions unchanged. The // ... other actions placeholder represents your existing rollDice, confirmMove, etc.

/**
 * Snake & Ladder Game Service — multiplayer board game engine.
 * Players take turns rolling dice and moving tokens across a 10×10 board.
 * Snakes send players back; ladders advance them. First to reach square 100 wins.
 */
@mcp
@protocol: ['odata-v4', 'mcp']   // keep OData alongside MCP — REQUIRED or OData drops
@title: 'Snake & Ladder Game'
service GameService {

  @title: 'Game Sessions'
  @description: 'Create a session, add players, then call startGame. SessionStatus: Lobby → InProgress → Complete.'
  @flow.status: SessionStatus
  entity GameSessions as projection on snakeladder.GameSessions actions {
    /** Start the game. Requires at least 2 players. Sets first player (turnOrder=1) to Playing. */
    @from: [ #Lobby ] @to: #InProgress
    action startGame();
    // ... other actions
  }

  @title: 'Players'
  @description: 'Each player has a position (1-100) and TurnStatus. Call rollDice when Playing, then confirmMove to end the turn.'
  @flow.status: TurnStatus
  @cds.redirection.target
  entity Players as projection on snakeladder.Players actions {
    /**
     * Roll a 6-sided dice and move the player.
     * Returns: roll (1-6), position (new square after snakes/ladders), event (normal/ladder/snake/doubleSnake).
     */
    @from: [ #Playing ] @to: #Moving
    action rollDice() returns { roll: Integer; position: Integer; event: String; };
    // ... other actions
  }

  @title: 'Board State'
  @description: 'Live view of all player positions. Filter by session_ID to see a specific game.'
  @readonly
  entity BoardState as select from snakeladder.Players {
    key ID,
    name, position, TurnStatus, lastRoll,
    session.ID   as session_ID : UUID,   // typed alias — makes session_ID OData-filterable
    session.name as sessionName
  };
}

Start `cds watch` and the MCP endpoint appears automatically

cds watch

Look for this line in the output:

[cds] - serving GameService {
  at: [ '/odata/v4/game', '/mcp/game' ],
  ...
}

The MCP server is live at http://localhost:4004/mcp/game.

Add MCP-callable wrapper functions

The @cap-js/mcp query tool reads data; bound actions on entities (like rollDice) aren't directly callable by the AI. Add unbound service functions that the AI can call via per_action_tool. Add these to srv/game-service.cds inside the service block:

// ── MCP-callable unbound functions — allow AI to drive the game ──────────
/** Start a game session. Requires sessionID of a Lobby session with ≥2 players. */
function mcpStartGame(sessionID: UUID) returns String;

/** Roll the dice for the current Playing player. */
function mcpRollDice(playerID: UUID) returns { roll: Integer; position: Integer; event: String; };

/** Confirm a move and rotate the turn to the next player. */
function mcpConfirmMove(playerID: UUID) returns String;

/** Get the current board state for a game session. */
function mcpBoardState(sessionID: UUID) returns array of {
  name: String; position: Integer; TurnStatus: String; lastRoll: Integer;
};

/** All 100 squares with snake/ladder info. */
function mcpBoardMap() returns array of {
  square: Integer; snakeTo: Integer; ladderTo: Integer; isDoubleHead: Boolean;
};

Implement them in srv/game-service.js (add before return super.init()😞

Critical: use the object form of this.send() for bound entity actions. The string form this.send('rollDice', { params }) puts { params } into req.data of the dispatched request — bound action handlers read the entity key from req.params[0].ID, which will be undefined. Your handlers will run silently returning success but touching nothing. Always use the object form:
// ✗ WRONG — params land in req.data, req.params is empty
await this.send('rollDice', { params: [{ ID: playerID }] })

// ✓ CORRECT — params routed to req.params[0]
await this.send({ event: 'rollDice', entity: 'Players', params: [{ ID: playerID }] })

this.on('mcpStartGame', async (req) => {
  // Use object form: string form puts params in req.data, not req.params
  await this.send({ event: 'startGame', entity: 'GameSessions', params: [{ ID: req.data.sessionID }] })
  return `Game started for session ${req.data.sessionID}`
})
this.on('mcpRollDice', async (req) => {
  return await this.send({ event: 'rollDice', entity: 'Players', params: [{ ID: req.data.playerID }] })
})
this.on('mcpConfirmMove', async (req) => {
  await this.send({ event: 'confirmMove', entity: 'Players', params: [{ ID: req.data.playerID }] })
  return `Move confirmed for player ${req.data.playerID}`
})
this.on('mcpBoardState', async (req) => {
  return await SELECT.from(Players).where({ session_ID: req.data.sessionID })
    .columns('name','position','TurnStatus','lastRoll').orderBy('turnOrder')
})
this.on('mcpBoardMap', async () => SELECT.from(BoardSquares).orderBy('square'))

Enable per_action_tool in package.json:

{
  "cds": {
    "mcp": { "per_action_tool": true }
  }
}

After restarting, the MCP server exposes 7 tools: describe, query, mcpStartGame, mcpRollDice, mcpConfirmMove, mcpBoardState, mcpBoardMap.

Note: You can use any MCP tool of your choice.

Use with Claude Code (auto-wired — just ask)

With cds watch running, open a new terminal and ask Claude Code directly:

claude "What is the current board state? Who is in the lead?"

claude "Show me the turn history for the most recent game session."

claude "Which squares have snakes and which have ladders? Summarise the dangerous zones."

Claude Code uses the query and describe MCP tools to read your live game data and answer.

Use with Claude Desktop (manual wiring)

If you want the AI to also roll dice and make moves, connect Claude Desktop. Add to claude_desktop_config.json (macOS: ~/Library/Application Support/Claude/claude_desktop_config.json😞

{
  "mcpServers": {
    "snake-ladder": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "http://localhost:4004/mcp/game"]
    }
  }
}

Restart Claude Desktop, then try:

"What is the current board state for the active game? Who is winning?"

"Roll the dice for the current Playing player and tell me what happened."

"Narrate the last 5 turns like a sports commentator."

Verify the MCP endpoint — tools list and action tests

Step 1 — List all tools (should be exactly 7):

curl -X POST http://localhost:4004/mcp/game \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}'

Expected: SSE response with tools array containing query, describe, mcpStartGame, mcpRollDice, mcpConfirmMove, mcpBoardState, mcpBoardMap.

Step 2 — mcpBoardMap (no session needed):

curl -X POST http://localhost:4004/mcp/game \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"mcpBoardMap","arguments":{}}}'

Expected: 100 squares with snakeTo, ladderTo, isDoubleHead fields.

Step 3 — mcpStartGame (use an existing Lobby session ID):

curl -X POST http://localhost:4004/mcp/game \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":3,"method":"tools/call","params":{"name":"mcpStartGame","arguments":{"sessionID":"<your-session-id>"}}}'

Expected response: "result": "Game started for session ...". Then verify with OData:

GET http://localhost:4004/odata/v4/game/GameSessions(<session-id>)?$select=SessionStatus,startedAt

SessionStatus should be "InProgress" and startedAt not null.

If mcpStartGame returns success but SessionStatus stays Lobby, you have the this.send() bug — the string form was used instead of the object form. See the critical note above.

Step 4 — mcpRollDice (use the Playing player's ID):

curl -X POST http://localhost:4004/mcp/game \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":4,"method":"tools/call","params":{"name":"mcpRollDice","arguments":{"playerID":"<alice-id>"}}}'

Expected: {"roll":N, "position":M, "event":"normal|ladder|snake|doubleSnake"}. If you get "result": null, the this.send() object form is not being used.

Step 5 — mcpConfirmMove:

curl -X POST http://localhost:4004/mcp/game \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":5,"method":"tools/call","params":{"name":"mcpConfirmMove","arguments":{"playerID":"<alice-id>"}}}'

Expected: "result": "Move confirmed for player ...". Check Bob's TurnStatus is now "Playing".

Step 6 — mcpBoardState:

curl -X POST http://localhost:4004/mcp/game \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":6,"method":"tools/call","params":{"name":"mcpBoardState","arguments":{"sessionID":"<your-session-id>"}}}'

Expected: array of players with name, position, TurnStatus, lastRoll.

MCP uses SSE transport — responses arrive as event: message\ndata: {...}. Strip the data: prefix to parse JSON. HTTP clients that don't support SSE (like some REST clients) will show the raw text.

Understanding the Two State Machines

After this week you have two independent status flows running in your service:

Entity Field States Purpose

`GameSessions`	`SessionStatus`	Lobby → InProgress → Complete	Governs the game lifecycle
`Players`	`TurnStatus`	Waiting → Playing → Moving → Blocked / Finished	Governs each player's turn

The session state machine controls whether the game is happening. The player state machine controls whose turn it is and what they can do. CAP enforces both independently with their own @flow.status annotations.

Stretch Goal

Add a skipTurn action that a blocked player can call as an alternative to unblockPlayer, which also records how many turns they've been blocked:

@from: [ #Blocked ]
@to: $flow.previous
action skipTurn();

this.on('skipTurn', 'Players', async (req) => {
  const player = await SELECT.one.from(Players).where({ ID: req.params[0].ID })
  await UPDATE(Players)
    .set({ turnsBlocked: (player.turnsBlocked || 0) + 1 })
    .where({ ID: player.ID })
})

Note: BoardState is already included as a required entity in Step 5 (inside the @mcp-annotated service). The @cds.on.insert: $now annotation on GameSessions.createdAt coexists correctly with the Week 1 seed CSV — CAP uses the annotation for programmatic inserts but still honours explicit values in seed files.

How to Submit

Reply to the Week 3 blog post on SAP Community with a comment containing:

A screenshot or JSON response showing two players after confirmMove — one Waiting, one Playing
A screenshot or curl response showing mcpRollDice returning {roll, position, event} (not null) — proves the MCP action tools are wired correctly
A screenshot of Claude Code or Claude Desktop ( or any MCP tool client of your choice) querying your game state via MCP — even a simple "who is winning?" response counts
Optional but celebrated: a short AI-narrated turn log using mcpBoardState + TurnLog

What's Next

In Week 4 — Fiori UI & CAP MCP, you wire up the ready-made board UI, add your service URL to see your live game on a real Snake & Ladder board to complete the challenge.

Resources

Re: 🐍 July Developer Challenge Week 3 — Multiplayer & Events

2026-07-23T10:33:16.552000+02:00

@shotokka yes @Dan_Wroblewski is right there is a ladder at position 2 that takes the player to 38.

SAP Community - Ajay Soreng

🟠 CAP Tools – What's New and Hot

🟠 Best Practices in CAP

Re: CodeJam Request | Pune| Q1 2026- Build AI services using the SAP Cloud Application Programming M

Re: SAP CodeJam Request - Pune, India - May 2026

Re: Request to Host SAP CodeJam – Nagarro, Gurgaon

SAP Cloud Application Programming Model with SAP HANA Cloud at Tarento Technologies - 6th September

🇮🇳 Event-driven integrations with SAP Integration Suite, advanced event mesh (Hyderabad, India)

🇮🇳 Build AI services using SAP CAP and Generative AI Hub (Gurugram, India)

🇮🇳 Build AI services using SAP CAP and Generative AI Hub (Gurugram, India)

Re: May 2026 Developer Challenge — Week 1: Getting familiar with the events

Re: May 2026 Developer Challenge — Week 2: Connecting to the broker and consuming events

Re: 🇮🇳 Event-driven integrations with SAP Integration Suite, advanced event mesh (Hyderabad, India

Re: 🇮🇳 Event-driven integrations with SAP Integration Suite, advanced event mesh (Hyderabad, India

🇸🇬 Build AI services using SAP CAP and Generative AI Hub (Singapore)

🇮🇳 Build AI services using SAP CAP and Generative AI Hub (Bengaluru, India)

🐍 July Developer Challenge — Snake & Ladder with SAP CAP Status Transition Flows

SAP Developer Challenge - Snake & Ladder with SAP CAP Status Transition Flows

The Scenario

What Makes This Interesting

Challenge Format

Prerequisites

The Board

Ladders (climb up)

Single-Headed Snakes (slide back)

Double-Headed Snakes (two biting ends, one shared tail)

Reusable Board UI

Resources

🐍 July Developer Challenge Week 1 — Model the Board

Week 1 — Model the Board

The Setup

What You'll Build This Week

Prerequisites

Background: CAP Status Flows in 60 Seconds

Step-by-Step

1. Initialise the CAP project

2. Create the data model

3. Create the service

4. Add seed data

5. Run and verify

How to Submit

What's Next

Resources

🐍 July Developer Challenge Week 2 — Roll & Move

Week 2 — Roll & Move

The Setup

What You'll Build This Week

How CAP Enforces State Transitions

Step-by-Step

1. Create the service implementation file

2. Add the domain events to your service CDS

3. Test the state machine manually

4. Test the double-headed snake

The $flow.previous Moment

Stretch Goal

How to Submit

What's Next

🐍 July Developer Challenge Week 3 — Multiplayer & Events

Week 3 — Multiplayer & Events

The Setup

What You'll Build This Week

Background: CAP Events as the Turn Engine

Step-by-Step

0. Upgrade to the latest CAP version

1. Add the TurnLog entity

2. Implement turn rotation in the handler

3. Add a session-level startGame action

4. Test multiplayer turn rotation

5. Connect the CAP MCP Server

Install

Annotate GameService

Start cds watch and the MCP endpoint appears automatically

Add MCP-callable wrapper functions

Note: You can use any MCP tool of your choice.

Use with Claude Code (auto-wired — just ask)

Use with Claude Desktop (manual wiring)

Verify the MCP endpoint — tools list and action tests

Understanding the Two State Machines

Stretch Goal

How to Submit

The `$flow.previous` Moment

1. Add the `TurnLog` entity

3. Add a session-level `startGame` action

Start `cds watch` and the MCP endpoint appears automatically