...
The table below shows how previously proposed headers should be mapped to pre-defined CNFC headers.
Before | After1 | CloudeEvent builder method | Example Value | Notes |
|---|---|---|---|---|
eventId | (ce_)id | .withId() | Mandatory | |
eventSource | (ce_)source | .withSource() | Mandatory | |
N/A | (ce_)specversion (default 1.0) | .v1() | 1.0 | Mandatory - This is the version of the cloud events |
eventType | (ce_)type | .withType() | Mandatory | |
eventTime | (ce_)time | .withTime() | Optional (could be Mandatory for | |
eventSchema | (ce_)dataschema | .withDataSchema() | Optional includes the version of the schema | |
| datacontenttypecontent-type2 | withDataContentType() | application/json | Optional | |
| eventCorrelationId | (ce_)correlationid | .withEXtensionwithExtension() | Optional This will be part of the eXtensions field in the cloud events and all the restrictions of the attribute field naming applies to it. i.e these fields will be in the small case. This is marked as optional as it only applies to some events. | |
| event | (ce_)data | .withData(json TBC) | Mandatory actual event/payload now would be under "data" field. |
- Note 1 all cloud-event headers will be prefixed during serialization with 'ce_' (this means when filtering on serialized Kafka-headers this prefix need to be applied)
- Note 2 content-type is a a 'default' header name no 'wrapped' by CloudEvents and hence the inconsistency in names and that is does NOT have the 'ce_' prefix.