From e63c2a4c89fa2cc3ce2a5b03aa0e004724f2930f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Adrian=20G=C3=B6rler?= Date: Fri, 19 Jun 2026 18:21:15 +0200 Subject: [PATCH 1/2] Update fiori.md --- guides/uis/fiori.md | 29 +++++++++++++++++++++++------ 1 file changed, 23 insertions(+), 6 deletions(-) diff --git a/guides/uis/fiori.md b/guides/uis/fiori.md index a2c5eb43c..740ccdf60 100644 --- a/guides/uis/fiori.md +++ b/guides/uis/fiori.md @@ -287,7 +287,7 @@ In essence, the draft choreography defines the following flows: - Filling in draft data through a series of _PATCH_ events. - **Saving** the draft back to the active entity, or **discarding** it. -Drafts are isolated from any active data until they are saved/activated. When drafts are discarded, they are removed as if they never existed – with draft locks as the only exception to prevent conflicting changes. +Drafts are isolated from any active data until they are saved/activated. When drafts are discarded, they are removed as if they never existed. Draft locks are the mechanism to prevent conflicting changes. ### Draft Locks @@ -359,7 +359,7 @@ While this was always possible in CAP Java before, it's available for CAP Node.j > Directly updating an active entity does **not** bypass [draft locks](#draft-locks). > If an existing draft locks the entity, direct updates are blocked to prevent lost update situations. -#### Draft-agnostic Requests +#### Draft-agnostic Requests (CAP Node.js) Taking this further, through cds.fiori.draft_new_action: true `IsActiveEntity=true` is assumed by default, so clients that are unaware of drafts or don't need to handle them can ignore all draft-specific requests and parameters: @@ -392,12 +392,20 @@ You can also access draft data programmatically from custom code in JavaScript o In CAP Java, add `IsActiveEntity` as a key parameter to your queries ([learn more](../../java/fiori-drafts#draftservices)): ```java {3} -Select.from(FOO).where(o -> o.ID().eq(201); //> reads active data -Select.from(FOO).where(o -> o.ID().eq(201) .and( //> reads draft data - o.IsActiveEntity().eq(false)) -); +Select.from(FOO).where(o -> o.ID().eq(201).and( + o.IsActiveEntity().eq(true))); //> reads active version +Select.from(FOO).where(o -> o.ID().eq(201).and( + o.IsActiveEntity().eq(false))); //> reads draft ``` +Alternativley you can define a filtered structured type `activeFoos`, which gives you access to active versions only and then just work with `activeFoos`: + +``java +Foo_ activeFoos = CQL.entity(FOO).filter(f -> f.isActiveEntity().eq(true)); //> active versions only +Select.from(activeFoos).byId(201); //> reads active version +``` + + In CAP Node.js, use the [`Foo.drafts`](../../node.js/cds-reflect#drafts) references to access draft data: ```js {3} @@ -413,6 +421,15 @@ this.on ('approveTravel', req => UPDATE (req.subject) .with ({ status: 'A' })) this.on ('rejectTravel', req => UPDATE (req.subject) .with ({ status: 'X' })) ``` +In CAP Java, use an [entity reference](../../java/event-handlers/#entity-reference-arguments) in your handler's method signature which capture the `IsActiveEntity` key component so that you don't have to specify it in your code: + +```java +@On(event = TravelService.APPROVE) +public void approveTravel(Travels_ ref) { + db.run(Update.entity(ref).set("status", "A")); +} +``` + ### Draft Input Validation ###### Validating Drafts From 56dbc7460be69565edb753ce3cfda61562361875 Mon Sep 17 00:00:00 2001 From: Mahati Shankar <93712176+smahati@users.noreply.github.com> Date: Tue, 23 Jun 2026 12:00:07 +0200 Subject: [PATCH 2/2] cosmetics --- guides/uis/fiori.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/guides/uis/fiori.md b/guides/uis/fiori.md index 740ccdf60..891f8bbb8 100644 --- a/guides/uis/fiori.md +++ b/guides/uis/fiori.md @@ -287,7 +287,7 @@ In essence, the draft choreography defines the following flows: - Filling in draft data through a series of _PATCH_ events. - **Saving** the draft back to the active entity, or **discarding** it. -Drafts are isolated from any active data until they are saved/activated. When drafts are discarded, they are removed as if they never existed. Draft locks are the mechanism to prevent conflicting changes. +Drafts are isolated from any active data until they're saved/activated. When drafts are discarded, they're removed as if they never existed. Draft locks serve as the mechanism to prevent conflicting changes. ### Draft Locks @@ -398,9 +398,9 @@ Select.from(FOO).where(o -> o.ID().eq(201).and( o.IsActiveEntity().eq(false))); //> reads draft ``` -Alternativley you can define a filtered structured type `activeFoos`, which gives you access to active versions only and then just work with `activeFoos`: +Alternatively you can define a filtered structured type `activeFoos`, which gives you access to active versions only and then just work with `activeFoos`: -``java +```java Foo_ activeFoos = CQL.entity(FOO).filter(f -> f.isActiveEntity().eq(true)); //> active versions only Select.from(activeFoos).byId(201); //> reads active version ``` @@ -421,7 +421,7 @@ this.on ('approveTravel', req => UPDATE (req.subject) .with ({ status: 'A' })) this.on ('rejectTravel', req => UPDATE (req.subject) .with ({ status: 'X' })) ``` -In CAP Java, use an [entity reference](../../java/event-handlers/#entity-reference-arguments) in your handler's method signature which capture the `IsActiveEntity` key component so that you don't have to specify it in your code: +In CAP Java, use an [entity reference](../../java/event-handlers/#entity-reference-arguments) in your handler's method signature which captures the `IsActiveEntity` key component so that you don't have to specify it in your code: ```java @On(event = TravelService.APPROVE)