Référence appels API REST

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

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

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

Nom

Détail

Informations

Installation

Installation et activation des services web SOAP

et/ou

Installation et activation des services web REST

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

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

  • Chaque service métier impose le format et le contenu de la demande.

  • La majorité des services métiers attendent une entrée au format texte XML ou HMP.

  • Un appel un mode REST est toujours possible, même si le métier attend un format XML



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.