Bases d’API

L’objectif de l’API Adobe Workfront est de simplifier la création d’intégrations avec Workfront en introduisant une architecture REST qui fonctionne sur HTTP. Ce document suppose que vous connaissez les réponses REST et JSON et décrit l’approche adoptée par l’API Workfront.

Une bonne connaissance du schéma Workfront vous aidera à comprendre les relations entre les bases de données qui peuvent être utilisées pour extraire des données de Workfront à des fins d’intégration.

Politiques et directives

Pour garantir des performances système Workfront à la demande cohérentes, l’API Workfront limite les threads API simultanés. Cette barrière de sécurité empêche les problèmes système causés par les appels d’API abusifs. L’environnement Sandbox dispose de la même limite de thread d’API simultanée, ce qui permet aux clients et aux partenaires de tester précisément les appels d’API avant de publier du code en production.

Pour les environnements de production, de prévisualisation et de test, les demandes des utilisateurs et utilisatrices finaux ont une longueur maximale d’URI de 8 892 octets parce qu’elles sont acheminées par le CDN de Workfront (Akamai). Cette limite ne s’applique qu’aux URI acheminés par le CDN.

Avertissement

Toute utilisation de l’API doit être testée dans l’environnement bêta de Workfront avant d’être exécutée dans l’environnement de production. Si un client ou une cliente utilise l’API pour un processus que Workfront considère raisonnablement comme une charge pour le logiciel à la demande (c’est-à-dire que le processus a un effet négatif important sur la performance du logiciel pour d’autres clientes et clients), Workfront se réserve le droit de demander au client ou à la cliente d’interrompre ce processus. Si le client ou la cliente ne se conforme pas et que le problème persiste, Workfront se réserve le droit de mettre fin au processus.

URL de l’API Workfront

Pour plus d’informations sur l’URL que vous utiliserez pour appeler l’API Workfront, voir Format de domaine pour les appels API Adobe Workfront.

Concepts de base de REST

Cette section fournit une introduction de haut niveau sur la façon d’interagir avec l’API REST de Workfront pour les principes REST suivants :

URI d’objet

Chaque objet du système se voit attribuer un URI unique composé du type d’objet et de l’ID. Les exemples suivants montrent des URI décrivant trois objets uniques :

/attask/api/v15.0/project/4c78821c0000d6fa8d5e52f07a1d54d0
/attask/api/v15.0/task/4c78821c0000d6fa8d5e52f07a1d54d1
/attask/api/v15.0/issue/4c78821c0000d6fa8d5e52f07a1d54d2

Le type d’objet n’est pas sensible à la casse et peut être soit le code ObjCode abrégé (tel que proj), soit le nom alternatif de l’objet (projet).

Pour obtenir la liste des objets, des ObjCodes et des champs d’objet valides, voir  Explorateur API.

Opérations

Les objets sont manipulés en envoyant une requête HTTP à leur URI unique. L’opération à effectuer est spécifiée par la méthode HTTP.

Les méthodes HTTP standard correspondent aux opérations suivantes :

Afin de contourner les déficiences du client ou les limites de longueur du protocole, le paramètre de méthode peut être utilisé pour modifier le comportement du protocole HTTP. Par exemple, une opération GET peut être mise en œuvre en publiant l’URI suivant :

GET /attask/api/v15.0/project?id=4c78...54d0&method=get
GET /attask/api/v15.0/project/4c78...54d0?method=get

Réponse

Chaque requête reçoit une réponse au format JSON. La réponse comporte soit un attribut data si la demande a abouti, soit un attribut error en cas de problème. Par exemple, la requête

GET /attask/api/v15.0/proj/4c7c08b20000002de5ca1ebc19edf2d5

renvoie une réponse JSON similaire à la suivante :

{
    "data": [
        {
            "percentComplete": 0,
            "status": "CUR",
            "priority": 2,
            "name": "Brand New Project",
            "ID": "4c7c08b20000002de5ca1ebc19edf2d5" 
        } 
    ] 
}

Une sécurité particulière a été ajoutée pour les requêtes PUT, POST et DELETE. Toute requête d’écriture ou de suppression dans la base de données ne peut être exécutée que si sessionID=abc123 est inclus dans l’URI. Les exemples suivants montrent ce que cela donnerait pour une requête DELETE :

