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/PAI/pages/10516504869/R+f+rence+appels+API+REST) de cette page.

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

Vous regardez la version actuelle de cette page. (v. 1) afficher la version suivante »

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

NomDétailInformations
InstallationInstallation et activation des services web RESTLe service web REST RecordSql doit être opérationnel pour exposer les service web sur le réseau ou internet
DroitsDroits 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étrageParamétrage des dictionnaires de RecordSqlPar 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
URLDétermination de l'URL de l'APISelon 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

NomDétailInformations
URL et compteObtenir 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

AuthentificationAppel API AuthentificationAppel de l'API REST Auth pour authentification. Cet appel retourne un jeton "access_token"
Lecture de donnéesAppel API LectureAppel 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

NomDétailInformations
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
DroitsDroits 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

NomDétailInformations
URL et compteObtenir 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 AuthentificationAppel de l'API REST Auth pour authentification. Cet appel retourne un jeton "access_token"
Demande de service métierAppel 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.

  • Aucune étiquette