error in SINAPS workflow

Description

It seems that Passport send acquisition ( like role deletion) before sending acknowledgment of diffusion

Distribution Name and Version

Debian

FusionDirectory Version

1.3.1

Plugin with the defect

SINAP

PHP version used

7

Origin of php packages

from debian

Steps to Reproduce

1. a user is expired on sinaps
2. sinaps send a diffusion
3. FD send acquisition
4. FD send acknoledgement of diffusion

Expected behavior:

we must have following order

1. sinaps send diffusion
2. FD acknowledge diffusion
3. FD send acquisition

Reproduces how often: no information

Additional Information

Message of SINAPS support

De plus, nous constatons au travers des logs que FUSIONDIRECTORY envoie la suppression du rôle EXT de type "AN" avant d'avoir retourné la réponse d'acquittement (synchrone) de la diffusion. De fait, la référence croisée FUSIONDIRECTORY est supprimée dans Sinaps et lorsque l'acquittement arrive, il recherche cette référence croisée qui n'existe plus. Cela a pour impact de re-créer une ligne dans la table des références croisées pour laquelle la valeur de la colonne "clé primaire de l'objet métier cible" est vide. Il est indispensable que les actions soient traitées dans le bon ordre à savoir :

• d'abord le retour d'acquittement Synchrone de FUSIONDIRECTORY
• et ensuite seulement l'envoi par FUSIONDIRECTORY à SINAPS de la suppression Cela doit être vu côté FUSIONDIRECTORY.

changed milestone to %FusionDirectory 1.3.2

added Bugs plugin-sinaps labels

assigned to @bmortier

added PJ1807-0216 label

added 1 deleted label

changed due date to June 27, 2019

hello @MCMic,

to be coded in the 1.3.1-fixes branch

Cheers

FD cannot send an answer to the Diffusion before is has been treated, so it needs to make the modifications on the user before it sends the answer.

FD cannot do anything after the answer has been sent because of how synchrone HTTP transaction works.

When applying the edit to the user, it triggers the acquisition, because this is how it’s supposed to work, any modification to a user triggers sinaps Acquisition.

What we can do easily is bypass the acquisition when modifying a user from diffusion, maybe only in some cases.

If we want to bypass it and send it later I think we’ll need to go back to asynchrone mode but that will be a lot of work.

added 20m of time spent at 2019-06-27

hello @gallak @MCMic,

here is the debug of the issues as discussed already

pb-synchro.odt

removed due date

Voilà la description exacte du bug sous forme de diagramme:

Le problème est donc que Sinaps supprime la référence croisée lors du traitement de l’acquisition et bug quand l’acquittement de la diffusion revient.

Ça ne devrait pas être un problème pour Sinaps, c’est lui qui a déclenché la diffusion, il ne devrait pas créer une référence fantôme quand elle est acquittée. C’est aussi lui qui décide quand supprimer la référence croisée, ce n’est pas du ressort de FD. Donc si il a besoin de la garder jusqu’à l’arrivée de l’acquittement de la diffusion il peut.

added 1h of time spent at 2019-08-07

mentioned in commit cbdce345

added 2h of time spent at 2019-09-03

added To Be Tested label

assigned to @gallak and unassigned @bmortier

removed Bugs label

It have been tested today fusiondirectory-plugin-sinaps 1.3-2~jenkinsbuild112

When a sinaps record has been deleted, FD answer

<?xml version="1.0" encoding="UTF-8"?>
<socle:root xmlns:socle="http://socle.sinaps.amue.fr/V1_1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:sinaps="http://common.nomenclature.sinaps.amue.fr/V1_1" xmlns:adr="http://referentiels.sinaps.amue.fr/adresseContact/V1_0" xmlns:ie="http://xml.insee.fr/schema" xmlns:prs="http://referentiels.sinaps.amue.fr/personne/V1_0">
  <domaine code="PERSONNE">
    <identifiantTransaction>d91951dd-b22b-43c3-9fff-419197b22e99</identifiantTransaction>
    <donnees>
      <operation codeOperation="ACQUISITION" version="1.0">
        <personne>
          <identifiantExternePersonne>19af07df-2242-45f1-a358-ab51ed02be63</identifiantExternePersonne>
          <dateSuppression>2019-09-24</dateSuppression>
        </personne>
      </operation>
    </donnees>
  </domaine>
</socle:root>

which is correct and no empty line appears on SINAPS

closed

mentioned in issue #5997 (closed)

removed To Be Tested label

changed milestone to %FusionDirectory 1.3.1

added 1 deleted label

added Fixed label