GET /attask/api/v15.0/project?id=4c78...54d0&method=delete&sessionID=abc123
GET /attask/api/v15.0/project/4c78...54d0?method=delete&sessionID=abc123

Authentification

L’API authentifie chaque demande pour s’assurer que le client a le droit d’afficher ou de modifier l’objet concerné par la requête.

L’authentification s’effectue en transmettant un ID de session qui peut être fourni en utilisant l’une des méthodes suivantes :

Authentification de l’en-tête de la demande

La méthode d’authentification préférée consiste à transmettre un en-tête de requête nommé SessionID contenant le jeton de session. Cela présente l’avantage d’être à l’abri des attaques Cross-site Request Forgery (CSRF) et de ne pas interférer avec l’URI à des fins de mise en cache.

Voici un exemple d’en-tête de requête :

GET /attask/api/v15.0/project/search
SessionID: abc1234

Authentification avec un paramètre de requête

Vous pouvez vous authentifier en passant un paramètre de requête nommé sessionID, comme le montre l’exemple suivant :

GET /attask/api/v15.0/project/4c78821c0000d6fa8d5e52f07a1d54d0?sessionID=abc1234

Authentification basée sur les cookies

L’API utilise la même authentification basée sur les cookies que celle utilisée par l’interface web du système. Ainsi, si un client ou une cliente se connecte à Workfront à l’aide de l’interface web, tous les appels AJAX effectués à partir du même navigateur utilisent la même authentification.

Connexion

À l’aide d’un nom d’utilisateur ou d’utilisatrice et d’un mot de passe valides, vous pouvez utiliser la requête suivante pour obtenir un ID de session :

POST /attask/api/v15.0/login?username=admin&password=user

Cela permet de créer un cookie pour authentifier les futures requêtes et de renvoyer une réponse JSON contenant l’ID de session nouvellement créé, l’ID de la personne connectée et d’autres attributs de session.

Génération d’une clé API

Vous pouvez générer une clé API lorsque vous vous connectez au système en tant qu’utilisateur ou utilisatrice, comme le montre l’exemple suivant :

PUT /attask/api/v15.0/user?action=generateApiKey&username= username&password=password&method=put

Récupération d’une clé API précédemment générée

Vous pouvez également récupérer une clé API qui a été précédemment générée pour un utilisateur ou une utilisatrice en particulier en exécutant getApiKey :

PUT /attask/api/v15.0/user?action=getApiKey&username=user@email.com&password=userspassword&method=put

Vous pouvez ensuite utiliser ce résultat pour authentifier tout appel API en ajoutant « apiKey » comme paramètre de requête avec cette valeur à la place d’un sessionID ou d’un nom d’utilisateur ou d’utilisatrice et d’un mot de passe. Cela est bénéfique du point de vue de la sécurité.

La requête suivante est un exemple de récupération de données d’un projet à l’aide de la clé API :

GET /attask/api/v15.0/project/abc123xxxxx?apiKey=123abcxxxxxxxxx

Invalider une clé API

Si la valeur apiKey a été compromise, vous pouvez exécuter « clearApiKey », ce qui invalide la clé API actuelle, comme le montre l’exemple suivant :

GET /attask/api/v15.0/user?action=clearApiKey&username=user@email.com&password=userspassword&method=put

Une fois la clé effacée, vous pouvez relancer getApiKey pour générer une nouvelle clé API.

Déconnexion

Lorsqu’une session est terminée, vous pouvez utiliser la requête suivante pour déconnecter l’utilisateur ou l’utilisatrice, en empêchant tout accès ultérieur avec l’ID de session.

GET /attask/api/v15.0/logout?sessionID=abc1234

L’ID de session à déconnecter peut être spécifié sous la forme d’un cookie, d’un en-tête de requête ou d’un paramètre de requête.

Pour déconnecter un utilisateur ou une utilisatrice :

Vous devez toujours inclure le sessionID fourni après la connexion lorsque vous effectuez des requêtes PUT, POST et DELETE.

Comportement GET

Utilisez la méthode HTTP GET pour récupérer un ou plusieurs objets et pour exécuter des rapports.

Récupération d’objets

Vous pouvez améliorer la recherche d’objets à l’aide de modificateurs et de filtres.

Récupération d’un objet à l’aide de l’ID de l’objet

Si vous connaissez l’identifiant d’un objet, vous pouvez le retrouver en accédant à son URI unique. Par exemple, la requête

