Meilleures pratiques et instructions de modélisation pour la personnalisation du Management Center

Pour personnaliser le Management Center, vous pouvez modifier certains fichiers fournis par HCL Commerce et créer vos propres fichiers de configuration afin de définir des fonctions ou des objets personnalisés pour votre magasin. Avant de commencer la personnalisation du Management Center, examinez comment les mises à niveau ou les correctifs de maintenance fournis par HCL Commerce peuvent affecter vos objets personnalisés et vos modifications. En suivant l'approche de personnalisation appropriée, vous pouvez vous assurer qu'aucune personnalisation n'est écrasée lorsque vous installez un correctif de maintenance ou une mise à niveau vers un édition ultérieure.

Meilleures pratiques

Assurez-vous que la personnalisation planifiée suit les meilleures pratiques ci-après :

N'utilisez que les classes documentées du Management Center lorsque vous personnalisez le Management Center. N'utilisez pas les classes marquées privées et ne modifiez pas les fichiers restreints.
Utilisez toujours HCL Commerce Developer pour le développement. Cet environnement de développement est conçu pour faciliter la personnalisation et la migration à venir. Les applications que vous développez à l'aide d'autres outils ne peuvent pas être gérées ou migrées correctement.
Utilisez toujours les points d'extension désignés. Les classes documentées du Management Center incluent ces points d'extension.
Appliquez toujours la procédure de déploiement recommandée. Pour plus d'informations, voir Code personnalisé de combinaison pour le déploiement.
Lorsque vous personnalisez le Management Center, vous pouvez directement modifier les fichiers suivants, fournis par HCL Commerce :
- Tous les fichiers XML de définition qui se trouvent dans le répertoire WCDE_installdir\LOBTools\WebContent\WEB-INF\src\xml. N'ajoutez pas et ne modifiez pas de fichier dans un répertoire restreint.
- Le fichier spring-extension.xml dans le répertoire WCDE_installdir\LOBTools\WebContent\WEB-INF.
Pour les fichiers restreints non modifiables, vous pouvez en créer des versions personnalisées dans vos propres répertoires. En phase d'exécution, ces fichiers sont fusionnés avec les fichiers fournis par HCL Commerce. Les configurations ou les définitions incluses dans vos fichiers personnalisés sont prioritaires.
Conservez une structure de répertoire cohérente si vous envisagez de migrer vers une version ultérieure ou si vous demandez l'assistance du support IBM pour vos personnalisations. Lorsque vous ajoutez des fichiers à la structure du Management Center, respectez la même structure de répertoire que les fichiers par défaut fournis, avec les exceptions suivantes :
- Utilisez le nom de votre société pour le répertoire commerce de votre structure de répertoire. Par exemple, au lieu d'utiliser la structure du répertoire workspace_dir\LOBTools\WebContent\WEB-INF\src\xml\commerce\component, utilisez workspace_dir\LOBTools\WebContent\WEB-INF\src\xml\mycompany\component.
- Vous n'avez pas besoin d'un répertoire restricted dans votre structure d'annuaire mycompany. Les répertoires restreints du répertoire commerce indiquent des répertoires qui sont remplacés lorsque vous installez des correctifs HCL Commerce ou que vous migrez vers une version ultérieure.
  Remarque : Si vous utilisez un système de gestion de contrôle source pour stocker vos fichiers, ne restituez pas les fichiers des répertoires restreints sur le système de gestion de contrôle de source.

Conseil : Pour vous aider à mieux comprendre la procédure de personnalisation du Management Center, suivez les tutoriels fournis pour personnaliser le Management Center. Ces tutoriels proposent des exemples de scénario pour personnaliser la structure du Management Center. Pour plus d'informations, voir Management Center tutoriels de personnalisation.

Instructions de modélisation des fichiers de définition

Les fichiers de définition du Management Center peuvent être restreints ou personnalisables.

Fichiers restreints

Les fichiers restreints incluent des définitions de classe pour la fonctionnalité de base, commune à tous les outils du Management Center. Etant donné que ces fichiers restreints sont remplaçables lorsque vous installez des correctifs de maintenance ou une mise à niveau HCL Commerce, ne les modifiez pas.

Fichiers personnalisables

