1 Introduction
2 Déclaration webhooks
- 2.1 Webhook
- 2.2 Process
3 Présentation
4 Créer webhook sur une table standard
5 Créer webhook sur une table standard si scripts déjà existants
6 Créer webhook sur une table spécifique
7 Compléter webhook existant pour mise à jour

Introduction

Ce document décrit la création de webhooks spécifiques.

Avant de créer vos propres webhooks, il est conseillé de lire l’ensemble des documents présents dans le chapitre WebHooks.

Et tout particulièrement de bien comprendre le document sur les Surcharges.

Déclaration webhooks

Dans Divalto weavy Studio : Outils > Gérer les webhooks

Webhook

Le webhook ne nécessite aucune authentification mais doit être lié à un compte API public.

Son URL d’appel sera de la forme : https://api.weavy.divalto.com/v1/entrypoints/{companyCode}/webhook/?c={codeEntryPoint}

Code utilisateur : Code du webhook

Lors de la création d’un webhook spécifique, il est conseillé d’utiliser un code utilisateur bien identifiable.

Les webhooks n'étant pas surchargeables, ceci permettra d’identifier correctement les webhooks standards des webhooks spécifiques.

Utilisez le préfixe “SPE”.

Le code du webhook commencera donc par SPEWHK_….

Libellé : Libellé du webhook

Description : Description

Code script : Code du script qui sera appelé lors de l’exécution du webhook

Compte API : Compte utilisateur de type API publique qui sera utilisé pour l’authentification

URL : Url qui permettra d’appeler le webhook

Process

C’est l'équivalent du webhook, mais le process nécessite une authentification préalable avec un compte utilisateur valide.

Les scripts utilisés seront exactement pareils, il n’y a aucune différence entre un webohook et un process.

Son URL d’appel sera de la forme : https://api.weavy.divalto.com/v1/entrypoints/{companyCode}/process/?c={userCode}

Code utilisateur : Code du process

Lors de la création d’un process spécifique, il est conseillé d’utiliser un code utilisateur bien identifiable.

Les process n'étant pas surchargeables, ceci permettra d’identifier correctement les process standards des process spécifiques.

Utilisez le préfixe “SPE”.

Le code du process commencera donc par SPEPRO_….

Libellé : Libellé du process

Description : Description

Code script : Code du script qui sera appelé lors de l’exécution du process. C’est exactement le même script que pour un webhook.

Compte API : On utilisera automatiquement le compte utilisé pour l’authentification

URL : Url qui permettra d’appeler le process

Présentation

Lors de la création d’un nouveau webhook, cinq scripts sont obligatoires.

Pour le détail des scripts, vous pourrez vous appuyer sur ce qui a été effectué dans les scripts des webhooks standards.

Des exemple précis mais non exhaustifs seront données dans la suite de ce document.

Script d’entrée : Ce script est appelé dans la déclaration du webhook.

Le code du script devra être de la forme : {Prefix}_Webhook{EntityName}

Script de définition : C'est dans ce script que l'on déclare la définition de l'entité. C'est une "carte d'identité" qui va définir les champs, les filtres, etc...

Le code du script devra être de la forme : {Prefix}_WebhookDefinition_{entityname}.

Script de surcharge de définition : Il est obligatoire même pour un webhook spécifique.

Le code du script devra être de la forme : {Prefix}_WebhookDefinitionOverload_{entityname}.

Vous pouvez vous contenter de la trame de base, vu que votre définition sera déjà dans le script de définition.

Script de règles : C’est dans ce script que l’on applique les règles métiers. Ces règles s’appliqueront lors de la méthode PUT (ajout/mise à jour).

Le code du script devra être de la forme : {Prefix}_WebhookRules_{entityname}.

Script de surcharge de règles : Il est obligatoire même pour un webhook spécifique.

Le code du script devra être de la forme : {Prefix}_WebhookRulesOverload_{entityname}.

Vous pouvez vous contenter de la trame de base, vu que vos règles seront déjà dans le script de règles.

Créer webhook sur une table standard

Création d’un nouveau webhook sur la table standard “sw_data_supplier” qui contient des champs spécifiques en surcharge FINAL.

On peut voir également que le champ “final_suppliercategory_ID” s’appuie sur une table spécifique “sw_data_final_suppliercategory”.

Dictionnaire :

Script d’entrée : FINAL_WebhookSupplier

tableName   = "supplier"
entityName  = "supplier"

INCLUDE( "FuncWebhook_BuildEndpoint" )

Script de définition : FINAL_WebhookDefinition_supplier

// FINAL_WebhookDefinition_supplier
// Webhook definition
tableName             = "supplier"
specificOverload      = CALL_SCRIPT( "FINAL_WebhookDefinitionOverload_<varscript>tableName</varscript>" )
tableSchema           = DB_GET_TABLEINFO( "sw_data_<varscript>tableName</varscript>" )
tableSchemaDocument   = DOCUMENT_CREATE_FROM_JSON( tableSchema )
languageCode          = VARGET_SHELL( "languageCode", "WebhookDefinition" )
authorizedTables      = TRANSLATE( "[{'tableName':'<varscript>tableName</varscript>'}]" )