GET /attask/api/v15.0/project/4c78821c0000d6fa8d5e52f07a1d54d0

renvoie une réponse similaire à la suivante :

{
    "percentComplete": 0,
    "status": "CUR",
    "priority": 2,
    "name": "Brand New Project",
    "ID": "4c7c08b20000002de5ca1ebc19edf2d5" 
}

Vous pouvez récupérer plusieurs objets dans la même requête en spécifiant le paramètre de requête ID et en donnant une liste des identifiants séparés par des virgules, comme le montre l’exemple suivant :

GET /attask/api/v15.0/project?id=4c78...54d0,4c78...54d1

Notez que la requête /attask/api/v15.0/project?id=… est identique à la requête /attask/api/v15.0/project/....

Récupérer un objet à l’aide de l’URI

Si vous souhaitez récupérer un objet en fonction de critères autres que l’identifiant, vous pouvez rechercher l’URI.

Par exemple, vous pouvez utiliser la requête suivante pour obtenir une liste de tous les projets dans le système :

GET /attask/api/v15.0/project/search

Vous pouvez spécifier des filtres en utilisant les paramètres de la requête sous forme de paires nom-valeur. Par exemple, l’exemple suivant montre une requête qui recherche tous les projets en cours :

GET /attask/api/v15.0/project/search?status=CUR

La requête suivante trouve toutes les tâches qui ne sont pas encore terminées et qui sont affectées à un utilisateur nommé John.

GET /attask/api/v15.0/task/search?percentComplete=100
&percentComplete_Mod=lt &assignedTo:firstName=John

Utiliser les modificateurs de recherche

Le tableau suivant répertorie certains des modificateurs que vous pouvez utiliser avec l’API Workfront.

…status=cls&status_Mod=eq…

…status=cls&status_Mod=ne…

…percentComplete=50&percentComplete_Mod=gte…

…percentComplete=50&percentComplete_Mod=lte…

…description_Mod=isnull…

…description_Mod=notnull…

…name=Workfront&name_Mod=contains…

…entryDate=$$TODAY-7d&entryDate_Range=$$TODAY&entryDate_Mod=between…

Utiliser des instructions OR (OU)

Vous pouvez améliorer une recherche en ajoutant un paramètre comprenant « OR » ainsi qu’un nombre pour indiquer le niveau d’un filtre ou d’une série de filtres.

Une instruction OR renvoie uniquement les enregistrements de l’appel API qui répondent aux critères de filtrage de l’instruction OR. Les filtres ne sont pas nécessairement appliqués à tous les niveaux de l’instruction OR.

Par exemple, si vous souhaitez filtrer les éléments suivants :

alors utilisez l’appel API suivant avec ses multiples instructions OR :

GET /attask/api/v15.0/task/search?name=Planning
&name_Mod=contains
&OR:1:portfolio:name=FixedAssets
&OR:1:portfolio:name_Mod=eq
&OR:1:assignedTo:name=Steve
&OR:1:assignedTo:name_Mod=cicontains
&OR:2:parent:name=Final Task
&OR:2:parent:name_Mod=eq

Utiliser les paramètres du filtre

L’un des inconvénients potentiels de l’utilisation de paramètres URL pour les filtres de recherche est que Workfront analyse certains paramètres avant de vérifier les différentes méthodes d’authentification (par exemple, nom d’utilisateur ou d’utilisatrice, mot de passe, apiKey, cookie). Dans ce cas, les paramètres ne sont pas utilisés comme filtres dans l’appel.

Pour éviter ce problème, vous pouvez placer ces valeurs dans des paramètres de filtre avec un formatage JSON. Par exemple, si vous voulez filtrer le nom d’utilisateur ou d’utilisatrice testuser, au lieu d’utiliser

/attask/api/v15.0/user/search?username=testuser@workfront.com

/attask/api/v15.0/user/search?filters={"username":"testuser@workfront.com"}

Utiliser le paramètre de requête Map

Par défaut, les données renvoyées par une recherche sont sous la forme d’un tableau JSON. Selon votre cas d’utilisation, il peut être plus efficace d’obtenir le résultat sous la forme d’un objet JSON indexé par ID. Pour ce faire, il convient d’utiliser le paramètre de requête Map. Par exemple, la requête

/attask/api/v15.0/task/search?map=true

