Diferencias

Muestra las diferencias entre dos versiones de la página.

--- ada:tips:sicoferp:general:pbtows:procesos:guiarapidacomponenteproxy [2019/09/02 20:28]
172.16.200.205 creado
+++ ada:tips:sicoferp:general:pbtows:procesos:guiarapidacomponenteproxy [2019/09/02 21:54] (actual)
172.16.200.205
@@ Línea 1: / Línea 1: @@
 ====== PBtoWS - Procesos: Guía Rápida de implementación del Componente Proxy Backend ======
 Este capitulo contiene información relacionada con el proceso de creación de componentes proxy aplicando la [[ada:tips:sicoferp:general:pbtows:framework:arquitectura:backend|arquitectura]] propuesta en el desarrollo backend. El objetivo de esta sección es centrar al desarrollador en los aspectos fundamentales que debe tener presente al crear componentes Proxies que serán utilizados en los consumos internos de servicios SOAP Powerbuilder. Tener presente que sólo se explicará el proceso de implementación y se excluirán los demás procesos asociados a la utilización. Para más información favor consultar los pasos del [[ada:tips:sicoferp:general:pbtows:procesos:checklistcomponet|Check List Component]]
+===== Paso 0: Tipos de Componente Proxy =====
+Antes de iniciar el proceso de creación de la clase de consumo se debe identificar el tipo de proxy el cual puede ser de 2 Tipos:
+  * **ComponentProcessProxy** - Componente de Proceso Estandard: Este tipo de proxy se debe implementar para el consumo de servicios que representan procesos estandares del ERP.
+  * **ComponenteCrudProxy** - Componente de Proceso Crud: Este tipo de proxy se debe implementar para el consumo de servicios CRUD (simples).
 ===== Paso 1: Creación del Proyecto del Componente Proxy =====