JSONFieldsDefinition = TRANSLATE( "
  { 
    'languageCode': '<varscript>languageCode</varscript>',
    'strictFilterMode': 1,
    'relatedTablesCount': 0,
    'relatedTables': [ ],
    'authorizedTables': <varscript>authorizedTables</varscript>,
    'simpleFieldsList': 'CodeSupplier,label',
    'extendedFieldsListToExclude': '',
    'defaultFilters': [
     
    ],
    'strictFilters': [
      
    ],
    'strictOrderBy': [
    
    ],
    'outOfMainTableFields': [
      
    ],
    'standardOverload': {
      
    },
    'specificOverload':
    <varscript>specificOverload</varscript>,
    'simpleFields': [],
    'extendedFields': [],
    'strictFilterFields': [],
    'defaultFilterFields': [],
    'strictOrderByFields': []
  }
" )

INCLUDE( "FuncWebhook_BuildDefinition" )

Script de surcharge de définition : FINAL_WebhookDefinitionOverload_supplier

Vu qu’il s’agit d’un webhook entièrement spécifique, on aurait pu laisser uniquement le squelette de “FINAL_WebhookDefinitionOverload_supplier“ et mettre le code nécessaire au fonctionnement directement dans “FINAL_WebhookDefinition_supplier“.

// FINAL_WebhookDefinitionOverload_supplier

languageCode     = VARGET_SHELL( "languageCode", "WebhookDefinition" )

specificOverload = TRANSLATE( "
  {
    'simpleFieldsList': 'CodeSupplier,label,city',
    'extendedFieldsListToExclude': '',
    'relatedTablesCount': 2,
    'relatedTables': [ 'final_customer_ID', 'final_suppliercategory_ID' ],
    'authorizedTables': [ {'tableName':'supplier'}, {'tableName':'final_supplieraddress'}, {'tableName':'product'} ],
    'cascadeDeleteTables': [ {'tableName':'final_supplieraddress'} ],
    'fieldsList': {
      'final_customer_ID': {
        'targetTableName': 'sw_data_customer',
        'targetFieldName': 'name'
      },
      'final_suppliercategory_ID': {
        'canGetDefinitionList': 1,
        'definitionLabelFieldName': 'final_label'
      }
    },
    strictFilters: [
      
    ],
    'strictOrderBy': [
      
    ],
    'outOfMainTableFields': [
      
    ]
  }
" )

RETURN( "<varscript>specificOverload</varscript>" )

Script de règles : FINAL_WebhookRules_supplier

Il s’agit ici uniquement du squelette nécessaire au bon fonctionnement car nous nous n’avons pas implémenté de règle métier dans notre exemple.

Script de surcharge de règles : FINAL_WebhookRulesOverload_supplier

Compléments :

Pour être tout à fait complet, on peut voir dans notre exemple que l’on veut afficher les données de la table spécifique liée “sw_data_final_suppliercategory” et mettre à jour “sw_data_final_supplieraddress“.

Pour la mise à jour de “sw_data_final_supplieraddress“, une description est donnée dans le chapitre sur la création d’un webhook sur une table spécifique.

Pour l’affiche des données liées dans “sw_data_final_suppliercategory“, il faut donc au minimum également ajouter les deux scripts de définition de cette table.

Script de définition : FINAL_WebhookDefinition_final_suppliercategory

Script de surcharge de définition : FINAL_WebhookDefinitionOverload_final_suppliercategory :

Créer webhook sur une table standard si scripts déjà existants

Création d’un nouveau webhook sur la table standard “sw_data_symptom”.

Script d’entrée : FINAL_WebhookSymptom

Script de définition : WebhookDefinition_symptom

Le script de définition “WebhookDefinition_symptom“ existe déjà en standard. Donc on y touche pas.

Script de surcharge de définition : WebhookDefinitionOverload_symptom

Le script de surcharge de définition “WebhookDefinitionOverload_symptom“ est déjà prévu en standard. Il suffit donc de surcharger ce script si besoin.

Script de règles : FINAL_WebhookRules_symptom

Par contre le script des règles métiers n’existe pas en standard. Il suffit donc de le créer en spécifique.

Script de surcharge de règles : FINAL_WebhookRulesOverload_symptom

Evidemment ce script n’existait pas en standard. Il suffit donc de le créer en spécifique.

Créer webhook sur une table spécifique

Création d’un nouveau webhook sur la table spécifique “sw_data_final_supplieraddress”.

Dictionnaire :

Script d’entrée : FINAL_WebhookSupplierAddress

Script de définition : FINAL_WebhookDefinition_final_supplieraddress

Bien noter la subtilité sur le nom de l’entité dans le code du script : final_supplieraddress

Script de surcharge de définition : FINAL_WebhookDefinitionOverload_final_supplieraddress

Script de règles : FINAL_WebhookRules_final_supplieraddress

Script de surcharge de règles : FINAL_WebhookRulesOverload_final_supplieraddress

Compléter webhook existant pour mise à jour

Sur le webhook “Intervention” pour la méthode PUT, je veux également mettre à jour des données concernant les opérations.

Ceci va concerner les tables “sw_data_interventionoperationrange“ et “sw_data_interventionoperationtype“.

Script de définition : WebhookDefinition_intervention

Le script de définition “WebhookDefinition_intervention“ existe déjà en standard. Donc on y touche pas.

Script de surcharge de définition : WebhookDefinitionOverload_intervention

Le script de surcharge de définition “WebhookDefinitionOverload_intervention“ est déjà prévu en standard. Il suffit donc de surcharger ce script.

On reprend la propriété “authorizedTables“ du standard, complétée avec les 2 nouvelles tables.

Complément :

Il faut au minimum créer les scripts de définition pour “interventionoperationrange“ et “interventionoperationtype“ vu qu’ils n’existent pas en standard.

Script de définition : FINAL_WebhookDefinition_interventionoperationrange

Script de surcharge de définition : FINAL_WebhookDefinitionOverload_interventionoperationrange

Script de définition : FINAL_WebhookDefinition_interventionoperationtype

Script de surcharge de définition : FINAL_WebhookDefinitionOverload_interventionoperationtype

06 CRM 6.2

WebHooks Spécifiques