Les fichiers personnalisables décrivent les objets gérés dans un outil du Management Center et la manière de les afficher. Lorsque vous installez des correctifs de maintenance ou une mise à niveau HCL Commerce, vos fichiers de personnalisation sont conservés. Vous pouvez utiliser, étendre ou modifier les classes dans des fichiers personnalisables lorsque vous personnalisez le Management Center. Lorsque vous travaillez avec des fichiers personnalisables, respectez les consignes suivantes :

Notes :

Séparez clairement votre code du code IBM de base. Si vous créez des classes, placez-les dans votre fichier afin d'éviter de compliquer le processus de migration.
Ne déplacez pas les instances d'une classe d'une classe parent vers une autre. La modification de la classe parent d'une classe est considérée comme un ajout ou une suppression de parent. Il n'existe aucune méthode pour associer les deux opérations. Les instances d'une classe sous le nouveau parent sont considérées comme des ressources personnalisées et ne sont pas mises à jour lorsque vous installez un correctif de maintenance ou une mise à niveau HCL Commerce.
Ne supprimez pas le code IBM. Les classes dans les définitions de recherche et les définitions d'objet n'ont aucune incidence si vous ne les appelez pas. Lorsque vous installez des correctifs de maintenance ou une mise à niveau HCL Commerce, vous recevez automatiquement les classes mises à jour. Vous pouvez masquer la plupart des widgets du Management Center dans l'interface utilisateur lorsque ceux-ci ne sont pas nécessaires, en attribuant la valeur false à leur indicateur de visibilité.
Si les éléments suivants sont absents du fichier de définition, évitez de les y introduire. Si vous ajoutez ces éléments au fichier, vous pouvez rencontrer des problèmes lors de l'installation d'un correctif de maintenance ou d'une mise à niveau HCL Commerce.
- <method>
- <handler>

Remarque : Lorsque vous ajoutez ou modifiez des fichiers de définition dans le répertoire workspace_dir\LOBTools\WebContent\WEB-INF\src\xml, vous n'avez pas besoin de redémarrer le serveur HCL Commerce. Les nouvelles définitions sont automatiquement détectées par le servlet de module AMD qui vérifie les dernières données modifiées dans les fichiers de définition. Vous n'avez pas besoin de redémarrer le Centre de gestion en fermant la fenêtre du navigateur du Centre de gestion et en effaçant le cache de ce navigateur.

Vous pouvez utiliser des chemins d'objet pour demander à la structure du Management Center de rechercher les objets enfants d'un objet sélectionné afin de localiser un objet à employer. Un chemin d'objet est constitué d'une liste de types d'objet séparés par une barre oblique "/". La structure effectue une recherche récursive des objets enfants correspondant aux types d'objet spécifiés. Par exemple, le chemin d'objet objectPath="CatentryDescription" indique au Management Center de rechercher l'objet en cours d'un objet enfant associé au type d'objet "CatentryDescription". Tout type d'objet dans un chemin d'objet peut être remplacé par un groupe d'objets. Par exemple, si un groupe d'objets Catentry est défini pour les types d'objet Product, Bundle, Kit ou SKU, le chemin d'objet de Catentry correspond à des objets de type Product, Bundle, Kit ou SKU. Les types d'objet inclus dans un chemin d'objet peuvent être qualifiés par un nom et une valeur de propriété à l'aide d'une syntaxe de type XPath telle que [prop=value]. Les classes suivantes du Management Center acceptent les chemins d'objet :

cmc/foundation/ChildListEditor
cmc/foundation/GridCellDescriptor
cmc/foundation/GridColumn
cmc/foundation/ObjectPathFilter
cmc/foundation/ObjectPropertyFilter
cmc/foundation/PreviewFileClientAction
cmc/foundation/PropertiesComponent
cmc/foundation/PropertyValuesFilter
cmc/foundation/NumericPropertyComparator
cmc/foundation/RequiredChildObjectValidator
cmc/foundation/RequiredSpecificValueForChildObjectPropertyValidator
cmc/foundation/UniqueValueForChildObjectPropertyValidator
cmc/foundation/ValueResolver

Instructions de modélisation de l'éditeur d'objet métier