{
    "data": {
        "4c9a97db0000000f13ee4446b9aead9b": {
            "percentComplete": 0,
            "status": "NEW",
            "name": "first task",
            "ID": "4c9a97db0000000f13ee4446b9aead9b",
            "taskNumber": 1 
        },
        "4ca28ba600002024cd49e75bd43cf601": {
            "percentComplete": 0,
            "status": "INP:A",
            "name": "second task",
            "ID": "4ca28ba600002024cd49e75bd43cf601",
            "taskNumber": 2 
        } 
    } 
}

Utiliser le paramètre de requête Fields

Par défaut, la récupération d‘un objet ne renvoie que le sous-ensemble de champs le plus couramment utilisé.

Vous pouvez utiliser le paramètre de requête Fields pour spécifier une liste de champs spécifiques séparés par des virgules. Par exemple, la requête

/attask/api/v15.0/task/search?fields=plannedStartDate,priority

{
    "priority": 2,
    "name": "first task",
    "ID": "4c7c08fa0000002ff924e298ee148df4",
    "plannedStartDate": "2010-08-30T09:00:00:000-0600" 
}

Pour obtenir une liste des références de champs possibles, consultez l’Explorateur d’API.

Rechercher des objets imbriqués

Vous pouvez rechercher des objets imbriqués. Par défaut, les objets imbriqués sont renvoyés avec seulement le nom et l’ID. Par exemple, pour obtenir tous les problèmes avec leurs personnes propriétaires, utilisez la requête suivante :

/attask/api/v15.0/issue/search?fields=owner

/attask/api/v15.0/issue/search?fields=owner:title,owner:phoneNumber

{
    "name": "an important issue",
    "ID": "4c78285f00000908ea8cfd66e084939f",
    "owner": {
        "title": "Operations Specialist",
        "phoneNumber": "555-1234",
        "name": "Admin User",
        "ID": "4c76ed7a0000054c172b2c2d9f7f81c3" 
    } 
}

Récupérer des collections imbriquées

Vous pouvez récupérer des collections imbriquées d’objets. Par exemple, pour obtenir un projet avec toutes ses tâches, utilisez la requête suivante :

/attask/api/v15.0/project/search?fields=tasks

/attask/api/v15.0/task/search?fields=assignments

Rechercher plusieurs champs imbriqués

Par défaut, seuls le nom et l’ID de chaque tâche sont renvoyés, mais des champs imbriqués supplémentaires peuvent être spécifiés à l’aide de la syntaxe des deux points. Pour afficher tous les champs disponibles pour un objet ou une collection connexe, il suffit d’ajouter deux points et un astérisque à la référence de l’objet ou de la collection.

/attask/api/v15.0/task/search?fields=assignments:*

Récupérer des données personnalisées

Vous pouvez récupérer des champs de données personnalisés en utilisant le préfixe « DE: ». Par exemple, pour demander un projet avec un paramètre appelé « CustomText », utilisez la requête suivante :

/attask/api/v15.0/project/search?fields=DE:CustomText

{
    "name": "custom data project",
    "ID": "4c9a954f0000001afad0687d7b1b4e43",
    "DE:CustomText": "task b" 
}

/attask/api/v15.0/project/search?fields=parameterValues

{
    "name": "custom data project",
    "ID": "4c9a954f0000001afad0687d7b1b4e43",
    parameterValues: { 
        "DE:CustomText": "task b", 
        "DE:CustomNumber": 1.4, 
        "DE:CustomCheckBoxes": ["first", "second", "third"] 
    } 
}

Utiliser les requêtes nommées

Certains types d’objets ont des recherches nommées qui sont couramment exécutées et sont disponibles en ajoutant le nom de la requête à la fin de l’URI du type d’objet. Par exemple, la requête suivante permet de récupérer les éléments de travail (tâches et problèmes) qui sont actuellement affectés à l’utilisateur ou l’utilisatrice :

/attask/api/v15.0/work/myWork

Utiliser Count

Vous pouvez utiliser count pour obtenir le nombre de résultats correspondant à votre requête. Cela peut être utile lorsque vous n’avez pas besoin des données dans les résultats. En ne renvoyant que le nombre, le serveur peut traiter la requête plus rapidement et économiser de la bande passante. Par exemple, la requête

GET /attask/api/v15.0/project/count?status=CUR

{
    "count": 3 
}

Demander un rapport

