Configuration requise

Connaissances préalables

  • Compréhension d'AEM Mobile
  • Maîtrise du processus standard de création et de publication de contenu via le portail à la demande standard
  • Expérience avec l'interface On-Demand Services API

Produits requis

  • AEM Mobile
  • Clé de l’API
  • Accès à l'interface On-Demand Services API

 

Introduction

Le On-Demand Services SDK pour PHP d'Experience Manager Mobile est une bibliothèque qui permet aux développeurs tiers d’intégrer facilement leurs contenus à l’interface On-Demand Services API (précédemment appelée « API Content Producer Services »).

Le SDK assiste les développeurs PHP en prenant en charge différents éléments, notamment les bonnes pratiques, les dispositifs à sécurité intégrée en cas d’erreur et les consignes mineures (mais importantes), telles que la nécessité de définir les en-têtes appropriés pour chaque demande d’API.

Téléchargement du On-Demand Services SDK pour PHP

Remarque :

en téléchargeant les logiciels mentionnés ci-après, vous reconnaissez avoir lu et accepter les conditions énoncées dans le document APIs for Experience Manager Mobile Services License, les Conditions d'utilisation d’Adobe.com et la Politique de confidentialité en ligne d’Adobe.

Telechargement

Pour obtenir la liste des modifications récentes, reportez-vous au journal des modifications à la fin de ce document.

Compréhension des concepts

L’interface On-Demand Services API nécessite un accès autorisé. Il est donc important de bien comprendre et de lire cette section en entier avant de poursuivre.

Authentification

Pour chaque demande client (HTTPS) lancée à l’aide de l’interface On-Demand Services API, vous devez inclure les éléments suivants dans les en-têtes de la demande :

  • X-Dps-Api-Key: {{client_id}}
  • Authorization: Bearer {{access token}}

La clé de l’API permet au client d’accéder à l’interface On-Demand Services API, tandis que le jeton d’accès permet d’identifier le compte client.

Pour demander une clé d’API, veuillez lire la documentation concernant l’interface On-Demand Services API, puis télécharger et renseigner le formulaire de demande en suivant les instructions de la documentation.

Une fois que vous aurez reçu la clé d’API, vous pourrez générer un jeton d’accès. Pour générer le jeton d’accès, procédez comme suit :

  1. Accédez à l’outil AEX Device Token Generator.
  2. Saisissez un ID client valide.
  3. Ouvrez une session à l’aide d’un Adobe ID valide.
  4. Si tout fonctionne correctement, un ID de périphérique (« device Id ») ainsi qu’un jeton de périphérique (« device token ») sont générés.
  5. Pour générer le jeton d’accès, effectuez une demande d’API à l’aide de l’identifiant du client, de l’identifiant du périphérique et du jeton de périphérique.

Remarques concernant l’authentification :

  • Le jeton d’accès expire dans un délai de 24 heures.
  • L’ID de périphérique et le jeton de périphérique se renouvellent automatiquement tant qu’ils sont utilisés. Le client peut utiliser l’identifiant et le jeton de périphérique pour générer de nouveaux jetons d’accès si nécessaire.
  • Si le mot de passe du compte qui a été utilisé pour les générer est mis à jour, l'ID de périphérique et le jeton de périphérique ne seront plus valides. Si cela se produit, générez un nouvel jeu d'ID de périphérique et de jetons de périphérique.

 

Autorisation

Au cours du processus de demande de clé d’API, vous pouvez demander jusqu’à trois Adobe ID qui permettront d’accéder à l’outil AEX Device Token Generator. Cela signifie que vous ne pouvez pas utiliser plus de trois Adobe ID pour accéder aux projets. Toutefois, avec nos nouveaux Rôles et autorisations, vous pouvez ajouter chaque Adobe ID à autant de projets que vous le souhaitez.

Par exemple, si vous possédez des projets dans les comptes A, B et C, vous pouvez ajouter le compte A aux projets des comptes B et C. De cette façon, vous n’avez plus qu’à générer l’ID et le jeton de périphérique pour le compte A. Ce périphérique pourra ainsi accéder aux projets qui se trouvent dans les comptes A, B et C.

