Comparaison des versions

Légende

  • Ces lignes ont été ajoutées. Ce mot a été ajouté.
  • Ces lignes ont été supprimées. Ce mot a été supprimé.
  • La mise en forme a été modifiée.

Présentation

Comprendre comment s’articulent les scripts, leur rôle et toutes les informations techniques telles que le bodyData ou l’antil'anti-loop.
Nous partons du principe que le paramétrage du datatracking est acquis.
Si ce n’est pas le cas, il est conseillé de consulter cette page en amont : Traquer une table et un champ

...

Lorsqu’une entité est intégrée dans la gestion des notifications du studio, le datatracking sera déclenché suivant les actions définis dans le paramétrage.
Le déclenchement se fera depuis :

  • Le BackOffice

  • La Synchronisation

  • Les backend

  • Les webhook

  • Les événements

S’en suivra plusieurs étapes :

  • Le système écrira une ligne dans sw_sys_brokermessage. Table à ne pas altérer.

  • Le service broker-message-gateway parcours tous les projets et regarde s'il y a des messages à envoyer au serveur RabbitMQ.

  • Le service JobCenter crée les queues de messages dans RabitMQ au démarrage et gère le dispatching, qui au final appel le script d'endpoint définis dans le notifications managment du studio.

...

  • Le script d’endpoint ou script d’entrée

    • C’est le script définit dans la paramétrage du studio dans Tools > Notifications managment
      En l’appelant, le système lui passe un objet document JSON appelé bodyData détaillé plus bas, accessible via la variable éponyme.

      • Exemple : SysNotifcation_Customer

  • Le script de parsing

    • Appelé par le script d'endpoint. Il permet de boucler sur les data présentes dans l'objet le document JSON bodyData et de les traiter en conséquence.

      • Exemple : SysNotification_Customer_ParseForEach

  • Le script d’overload

    • Appelé en amont du script de parsing. Il permet d'intégrer un point de surcharge afin de proposer des traitements supplémentaires à ceux du standard.

      • Exemple : SysNotificationOverload_Customer

  • Le script annexe

    • Permet d’exécuter des instructions qui pourraient êtres appelés par les script de parsing ou script de surchage.

      • Exemple : FuncSysNotification_InsertNotification

...

Actuellement, nous utilisons le système de datatracking pour trois raisons :

  • Les notifications système

    • Les script SysNotification

  • La gestion d’une entité

    • Les script Datatracking_MainHandling

  • Les échanges externes

    • Les scripts ExtDataUpdateAsync

BodyData

...

Lorsque le script d'endpoint est exécuté, il reçoit en entrée un document JSON accessible via la variable bodyData.

Le document JSON contient un tableau dont chaque élément à les propriétés suivantes :

  • ProjectCode

  • TableName

  • RowID : Clé primaire de l'enregistrement (exemple : customer_ID)

  • RowCode : Code de l'enregistrement (exemple : codeCustomer)

  • Company_ID

  • Device_ID : il s'agit du device à l'origine de la notification

  • Action : indique le type d'action à l'origine de la notification, les valeurs possibles sont :

    • 1 : Ajout de l'enregistrement

    • 2 : Mise à jour de l'enregistrement

    • 4 : Suppression de l'enregistrement

  • BeforeValues : contient les valeurs avant modification des champs suivis.

  • AfterValues : contient les valeurs après modification des champs suivis.

Le nombre d'élément maximum de ce tableau pour un appel de script est défini par le paramètre 'Packet size' dans l'écran de configuration des notifications.

Anti-loop

Par défaut, un script appelé via datatracking n'ira pas déclencher un nouvel appel lors de la modification d'une table. Ceci pourrait créer des boucles infinies.
Cependant, il existe une fonction SwingScript nommée DATA_TRACKING permettant d'indiquer explicitement de déclencher le datatracking sur une ligne.
A utiliser en connaissance de cause. Il faut être certain de maitriser le cycle d’exécution.

...