[BO - Teamnet] Intégrer interfaçage à iDoss

[numew]

Ticket

#2515

Description

Interfaçage avec iDoss pour la création de dossier

Changements apportés

• Réorganisation de la page création/édition d'un partenaire
• Ajout des options iDoss configurable sur le partenaire
• Envoie du dossier vers iDoss pour les partenaire configuré lors de l'acceptation de l'affectation

Pré-requis

Ajout dans env.dev (voir user et pass dans la collection postman dispo ici https://drive.google.com/drive/folders/1oH6EfN8raeA_-2iBNAX5LD0-j2M1aX_x?usp=drive_link)

FEATURE_IDOSS_ENABLE=1
IDOSS_USERNAME='XXX'
IDOSS_PASSWORD='YYY'

make load-fixtures
make worker-start

Tests

• Se connecter avec user-13-05@histologe.fr et accepter l'affectation sur le signalement http://localhost:8080/bo/signalements/00000000-0000-0000-2023-000000000012
• Vérifier qu'il y'a une nouvelle entrée dans la table job_event de service idoss avec un statut success

[emilschn]

il faudrait peut-être un mock comme pour Esabora ?
Sinon on est tributaire de la disponibilité d'idoss pour notre CI :)

[sfinx13]

également pour le dev comme c'est arrivé lors de la coupure du web-service

[numew]

En l'état cette URL c'est pour pouvoir tester à la main mais ce n'est pas utilisé par la CI (ceci dit je vais retravailler la partie test auto, mais on ne dépendra pas du service externe)

[sfinx13]

Comme évoqué mais pas d'urgence il faudra être capable de travailler en local (peut être fait plus tard)
Ex => http://histologe_wiremock:8080/ARS/ws/rest
Genre => http://histologe_wiremock:8080/idoss/ws/rest

[emilschn]

Quelques commentaires. Je n'ai pas encore testé.
Mais peut-être que ça manque de test ? (expiration du token, tester des cas qui ne sont pas censés marcher...?)

[hmeneuvrier]

J'ai testé le cas que tu as cité, et il est OK.
J'ai testé aussi une acceptattion d'affectation pour un partenaire ARS et c'est OK aussi (ça ne créé pas un job event).
J'ai testé la page partenaire pour différents utilisateurs et différents types de partenaires (d'où mes remarques)

Mais je pense qu'il faudrait un peu plus de TNR sur les autres interfaçages, et tester aussi les cas en erreur pour vérifier qu'on reçoit les erreurs convenablement.

[sfinx13]

également pour le dev comme c'est arrivé lors de la coupure du web-service

[sfinx13]

Proposition d'évolution pour éviter de s'appuyer sur le statut des affectations

Introduction d'événements explicites
Faudrait introduire des événements explicites pour éviter la dépendance au statut d'affectation et rendre le code plus lisible sur les conditions d'envoi

Stockage des événements en base
Dans le champ de type JSON discuté en PR event_name peut être ajouté pour stocker le type d'événement (acceptation ou affectation).
En constante dans le dossierMessageFactories ça sera plus simple

Modification du contrôleur
Le contrôleur doit être capable de différencier si l'événement est une acceptation ou une affectation.

    $this->interconnectionBus->dispatch($affectation, $event);

Mise à jour du bus d'interconnexion
La méthode dispatch du InterconnectionBus doit être mise à jour pour inclure l'événement en tant que paramètre.

    public function dispatch(Affectation $affectation, string $event): void
    {
        /** @var DossierMessageFactoryInterface $dossierMessageFactory */
        foreach ($this->dossierMessageFactories as $dossierMessageFactory) {
            if ($dossierMessageFactory->supports($affectation, $event) {
                $this->messageBus->dispatch($dossierMessageFactory->createInstance($affectation));
            }
        }
    }

Les dossierMessageFactories doivent supporter ce nouveau paramètre

    public function supports(Affectation $affectation, string $event): bool
    {
        return $event === $dossierMessageFactory->getEvent()
            && $this->isEsaboraPartnerActive($affectation)
            && PartnerType::ARS === $affectation->getPartner()->getType();
    }

Faire évoluer l'interface pour forcer la déclaration d’événement pour chaque dossier factory

#[AutoconfigureTag('app.dossier_message_factory')]
interface DossierMessageFactoryInterface
{
    public function getEvent() : string;

    public function supports(Affectation $affectation, string $event): bool;

    public function createInstance(Affectation $affectation): DossierMessageInterface;
}

[sfinx13]

J'ai laissé 3 com mais lecture et test OK

[sfinx13]

restons sur les codes erreur http (500 fera l'affaire)

[numew]

Je préfère garder un code à part en cas d'exception pour justement savoir que ce n'est pas un retour erreur serveur

[sfinx13]

Rendre le type php en DateTimeImmutable, il sera donc pas nécessaire d'ajouter le paramètre doctrine type, ça sera automatique

[sfinx13]

Comme évoqué mais pas d'urgence il faudra être capable de travailler en local (peut être fait plus tard)
Ex => http://histologe_wiremock:8080/ARS/ws/rest
Genre => http://histologe_wiremock:8080/idoss/ws/rest

[sonarcloud]

Quality Gate failed

Failed conditions
4.2% Duplication on New Code (required ≤ 3%)

See analysis details on SonarCloud

[hmeneuvrier]

Relecture et retests OK pour moi