Prise en main

Le SDK pour PHP suit la procédure PHP PSR-4, laquelle utilise un outil d’auto-chargement (« autoloader ») et un espace de noms pour charger les classes requises.

Outil d’auto-chargement

L’outil d’auto-chargement (« autoloader ») se trouve dans le dossier /aemmobilesdk/vendor/autoload.php. Vous pouvez charger l’outil d’auto-chargement en suivant la méthode ci-après, et en remplaçant la mention « path/to » par l’emplacement où se trouve le fichier PHP de l’outil autoloader sur votre ordinateur :

require_once('path/to/aemmobilesdk/vendor/autoload.php');

Espace de noms

L’espace de noms qui renvoie au nom de la classe suit l’arborescence du dossier /aemmobilesdk/. Par exemple, l’objet de classe « Article » se trouve dans le dossier /aemmobilesdk/contentService/Article.php. Dans ce cas, l’espace de noms se présente comme suit :

use aemmobilesdk\contentService\Article

Notez que l’espace de noms est sensible à la casse dans certaines versions de PHP ; il est donc préférable d’utiliser la casse exacte du nom de dossier/fichier.

Nom de classe

Chaque objet de classe représente un composant dans AEM Mobile et traite uniquement les données correspondant à son propre domaine de compétences. Par exemple, l’objet de classe « Article » gère uniquement les tâches relatives aux articles, comme le chargement d’un fichier compressé portant l’extension .article. Vous ne pouvez pas utiliser d’objet de classe « Article » pour ajouter un article à une collection. Dans ce cas, c’est l’objet de classe « Collection » qui est requis.

Configuration

Tous les objets de classe nécessitent une instance du client utilisateur lors de leur initialisation. Aucun objet de classe abstrait ne doit (ni ne peut) être initialisé.

Client utilisateur

L’objet de classe « utilisateur » représente le client utilisateur, et contient les éléments suivants :

  • Identifiants du client
  • ID de projet client
  • Exécution de la demande d’API

Pour initialiser le client utilisateur, vous devez spécifier l’espace de noms (tout comme avec les autres objets de classe) :

use aemmobilesdk\userService\User; 
$objUser = new User();

Les identifiants du client peuvent être définis dans le dossier /aemmobilesdk/configuration/Credentials.php. Ils seront alors chargés automatiquement ou en invoquant les fonctions suivantes lors de l’exécution :

$objUser->setClientId('enter-your-client-id');
$objUser->setClientSecret('enter-your-client-secret');
$objUser->setDeviceId('enter-your-device-id');
$objUser->setDeviceToken('enter-your-device-token');

Pour générer le jeton d’accès, vous pouvez invoquer les deux fonctions suivantes, lesquelles demandent et stockent le jeton d’accès au cours d’une session PHP, respectivement :

$objUser->requestToken(); 
$objUser->storeToken();

Pour cibler un projet, vous devez spécifier l’ID de projet correspondant :

$objUser->setPublicationGuid('68957c92-99c2-47a3-8f54-83771ba21348');