Vous pouvez demander un rapport, où seul l’agrégat de certains champs avec un ou plusieurs regroupements est nécessaire. Comme le montre l’exemple suivant, la syntaxe du rapport est la même que celle de l’API SOAP :

GET /attask/api/v15.0/hour/report?project:name_1_GroupBy=true&hours_AggFunc=sum

{
    "First Project": { 
        "sum_hours": 15 
    }, 
     "Second Project": { 
        "sum_hours": 30 
    } 
}

{
    "First Project": { 
        "sum_hours": 15 
    }, 
    "Second Project": { 
        "sum_hours": 30 
    }, 
    "$$ROLLUP": { 
        "sum_hours": 45 
    } 
}

Trier les résultats d’une requête dans l’API

Vous pouvez trier vos résultats selon n’importe quel champ si vous ajoutez les éléments suivants à votre appel API :

&entryDate_Sort=asc

Par exemple, si vous souhaitez trier les tâches en fonction de leur date de début prévue, supprimez entryDate et remplacez-la par plannedCompletionDate.

Cela fonctionne pour la plupart des champs de Workfront.

Prendre en compte les limites des requêtes

Lorsque vous interrogez un objet, il convient de tenir compte des relations entre les objets connexes et des limites de la recherche.Par exemple, comme le montre le tableau suivant, une requête portant sur les projets ne peut pas renvoyer plus de 2 000 projets. Ces 2 000 projets sont considérés comme des « objets principaux ». Si vous interrogez le champ Tâches sur les projets, le champ Tâches, qui est une collection, devient un objet secondaire par rapport à l’objet principal Projet. Une requête du champ Tâches peut inclure des milliers de tâches sur des projets. Au total, le nombre combiné d’objets (projets et tâches) renvoyés ne peut dépasser le maximum de 50 000.

Pour garantir des performances optimales, le tableau suivant indique les limites imposées aux requêtes de recherche.

Utiliser les réponses paginées using-paginated-responses

Pour passer outre la limite du nombre de résultats par défaut et autoriser 200 résultats, vous pouvez inclure le filtre $$LIMIT=200 dans votre requête, comme dans l’exemple suivant :

GET /attask/api/v15.0/project/search?$$LIMIT=200

Pour garantir la fiabilité et les performances des autres clientes et clients du système, la limite maximale des résultats autorisés par requête est de 2 000 objets. Toute tentative de spécifier une limite plus importante entraîne un message d’erreur IllegalArgumentException.

Par conséquent, nous vous recommandons d’utiliser des réponses paginées pour les jeux de données volumineux. Pour spécifier le premier résultat à renvoyer, ajoutez le filtre $$FIRST. Par exemple, la demande suivante renvoie les résultats 201-250 pour une requête :

GET /attask/api/v15.0/project/search?$$FIRST=200&$$LIMIT=50

Notez que dans l’exemple ci-dessus, $$FIRST=200 renvoie le 201e résultat. $$FIRST=0 renverrait le premier résultat. Il peut être utile de considérer la valeur $$FIRST comme le nombre de résultats que vous souhaitez ignorer avant de renvoyer les résultats.

Pour vous assurer que vos résultats sont correctement paginés, utilisez un paramètre de tri. Cela permet de renvoyer les résultats dans le même ordre, de sorte que la pagination ne répète pas ou n’ignore pas de résultats. Par exemple, pour trier à l’aide de l’ID de l’objet, utilisez ID_Sort=asc.

Créer une règle d’accès

Vous pouvez créer une règle d’accès pour déterminer qui peut accéder à un objet. Voici des exemples de règles d’accès que vous pouvez définir :

Pour configurer un projet de manière à ce qu’il ne soit partagé qu’avec un utilisateur ou une utilisatrice dont l’ID est « abc123 », utilisez la requête suivante :

GET /attask/api/v15.0/project/123abcxxxxxxxxxxxxxxxxxxxxxxxxxx?method=put &updates={ accessRules: [ {accessorID: 'abc123', accessorObjCode: 'USER', coreAction: 'VIEW'} ] }

GET /attask/api/v15.0/project/123abcxxxxxxxxxxxxxxxxxxxxxxxxxx/share?method=put&accessorID=abc123&accessorObjCode=USER&coreAction=VIEW

GET /attask/api/v15.0/project/123abcxxxxxxxxxxxxxxxxxxxxxxxxxx?fields=accessRules:*

Comportement de la requête POST

