Aller directement à la fin des métadonnées
Aller au début des métadonnées

Vous regardez une version antérieure (v. /wiki/spaces/UDW56/pages/10558341870/G+rer+et+comprendre+les+scripts) de cette page.

afficher les différences afficher l'historique de la page

« Afficher la version précédente Vous regardez la version actuelle de cette page. (v. 5) afficher la version suivante »

Présentation

Comprendre comment s’articulent les scripts, leur rôle et toutes les informations techniques telles que le bodyData ou l’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

Fonctionnement

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 étape

  • 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.

Les types de script

Il existe actuellement un schéma logique utilisé par le standard pour traiter les data :

  • 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 appelé bodyData détaillé plus bas.

      • 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 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

Les domaines d’application

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

Anti-loop

  • Aucune étiquette