Prácticas recomendadas de personalización y directrices de modelado del Management Center

Para personalizar el Management Center, puede cambiar algunos archivos facilitados por HCL Commerce y crear sus propios archivos de configuración personalizados con el objeto de definir los objetos personalizados o las características de la tienda. Antes de empezar a personalizar el Management Center, considere cómo los arreglos de mantenimiento o las actualizaciones en HCL Commerce pueden afectar a los objetos personalizados y los cambios. Si Siguiendo el método de personalización correcto, se puede asegurar de que los arreglos y las actualizaciones no se graben encima de las personalizaciones cuando instale un arreglo de mantenimiento o actualice a un release posterior.

Mejores prácticas

Asegúrese de que la personalización planificada sigue estas recomendaciones:
  • Utilice únicamente las clases del Management Center que se documentan cuando vaya a personalizar el Management Center. No utilice las clases que están marcadas como privadas y no cambie los archivos restringidos.
  • Utilice siempre HCL Commerce Developer para el desarrollo. Este entorno de desarrollo está diseñado para facilitar la personalización y la migración futura. Las aplicaciones que se desarrollan utilizando otras herramientas no pueden mantenerse o migrarse adecuadamente.
  • Utilice siempre puntos de extensión designados. Las clases del Management Center incluyen estos puntos de extensión.
  • Siga siempre el procedimiento de despliegue recomendado. Para obtener más información, consulte Empaquetado del código personalizado para el despliegue.
  • Cuando personaliza el Management Center, puede cambiar directamente uno cualquiera de los archivos siguientes que se proporcionan con HCL Commerce:
    • Todos los archivos XML de definición que están en el directorio WCDE_installdir\LOBTools\WebContent\WEB-INF\src\xml. No añada ni modifique los archivos dentro de un directorio restringido.
    • El archivo spring-extension.xml se encuentra en el directorio WCDE_installdir\LOBTools\WebContent\WEB-INF.
    Para los archivos restringidos que no va a cambiar, puede crear versiones personalizadas de cualquiera de los archivos dentro de sus propios directorios personalizados. En tiempo de ejecución, los archivos personalizados se fusionan con los archivos proporcionados en HCL Commerce. Las configuraciones o definiciones en los archivos personalizados tienen prioridad.
  • Mantenga una estructura de directorios que sea coherente si tiene la intención de migrar a un release posterior o si precisa de ayuda del centro de soporte de IBM con las personalizaciones. Cuando añada archivos a la infraestructura del Management Center, respete la misma estructura de directorios que los archivos predeterminados que se han facilitado, con las excepciones siguientes:
    • Utilice su propio nombre de empresa para el directorio commerce en la estructura de directorio. Por ejemplo, en lugar de utilizar la estructura de directoriosworkspace_dir\LOBTools\WebContent\WEB-INF\src\xml\commerce\component, utilice workspace_dir\LOBTools\WebContent\WEB-INF\src\xml\mycompany\component
    • No necesita un directorio restricted en la estructura del directorio mycompany. Los directorios restringidos que están en el directorio commerce indican directorios que se sustituyen cuando instala arreglos de HCL Commerce o cuando migra a un release posterior.
      Nota: Si utiliza un sistema de gestión de control de origen para almacenar archivos, no compruebe los archivos que están en los directorios restringidos en el sistema de gestión de control de origen.
Consejo: Para ayudar a comprender mejor cómo se personaliza el Management Center, siga las guías de aprendizaje de personalización del Management Center. Estas guías de aprendizaje proporcionan ejemplos de escenarios de personalización para personalizar la infraestructura del Management Center. Para obtener más información, consulte Management Center Guías de aprendizaje para la personalización de.

Directrices de modelado de los archivos de definición

