Bruk av meldingsk?

For ? lese og skrive til meldingsk?a, treng du ein brukar i meldingsk?a med dei rette tilgangane. Vi skiljer mellom brukarar for avsendarar (publishers) og mottakarar (consumers). Avsendarar skal ikkje ha tilgang til k?er, og mottakarar skal ikkje kunne skrive til exchange-entiteter. Mottakarar har tilgang til ? opprette k?er og knytte dei til exchange-entiteter.

Exchange

Ein exchange er eit "postkontor" som ein avsendar sender notifikasjonar til. Notifikasjonane distribuerast (router) vidare derfra, til dei forskjellige k?ene som vil ha den relevante notifkasjonen.

P? UiO bruker vi prim?rt berre ein exchange, "ex_messages", for alle avsendarar. Denne ruter notifikasjonar med metoden Topic Exchange.

K?

Ei k? (queue) er ¨¦in konsument si samling av notifikasjonar, eller kva type notifikasjonar den vil ha (sj? Binding). RabbitMQ vidaredistribuerer (router) dei notifikasjonane k?a vil ha. Konsumenten abonnerer d? p? denne k?a.

Navnet til k?ene starter p? "q_", og b?r inneholde navnet p? mottakaren eller tenesten som bruker den. Til d?mes "q_ad_microservice" eller "q_cerebrum".

Binding

Kvar k? settast opp med kva type notifikasjonar den vil ha - k?a m? vere bunden (bound) til ein exchange med ein eller fleire n?klar. For topic exchange, som "ex_messages" er, g?r knyttinga mot topic.

Administratorbrukaren i RabbitMQ set opp dette for forh?ndsdefinerte k?er, rett etter at k?a er oppretta. Mottakar kan ogs? sj?lv definere k?a, men m? d? ha lesetilgang til ex_messages og skrivetilgang til k?a den vil binde.

Til d?mes kan k?a q_ad_microservice binde seg til ex_messages med n?kkelen "cerebrum.event.account.*". Dette gjer at alle notifikasjonar med topic som starter med "cerebrum.event.account." vil dukke opp i q_ad_microservice.

Topic

N?r topic exchange brukast for ? distribuere (route) notifikasjonar fr? exchange til riktig k?, m? avsendar markere kvar notifikasjon med ein message routing key (topic). RabbitMQ vil sj? p? topic og vidaresende (route) notifikasjonen til dei k?ene som har binding mot samme topic.

`kilde`.`type`.`objekt`.`hending`

der:

Notifikasjonar

Kva finn du av innhald i notifikasjonane? Etter UiO sin integrasjonsarkitektur skal notifikasjonar vere tynne, som betyr at dei skal prim?rt brukast til ? informere om at noko har skjedd, for ein gitt entitet, men fortel deg ikkje meir om entiteten. Dette m? du f? ved ? sp?rre kjeldesystemet.

Det er opp til kvar teneste ? definere formatet p? notifikasjonane sine. Dette skal vere dokumentert hos kvart API, p? api.uio.no.

Til d?mes bruker Cerebrum og SAPUiO eit notifikasjonssformat som er inspirert av SCIM sitt utkast til standard p? eit meldingsformat, der vi bruker versjonen med minimalt med informasjon. D?me p? korleis ei melding vil sj? ut, omtrent:

{
  // token identifier (unik id for meldingen)
  "jti": "4d3559ec67504aaba65d40b0363faad8",
  // endringer
  "eventUris": [
    "urn:ietf:params:event:SCIM:create"
  ],
  // timestamp
  "iat": 1458496404,
  // issuer
  "iss": "https://cerebrum-uio.uio.no",
  // audience (spreads/kontekst) - gjer det enklare ? forkaste meldingar du ikkje er interessert i
  "aud": [
   "AD_account",
   "exchange_acc@uio.no",
   "LDAP_account"
  ],
  // URL til entitet (GET)
  "sub": "https://cerebrum-ws.uio.no/v1/accounts/1234",
  // Parametre til event - her: kva attributtar hos objektet som er p?virka - gjer det enklare ? forkaste meldingar du ikkje er interessert i
  "urn:ietf:params:event:SCIM:create":{
    "attributes":["id","name","userName","password","emails"],
  }
}

Andre system, som FS og TP brukar, eit format som er avleda fr? JWT-standarden. Eit d?me p? ein notifikasjon fr? FS om at ein person er oppdatert (routing key er i dette tilfelle no.uio.fs.FS-prod.personer.update)

{"sub": "personer/56154",
 "iss": "FS-prod",
 "iat": "1582344412462",
 "operation": "update",
 "jti": "35380ac0-247d-44b3-9be3-2f2dded049ee",
 "person_id": "56154"}

Det kan og vere lurt ? ta ei avgjersle om korleis du skal referere til ressursar i kjeldesystem. Til d?mes er me bunden til eit spesielt domene i dette tilfellet:

{"sub": "https://api-waygate.uio.no/eksempeltjeneste/5"}

Mens f?ljande ikkje er bunden til ei spesifikk maskin:

{"sub": "/5",
 "iss": "eksempeltjeneste"}

Det same kan du oppn? med ein meir formalisert URN:

{"sub": "urn:eksempeltjeneste:5"}

I dei to siste d?ma har me ikkje inkludert informasjon om kor ei ressurs er lokalisert. N?r du hentar ressursen m? du d? velje ? sl? opp maskinnavnet. Erfaringsmessig lettar dette arbeidet med ? flytte tenester mellom forskjellige milj?.

For nyutvikla system, b?r du vurdera ? bruka standariserte format, til d?mes CloudEvents.

Meir info

• RabbitMQ si offisielle side
• Tutorials og koded?mer fr? RabbitMQ
• RabbitMQ si beskriving av begrepa i AMQP
• Beskrivelse av meldingsprotokollen AMQP 0.9.1
• Meldingsformatet til SCIM, som er utgangspunktet for mange av meldingene, som igjen baserer seg p? JWT (RFC 7519)