Vous pouvez récupérer l’ID du projet soit dans l’URL du tableau de bord (https://aemmobile.adobe.com/content/index.html#/publication/68957c92-99c2-47a3-8f54-83771ba21348/content), soit via l’API. Pour utiliser la seconde option, vous pouvez exécuter la fonction suivante afin d’obtenir la liste des projets associés à ce client utilisateur :

$objUser->requestPermissions(); 
$arrPermissionList = $objUser->getResponse();

Nous vous conseillons de prendre l’habitude de vérifier que l’utilisateur client dispose des droits et des autorisations adéquats avant d’accéder au projet indiqué :

$objUser->requestPermissions(); 
$objUser->verifyPermissions();

Demande d’API

Comme indiqué précédemment, chacune des fonctions de l’objet de classe générera correctement les en-têtes et données de la demande, mais l’exécution en elle-même revient à l’objet de classe « Utilisateur ». L’initialisation de l’objet de classe est similaire au processus d’initialisation du client utilisateur :

use aemmobilesdk\contentService\Article; 
$objArticle = new Article($objUser);

Persistance des données

C’est à l’utilisateur d’assurer la persistance des métadonnées. Prenons l’exemple d’une collection contenant deux articles et une bannière, à laquelle vous souhaitez ajouter un troisième article. Vous devez commencer par obtenir la liste des deux articles et de la bannière existants dans cette collection, ajouter (en suffixe ou en préfixe) le troisième article à cette liste, puis mettre à jour la collection avec les quatre éléments. Sinon, si vous vous contentez de mettre à jour la collection avec le troisième article, la collection ne contiendra plus que ce troisième article et les trois autres éléments (bannière et deux articles) seront supprimés.

Expérimentation des recettes

Nous proposons des recettes que vous pouvez utiliser pour valider les concepts présentés. Ces recettes se trouvent dans le dossier /recipes/. Veuillez noter que le SDK pour PHP est encore en phase de développement. Nous fournissons régulièrement des mises à jour visant à améliorer le SDK pour PHP et à intégrer toutes les nouvelles fonctionnalités d'AEM Mobile.

Journal des modifications

 

Mises à jour du 01/11/2016

  • Ajout de la prise en charge et des recettes pour la bannière dynamique.
  • Ajout de la prise en charge pour le téléchargement du fichier PDF directement dans le service d'importation (article uniquement).

Mises à jour du 22/02/2016

  • Le répertoire SDK a été modifié de dps2015sdk en aemmobilesdk. Tous les espaces de noms SDK PHP existants et futurs doivent être mis à jour en aemmobilesdk (utilisez particulièrement aemmobilesdk\userService\User;).
  • Paramètre facultatif ajouté à Entity::publish() et Entity::unpublish(). Ce paramètre permet les actions de publication et dépublication en bloc. Le paramètre facultatif doit contenir une liste sous forme de tableau des HREF d'entité avec les versions principales.
  • Paramètre facultatif ajouté à Entity::getHref(). Ce paramètre permet de conserver l'HREF d'entité sans la version principale. Principalement utilisé pour ajouter des entités à une collection, l'indication de la version principale étant facultative.
  • Mise à jour de la logique dans recipes/publication/reset.php (précédemment deleteAll.php). Cette recette utilise maintenant le paramètre Entity::unpublish() en bloc mis à jour pour dépublier une liste d'entités (en fonction des dépendances), plutôt que de les dépublier individuellement.

Mises à jour du 06/01/2016

  • Stockage des métadonnées d'entité requises en interne.
  • Classe d'entité après une requête Entity::update().
  • Fonction Collection::removeEntity() pour supprimer une entité spécifique de la liste des éléments de contenu de la collection stockés dans la classe de la collection. Appel de la fonction Collection::requestContentElements() avant d'utiliser cette nouvelle fonctionnalité ; dans le cas contraire, la liste dans la classe de la collection est vide.
  • Ajout d'une classe statique d'outils afin de gérer des fonctionnalités plus génériques, telles que la génération d'un horodatage, les objets « Pretty print », etc.
  • Dans recipes/product/genIssueList.php, la recette télécharge dorénavant les vignettes (et les images d'arrière-plan) si disponibles et pas encore téléchargées. Une recette distincte (voir recipes/product/downloadImage.php) a été créée pour télécharger uniquement les images, réduisant ainsi le temps de chargement de genIssueList.php.
  • Ajout d'une recette permettant d'ajouter un article à une collection (voir recipes/collection/addArticle.php).
  • Ajout d'une recette permettant de supprimer un article d'une collection (voir recipes/collection/removeArticle.php).
  • Ajout d'une recette permettant de publier toutes les entités (et non simplement les entités immédiates) d'une collection (voir recipes/collection/publishAllChildren.php).

Ce produit est distribué sous licence Creative Commons Attribution - Pas d’utilisation commerciale - Partage à l’identique 3.0 non transposé  Les publications Twitter™ et Facebook ne sont pas couvertes par les dispositions Creative Commons.

Mentions légales   |   Politique de confidentialité en ligne