Evènements communs entre anomalieadresse et malfacon

[NinjaKinshasa]

La liste des événements pour anomalieadresse et malfacon est la suivante :

Événement	Description
fr.interop.anomalieadresse.update	Mise à jour de l'anomalie adresse
fr.interop.anomalieadresse.note.create	Création d'une note
fr.interop.anomalieadresse.attachment.create	Création d'une pièce jointe
fr.interop.anomalieadresse.attachment.update	Mise à jour d'une pièce jointe
fr.interop.malfacon.create	Création d'une malfaçon
fr.interop.malfacon.update	Mise à jour de la malfaçon
fr.interop.malfacon.note.create	Création d'une note
fr.interop.malfacon.attachment.create	Création d'une pièce jointe
fr.interop.malfacon.attachment.update	Mise à jour d'une pièce jointe

Certains événements sont répliqués pour anomalieadresse et malfacon avec des noms différents mais un rôle identique. J'ai le sentiment que ces évènements sont en fait des évènements "génériques" au niveau du ticket, et qu'ils pourraient être définis dans la partie common plutôt qu'être répliqués.

Je me serai attendu à voir quelque chose comme cela :

Événements communs au niveau du ticket

Événement	Description
fr.interop.ticket.create	Création du ticket
fr.interop.ticket.update	Mise à jour de l'état du ticket
fr.interop.ticket.attachment.create	Création d'une pièce jointe
fr.interop.ticket.attachment.update	Mise à jour d'une pièce jointe
fr.interop.ticket.note.create	Création d'une note

Événements propres aux services

Événement	Description
fr.interop.anomalieadresse.update	Mise à jour de l'anomalie adresse
fr.interop.malfacon.update	Mise à jour de la malfaçon autre que l'état du ticket

Plus précisément, il y a trois notions dans cette idée :

• le concept de pièce jointe est commun à tous les types de tickets
• le concept de note est commun à tous les types de tickets
• le concept d'état (ACKNOWNLEDGED, REJECTED etc) est commun à tous les types de tickets.

Réciproquement, le fait d'avoir des évènements différents suggère qu'ils s'agit de concepts différents, ce qui n'est pas le cas de ce que j'en ai compris.

Question

Pour quelle raison le choix a-t-il été fait de ne pas mutualiser les événements et d'avoir des événements distincts pour anomalieadresse et malfacon alors que leur rôle est identique ?

[ggrebert]

Bonjour @NinjaKinshasa , En effet, il serait possible de mutualiser le nommage entre les 2 protocoles. Pour cela il faut ouvrir aussi une issue dans le projet AA car ce n'est pas forcément les mêmes personnes qui s'en occupe.

Par contre, les valeurs ne peuvent pas être gérées dans common car c'est une valeur lié au métier. Surtout, il est possible de garder la notion d'event sur d'autres protocoles.

Pour rappel, le data model Event est basé sur le standard CloudEvents.

[NinjaKinshasa]

Bonjour @ggrebert,

merci pour ta réponse.

Par contre, les valeurs ne peuvent pas être gérées dans common car c'est une valeur lié au métier.

Donc si je comprends bien il pourrait y avoir un autre service qui n'est pas un troubleTicket qui implemente common mais qui utilise une machine à états différente, et c'est pour cala qu'on ne peut pas gérer les états directement au niveau de common ?

Quelque chose comme ça :

classDiagram
    class Common {
        <<Interface>>
    }

    class TroubleTicket {
        enum status
    }

    class AnomalieAdresse {
        string type
        json data
    }

    class Malfaçon {
        string type
        json data
    }

    class OtherTicket {
        enum otherStatuses
    }

    Common <|-- TroubleTicket
    Common <|-- OtherTicket
    TroubleTicket <|-- AnomalieAdresse
    TroubleTicket <|-- Malfaçon
    Common: create()
    Common: createNote()
    Common: createAttachment()

C'est correct ?

Si c'est bien, est ce que tu es ok pour que je propose le renommage suivant :

Événement	Nouveau nom
fr.interop.anomalieadresse.note.create	fr.interop.ticket.note.create
fr.interop.anomalieadresse.attachment.create	fr.interop.ticket.attachment.create
fr.interop.anomalieadresse.attachment.update	fr.interop.ticket.attachment.update
fr.interop.malfacon.note.create	fr.interop.ticket.note.create
fr.interop.malfacon.attachment.create	fr.interop.ticket.attachment.create
fr.interop.malfacon.attachment.update	fr.interop.ticket.attachment.update

Ou est ce que c'est mieux avec fr.interop.troubleticket.* ?

Mais du coup ne peut pas renommer ces trois là :

Événement non renommés
fr.interop.anomalieadresse.update
fr.interop.malfacon.create
fr.interop.malfacon.update

...Car il faudrait faire la distinction entre l'évènement "update de l'état du ticket" et l'événement "update d'un attribut de anomalieAdresse ou malfacon qui n'est pas l'état du ticket". Faire cette distinction impliquerai donc deux choses:

• ajouter un évènement fr.interop.ticket.update
• modifier la définition de fr.interop.anomalieadresse.update et fr.interop.malfacon.update pour qu'ils ne soient plus déclenchés sur un update de l'état du ticket. Il ne s'agit plus d'un simple renommage, et je n'ai pas une connaissance suffisante du système pour savoir si c'est une bonne ou une mauvaise idée de séparer les évènements comme cela.

[richard-olvera]

vu en interop du 18 juin