You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+59Lines changed: 59 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -874,6 +874,17 @@ A Cloud Event message has the following structure:
874
874
}
875
875
```
876
876
877
+
To configure the CloudEvents format, the service needs to be annotated in addition with `@websocket.format: 'cloudevent'` or
878
+
`@ws.format: 'cloudevent'`.
879
+
880
+
```cds
881
+
@ws
882
+
@ws.format: 'cloudevent'
883
+
service CloudEventService {
884
+
// ...
885
+
}
886
+
```
887
+
877
888
To create a Cloud Event compatible CDS event, either the event is modeled as CDS service event according to the specification
878
889
or a CDS event is mapped via annotations to a Cloud Event compatible event.
879
890
@@ -1010,6 +1021,54 @@ cloud event data section.
1010
1021
1011
1022
Static and dynamic annotations can be combined. Static values have precedence over dynamic values, if defined.
1012
1023
1024
+
##### Cloud Event Operation
1025
+
1026
+
CDS service operations (actions or functions) can also be exposed via cloud event. The operation name is derived from the `@websocket.cloudevent.name` or
1027
+
`@ws.cloudevent.name` annotation. Emitting a cloud event based websocket event that matches the annotation value of `name`, calls the
1028
+
respective service operation handler.
1029
+
1030
+
The operation parameter structure can be either modelled according to the Cloud Event specification using the attributes as parameter names or
1031
+
mapped via annotations like `@websocket.cloudevent.<annotation>` or `@ws.cloudevent.<annotation>` to a Cloud Event compatible structure.
0 commit comments