Herramientas de usuario
ada:tips:sicoferp:general:pbtows:procesos:guiarapidacomponente
Diferencias
Muestra las diferencias entre dos versiones de la página.
| Ambos lados, revisión anterior Revisión previa Próxima revisión | Revisión previa | ||
|
ada:tips:sicoferp:general:pbtows:procesos:guiarapidacomponente [2019/08/12 18:42] administraidor |
ada:tips:sicoferp:general:pbtows:procesos:guiarapidacomponente [2019/09/24 16:58] (actual) administraidor [Modelo de implementación: Clases Modelo (Lógica del Negocio)] |
||
|---|---|---|---|
| Línea 29: | Línea 29: | ||
| ==== Modelo de implementación: Clase Lanzadora ==== | ==== Modelo de implementación: Clase Lanzadora ==== | ||
| - | El modelo debe implementar invocacion dinamica por eventos, por lo tanto la clase lanzadora debe invocar el evento factory_launch_event y recibe el nombre de la clase invocadora, el evento de invocación, parametros de configuración formato json, datos de invocación (solo si lo requiere el servicio y el método de autenticación de servicio. | + | El modelo debe implementar invocacion dinamica por eventos, por lo tanto la clase lanzadora debe invocar el evento **factory_launch_event** y recibe: |
| + | * Nombre de la clase invocadora | ||
| + | * Nombre del evento de invocación | ||
| + | * Parametros de configuración en formato json **as_config** | ||
| + | * Datos de invocación (solo si lo requiere el servicio) en formato json **as_data** | ||
| + | * Tipo de autenticación de servicio. | ||
| {{ :ada:tips:sicoferp:general:pbtows:procesos:imeplementacion_clase_lanzadora.png?800 |}} | {{ :ada:tips:sicoferp:general:pbtows:procesos:imeplementacion_clase_lanzadora.png?800 |}} | ||
| Línea 37: | Línea 42: | ||
| * el parametro as_data será requerido dependendiendo de la implementación de los procesos de la lógica del negocio por lo tanto no siempre es obligatorio. | * el parametro as_data será requerido dependendiendo de la implementación de los procesos de la lógica del negocio por lo tanto no siempre es obligatorio. | ||
| * la cadena de definición de la clase invocadora y el evento de invocacion deben ingresarse en minusculas. | * la cadena de definición de la clase invocadora y el evento de invocacion deben ingresarse en minusculas. | ||
| + | |||
| + | ==== Modelo de implementación: Clase Invocadora ==== | ||
| + | El modelo debe implementar en el evento invocado la inicialización del controlador principal y debe recibir los parametros inicializados para la ejecución de los procesos soportados. Los argumentos inicializados automaticamente son: | ||
| + | * iuo_json_config: Clase json que contiene los parametros de configuración del servicios EJ contiene el atributo token_session | ||
| + | * iuo_json_data: Clase json (opcional) que contiene los parametros asociados a la ejecución de los procesos soportados. | ||
| + | * iuo_msg: Clase que contiene los mensajes del sistema. | ||
| + | * its_db: Clase que contiene la conexión de la base de datos del cliente. | ||
| + | * SQLCA: conexión genérica a la base de datos de configuración. | ||
| + | |||
| + | De igual forma debe asegurar que el resultado del proceso debe ser devuelto en un objeto tipo **n_cst_return** para luego convertirlo en una cadena en formato json que debe ser asignada a la variable **is_return** para cual es la que siempre se devuelve en la [[ada:tips:sicoferp:general:pbtows:framework:arquitectura:backend#4.4.2 Resolución y Orquestación de Servicios|Resolución y Orquestación de Servicios]]. | ||
| + | |||
| + | A continuación se visualiza la imagen de la implementación del Componente Login. | ||
| + | |||
| + | {{ :ada:tips:sicoferp:general:pbtows:procesos:implementacion_clase_invocadora.png?800 |}} | ||
| + | |||
| + | === Consideraciones === | ||
| + | * En lo posible evite el uso de variables de instancia en los controladores. | ||
| + | * No utilizar la variable SQLCA para realizar transacciones. | ||
| + | * No implementar lógica de negocio en las clases n_cst_service | ||
| + | |||
| + | ==== Modelo de implementación: Clase Controladora ==== | ||
| + | El modelo debe implementar un método en el controlador que permita la inicialización de la clase modelo que contiene la lógica del negocio del proceso. Ademas debe validar los argumentos de entrada y las reglas que puedan aplicar a la ejecución del proceso. | ||
| + | |||
| + | {{ :ada:tips:sicoferp:general:pbtows:procesos:implementacion_clase_controladora.png?800 |}} | ||
| + | |||
| + | === Consideraciones === | ||
| + | * El método del controlador debe recibir todos los argumentos que requiera el proceso. | ||
| + | * Los argumentos del proceso que se envien a la clase modelo deben ser encapsulados en una clase json. | ||
| + | * Los controladores no deben procesar el objeto de retorno. | ||
| + | * Los controladores pueden modificar los parametros de ejecución de los procesos. | ||
| + | * En la mayoria de los casos se deben inicializar las variables de transacción y mensaje. | ||
| + | |||
| + | ==== Modelo de implementación: Clases Modelo (Lógica del Negocio) ==== | ||
| + | Estas clases contienen el código Powerbuilder de los procesos del ERP. | ||
| + | |||
| + | === Consideraciones === | ||
| + | * Evite en lo posible el uso de clases del framework relacionadas la arquitectura ejemplo: **n_cst_controller**, **n_cst_service**, **n_cst_factory**, **n_cst_core** en su defecto se ha implementado la clase **n_cst_param_utility** para proveer funcionalidades de esas capas. | ||
| + | * Extienda la clase modelo **n_cst_model** directamente. | ||
| + | * Asegurese que el retorno de los procesos **n_cst_return** tiene toda la información necesaria para la respuesta, no realice implementaciones parciales entre capas. | ||
ada/tips/sicoferp/general/pbtows/procesos/guiarapidacomponente.1565635375.txt.gz · Última modificación: 2019/08/12 18:42 por administraidor
Herramientas de la página
