Adobe Experience League

Configurations du service cloud

Les configurations apportent la logique et la structure de stockage des configurations de service.

Vous pouvez étendre les instances existantes pour créer vos propres configurations.

Concepts

Les principes suivis dans le développement des configurations sont basés sur les concepts ci-après :

Les services/adaptateurs sont utilisés pour récupérer la ou les configurations.
Les configurations (par exemple les propriétés/paragraphes) sont héritées du ou des parents.
Référencées à partir du(des) nœud(s) analytique(s) par chemin.
Facilement extensibles.
Dispose de la possibilité de prendre en charge des configurations plus complexes, telles que Adobe Analytics.
Prise en charge des dépendances (par ex. Les modules externes Adobe Analytics ont besoin d’une configuration Adobe Analytics.

Structure

Le chemin de base des configurations est :

/etc/cloudservices.

Pour chaque type de configuration, un modèle et un composant sont fournis. Ainsi, une fois personnalisés, les modèles de configuration peuvent répondre à la plupart des besoins.

Pour fournir une configuration à un nouveau service, vous devez :

création d’une page de service dans

/etc/cloudservices
sous :
- un modèle de configuration
- un composant de configuration

Le modèle et le composant doivent hériter du sling:resourceSuperType du modèle de base :

cq/cloudserviceconfigs/templates/configpage

ou composant de base respectivement

cq/cloudserviceconfigs/components/configpage

Le fournisseur de services doit également fournir la page de service :

/etc/cloudservices/<service-name>

Modèle

Votre modèle étendra le modèle de base :

cq/cloudserviceconfigs/templates/configpage

et définissez un resourceType qui pointe vers le composant personnalisé.

/libs/cq/analytics/templates/sitecatalyst
sling:resourceSuperType = cq/cloudserviceconfigs/templates/configpage
allowedChildren = /libs/cq/analytics/templates/sitecatalyst
allowedPaths = /etc/cloudservices/analytics/*, /etc/cloudservices/analytics/.*
componentReference = cq/analytics/components/sitecatalyst
jcr:content/
cq:designPath = /etc/designs/cloudservices
sling:resourceType = cq/analytics/components/sitecatalystpage

/libs/cq/analytics/templates/generictracker
sling:resourceSuperType = cq/cloudservices/templates/configpage
allowedChildren = /libs/cq/analytics/templates/generictracker
allowedPaths = /etc/cloudservices/analytics/*, /etc/cloudservices/analytics/.*
jcr:content/
cq:designPath = /etc/designs/cloudservices
sling:resourceType = cq/analytics/components/generictrackerpage

Composants

Votre composant devrait étendre le composant de base :

cq/cloudserviceconfigs/templates/configpage

/libs/cq/analytics/components/sitecatalystpage

/libs/cq/analytics/components/generictrackerpage

Après avoir configuré votre modèle et votre composant, vous pouvez ajouter votre configuration en ajoutant des sous-pages sous :

/etc/cloudservices/<service-name>

Modèles de contenu

Le modèle de contenu est stocké sous la forme cq:Page sous :

/etc/cloudservices/<service-name>(/*)

/etc/cloudservices
/etc/cloudservices/service-name
/etc/cloudservices/service-name/config
/etc/cloudservices/service-name/config/inherited-config

Les configurations sont stockées sous le sous-noeud jcr:content.

Les propriétés fixes, définies dans une boîte de dialogue, doivent être stockées directement sur le jcr:node.
Les éléments dynamiques (utilisant parsys ou iparsys) se servent d’un sous-nœud pour stocker les données du composant.

/etc/cloudservices/service/config/jcr:content as nt:unstructured
propertyname
*
par/component/ as cq:Component
propertyname
*

API

Pour la documentation de référence sur l’API, voir com.day.cq.wcm.webservicesupport.

Intégration d’AEM

Les services disponibles sont répertoriés dans l’onglet Cloud Services de la boîte de dialogue Propriétés de la page (de toute page qui hérite de foundation/components/page ou wcm/mobile/components/page).

L’onglet contient également :

un lien vers l’emplacement où vous pouvez activer le service
le choix d’une configuration (sous-nœud du service) à partir d’un champ de chemin

Chiffrement de mot de passe

Lorsque vous stockez des informations d’identification d’utilisateur pour le service, tous les mots de passe doivent être chiffrés.

Pour cela, il faut ajouter un champ de formulaire masqué. Ce champ doit comporter l’annotation @Encrypted dans le nom de la propriété ; En d’autres termes, pour le champ password, le nom serait écrit comme suit :

password@Encrypted

La propriété est alors automatiquement chiffrée (en utilisant le service CryptoSupport) par EncryptionPostProcessor.

REMARQUE

Ceci est similaire aux annotations [SlingPostServlet](https://sling.apache.org/site/manipulating-content-the-slingpostservlet-servletspost.html) standard.

REMARQUE

Par défaut, EcryptionPostProcessor ne chiffre que les demandes POST effectuées à /etc/cloudservices.

Propriétés supplémentaires pour les nœuds jcr:content de page de service

Propriété	Description
componentReference	Chemin d’accès de référence à un composant à inclure automatiquement dans la page. Ceci est utilisé pour des fonctionnalités supplémentaires et des inclusions JS. Cela inclut le composant sur la page `cq/cloudserviceconfigs/components/servicecomponents` où est inclus (normalement avant la `body` balise ). Dans le cas de Google Analytics et Target, nous utilisons ceci pour insérer des fonctionnalités supplémentaires, telles que des appels JavaScript, afin de suivre le comportement des visiteurs.
description	Brève description du service.
descriptionExtended	Description étendue du service.
ranking	Classement des services à utiliser dans les listes.
selectableChildren	Filtre pour l’affichage des configurations dans la boîte de dialogue des propriétés de page.
serviceUrl	URL du site Web du service.
serviceUrlLabel	Libellé de l’URL du service.
thumbnailPath	Chemin d’accès à la miniature du service.
visible	Visibilité dans la boîte de dialogue des propriétés de page ; visible par défaut (facultatif)