Skip to content

Commit b5ea799

Browse files
soccermaxsoccermax
committed
wip
1 parent 2d60dc4 commit b5ea799

File tree

3 files changed

+62
-20
lines changed

3 files changed

+62
-20
lines changed

‎CHANGELOG.md‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -11,6 +11,7 @@ and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.
1111

1212
- CAP outbox: allow to return the event status. [Documentation](https://cap-js-community.github.io/event-queue/use-as-cap-outbox/#how-to-return-a-custom-status)
1313
- Keep alive handling to reduce the time after which events are restarted after a server crash.
14+
- Allow to define events and periodic events by configuration. [Documentation](https://cap-js-community.github.io/event-queue/configure-event/#configuration)
1415

1516
## v1.8.7 - 2025-02-05
1617

‎docs/configure-event/index.md‎

Lines changed: 58 additions & 19 deletions
Original file line numberDiff line numberDiff line change
@@ -15,21 +15,60 @@ nav_order: 4
1515

1616
<!-- prettier-ignore-end -->
1717

18+
# Where to Define Events?
19+
20+
Events can be configured either via `cds.env` or by passing them during the `eventQueue.initialize` call. Both options
21+
are described below. Choose the right option depending on your initialization method (
22+
see [here](/event-queue/setup/#ways-of-initialization)).
23+
24+
## Configuration
25+
26+
The easiest way is to use `cds.env`. This configuration method supports all parameters compatible with the YAML format.
27+
The event `type` and `subType` are derived from the key in the object. Based on the example below, these would be
28+
`Notification` and `Email`.
29+
30+
This approach allows full flexibility with `cds.env`, enabling techniques like `.cdsrc.json` and CDS profiles to adjust
31+
and extend event settings.
32+
33+
```json
34+
{
35+
"cds": {
36+
"eventQueue": {
37+
"events": {
38+
"Notification/Email": {
39+
"impl": "./srv/util/mail-service/EventQueueNotificationProcessor",
40+
"load": 1,
41+
"parallelEventProcessing": 5
42+
}
43+
},
44+
"periodicEvents": {
45+
"HealthCheck/DB": {
46+
"impl": "./test/asset/EventQueueHealthCheckDb",
47+
"load": 1,
48+
"transactionMode": "alwaysRollback",
49+
"interval": 30
50+
}
51+
}
52+
}
53+
}
54+
}
55+
```
56+
57+
## YAML File
58+
59+
Examples are shown in the sections below. See [here](#configuration-1) and [here](#configuration-2).
60+
1861
# Ad-Hoc events
1962

2063
Ad-hoc events are one-time events that are either processed directly or with a defined delay. The purpose of such events
2164
is to process asynchronous loads, such as sending email notifications or compressing uploaded attachments, where you
2265
don't want the user to wait until the process is finished. These events have various configurations to determine how
2366
they should be processed.
2467

25-
## Configuration
26-
27-
The configuration YAML file is where all the required information regarding event processing should be maintained.
28-
2968
## Parameters
3069

3170
| Property | Description | Default Value |
32-
| ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------- |
71+
|-------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------|
3372
| impl | Path of the implementation class associated with the event. | - |
3473
| type | Specifies the type of the event. | - |
3574
| subType | Specifies the subtype of the event, further categorizing the event type. | - |
@@ -83,7 +122,7 @@ instance is overloaded.
83122
## Parameters
84123
85124
| Property | Description | Default Value |
86-
| ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------- |
125+
|-------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------|
87126
| impl | Path of the implementation class associated with the event. | - |
88127
| type | Specifies the type of the periodic event. | - |
89128
| subType | Specifies the subtype of the periodic event, further categorizing the event type. | - |
@@ -169,7 +208,7 @@ or months. Please note that the minimum interval allowed between two executions
169208
maintains stability and avoids overloading.
170209

171210
| Cron Expression | Description |
172-
| ------------------- | ------------------------------------------------------------------------- |
211+
|---------------------|---------------------------------------------------------------------------|
173212
| `0 * * * *` | Runs at the start of every hour. |
174213
| `* * * * *` | Runs every minute. |
175214
| `0 0 * * *` | Runs at midnight every day. |
@@ -213,7 +252,7 @@ The initialization configuration can be changed by setting the value of the corr
213252
config class instance. Here is an example:
214253

215254
```js
216-
const { config } = require("@cap-js-community/event-queue");
255+
const {config} = require("@cap-js-community/event-queue");
217256
218257
config.runInterval = 5 * 60 * 1000; // 5 minutes
219258
```
@@ -223,7 +262,7 @@ config.runInterval = 5 * 60 * 1000; // 5 minutes
223262
To change the configuration of a specific event, you can refer to the example below:
224263

225264
```js
226-
const { config } = require("@cap-js-community/event-queue");
265+
const {config} = require("@cap-js-community/event-queue");
227266
228267
const eventConfig = config.getEventConfig("HealthCheck", "DB");
229268
eventConfig.load = 5;
@@ -250,7 +289,7 @@ accomplished.
250289
## Blocking/Unblocking based on configuration
251290

252291
```js
253-
const { config } = require("@cap-js-community/event-queue");
292+
const {config} = require("@cap-js-community/event-queue");
254293
255294
// Block type: HealthCheck and subType: DB for tenant 123
256295
const isPeriodicEvent = true;
@@ -272,10 +311,10 @@ For greater flexibility, the decision to block an event can be determined based
272311
The example below shows how to register the callback.
273312

274313
```js
275-
const { config } = require("@cap-js-community/event-queue");
314+
const {config} = require("@cap-js-community/event-queue");
276315
277316
config.isEventBlockedCb = async (type, subType, isPeriodicEvent, tenant) => {
278-
// Perform custom check and return true or false
317+
// Perform custom check and return true or false
279318
};
280319
```
281320

@@ -288,15 +327,15 @@ To react to unsubscribe events across all application instances, the event-queue
288327
that are triggered when a tenant is unsubscribed. Follow the code example below:
289328

290329
```javascript
291-
const { config } = require("@cap-js-community/event-queue");
330+
const {config} = require("@cap-js-community/event-queue");
292331
293332
config.attachUnsubscribeHandler(async (tenantId) => {
294-
try {
295-
cds.log("server").info("received unsubscribe event via event-queue", { tenantId });
296-
await cds.db.disconnect(tenantId);
297-
} catch (err) {
298-
logger.error("disconnect db failed!", { tenantId }, err);
299-
}
333+
try {
334+
cds.log("server").info("received unsubscribe event via event-queue", {tenantId});
335+
await cds.db.disconnect(tenantId);
336+
} catch (err) {
337+
logger.error("disconnect db failed!", {tenantId}, err);
338+
}
300339
});
301340
```
302341

‎docs/setup/index.md‎

Lines changed: 3 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -64,8 +64,10 @@ such as the configuration file path, event processing behavior, load balancing,
6464
The table includes the parameter name, a description of its purpose, and the default value if not specified.
6565

6666
| Name | Description | Default | Can be changed at runtime |
67-
| :----------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------- | :------------------------ |
67+
|:-------------------------------------|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:---------------| :------------------------ |
6868
| configFilePath | Path to the configuration file. | null | no |
69+
| events | Options to allow events in the configuration. E.g. via cds-env. | {} | no |
70+
| periodicEvents | Options to allow periodicEvents in the configuration. E.g. via cds-env | {} | no |
6971
| registerAsEventProcessor | Whether or not to register as an event processor. If false, the app can publish events but doesn't process events. | true | no |
7072
| processEventsAfterPublish | Whether or not to process events immediately after publish. Events are distributed via Redis to all available app instances. | true | no |
7173
| isEventQueueActive | Determines if the event queue is active. This property controls whether events are automatically processed. It can be modified in real-time to temporarily disable periodic runs. | true | yes |

0 commit comments

Comments
 (0)