La classe de l'éditeur d'objet métier, cmc/foundation/BusinessObjectEditor, est la classe de base pour tous les outils du Management Center. L'éditeur d'objet métier inclut la prise en charge du menu, de la barre d'outils, du widget de recherche, de la vue d'explorateur et de la vue des utilitaires du Management Center . Il est chargé de gérer toutes les interactions d'utilisateur qui permettent à l'utilisateur d'éditer les objets métier déclarés auprès de l'éditeur. N'instanciez pas directement des instances de cette classe. Enregistrez les instances de cette classe en ajoutant une instance de "cmc/foundation/ApplicationMenu" à "cmc/foundation/ApplicationMenuItems".

La création d'une instance de la classe BusinessObjectEditor consiste principalement à déclarer les objets qui doivent être traités (c'est-à-dire, créés, modifiés ou supprimés). Pour garantir que l'éditeur d'objet métier puisse utiliser des définitions d'objet et fournir un outil de création efficace pour différents domaines d'objet, les objets doivent être déclarés de manière cohérente. Pour créer un modèle d'objet métier utilisable par l'éditeur d'objet métier, respectez les consignes suivantes :

Incluez une définition d'objet supérieur dans la déclaration de l'éditeur d'objet métier. Cette définition d'objet supérieur décrit l'objet racine de l'arborescence d'explorateur. Cet objet est un objet d'organisation côté client qui n'est pas renvoyé par un appel de service. L'objet supérieur n'est pas visible, mais ses enfants apparaissent en tant que nœuds d'arborescence d'explorateur de niveau supérieur, sous le nœud Travail actif. Lorsque l'instance de l'objet supérieur est instanciée, tous les objets enfant déclarés dans le cadre du modèle de définition d'objet sont créés. En outre, toutes les instances déclarées de la classe GetChildrenService sont appelées pour extraire des objets enfants supplémentaires depuis le serveur HCL Commerce.
Si un ou plusieurs noeuds d'arborescence d'explorateur de niveau supérieur sont requis en tant qu'éléments d'organisation, ils doivent être déclarés en tant que définitions d'objet d'organisation. Ils peuvent uniquement être instanciés en tant qu'éléments d'une autre déclaration de modèle de définition d'objet.
Tous les types d'objet métier pouvant être créés, mis à jour ou supprimés doivent être déclarés en tant que définitions d'objet principal ou en tant que définitions d'objet enfant d'une définition d'objet principal.
Si un objet métier existe uniquement dans le contexte d'un autre objet et ne peut pas être référencé ou recherché sans rechercher son parent, ce type d'objet doit alors être déclaré en tant que définition d'objet enfant d'une définition d'objet principal ou d'une autre définition d'objet enfant.
Les objets métier principaux peuvent ne pas avoir d'objet métier principal en tant qu'enfant direct. Un objet intermédiaire, appelé objet de référence, est requis pour décrire la nature de la relation entre les deux objets principaux. Ce type d'objet intermédiaire doit être déclaré en tant que définition d'objet de référence.
Tous les objets métier sont constitués d'une liste de propriétés simples à nom unique. Si un objet contient une liste variable de propriétés enfant similaires, cette propriété doit alors être modélisée en tant que type d'objet enfant distinct.
Un objet métier doit pouvoir être identifié de manière unique à l'aide de la valeur de l'une des propriétés (identifiée par la propriété ID). La valeur ID des objets décrits par des définitions d'objet enfant ou de référence ne doit être unique qu'au sein de l'ensemble d'objets ayant le même parent. Les objets principaux du même type doivent tous avoir une valeur ID unique.
Tous les objets principaux doivent posséder un identificateur d'affichage en tant que valeur de l'une des propriétés de l'objet (identifié par la propriété de nom d'affichage). Notez que toute définition d'objet peut déclarer une propriété displayNameProperty, mais cela est obligatoire uniquement pour les objets principaux. Ce nom d'affichage est utilisé comme texte sur un objet fenêtre de l'interface utilisateur qui représente l'instance d'objet. Il n'est pas nécessaire que cette valeur soit unique mais cela est préférable. Evitez d'utiliser des propriétés traduisibles lorsque vous choisissez la propriété de nom d'affichage.
Si deux objets métier requièrent des déclarations de vue de propriétés différentes, ils doivent être modélisés en tant que types d'objet distincts. Par exemple, modélisez les produits et les SKU en tant que types d'objet différents et non en tant que type d'objet unique pour les entrées de catalogue.

