Passer au contenu principal
Adaptive Planning
Dernière mise à jour : 2024-05-03
Concept : API au format JSON

Concept : API au format JSON

Seul un nombre limité d'API REST Adaptive Planning peut utiliser le format JSON pour soumettre des données issues d'Adaptive Planning et les obtenir. D'autres API utiliseront le format JSON dans les futures versions.

Demandes JSON

Chaque demande JSON nécessite un :
  • Méthode ou Action HTTP.
    Exemple :
    GET
    ,
    PUT
    , ou
    PATCH
  • Point de terminaison de l'URL.
    Si votre instance utilise une authentification régionale et non basée sur les États-Unis, les URL d'autorisation et les points de terminaison de l'API varient en fonction de votre région. Voir Référence : URL d'authentification régionale.
    Exemple :
    HTTPS://api.adaptiveplanning.com/api/rest/modeling/v1/globosales/sheet/availability
  • En-tête de l'autorisation
    Exemple :
    --header 'Authorization: Basic c5RldmVjQLdsb2JvLmNabTpjaGFuZ2VtZQ=='

Méthodes ou Actions HTTP

Les méthodes ou partages disponibles varient selon le service et la ressource :
Méthode
Description
GET
Récupère un ensemble de données ou un objet unique.
POST
Crée une seule instance de données avec les données indiquées.
PATCH
Met à jour partiellement les données existantes.
PUT
Met à jour les données existantes et les remplace par les données indiquées dans le corps de la demande.
DELETE
Supprime une instance de données existante.

Point de terminaison de l'URL

Si votre instance utilise une authentification régionale et non basée sur les États-Unis, les URL d'autorisation et les points de terminaison de l'API varient en fonction de votre région. Voir Référence : URL d'authentification régionale.
https://api.adaptiveplanning.com/rest/<service name>/<version>/<tenant>/<resource path>
  • service name
    Un nom de composant, basé sur une fonctionnalité comme
    modeling
    , ou
    security
    .
  • version
    Version du service. Version actuelle pour tous les services :
    v1
    .
  • tenant
    Environnement client de ce service, indiquant l'instance Adaptive Planning. Utiliser
    default
    pour l'instance par défaut de l'utilisateur dans l'autorisation.
  • resource path
    Le chemin d'accès à la ressource, en utilisant des noms tels que
    sheet
    et
    availability
    . Le chemin prend également en charge les paramètres de requête, comme :
    • sheetName
      pour indiquer le nom d'une feuille dans Adaptive Planning.
    • columnName
      pour indiquer le nom d'une colonne dans une feuille Adaptive Planning.
    • limit
      pour spécifier le nombre maximum d'entrées de données d'objets incluses dans une seule réponse.
    • offset
      pour spécifier le décalage du premier objet d'un recouvrement à inclure dans la réponse.
Exemple :
https://api.adaptiveplanning.com/api/rest/modeling/v1/globosales/sheet/availability?sheetName=Expense Cube&columnName=Level&columnType=Level

Exemple : POST Request avec le corps JSON

curl --location --request POST 'https://api.adaptiveplanning.com/api/rest/modeling/v1/default/sheet/availability?sheetName=Sales Cube&columnName=account&columnType=Account' \ --header 'Authorization: Basic c5RldmVjQLdsb2JvLmNabTpjaGFuZ2VtZQ==' \ --header 'Content-Type: application/json' \ --data-raw '[ { "name": "Discount Percent", "code": "SalesCube.DiscountPercent", "accountGroup": false, "available": true } ]'

Collections

Les ressources représentent généralement un ensemble d'objets de gestion,
Adaptive Planning
renvoyée sous la forme d'une collection JSON. Le recouvrement peut être utilisé dans les structures de développement pour créer des listes d'objets de gestion. Un objet spécifique de la collection est accessible via un identifiant.
L'ordre de tri des objets dans une collection est défini par
Adaptive Planning
, et n'est pas configurable.
La pagination des recouvrements est contrôlée par deux paramètres de requête facultatifs : limite et décalage.
Paramètre de requête
Description
limit
Limite des saisies de données d'objet incluses dans une réponse unique. La valeur par défaut est 20 et le maximum est 100.
offset
Le décalage du premier objet d'une collection à inclure dans la réponse. La valeur par défaut est 0.

