Patrón de proceso de cambio de Documento de objeto de negocio

El patrón de proceso de cambio de Documento de objeto de negocio añade, cambia o suprime un objeto de negocio. Este patrón de proceso es parecido al patrón de cambio de SOI. En la implementación del patrón de cambio de SOI, las peticiones de cambio se correlacionan con mandatos de controlador de HCL Commerce existentes. El Documento de objeto de negocio de petición se convierte en parámetros de par nombre-valor que se pasan al mandato de controlador. Esto permite la reutilización como servicio de la lógica de negocio existente. Una limitación de esta implementación es que la petición de cambio de SOI solo puede tener una acción. Puesto que este patrón de diseño utiliza mandatos de proceso de BOD, se anula la limitación de una acción en la petición de cambio. La otra diferencia importante es que el patrón de cambio de BOD utiliza objetos de datos de servicio (SDO) para pasar datos, en lugar de parejas nombre-valor.

Para el patrón de proceso de petición de cambio, la lógica se divide en tres tipos de mandatos:
Mandato de controlador de cambio
Ayuda a dividir la petición en tareas más pequeñas y ejecuta dichas tareas. Estos mandatos de tarea más pequeños actuarán en partes del nombre en lugar de hacerlo en el nombre completo. El controlador también intenta recuperar los datos requeridos para la petición inicial y pasar esos datos a los otros mandatos de tarea, de forma que el mandato utilice y actualice elementos de datos comunes. Esto se hace para evitar la colisión de datos entre mandatos de tarea en los pueden actuar sobre los mismos datos, evitando la sobrecarga de rendimiento que se produce cuando cada tarea confirma los cambios de forma independiente. Cuando se han ejecutado todas las tareas, la lectura de datos inicial persiste, de forma que los cambios se confirman en la base de datos.
Mandatos de tarea Crear, Actualizar y eliminar de lógica de negocio
Estos mandatos realizan la acción adecuada en el nombre. Estas tareas solo tratan con una parte específica del nombre y se pasa la acción a realizar, la parte del nombre que ha cambiado y el nombre de la petición original junto con los datos que recuperó el controlador. El controlador puede tener muchas instancias de estos mandatos de tarea para actuar sobre las diversas partes de nombre que se están cambiando como parte del mensaje. El controlador es responsable de la ejecución de los distintos mandatos de tarea para realizar la operación de cambio completa. Las tareas de lógica de negocio únicamente necesitan comprender como han de tratar la parte de nombre específica que se está modificando.
Mandato PostChangeNounPart
Este mandato contiene cualquier lógica de negocio de requisito posterior que pueda ser el resultado de un cambio de esa parte del nombre. Estas tareas de lógica de negocio pueden no ser necesarias, pero hay casos en los que se necesita lógica de negocio como resultado del cambio de partes específicas de un objeto de negocio. Por ejemplo, se puede llamar a un mandato especial para evaluar la situación del inventario, cuando se han realizado cambios significativos en el inventario. El controlador de cambio creará instancias de estas tareas de negocio y las ejecutará después de realizar las acciones de cambio. A estas tareas se les pasan las acciones realizadas en la parte, el nombre de petición original y los datos recuperados por el controlador (que todavía no son persistentes). Estas tareas de lógica de negocio son opcionales y, por lo tanto, si no se encuentra ninguna implementación, el controlador de cambio supondrá que no se necesita ninguna lógica de negocio adicional.

Patrón de proceso Change de BOD

Los siguientes pasos describen el flujo detallado del patrón de proceso de cambio:

  1. El mandato de controlador Cambiar nombre divide el BOD y llama a read() para resolver los objetos raíz de los nombres que se deben cambiar. El objeto raíz es el registro primario del objeto de negocio.
  2. Se llama al método validate() para realizar las validaciones comunes que sean necesarias.
  3. Se realiza una comprobación de control de acceso para asegurarse de que el usuario actual tiene permiso para cambiar el nombre especificado.
  4. Se crea una instancia para los mandatos de tarea Cambiar parte del nombre y, para cada mandato, se ejecuta el método validate() para informar de los posibles errores que puedan producirse durante el proceso.
    1. El mandato Cambiar parte del nombre leerá la información necesaria y validará la entrada.
  5. El mandato de tarea Cambiar parte del nombre se ejecuta para realizar el cambio.
    1. Cambiar parte del nombre aplica los cambios.
    2. Cambiar parte del nombre guarda los cambios realizados en los objetos de datos recuperados en la instancia actual del mandato.
  6. Se crea una instancia del mandato PostChangeNounPart y se ejecuta.
    1. Se leen más datos en el método findObjects().
    2. Otros datos pueden cambiarse con el método applyChanges().
    3. Se guarda cualquier cambio con el método saveObject().
  7. Se llama a la operación de guardar para el objeto recuperado en el paso 1.
  8. La respuesta se crea y se devuelve.