Instructions de modélisation des magasins de site étendu

Si vous utilisez des magasins de site étendu, assurez-vous que l'outil est modélisé pour la prise en charge des sites étendus, en respectant les consignes suivantes :

Les objets prenant en charge les sites étendus peuvent être locaux ou hérités. Un objet local est un objet appartenant au magasin sélectionné et un objet hérité est un objet appartenant à un magasin de ressources référencé. Pour distinguer les objets locaux des objets hérités, le Management Center nécessite deux définitions d'objet : une pour l'objet local et une autre pour l'objet hérité. Etant donné que les objets métier principaux locaux et les objets métier principaux hérités sont modélisés en deux définitions d'objet distinctes dans le magasin de sites étendus, vous devez dupliquer toutes les définitions d'objet qui sont héritées de votre magasin de ressources.
Si vous créez une définition d'objet de base pour générer un ancêtre commun à tous les types d'objet, paramétrez les définitions d'objet de base et héritée sur createable="false" afin que l'interface utilisateur ne permette pas de créer d'objet de ce type.
Si vous modélisez des définitions d'objet pour des objets Sites étendus gérés avec un outil du Management Center, respectez les consignes suivantes :
- Déplacez toutes les définitions d'objet dépendant du magasin vers une définition de base et nommez l'objectType baseABC. Pour établir si une propriété est dépendante du magasin, déterminez si elle doit être remplacée au niveau du site étendu. Par exemple, les descriptions de produit sont actuellement indépendantes du magasin, c'est-à-dire que chaque magasin ayant accès à un produit voit la même description de produit. Pour personnaliser HCL Commerce afin que la description de produit soit dépendante du magasin, déplacez la définition d'objet de la description de produit vers la définition de base.
  Remarque : Le schéma sous-jacent doit également prendre en charge les propriétés dépendantes du magasin. Par exemple, étant donné que la table de base de données actuelle qui stocke les associations de marchandisage (MASSOCCECE) comporte une colonne pour l'ID de magasin, les produits peuvent avoir des associations de marchandisage distinctes dans les différents magasins. Vous pouvez également effectuer le suivi d'une association de marchandisage spécifique au magasin pour un produit.
- Dupliquez toutes les définitions d'objet métier de référence pour les références qui sont dépendantes du magasin et marquez-les clairement en tant qu'objets hérités. Nommez le type d'objet, objectType, des définitions d'objet de référence hérité afin d'indiquer qu'elles sont héritées. Lorsque vous créez ce type d'objet, déterminez si la référence est dépendante du magasin.
  Par exemple, une association de marchandisage est un objet métier de référence qui crée une référence entre un produit source et un produit cible. Si le produit source et le produit cible proviennent d'un magasin de ressources, vous devez déterminer si l'utilisateur doit créer une association de marchandisage sur le magasin de ressources ou sur un site étendu qui hérite de ce magasin de ressources. Dans le premier cas, tous les sites étendus qui héritent de ce magasin de ressources présentent l'association de marchandisage. Dans le second cas, seul le site étendu sur lequel l'association de marchandisage a été créée comporte cette dernière. Pour prendre en charge ces deux scénarios, l'objet métier de référence de l'association de marchandisage doit être dépendant du magasin.
- Définissez compatibleObjectTypes par la valeur d'objectType de l'objet métier de magasin du site étendu. Lorsque l'objet est copié, le nouvel objet est marqué en tant qu'objet métier de magasin de site étendu par opposition à un objet métier hérité.
```

<PrimaryObjectDefinition baseDefinition="cmc/catalog/BaseKitPrimaryObjectDefinition" 
  compatibleObjectTypes="Kit" 
  definitionName="cmc/catalog/InheritedKit" displayName="${catalogResources.inheritedKit_DisplayName}" 
  headerIcon="inheritedKitHeaderIcon" icon="inheritedKitIcon" 
  objectType="InheritedKit">
<dependency localName="catalogResources" moduleName="cmc/catalog/CatalogResources"/>
```
- Ajoutez un élément de condition d'activation en tant qu'enfant de vos objets métier principaux hérités.
```

<EnablementOrCondition baseDefinition="cmc/catalog/StoreTypeCatalogObjectCreationRestriction"/>
```
  Généralement, les objets hérités ne peuvent pas être créés par la structure. Toutefois, il existe deux exceptions. Bien que vous puissiez créer des associations de marchandisage et des prix hérités dans le site étendu, il s'agit d'objets de référence et non d'objets principaux. Les objets principaux hérités ne sont jamais créés dans le site étendu. En outre, les objets hérités ne peuvent pas avoir de conditions d'activation contrairement aux objets locaux. Définissez une condition d'activation avec la liste des types de magasin, storeTypes, où la création de ces objets est autorisée. Utilisez cet attribut pour les objets métier principaux de sites étendus devant empêcher la création et la copie des objets par type de magasin.