Demande d'exemple avec limite et contrepartie

L'exemple récupère un ensemble d'instances d'utilisateur avec le
instanceCode
de
GLOBO
.
@GET @PATH("/users/instances?instanceCode=GLOBO&limit=20&offset=0") @Produces(MediaType.APPLICATION_JSON) public List<User> getUsers(@PathParam("instanceCode") String instanceCode,@PathParam("limit")int limit,@PathParam("offset")int offset)

Exemple de réponse avec limite et décalage

{ "total": 25, "link": { "next": "https://api.adaptiveplanning.com/api/rest/security/v1/default/users/instances?instanceCode=GLOBO&offset=4&limit=2", "previous": "https://api.adaptiveplanning.com/api/rest/security/v1/default/users/instances?instanceCode=GLOBO&offset=0&limit=2" }, "users": [ { "userId": 14, "userGuid": "474C4F424F000000000000000100000E", "userName": "asiaboss@globo.com", "instances": [ { "code": "GLOBO", "default": true } ] }, { "userId": 21, "userGuid": "474C4F424F0000000000000001000015", "userName": "Bob@globo.com", "instances": [ { "code": "GLOBOSALES" }, { "code": "GLOBOSUB" }, { "code": "GLOBO", "default": true } ] } ] } Note: -Default offset = 0 and limit = 500

Types d'identifiant, authentification et autorisation

Toutes les demandes API sont des demandes d'action unique et sans état. L'utilisateur doit s'authentifier à chaque invocation distincte, de sorte qu'il n'existe aucune possibilité qu'un escroc tente de capturer une session de service web existante.
L'authentification d'un utilisateur dans une demande API ne crée pas de session persistante pour cet utilisateur. Chaque appel de service web distinct doit authentifier son utilisateur séparément.
Le
Adaptive Planning
Les API au format JSON prennent en charge les méthodes d'authentification de base et d'authentification par jeton (TBA).
Adaptive Planning
prend en charge les API REST réels au format JSON avec l'autorisation indiquée dans l'en-tête de la demande et non le corps de la demande, comme les API XML. Voir Formats de message de demande et de réponse et Créer des demandes API Adaptive Planning avec Workday Credentials pour des exemples d'API XML.

Authentification de base

L'authentification de base utilise le nom d'utilisateur et le mot de passe codés en base64 dans l'en-tête d'authentification.
Exemple :
'Authorization': 'Basic <insert base64 encoded string>'
Exemple :
xyz@demo.com:password
se code en
eHl6QGRlbW8uY29tOnBhc3N3b3Jk

Authentification par jeton (TBA)

Si vous synchronisez des utilisateurs entre Workday et Adaptive Planning, vous devez utiliser des méthodes d'authentification par jeton. Pour obtenir votre jeton, suivez les étapes de la section Rendre les demandes API Adaptive Planning avec Workday Credentials. Une fois votre jeton obtenu, transmettez-le dans l'en-tête.
Exemple : 'Autorisation' : ' Porteur < jeton d'insertion ici>'
Exemple : '
Authorization: Bearer eyJjdHkiOiJ0ZXh0L3BsYWluIiwiYWxnIjoiSFMyNTYifQ.eyJsb2dpbl9pZCI6InN0ZXZlY0BheWdsb2JvLmNvbSIsIm5iZiI6MTU4NjEzMDA2NywibXVsdGlfdXNlIjoiMCIsImlzX2F1dGgiOiIxIiwiZXhwIjoxODg2MTMwMTg3LCJpYXQiOjE2MDM5NDYwMjEsImp0aSI6IjM0YzFkZDY2LTY2MTMtNDk0Ny05MjFhLTliZDQ2ZDVmZDkwNyJ9.FZnLHGQ3dNfpzvW-A9ILi53z6YLGNNI45Mlc-4NT3As'