L’Outil Surpuissant pour Exploser ton Chiffre d'Affaires en 2024 !
AEM Content Services : Utilisation des API Sling et Node pour fournir des collections d'actifs – Partie 2
Dans la partie 1 de cette série, j'ai discuté d'une méthode pour obtenir des éléments AEM Asset Collection dans la représentation JSON d'une page. Cela utilise le modèle Sling model + HTL component pour obtenir les éléments de collection et afficher leurs valeurs dans le JSON, en fonction du type d'actif. Plus précisément, le modèle Sling permet au moteur de rendu JSON d'afficher le balisage dans les fragments de contenu et les SVG, ainsi que le chemin AEM vers les ressources au format binaire.
Avec cette méthode, les applications et services tiers peuvent utiliser le JSON, en utilisant AEM sans tête. . Avec cette approche, les auteurs peuvent mettre à jour les collections, tandis que les consommateurs de contenu voient ces mises à jour de collection dans leur flux JSON. Il s'agit déjà d'une solution puissante, mais nous pouvons ajouter une certaine automatisation en mettant à jour le JSON et en le rendant disponible sur le domaine du répartiteur orienté client/consommateur.
Commençons par automatiser les mises à jour JSON. Lorsqu'un auteur ajoute ou supprime des éléments dans l'une des collections, cela devrait être automatiquement reflété dans le JSON. Pour ce faire, nous devons ajouter une classe JCR Event Listener à notre projet qui écoutera les modifications et demandera la page avec nos composants. Vous pouvez trouver une telle classe ici :
Notez la référence à une classe CollectionsListenerConfig. Au lieu de coder en dur le chemin d'accès au nœud de page, nous pouvons obtenir un tableau de chemins à partir de la configuration pour appeler une ou plusieurs pages configurées pour la consommation JSON.
pages = config.pagesToUpdate();
Pour écouter pour les modifications apportées aux collections, nous créons une session à l'aide d'un utilisateur du service. Il s'agit d'un type spécial de principal d'utilisateur AEM, mieux adapté aux tâches de service d'arrière-plan qu'un véritable ID utilisateur.
L'objet de session créé peut ensuite être utilisé pour configurer l'écouteur. Nous devons écouter les modifications de propriétés ainsi que les ajouts et suppressions de nœuds réels sous /content/dam/collections.
session.getWorkspace().getObservationManager().addEventListener(this,
Événement.PROPERTY_ADDED |
Événement.PROPERTY_REMOVED |
Événement.PROPERTY_CHANGED |
Événement.NODE_ADDED |
Event.NODE_REMOVED, "/content/dam/collections", true,null, null, false);
Lorsque l'un de ces événements se produit, la méthode onEvent est invoquée. Cette méthode est l'endroit où nous effectuons une requête pour chaque page du tableau obtenu à partir de CollectionsListenerConfig. Cela utilise une simple requête de servlet HTTP pour chaque page, en utilisant le même résolveur de ressources obtenu via l'utilisateur du service, dans la méthode activate.
Nous ne sommes pas concernés par le rendu des pages dans un navigateur, seulement pour appeler le pages. Cela obligera Sling et le moteur HTL à traiter nos composants de collections configurés sur ces pages, déclenchant ainsi la mise à jour de leurs propriétés avec les dernières données de collections DAM.
Maintenant à propos de cette classe CollectionsListenerConfig . Il s'agit d'une classe simple qui utilise l'annotation ObjectClassDefinition pour définir l'objet de configuration et une annotation AttributeDefinition pour définir le champ configurable.
@AttributeDefinition(name = "Pages to Update", description = "Les pages qui doivent être appelées via Sling lorsque DAM les collections sont mises à jour ou modifiées.", type = AttributeType.STRING )
String[] pagesToUpdate();Lorsque cette classe est chargée avec le bundle, sa configuration sera ajoutée à la liste des éléments configurables du service d'administration de configuration OSGi (fournie via l'implémentation Felix OSGi). Les administrateurs AEM pourront configurer la liste des pages pour cela sous /system/console/configMgr. Cette configuration peut également être incluse dans votre référentiel de code, sous un dossier de configuration spécifique au mode d'exécution.
Avec ces ajouts, la solution fournit désormais une mise à jour automatique du JSON de manière configurable.
Une autre chose facultative que nous pouvons faire est de mettre à jour la classe IncludeCollectionsModel pour permettre la réplication automatique. Une chose importante à faire ici sera de s'assurer que la réplication se fait uniquement sur l'auteur. Nous pouvons utiliser l'API du réplicateur et l'externaliseur pour cela.
Deux méthodes ont été ajoutées à la classe, checkIfAuthor et replicateContent. La première méthode est explicite, c'est une méthode booléenne pour déterminer si cela est exécuté sur un auteur ou non.
private boolean checkIfAuthor() {
Set modes = slingSettingsService.getRunModes();
if (modes.contains(Externalizer.AUTHOR)) {
renvoie vrai ;
} autre {
renvoie faux ;
}
} La deuxième méthode appelle l'API du réplicateur pour répliquer la page.
public void replicateContent(String path) {
essayer {
Session session = resourceResolver.adaptTo(Session.class);
réplicateur.replicate(session, ReplicationActionType.ACTIVATE, chemin);
log.info("{} Les collections ont été répliquées.", LOG_PREFIX);
} catch (ReplicationException e) {
log.error(e.getMessage(),e);
}
}
L'appel de réplication nécessite une session, une action de réplication et un chemin de ressource. Nous obtenons un objet de session en adaptant le résolveur de ressources fourni par Sling (il s'agit du même résolveur de ressources utilisé dans le composant pour obtenir le sling:members pour le chemin de collecte fourni). L'avantage d'utiliser cette session est qu'elle a été créée dans le contexte des listes de contrôle d'accès appliquées de l'utilisateur actuel. Cela signifie que la réplication n'aura lieu que si l'utilisateur du service ou un auteur modifiant le composant a des autorisations de réplication définies pour autoriser la page.
Nous appelons cette méthode juste après que les modifications apportées aux propriétés du composant ont été validées, donc la page répliquée a toujours les dernières mises à jour. Avant d'appeler cela, nous vérifions que la classe est exécutée sur un auteur et ne répliquons que si checkIfAuthor renvoie true.
resourceResolver.commit();
//Répliquer la page si elle est exécutée sur un auteur, afin que les mêmes mises à jour JSON soient accessibles depuis le ou les éditeurs.
PageManager pageManager= resource.getResourceResolver().adaptTo(PageManager.class);
Page currentPage = pageManager.getContainingPage(ressource);
if (checkIfAuthor() && currentPage != null) {
replicateContent(currentPage.getPath());
}
Avec tous ces changements, nous avons optimisé les mises à jour automatisées pour les auteurs et les éditeurs. Tout ce qui est fait ici utilise les API Sling, Node et Replicator intégrées à AEM, ainsi que les services OSGi intégrés. Cela illustre les avantages de l'extension des blocs de construction déjà bons d'AEM !
Source link