-El primer paso consiste en crear el proyecto del componente Proxy. La información relacionada de esta actividad puede ser consultada en el siguiente link [[ada:tips:sicoferp:general:pbtows:procesos:createproxy|Crear Componente Proxy]]
+El primer paso consiste en crear el proyecto del componente Proxy. La información relacionada de esta actividad puede ser consultada en el siguiente link [[ada:tips:sicoferp:general:pbtows:procesos:createproxy|Crear Componente Proxy]], además el componente debe estar previamente configurado en el catalogo de configuración de componentes.
-===== Paso 2: Establecer la Clase Transacción Proyecto =====
+===== Paso 2: Crear la Clase del Componente Proxy =====
-Una vez creada la estructura del componente el siguiente paso consiste en redefinir la clase que mapeará las conexiones de la base de datos. Esto es necesario ya que la transacción desempeña un papel fundamental para el procesameinto de la información. La clase encargada de ese proceso es **n_cst_transaction** y está en la libreria **sf00core_object.pbl**. Ubiquese en el objeto **application** del proyecto y presione el botono **Additional Properties** para desplegar la ventana de propiedades adicionales del proyecto luego seleccione la pestaña **Variable Types** y en el campo **SQLCA** cambie el valor **transaction** por **n_cst_transaction** aplique los cambios y presione el botono **Ok**. De esta forma ya quedará definida la clase transaction del componente.
+El siguiente paso consiste en definir la clase de operación del componente proxy de la sigueinte forma:
+  * Extender la clase **n_cst_proxy** para crear la clase de operación del componente proxy
-===== Paso 3: Crear las Clases Base del Componente =====
+**Nota:** Tener presente que la clase de operación debe agregarse a la libreria **sf[código de la aplicación]proxy_(nombre componente).pbl**.
-El siguiente paso consiste en definir las clases base de operación del componente las cuales deben ser extendidas (heredadas) del paquete de [[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]] de la sigueinte forma:
-  * Extender la clase **n_cst_service** para crear la clase de invocación de servicios
-  * Extender la clase **n_cst_controller_process** para crear los controladores que serán utilizados por las clases invocadoras **n_cst_service**
-  * Extener la clase **n_cst_model** para implementar la logico del negocio del componente, es decir en estas clases se generará el código fuente.
-**Nota:** Tener presente que las clases invocadoras y controladoras deben agregarse a la libreria sf(XX)controller_(xxxxxxxx).pbl y las clases del modelo ó lógica del negocio debben ser agregadas a la libreria sf(XX)model_(xxxxxxxx).pbl.
+A continuación se visualiza una imagen de ejemplo con la implementación de la clase de operación
+{{ :ada:tips:sicoferp:general:pbtows:procesos:01001guiarapidaproxy.png?800 |}}
-A continuación se visualiza una imagen de ejemplo con la implementación de las clases base (tener presente el numero asociado a cada clase para identificar el tipo)
+  - **Clase de Operación**: Es la encarga de exponer el consumo del servicio web en funciones accesibles en el modelo de invocación de componentes. Se debe tener presente que estas clases en ningun escenario deben implementar lógica del negocio solo deben servir de intefaz de comunicación del consumo y respuesta de los servicios.
-{{ :ada:tips:sicoferp:general:pbtows:procesos:ejemplo_clases.png?400 |}}
+===== Paso 3: Modelo de implementación de invocación por capas =====
+A continuación se explica con ejemplos en imagenes el modelo de implementación de invocación por las capas del framework aplicando la arquitectura propuesta. Se toman 2 casos en los cuales se pueden implementar Proxies.
-  - **Clase Lanzadora**: Es generada automáticamente al crear el proyecto en ella se registran los metodos que serán expuestos en el servicio.
+==== Paso 3a: Caso ComponentProcessProxy (Ejemplo Componente Fórmulas Liquidación Nómina) ====
-  - **Clase Invocadora**: Es la clase que va a ser invocada por la Clase Lanzadora, crea los controladores y lanza los métodos que inician los procesos.
+Este caso expone la forma adecuada de creación de clases de operación de proxy para procesos del ERP.
-  - **Clase Controladora**: Este tipo de clases realizan validaciones, provven metodos de utilidades e invocan las clases de la lógica del negocio.
-  - **Clase de Logica del Negocio**: Contiene el código powerbuilder de los procesos del ERP.
-===== Paso 4: Modelo de implementación de invocación por capas =====
+=== Modelo de implementación: Método Wrapper ===
-A continuación se explica con ejemplos en imagenes el modelo de implementación de invocación por las capas del framework aplicando la arquitectura propuesta. El componente de referencia es el login.
+El modelo debe implementar un método wrapper((http://consejostallerdeprogramacion.blogspot.com/2015/11/que-es-wrapper-y-donde-lo-utilizamos.html)) que permita:
+  - Inicializar el Componente de consumo del Proxy (Previamente debe estar configurado en el catalogo de componentes. El método **of_init_component** recibe el nombre del componente y la referencia del objeto de mensajes.
+  - Crear el json que contiene los parámetros que recibe el servicio el cuál en la mayoría de los casos debe recibir la cadena json del consumo actual **as_config** y una cadena en formato json que especifica los datos que requiere el consumo del proxy.
+  - Por último debe consumir la interface **of_consume_ws** donde siempre se debe enviar el método wrapper actual y el json con los parametros de consumo del servicio.
-==== Modelo de implementación: Clase Lanzadora ====
+De igual forma debe asegurar que el resultado del proceso debe ser devuelto en un objeto tipo **n_cst_return**
-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 |}}
+A continuación se visualiza la imagen de la implementación del Componente Fórmula Liquidación.
+{{ :ada:tips:sicoferp:general:pbtows:procesos:01001guiarapidaproxy.png?800 |}}
 === Consideraciones ===
-  * Los parametros de entrada y salida son string en formato json.
+  * No implementar lógica de negocio en las clases n_cst_proxy
-  * 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.
-==== Modelo de implementación: Clase Invocadora ====
+=== Modelo de implementación: Método of_interface_consume_ws ===
-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:
+En este método se debe implementar la lógica de consumo de las operaciones expuestas por el servicio. Se deben seguir los siguientes pasos:
-  * 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]].
+  * Definir el objeto proxy del componente el cual contiene los métodos expuestos por el servicio por lo general el nombre es generado automaticamente y está definido de la siguiente forma **n_ws[código de la aplicación]_[nombre del componente]soap** Ejemplo: n_ws05_formula_liquidacionsoap
+  * Inicializar el objeto proxy consumiendo el método **of_create_instance()**
+  * Crear un Choose Case donde se puedan identifcar las interfaces de operación del servicio las cuales estan definidas en los métodos Wrapper creados. Cada opción del case debe consumir un método del proxy y debe devolver el resultado en una variable de tipo String
+  * Se debe encapsular el resultado y devolver en un tipo **n_cst_json** para que sea procesado en las capas de implementación posteriores.
-A continuación se visualiza la imagen de la implementación del Componente Login.
+De igual forma debe asegurar que el resultado del proceso debe ser devuelto en un objeto tipo **n_cst_json**
-{{ :ada:tips:sicoferp:general:pbtows:procesos:implementacion_clase_invocadora.png?800 |}}
+A continuación se visualiza la imagen de la implementación del Componente Fórmula Liquidación.
+{{ :ada:tips:sicoferp:general:pbtows:procesos:01002guiarapidaproxy.png?800 |}}
 === Consideraciones ===