- Mettez à jour la page JSP de réponse afin qu'elle renvoie l'ID magasin de l'objet si vous avez créé votre propre objet hérité et que vous souhaitez que les utilisateurs puissent créer l'objet au niveau du magasin de ressources alors qu'ils sont connectés à un magasin de site étendu.
  Lorsque vous appelez le service de création, l'interface utilisateur du Centre de gestion appelle une demande de création et la page JSP de réponse appropriée crée la réponse à la demande. Cette réponse contient les informations relatives au résultat de la demande, y compris toutes les informations modifiées que le Centre de gestion requiert en tant que résultat de la demande. Lorsque l'objet est hérité du magasin de ressources, vous devez ajouter la ligne suivante à la page JSP de réponse afin de renvoyer l'ID objectStoreId : <objectStoreId>.{param.storeID}</objectStoreId>
- Déclarez le service de création uniquement dans la définition d'objet local afin d'empêcher la création de l'objet hérité.
```

<CreateService sendDefaultLanguageProperties="true" url="/cmc/CreateCatalogGroup">
  <ServiceParam name="storeId"/>
  <ServiceParam name="masterCatalogId"/>
  <ServiceParam name="defaultLanguageId" parameterName="languageId"/>
  <ServiceParam name="isTopCategoryTrue" optional="false" parameterName="isTopCategory" value="true">
    <EnablementCondition checkObjectDefinition="true" conditionId="objectTypeCondition" 
     enablementValue="CatalogAlias" parentProperty="true" propertyName="objectGroups"/>
  </ServiceParam>
  <ServiceParam name="isTopCategoryFalse" optional="false" parameterName="isTopCategory" value="false">
    <EnablementCondition checkObjectDefinition="true" conditionId="objectTypeCondition" 
     enablementValue="CatalogAlias" negate="true" parentProperty="true" propertyName="objectGroups"/>
  </ServiceParam>
  <ServiceParam name="catalogId" optional="false" parentProperty="true" parentType="CatalogAlias" propertyName="catalogId"/>
  <ServiceParam name="catalogIdentifier" optional="true" parentProperty="true" parentType="CatalogAlias" propertyName="identifier"/>
</CreateService>
```

Instructions de modélisation des objets dépendants de la langue

Ces objets sont des objets métier contenant des informations traduisibles. Ces informations peuvent être traduites en plusieurs langues. Par exemple, les noms et descriptions de produits proposés en plusieurs langues sont des objets dépendants de la langue.

Modélisez les informations traduisibles avec des instances de la définition de classe ChildObjectDefinition pour laquelle l'attribut languageSensitive est défini sur true. Les définitions d'objet dépendant de la langue doivent définir idProperty à languageId. L'infrastructure du Management Center utilise la valeur de la propriété languageId pour déterminer la langue à charger.

Si un professionnel sélectionne plusieurs langues d'entrée dans la boîte de dialogue Sélectionner la langue de saisie, la structure du Management Center charge et crée comme requis des instances des objets dépendants de la langue.

Contrôle d'accès aux resources

Certains objets chargés par la structure du Management Center ne doivent pas être modifiés par les professionnels. Marquez ces objets comme étant en lecture seule an ajoutant readonly="true" à l'objet sérialisé. Par exemple, les promotions actives peuvent être visualisées, mais ne sont pas modifiables.

L'état lecture seule d'un objet enfant est hérité de son objet parent, mais peut être remplacé si l'état de lecture seule de l'objet enfant est différent de celui de son parent. Les objets principaux n'héritent pas de l'état de lecture seule des objets de référence qui les référencent.