Skip to content

Commit be319d5

Browse files
a (#91)
* a * Update nrc-db-subscriptions.md
1 parent 75eba08 commit be319d5

File tree

3 files changed

+89
-0
lines changed

3 files changed

+89
-0
lines changed

docs/nrc-db-subscriptions.md

Lines changed: 84 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,84 @@
1+
# Explanation of the Notification database tables for subscriptions
2+
3+
This document describes the subscription data model in the NRC database. The aim is to clarify the usage of the tables and especially the purpose of table abonnementkanalen that seemingly contains double records. We will explain that these double records are necessary for proper functioning of notification. There are four relevant tables: kanalen, abonnementen, abonnementkanalen, and filtervalues. The following ERD shows their relationships:
4+
5+
![alt text](./nrc_db_subscriptions-1.png)
6+
7+
Below follows an explanation of each of the tables.
8+
9+
## kanalen
10+
11+
The 'kanalen' table corresponds to the ['kanaal' resource in the OAS](https://vng-realisatie.github.io/gemma-zaken/standaard/notificaties/redoc-1.0.0#tag/kanaal/operation/kanaal_create). It represents the source from which notifications originate, such as 'zaken' in the ZRC.
12+
The key columns are:
13+
14+
1. id: PrimaryKey of table 'kanalen'
15+
2. naam: name of the 'kanaal', for example 'zaken' or 'besluiten'
16+
3. documentatielink: the URL to documentation about the 'kanaal'
17+
4. filters: List of possible filter attributes for a kanaal. These filter attributes can be used when creating a subscription.
18+
19+
## abonnementen
20+
21+
The 'abonnementen' table corresponds to the ['abonnement' resource in the OAS](https://vng-realisatie.github.io/gemma-zaken/standaard/notificaties/redoc-1.0.0#tag/abonnement/operation/abonnement_create).
22+
Subscriptions on ZGW notifications received by POST request are stored in this table. The most important columns are:
23+
24+
1. id: PrimaryKey of table abonnementen
25+
2. callbackurl: the full URL of the application's webhook to which the notification should be sent
26+
3. auth: bearer token of the webhook receiver for authorization
27+
4. owner: rsin of the organization that gives the application access
28+
29+
## abonnementkanalen
30+
31+
The 'abonnementkanalen' table corresponds to the individual elements in the 'kanalen' array within 'abonnement' in the OAS.
32+
The table thus establishes the N:M relationship between 'abonnementen' and 'kanalen', which is enabled by the OAS. The PrimaryKey (id) of the table is referenced by the filtervalues table. This allows for a single subscription to be related to the same 'kanaal' multiple times (seemingly double information), but with different filter values in the filtervalues table ​​each time.
33+
34+
The key columns are:
35+
36+
1. id: PrimaryKey of table 'abonnementkanalen'
37+
2. abonnement_id: ForeignKey pointing to a abonnement in the 'abonnementen' table
38+
3. kanaal_id: ForeignKey pointing to a kanaal in the 'kanalen' table
39+
40+
## filtervalues
41+
42+
The 'filtervalues' table corresponds to the 'filters' element within 'abonnement' in the OAS.
43+
44+
Often, it is undesirable to receive all notifications from a kanaal, as this would generate a lot of message traffic. Therefore, it is possible to specify filters on fields from the underlying kanaal in the subscription. Only notifications that match these filter values are being sent thus reducing traffic. The filters are stored in the filtervalues table.
45+
46+
The most important columns are:
47+
48+
1. id: PrimaryKey of table 'filtervalues'
49+
2. abonnement_kanaal_id: foreign key to 'abonnementkanalen' table
50+
3. key: the name of the filter. Possible values are shown in the table 'kanalen' in column 'filters'. Additionally, the values '#resource' and '#actie' are possible in the key field. These refer to the events that trigger the notification to be sent by the resource of the kanaal.
51+
4. value: the value of the filter to be matched.
52+
53+
For example, a filter-value definition for the 'zaken' kanaal could look like this:
54+
55+
- key='domein'
56+
- value='VTH'
57+
58+
In this example, the notification is only delivered if the zaak in question has a zaaktype from the catalog of domein 'VTH'.
59+
60+
The data model allows for multiple filtervalues for each 'abonnementkanalen'. The example below illustrates this:
61+
62+
Abonnementkanalen 1 of abonnement X
63+
Filter A:
64+
65+
- key='#resource'
66+
- value='zaakinformatieobject'
67+
68+
Filter B:
69+
70+
- key='#actie'
71+
- value='create'
72+
73+
Abonnementkanalen 2 of abonnement X
74+
Filter A:
75+
76+
- key='#resource'
77+
- value='zaakinformatieobject'
78+
79+
Filter B:
80+
81+
- key='#actie'
82+
- value='destroy'
83+
84+
The combination of filters within an abonnementkanaal is evaluated as 'AND'. The combination of filters among abonnementkanalen of the same abonnement is evaluated as 'OR'. In this example therefore, the client application will only receive a notification from the zaken kanaal when a zaakinformatieobject is created or deleted.

docs/nrc_db_subscriptions-1.png

48.7 KB
Loading

sidebars.ts

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -6,6 +6,11 @@ const sidebars: SidebarsConfig = {
66
"api-versions",
77
"usage-of-clientids",
88
"authorizations",
9+
{
10+
type: "doc",
11+
id: "nrc-db-subscriptions",
12+
label: "Notification database tables for subscriptions"
13+
},
914
{
1015
type: "doc",
1116
id: "gebruik-van-subscriptions-in-autorisaties",

0 commit comments

Comments
 (0)