-  * En lo posible evite el uso de variables de instancia en los controladores.
+  * No implementar lógica de negocio en las clases n_cst_proxy
-  * 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 ====
+==== Paso 3b: Caso ComponentCrudProxy (Ejemplo Componente CRUD: Tipo Identificación) ====
-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.
+Este caso expone la forma adecuada de creación de clases de operación de proxy para procesos CRUD (simples) del ERP.
-{{ :ada:tips:sicoferp:general:pbtows:procesos:implementacion_clase_controladora.png?800 |}}
+=== Modelo de implementación: Métodos Wrapper con las Operaciones Soportadas por el CRUD ===
+El modelo debe implementar los siguientes métodos wrapper((http://consejostallerdeprogramacion.blogspot.com/2015/11/que-es-wrapper-y-donde-lo-utilizamos.html)):
+  * **of_get_ws_crud_read_only_one**: Para operaciones de consulta de un solo registro
+  * **of_get_ws_crud_read**: Para operaciones de listado de registro
+  * **of_get_ws_crud_create**: Para operaciones de inserción
+  * **of_get_ws_crud_update**: Para operaciones de Actualización
+  * **of_get_ws_crud_delete**(No Implementado): Para operaciones de eliminación
+Estas funciones no pueden ser consumidas directamente por las implementaciones de operación de la clase proxy ya que son métodos protegidos por definición, por lo tanto deben encapsularse en métodos publicos para ser accedidos por la logica del negocio que lo requiera. Por estandarización los métodos deben ser encapsulados en los siguiente métodos públicos:
+  * **of_get_ws_crud_read_only_one** -> **of_crud_consultar**
+  * **of_get_ws_crud_read** -> **of_crud_listar**
+  * **of_get_ws_crud_create** -> **of_crud_insertar**
+  * **of_get_ws_crud_update** -> **of_crud_actualizar**
+  * **of_get_ws_crud_delete**(No Implementado) -> **of_crud_eliminar**
+Estos métodos debe que permitir:
+  - Inicializar el Componente de consumo del Proxy (Previamente debe estar configurado en el catalogo de componentes. El método **of_init_component** recibe el nombre del componente y la referencia del objeto de mensajes.
+  - Por último debe consumir la interface que corresponda a la operación del wrapper actual siempre se debe enviar el json con los parametros de consumo del servicio (No se debe enviar el config en el json) y el objeto de mensajes .
+De igual forma debe asegurar que el resultado del proceso debe ser devuelto en un objeto tipo **n_cst_return**
+A continuación se visualiza la imagen de la implementación del Componente Fórmula Liquidación.
+{{ :ada:tips:sicoferp:general:pbtows:procesos:02001guiarapidaproxy.png?800 |}}
+{{ :ada:tips:sicoferp:general:pbtows:procesos:02002guiarapidaproxy.png?800 |}}
+{{ :ada:tips:sicoferp:general:pbtows:procesos:02003guiarapidaproxy.png?800 |}}
+{{ :ada:tips:sicoferp:general:pbtows:procesos:02004guiarapidaproxy.png?800 |}}
+{{ :ada:tips:sicoferp:general:pbtows:procesos:02005guiarapidaproxy.png?800 |}}
 === Consideraciones ===
-  * El método del controlador debe recibir todos los argumentos que requiera el proceso.
+  * No implementar lógica de negocio en las clases n_cst_proxy
-  * 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) ====
+=== Modelo de implementación: Método of_interface_consume_ws ===
-Estas clases contienen el código Powerbuilder de los procesos del ERP.
+En este método se debe implementar la lógica de consumo de las operaciones expuestas por el servicio. Se deben seguir los siguientes pasos:
+  * Definir el objeto proxy del componente el cual contiene los métodos expuestos por el servicio por lo general el nombre es generado automaticamente y está definido de la siguiente forma **n_ws[código de la aplicación]_[nombre del componente]soap** Ejemplo: n_ws05_formula_liquidacionsoap
+  * Inicializar el objeto proxy consumiendo el método **of_create_instance()**
+  * Crear un Choose Case donde se puedan identifcar las interfaces de operación del servicio las cuales estan definidas en los métodos Wrapper creados. Cada opción del case debe consumir un método del proxy y debe devolver el resultado en una variable de tipo String
+  * Se debe encapsular el resultado y devolver en un tipo **n_cst_json** para que sea procesado en las capas de implementación posteriores.
+De igual forma debe asegurar que el resultado del proceso debe ser devuelto en un objeto tipo **n_cst_json**
+A continuación se visualiza la imagen de la implementación del Componente Fórmula Liquidación.
+{{ :ada:tips:sicoferp:general:pbtows:procesos:02006guiarapidaproxy.png?800 |}}
 === 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**
+  * No implementar lógica de negocio en las clases n_cst_proxy
-  * Extienda las clases modelo deacuerdo al módulo de componente Ejemplo **n_cst_model_nomina** para los componentes del módulo de Nómina. No extienda de la clase **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.

Wiki

Herramientas de usuario

Herramientas del sitio

Diferencias

Herramientas de la página