Los archivos de definición del Management Center se pueden restringir o personalizar.
Archivos restringidos
Los archivos restringidos incluyen definiciones de clases para las funciones básicas que son comunes a todas las herramientas del Management Center. Estos archivos restringidos pueden sustituirse cuando instale arreglos de mantenimiento o realice actualizaciones en HCL Commerce, por lo tanto, no los cambie.
Archivos personalizables
Los archivos personalizables describen los objetos que se gestionan en una herramienta del Management Center y definen cómo se visualizan dichos objetos. Cuando instale arreglos de mantenimiento o realice actualizaciones en HCL Commerce, los archivos de personalización se mantienen. Puede utilizar, ampliar o cambiar las clases que hay en los archivos personalizables cuando vaya a personalizar el Management Center. Cuando trabaje con los archivos personalizables, siga estas directrices:
Notes:
  • Separe claramente el código del código de IBM de base. Si crea nuevas clases, colóquelas en su propio archivo para evitar complicar el proceso de migración.
  • No mueva instancias de una clase, desde una clase padre hasta otra. Se considera que cambiar la clase padre de una clase es añadir y eliminar un padre. No hay ningún método que asocie las dos operaciones. Se considera que las instancias de una clase debajo del nuevo padre son elementos personalizados y no se actualizan cuando se aplica el mantenimiento o se actualiza HCL Commerce.
  • No suprima el código de IBM. Las clases en las definiciones de búsqueda y las definiciones de objeto no afectan a nada si no se invocan. Cuando se aplican arreglos de mantenimiento o actualizaciones en HCL Commerce, puede recibir automáticamente las clases actualizadas. Puede impedir que la mayoría de los widgets del Management Center se visualicen en la interfaz de usuario cuando un widget no es necesario cambiando el distintivo de visibilidad para el widget en false.
  • Si un archivo de definición no incluye los elementos siguientes, evite introducir los elementos en el archivo. Añadiendo estos elementos al archivo, puede encontrarse con problemas cuando aplique el mantenimiento o actualice HCL Commerce.
    • <method>
    • <handler>
Nota: Si añade o cambia archivos de definición en el directorio workspace_dir\LOBTools\WebContent\WEB-INF\src\xml, no es necesario que reinicie el servidor de HCL Commerce. Las nuevas definiciones las detecta automáticamente el servlet del módulo de AMD comprobando los últimos datos modificados de los archivos de definición. No es necesario reiniciar el Centro de gestión cerrando la ventana del navegador del Centro de gestión y borrando la memoria caché del navegador.
Puede utilizar vías de acceso en las definiciones para dar instrucciones a la infraestructura del Management Center de que busque por los objetos hijo de un objeto seleccionado para localizar un objeto que se va a utilizar. Una vía de acceso de objeto es una lista de tipos de objeto que están separados por una barra inclinada diagonal "/". La infraestructura busca reiteradamente los objetos hijo que coinciden con los tipos de objeto especificados. Como ejemplo, el objeto de vía de acceso objectPath="CatentryDescription" hace que el Management Center busque en el objeto actual un objeto hijo con un tipo de objeto que coincide con "CatentryDescription". Cualquiera de los tipos de objeto en una vía de acceso de objeto se puede sustituir por un grupo de objetos. Por ejemplo, si un grupo de objetos Catentryse ha definido para incluir los tipos de objeto Product, Bundle, Kit o SKU, la vía de acceso de objeto de Catentry hace coincidir los objetos con el tipo de objeto Product, Bundle, Kit o SKU. Los tipos de objeto en una vía de acceso de objeto se pueden calificar con un nombre de propiedad y valor utilizando una sintaxis similar a Xpath, como [prop=value]. Las siguientes clases del Management Center aceptan las siguientes vías de acceso de objeto:
  • 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

Directrices de modelado del editor de objetos de negocio

El Editor de objetos de negocio, clase cmc/foundation/BusinessObjectEditor es la clase base para todas las herramientas del Management Center. El Editor de objetos de negocio incluye soporte para el menú, la barra de herramientas, el widget de búsqueda, la vista de explorador y vista de programas de utilidades del Management Center. Este editor es responsable de gestionar todas las interacciones de usuario que permiten al usuario editar los objetos de negocio que están declarados con el editor. No cree instancias de esta clase directamente. Registre instancias de esta clase añadiendo una instancia de "cmc/foundation/ApplicationMenu" a "cmc/foundation/ApplicationMenuItems".