POST insère un nouvel objet. La syntaxe est identique à celle de PUT, à quelques exceptions près. Comme le nouvel objet n’existe pas encore, il n’a pas d’ID. Pour cette raison, l’URI n’inclut pas l’ID.

Créer un objet

Voici un exemple de requête de création d’un projet :

POST /attask/api/v15.0/project?name=New Project

Copier un objet

Certains objets peuvent être copiés. Pour ces types d’objets, il est possible de créer de nouveaux objets en les publiant avec un paramètre copySourceID. Par exemple, la requête suivante copie le projet donné et lui donne un nouveau nom :

POST /attask/api/v15.0/project?copySourceID=4c7...&name=Copied Project

Charger des documents

Vous pouvez charger des documents par l’intermédiaire de l’URL d’API suivante :

POST /attask/api/v15.0/upload

{
    "handle": "4c7c08fa0000002ff924e298ee148df4"
}

POST /attask/api/v15.0/document?updates={
    name: aFileName,
    handle: abc...123, (handle from the file upload)
    docObjCode: PROJ, (or TASK, OPTASK, etc)
    objID: abc...123,
    currentVersion:{version:v1.0,fileName:aFileName}
}

Comportement de la requête PUT

PUT est utilisée pour mettre à jour un objet existant.

La réponse à une requête PUT est identique à celle d’une GET. Dans les deux cas, le serveur renvoie le nouvel état de l’objet après la mise à jour. Toutes les règles utilisées pour modifier une réponse à une requête GET fonctionnent également avec PUT, comme la spécification de champs supplémentaires à renvoyer, de données personnalisées, etc.

Modifier des objets

Les mises à jour des objets sont toujours effectuées par ID en utilisant l’URI unique de l’objet. Les champs à mettre à jour sont spécifiés en tant que paramètres de la requête. Par exemple, pour modifier le nom d’un projet, vous pouvez envoyer une requête similaire à la suivante :

PUT /attask/api/v15.0/project/4c7...?name=New Project Name 
PUT /attask/api/v15.0/project?id=4c7...&name=New Project Name

Spécifier les modifications JSON

Comme le montre l’exemple suivant, vous pouvez utiliser le paramètre de requête updates pour spécifier les champs à mettre à jour en utilisant la syntaxe JSON :

PUT /attask/api/v15.0/project/4c7...?updates= 
{
     name: "New Project Name", 
     status: "CUR", 
     ... 
}

Effectuer des mises à jour imbriquées

Certains objets possèdent des collections privées qui peuvent être mises à jour. Par exemple, l’exemple suivant montre comment remplacer les affectations existantes pour une tâche donnée :

PUT /attask/api/v15.0/task/4c7...?updates= 
{
    assignments: [ 
        { 
            assignedToID: "2222...54d0, 
            assignmentPercent: 50.0 
        },{ 
            roleID: "1111...54d0"
        } 
    ] 
}

L’exemple suivant fait d’un projet une file d’attente publique pour le centre d’assistance. Notez que les propriétés existantes de la file d’attente sont remplacées.

PUT /attask/api/v15.0/project/4c7...?updates= 
{ 
    queueDef: { 
        isPublic: 1 
    } 
}

Utiliser le paramètre de requête Action

Certains objets permettent d’effectuer des actions supplémentaires, en plus des simples modifications. Vous pouvez spécifier ces actions à l’aide du paramètre de requête Action. Par exemple, la requête suivante recalcule la chronologie d’un projet donné :

PUT /attask/api/v15.0/project/4c7...?action=calculateTimeline

or

PUT /attask/api/v15.0/project/4c7.../calculateTimeline 

Déplacer des objets

La syntaxe suivante permet de déplacer une tâche d’un projet à un autre :

PUT /attask/api/v15.0/task/4c7.../move?projectID=5d8...

PUT /attask/api/v15.0/project/1234/approveApproval

PUT /attask/api/v15.0/project/1234/calculateFinance

PUT /attask/api/v15.0/project/1234/calculateTimeline

PUT /attask/api/v15.0/project/1234/calculateDataExtension

PUT /attask/api/v15.0/project/1234/recallApproval

PUT /attask/api/v15.0/project/1234/rejectApproval

PUT /attask/api/v15.0/task/1234/move

PUT /attask/api/v15.0/workitem/1234/markViewed

Voici un exemple de chaque type d’action :

