Voici une synthèse de l'appel API REST Divalto pour des appels extérieurs (hors Diva).
API REST RecordSql pour lire des données
Une API est dédiée à la lecture de données ERP.
Elle utilise les RecordSql, qui est la couche d'accès aux données de l'ERP. Un RecordSql (par exemple Client) est groupé par dictionnaire de RecordSql (par exemple GTRSTIERS.DHOQ) et comporte tous les éléments constitutifs d'une requête SQL (donc la table du FROM, les champs retournés, les jointures, les conditions et les tris).
Pour exploiter l'API REST RecordSql, il y a plusieurs étapes à suivre :
ACTEUR : Administrateur Infrastructure ou Administrateur ERP
Nom | Détail | Informations |
---|---|---|
Installation | Installation et activation des services web REST | Le service web REST RecordSql doit être opérationnel pour exposer les service web sur le réseau ou internet |
Droits | Droits d'accès ERP et Windows | Un utilisateur Windows doit être créé pour l'accès par service web API Un utilisateur Divalto doit être créé pour l'accès par service web API |
Paramétrage | Paramétrage des dictionnaires de RecordSql | Par défaut, aucun dictionnaire de RecordSql n'est autorisé en lecture par l'API. Il faut donc lister les dictionnaires de RecordSql qui sont autorisés |
URL | Détermination de l'URL de l'API | Selon l'infrastructure et le mode de déploiement, il s'agit de déterminer l'URL utilisées par l'appelant |
Cloud
Avec Divalto Cloud, ces étapes sont réalisées par défaut. Contactez le service cloud pour obtenir l'URL et les comptes à utiliser
ACTEUR : Appelant de l'API
Nom | Détail | Informations |
---|---|---|
URL et compte | Obtenir l'URL et le compte | Obtenir la ou les URL qui permettent l'appel à l'API, ainsi que le ou les comptes a utiliser pour l'authentification. Un compte comporte un utilisateur et un mot de passe, et en option un domaine et un environnement |
Authentification | Appel API Authentification | Appel de l'API REST Auth pour authentification. Cet appel retourne un jeton "access_token" |
Lecture de données | Appel API Lecture | Appel de l'API REST RecordSql leture de données. Cert appel utiliser le jeton "access_token" |
Voici la synthèse d'un appel simple API REST RecordSql. Retrouvez tous les détails dans les pages dédiées.
L'appel d'authentification est un appel avec header Content-Type : application/json et le corps suivant:
{
"domain":"{{DOMAIN}}",
"user": "{{LOGIN}}",
"password": "{{PASSWORD}}",
"env": "{{ENV}}"
}
avec pour réponse en réussite un error à 0 et un access_token
{
"error": 0,
"access_token": "xyz",
"txterr": "",
"infos": ""
}
L'appel de lecture de données est un appel avec header Content-Type : application/json et le corps suivant:
{
"dhoq" : "{{NOM DU DICTIONNAIRE DE RECORDSQL}}",
"recordsql" : "{{NOM DU RECORDSQL}}",
"access_token" : "xyz",
"parameters" : " ",
"fields" : "NOM DES CHAMPS A RECUPERER, VIDE ENVOIE TOUT",
"where" : "NOM CONDITION WHERE PAR EXEMPLE Equal_Tiers ",
"where_parameters" : "PARAMETRE CONDITION WHERE PAR EXEMPLE tiers=C0000001",
"offset" : 0,
"count" : 10000,
"orderby" : "NOM DE TRI",
"having" : " ",
"having_parameters" : " ",
"infos" : " "
}
avec pour réponse en réussite un error à 0 et un tableau de records
{
"error": 0,
"txterr": "",
"tablename": "NOM DE LA TABLE DU FROM",
"nbrecord": 1,
"records": [
{
"record": {
"TABLE_ID": "2",
"DOS": "998",
"CHAMP1": "valeur",
}
}
],
"infos": ""
}
Service web REST pour des fonctions métier
Deux services web exposent de nombreux services métiers de l'ERP concernant la gestion commerciale, la CRM, la comptabilité,...
Pour exploiter les services web métier, il y a plusieurs étapes à suivre :
ACTEUR : Administrateur Infrastructure ou Administrateur ERP
Nom | Détail | Informations |
---|---|---|
Installation | Installation et activation des services web SOAP et/ou | Le service web SOAP et/ou REST doit être opérationnel pour exposer les service web sur le réseau ou internet |
Droits | Droits d'accès ERP et Windows | Un utilisateur Windows doit être créé pour l'accès par service web Un utilisateur Divalto doit être créé pour l'accès par service web |
URL | Détermination de l'URL SOAP et/ou Détermination de l'URL REST | Selon l'infrastructure et le mode de déploiement, il s'agit de déterminer les URL utilisées par l'appelant |
Cloud
Avec Divalto Cloud, ces étapes sont réalisées par défaut. Contactez le service cloud pour obtenir les URL et les comptes à utiliser
ACTEUR : Appelant du service web
Nom | Détail | Informations |
---|---|---|
URL et compte | Obtenir l'URL (SOAP ou REST) et le compte | Obtenir la ou les URL qui permettent l'appel au service web, ainsi que le ou les comptes a utiliser pour l'authentification. Un compte REST comporte un utilisateur et un mot de passe, et en option un domaine et un environnement |
Authentification (mode REST uniquement) | Appel API Authentification | Appel de l'API REST Auth pour authentification. Cet appel retourne un jeton "access_token" |
Demande de service métier | Appel en mode SOAP ou REST |
|
Voici la synthèse d'un appel simple métier. Retrouvez tous les détails dans les pages dédiées.
L'appel d'authentification est un appel avec header Content-Type : application/json et le corps suivant:
{
"domain":"{{DOMAIN}}",
"user": "{{LOGIN}}",
"password": "{{PASSWORD}}",
"env": "{{ENV}}"
}
avec pour réponse en réussite un error à 0 et un access_token
{
"error": 0,
"access_token": "xyz",
"txterr": "",
"infos": ""
}
L'appel du service métier d'interrogation de stock est un appel avec header Content-Type : application/json et le corps suivant:
{
"action":"SYNCHRO_INFINITY_AGILEO",
"param":"<dem><action dos=\"998\" nom=\"INTERROGER_STOCK\" ><ref>ALB0001</ref><depot>*</depot></action></dem>",
"access_token":"xyz"
}
avec pour réponse en réussite un error à 0 et un result
{
"error": 0,
"result": "<?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>\r\n<rep version=\"1\" >\r\n<action dos=\"998\" nom=\"interroger_stock\" />\r\n Ref=\"ALB0001\" Depot=\"*\" Nst=\"N\" QteDispo=\"366,000\" QteRes=\"38,000\" QteStock=\"404,000\" >\r\n</rep>\r\n</action>\r\n",
"txterr": "",
"infos": ""
}
On remarque ici que l'appel illustré en mode REST avec un format de transport JSON intègre une demande (balise"action" à l'intérieur de la zone "param") de service métier en format HMP ou XML.
La réponse se fait également en mode REST/JSON mais avec une réponse métier au format XML.