Crear una instancia de la clase Editor de objetos de negocio implica principalmente declarar los objetos que deben crearse (es decir, crearse, cambiarse o eliminarse). Para garantizar que el editor de objetos de negocio pueda consumir definiciones de objeto y proporcionar una herramienta de autoría eficaz para diferentes dominios de objetos, los objetos deben declararse de forma coherente. Para crear un modelo de objeto de negocio que el editor de objetos de negocio pueda consumir satisfactoriamente, siga estas directrices:
  • Incluya una definición de objeto superior dentro de la declaración del editor de objetos de negocio. La definición de objeto superior describe el objeto raíz del árbol de explorador. El objeto superior es un objeto organizativo del lado del cliente no devuelto por una llamada de servicio. El objeto superior no es visible, pero los hijos se visualizan como nodos del árbol de nivel superior debajo del nodo Trabajo activo. Cuando se crea una instancia del objeto superior, se crean los objetos hijo que se declaran como parte de la plantilla de definición de objeto. Además, las instancias declaradas de la clase GetChildrenService se invocan para recuperar más objetos hijo del servidor de HCL Commerce.
  • Si se necesitan uno o más nodos del árbol de explorador de nivel superior como elementos organizativos, deben declararse como definiciones de objetos organizativos. Solamente se pueden instanciar como elementos de la declaración de plantilla de otra definición de objeto.
  • Todos los tipos de objeto de negocio que se pueden crear, actualizar o eliminar deben declarase como definiciones de objeto primario o bien como definiciones de objeto hijo de una definición de objeto primaria.
  • Si solamente existe un objeto de negocio en el contexto de otro objeto, y no se puede referenciar ni buscar sin buscar el objeto padre, ese tipo de objeto debe declararse como una definición de objeto hijo en una definición de objeto primario o en otra definición de objeto hijo.
  • Los objetos de negocio primarios no deben tener otro objeto de negocio primario como hijo directo. Es necesario un objeto intermedio, que se denomina objeto de referencia para describir la naturaleza de la relación entre los dos objetos primarios. Este tipo de objeto intermedio debe declararse como definición de objeto de referencia.
  • Todos los objetos de negocio están constituidos por una lista de propiedades simples con denominación exclusiva. Si un objeto contiene una lista variable de propiedades hijo similares, dicha propiedad debe modelarse como un tipo de objeto hijo separado.
  • Un objeto de negocio debe ser identificable de forma exclusiva mediante el valor de una de las propiedades (identificada como la propiedad de ID). Sólo se requiere que el valor de ID de los objetos descritos por las definiciones de objeto hijo o las definiciones de objeto de referencia sean exclusivos dentro del conjunto de objetos que tienen el mismo padre. Los objetos primarios del mismo tipo deben tener todos un valor de ID exclusivo.
  • Todos los objetos primarios deben tener un identificador de visualización como el valor de una de las propiedades del objeto (identificada como la propiedad de nombre de visualización). Cualquier definición de objeto puede declarar una displayNameProperty, pero sólo se precisa para objetos primarios. Este nombre de visualización se utiliza como texto en un widget de interfaz de usuario que representa una instancia de objeto. Si bien es preferible, no hay ningún requisito para que este valor sea exclusivo. Evite propiedades traducibles cuando seleccione la propiedad del nombre de visualización.
  • Si dos objetos de negocio requieren declaraciones de vista de propiedades diferentes, deben modelarse como dos tipos de objeto separados. Los productos y códigos de artículo deben modelarse como tipos de objeto diferentes, no como un tipo de objeto único para entradas de catálogo.

Directrices de modelado de la tienda de sitio ampliado

Si la tienda utiliza tiendas de sitios ampliados, asegúrese de que la herramienta se haya diseñado para dar soporte a los sitios ampliados, siguiendo estas directrices:
  • Los objetos con una herramienta habilitada para sitios ampliados pueden ser locales o heredados. Un objeto local es un objeto que es propiedad del almacén seleccionado actualmente y un objeto heredado es un objeto que es propiedad de una tienda con elementos referenciados. Para distinguir entre objetos locales y heredados del Management Center precisa de dos definiciones de objeto: una para el objeto local y una para el objeto heredado. Puesto que los objetos de negocio principales locales y los objetos de negocio primarios heredados se modelan como dos definiciones de objeto separados en el almacén de sitios ampliados, debe duplicar todas las definiciones de objetos que se heredan de la tienda con elementos.
  • Si va a crear una definición de objeto base para crear un ancestro común para todos los tipos de objeto, establezca las definiciones de objeto base y heredado en createable="false" para que la interfaz de usuario le impida crear objetos de ese tipo.
  • Si va a modelar definiciones de objeto para objetos de sitios ampliados que se gestionan con una herramienta del Management Center, siga estas directrices:
    • Mueva todas las definiciones de objeto que dependen de la tienda a una definición base y nombre el objecType baseABC. Para determinar si una propiedad depende de la tienda, considere si es necesario sustituirla a nivel del sitio ampliado. Por ejemplo, actualmente, las descripciones de producto son independientes de la tienda, lo que significa que cada tienda que dispone de acceso a un producto ve la misma descripción de producto. Puede personalizar HCL Commerce para que la descripción del producto dependa de la tienda, moviendo la definición de objeto para la descripción del producto a la definición base.
      Nota: El esquema subyacente también debe dar soporte a las propiedades que dependen de la tienda. Por ejemplo, puesto que la tabla de base de datos actual que almacena asociaciones de comercialización (MASSOCCECE) incluye una columna para el ID de tienda, los productos pueden tener asociaciones de comercialización diferentes en tiendas diferentes. También puede hacer un seguimiento de una asociación de comercialización específica de la tienda para un producto.
    • Duplique todas las definiciones de objeto de negocio de referencia para las referencias que dependen de la tienda y márquelas claramente como objetos heredados. Nombre el objectType de las definiciones de objeto de referencia heredado para indicar que se heredan. A la hora de crear este tipo de objeto, determine si la propia referencia necesita depender de la tienda.

      Por ejemplo, una asociación de comercialización es un objeto de negocio de referencia que crea una referencia entre un producto de origen y un producto de destino. Si tanto el producto de origen como el producto de destino proceden de una tienda con elementos, es necesario determinar si el usuario necesita crear una asociación de comercialización en la tienda con elementos o en un sitio ampliado que se hereda de dicha tienda con elementos. En el primer caso, todos los sitios ampliados que se heredan de la tienda con elementos tienen la asociación de comercialización. En el segundo caso, sólo el sitio ampliado en el que se ha creado la asociación de comercialización tiene la asociación de comercialización. Para dar soporte a ambos escenarios, el objeto de negocio de referencia de la asociación de comercialización debe depender de la tienda.

    • Establezca compatibleObjectTypes en el objectType del objeto de negocio de la tienda del sitio ampliado. Cuando se copia el objeto, el objeto creado recientemente se marca como un objeto de negocio de la tienda del sitio ampliado a diferencia de un objeto de negocio heredado.
      <!-- This definition represents the primary object definition describing an Inherited Kit as a business object. -->
