Definere event-typer

[elsand]

Basert på hendelsestypene som vi får fra DA (TODO! Insert swagger her) må det mappes opp interne event-typer som feedpoller genererer og som de andre appene (inbound-event-handler, authz) konsumerer.

Det må også defineres eventtyper som skal brukes for eksternt konsum, som for MVP kun vil være at skifteerklæring er sendt inn.

Se oversikt over felter i Excel

Foreløpig liste:

Fra DA:

• no.altinn.events.digitalt-dodsbo.v1.status-updated
• no.altinn.events.digitalt-dodsbo.v1.heir-roles-updated

Fra DD:

• no.altinn.events.digitalt-dodsbo.v1.declaration-submitted

• [x] Beslutt liste

• [x] Lag Cloudevents for disse

Documentation: https://altinn.studio/repos/digdir/oed-events/src/branch/master/README.md

[bdb-dd]

Google is the one cloud platform that has invested a lot in event driven architecture and adopted the Cloud Events standard throughout their products.

Here are a few random examples from different Google APIs:

Without subject:

"source": "//pubsub.googleapis.com/projects/atamel-eventarc-gke/topics/eventarc-us-central1-trigger-pubsub-gke-729", "type": "google.cloud.pubsub.topic.v1.messagePublished"

With subject:

...
"source": "//cloudaudit.googleapis.com/projects/atamel-eventarc-gke/logs/data_access",
"subject": "storage.googleapis.com/projects/_/buckets/eventarc-gcs-atamel-eventarc-gke/objects/random.txt",
"type": "google.cloud.audit.log.v1.written"
...

...
"source": "//storage.googleapis.com/projects/_/buckets/eventarc-gcs-atamel-eventarc-gke",
"subject": "objects/random.txt",
"type": "google.cloud.storage.object.v1.finalized"
...

For cases where the event has a direct relation to a REST resource, source is usually specified as a URL, or rather the static parts of a URL, while subject includes the dynamic part of the path.

[bdb-dd]

Regarding type, the cloud event spec recommends specifically to use a reverse DNS format, with the following examples:

• com.github.pull_request.opened
• com.example.object.deleted.v2

Versioning is also a recurring theme in the naming of types. Google lists a comprehensive set of event types they support and many seem to have started their lifecycle as ".v1beta" something.

https://cloud.google.com/eventarc/docs/reference/supported-events

It could be that "type" is the better field to base Registry resolution on as it is more likely to be stable, where as source is quite likely to change if we use URLs.

Some examples of event names following a reverse DNS naming convention:

"no.domstol.dodsbo.v1beta.opprettet" "no.domstol.dodsbo.v1beta.annulert" "no.domstol.dodsbo.v1beta.skifteform_satt" "no.domstol.dodsbo.v1beta.roller_oppdatert"

[elsand]

@b-brodie-digdir Den lista ser bra ut. Jeg har lagt den inn som "besluttet" i beskrivelsen. Hva tenker du om "no.digitaltdodsbo.v1beta.skifteerklaering_sendt" som eventet som kommer fra DD? er vel rimelig å ha et eget namespace for eventer som kommer fra oss.

Har lagt inn eksempel på "no.domstol.dodsbo.v1beta.roller_oppdatert" i #600. Fint om du får lagt inn en fullstendig liste over alle cloudevents med de nevnte typene i denne issuen, så er det den som gjelder inntil vi får dette dokumentert et sted.

[elsand]

@b-brodie-digdir Ser av branchen din til feedpoller at du har gått for en litt annen variant, som jeg egentlig liker bedre. Har oppdatert lista over utfra den, samt lagt inn en versjons-del. Usikker på om vi egentlig ender opp med noe mer enn "status-updated" og "heir-roles-updated" ?

[bdb-dd]

Anything from this issue that we should document somewhere else? I've migrated the sequence diagrams to the oed-events README.md file for convenience.

[elsand]

@b-brodie-digdir oppdaterer denne issuen med lenke til https://altinn.studio/repos/digdir/oed-events/src/branch/master/README.md og synker