PUT /attask/api/v15.0/project/1234?method=put&updates={accessRules:[{accessorID: 'abc123', accessorObjCode: 'USER', coreAction: 'VIEW'}]}

Partager des objets

La syntaxe suivante permet de partager un projet avec une équipe :

PUT /attask/api/v15.0/project/123abcxxxxxxxxxxxxxxxxxxxxxxxxxx/share?accessorID=123abcxxxxxxxxxxxxxxxxxxxxxxxxxx&accessorObjCode=TEAMOB

PUT /attask/api/v15.0/project/123abcxxxxxxxxxxxxxxxxxxxxxxxxxx?method=PUT&updates={accessRules:[{accessorID:'123abcxxxxxxxxxxxxxxxxxxxxxxxxxx',accessorObjCode:'TEAMOB',coreAction:'VIEW'}]}

PUT /attask/api/v15.0/task/4c7.../move?projectID=5d8...

Comportement de la requête DELETE

La requête DELETE supprime un objet. Dans tous les cas, l’URI peut inclure le paramètre force=true pour que le serveur supprime les données spécifiées et leurs éléments dépendants. Exécuter la méthode HTTP DELETE permet de supprimer une tâche sur un URI :

DELETE /attask/api/v15.0/task/4c78821c0000d6fa8d5e52f07a1d54d0 
DELETE /attask/api/v15.0/task?id=4c78821c0000d6fa8d5e52f07a1d54d0 
DELETE /attask/api/v15.0/task/4c78821c0000d6fa8d5e52f07a1d54d0?force=true 
DELETE /attask/api/v15.0/task?id=4c78821c0000d6fa8d5e52f07a1d54d0?force=true

Mises à jour en masse

Une instruction de mises à jour en masse met à jour plusieurs objets en même temps dans le cadre d’un seul appel API. Un appel API de création en masse est conçu de la même manière qu’un appel de mise à jour normal, comme le montrent les exemples suivants :

PUT /attask/api/v15.0/proj?updates=[{"name":"Test_Project_1"},{"name":"Test_Project_2"}]&method=POST&apiKey=123ab-cxxxxxxxxxxxxxxxxxxxxxxxxxx

data: [{
    ID: "53ff8d3d003b438b57a8a784df38f6b3",
    name: "Test_Project_1",
    objCode: "PROJ",
    percentComplete: 0,
    plannedCompletionDate: "2014-08-28T11:00:00:000-0400",
    plannedStartDate: "2014-08-28T11:00:00:000-0400",
    priority: 0,
    projectedCompletionDate: "2014-08-28T16:12:00:000-0400",
    status: "CUR"
},
{
    ID: "53ff8d49003b43a2562aa34eea3b6b10",
    name: "Test_Project_2",
    objCode: "PROJ",
    percentComplete: 0usi,
    plannedCompletionDate: "2014-08-28T11:00:00:000-0400",
    plannedStartDate: "2014-08-28T11:00:00:000-0400",
    priority: 0,
    projectedCompletionDate: "2014-08-28T16:12:00:000-0400",
    status: "CUR"
}]

PUT /attask/api/v15.0/proj?Umethod=PUT&updates=[{"ID":"123abcxxxxxxxxxxxxxxxxxxxxxxxxxx","name":"Test_Project_1_ Edit"},{"ID":"123abcxxxxxxxxxxxxxxxxxxxxxxxxxx","name":"Test_Project_2_Edit"}]&apiKey=123abcxxxxxxxxxxxxxxxxxxxxxxxxxx

data: [ {
     ID: "53ff8e15003b461d4560f7f65a440078",
     name: "Test_Project_1_Edit",
     objCode: "PROJ",
     percentComplete: 0,
     plannedCompletionDate: "2014-08-28T11:00:00:000-0400",
     plannedStartDate: "2014-08-28T11:00:00:000-0400",
     priority: 0,
     projectedCompletionDate: "2014-08-28T16:16:00:000-0400",
     status: "CUR"
},
{
    ID: "53ff8e19003b46238a58d303608de502",
    name: "Test_Project_2_Edit",
    objCode: "PROJ",
    percentComplete: 0,
    plannedCompletionDate: "2014-08-28T11:00:00:000-0400",
    plannedStartDate: "2014-08-28T11:00:00:000-0400",
    priority: 0,
    projectedCompletionDate: "2014-08-28T16:16:00:000-0400",
    status: "CUR"
}]