<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"/>
    • Añada un elemento de condición de habilitación falso como hijo de los objetos de negocio primarios heredados. 
      
<!--- Condition to disable the object creation in certain store types. -->
<EnablementOrCondition baseDefinition="cmc/catalog/StoreTypeCatalogObjectCreationRestriction"/>

      Normalmente, los objetos heredados no se pueden crear mediante la infraestructura. Sin embargo, hay dos excepciones. Se pueden crear asociaciones y precios de comercialización heredados en el sitio ampliado, pero ambos son objetos de referencia y no objetos primarios. Los objetos primarios heredados nunca se crean en el sitio ampliado. Además, los objetos heredados no pueden presentar condiciones de habilitación, mientras que los objetos locales sí. Defina una condición de habilitación con la lista de storeTypes donde se permite la creación de estos objetos. Utilice este atributo para los objetos de negocio primario en los sitios ampliados que necesiten impedir que se creen y copien objetos por el tipo de tienda.

    • Actualice la página JSP de respuesta para devolver el ID de tienda de objetos si ha creado su propio objeto heredado y desea que los usuarios puedan crearlo a nivel de tienda cuando estén conectados a una tienda de sitios ampliados.

      Cuando se invoca el servicio de creación, la interfaz de usuario del Centro de gestión invoca una solicitud de creación y la página JSP de respuesta apropiada crea la respuesta para la solicitud. Esta respuesta contiene la información que está relacionada con el resultado de la solicitud, incluida cualquier información cambiada que el Centro de gestión requiera como resultado de la solicitud. Cuando el objeto se hereda de la tienda con elementos, debe añadir la línea siguiente al JSP de respuesta para devolver el objectStoreId: <objectStoreId>.{param.storeID}</objectStoreId>

    • Declare el servicio de creación únicamente en la definición de objeto local para impedir que el objeto heredado se cree. 
      
<!--- Create service to create a new category. -->
<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>

Directrices de modelado de objetos sensibles al idioma

Los objetos sensibles al idioma son objetos de negocio que contienen información traducible. La información traducible es información que se puede traducir a varios idiomas. Por ejemplo, nombres y descripciones de productos que se ofrecen en varios idiomas son objetos sensibles al idioma.

Modele la información traducible con instancias de la definición de clase ChildObjectDefinition que el atributo el atributo languageSensitive ha establecido en true. Las definiciones de objetos sensibles al idioma deben establecer el atributo idProperty en languageId. La infraestructura del Management Center utiliza el valor de la propiedad languageId para determinar qué idioma debe cargarse.

Si un usuario de empresa selecciona varios idiomas en el diálogo Seleccionar idioma de entrada, la infraestructura del Management Center carga y crea instancias de los objetos sensibles al idioma, según crea necesario.

Control de acceso de recursos

Algunos objetos que son cargados por la infraestructura del Management Center no deben ser editados por un usuario de empresa. Marque estos objetos como de sólo lectura añadiendo readonly="true" al objeto serializado. Por ejemplo, los usuarios de empresa pueden ver las promociones activas, pero no las pueden cambiar.

El estado de sólo lectura de un objeto hijo se hereda de su objeto padre, pero se puede alterar temporalmente esa herencia si el objeto hijo tiene un estado de sólo lectura diferente del padre. Los objetos primarios no heredan el estado de sólo lectura de los objetos de referencia que los referencian.