OTT PM tool docs Help

Message queue

Použijeme RabbitMQ.

Komunikace skrz MQ bude fungovat asi následovně:

  • Jedna fronta je pouze pro Event sourcing.

    • Jednotlivé moduly do ní posílají informace o změnách ve svých datech.

    • Workflow modul bude události zpracovávat a ukládat do event store.

  • Ostatní moduly mají každý svou frontu, ale zprávy jsou předávány pomocí RabbitMQ routování.

    • Moduly pushují zprávy do jedné exchange, která přeposílá zprávy do správné fronty.

    • Fronta sama definuje, které routing key jí zajímají (tzn. modul si definuje svojí frontu a své routing key, které poslouchá)

    • Workflow modul by měl zpracovávat všechny zprávy nehledě na routing key (jeho fronta poslouchá všechny)

Formát zpráv

Ačkoliv RabbitMQ nedefinuje žádný konkrétní formát zpráv, díky použití Roadrunner je třeba držet formát kompatibilní s ním.

Bohužel formát není nikde jednoduše zdokumentovaný, ale v základu potřebujeme 2 věci:

  1. Tělo zprávy (body/obsah) je JSON string

  2. V metadatech zprávy je uvedený typ zprávy s klíčem rr_job.

Pro zjednodušení připravíme wrapper knihovnu, která umožní pushovat a parsovat kompatibilní zprávy přímo do RabbitMQ z PHP/Laravelu.

Formát zprávy pro modul

Moduly si můžou definovat vlastní formát zprávy (JSON) strukturu, ale bylo by dobré se držet aspoň nějaký podobný formát - bude upřesněno.

Formát zprávy pro Event sourcing

Pro event sourcing bude třeba držet jednotný formát zprávy.

Typ zprávy: 'insert'|'update'|'delete'

Přibližná struktura zprávy:

{ "entity": "App\Models\Entity", "id": 1, "user": 1, "data": { "property1": "value1", "property2": 123 } }

Položka

Povinné

Typ

Popis

entity

ano

string (Entity::class)

Typ entity, které se změna týká. Měl by to být celý název třídy všetně namespace. Případně pokud by se nepoužilo ORM, tak se dá použít název tabulky, nebo nějaký jiný jednoznačný identifikátor.

id

ano

int

ID entity. Při insert operaci je tedy nutné nejdřív ID získat z DB a potom až posílat event.

user

ano

int/string

ID uživatele, který změnu vyvolal, nebo "system" pro změny vyvolané jiným modulem.

data

ano (insert a update) / ne (delete)

object

Objekt obsahující všechny změny v entitě. Není třeba posílat všechny vlastnosti entity, ale ideálně jen ty, které se změnili.

Last modified: 06 února 2025