Este capitulo contiene información relacionada con el proceso de creación de componentes proxy aplicando la 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 Check List Component

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).

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 Crear Componente Proxy, además el componente debe estar previamente configurado en el catalogo de configuración de componentes.

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

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.

A continuación se visualiza una imagen de ejemplo con la implementación de la clase de operación

1. 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.

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.

Este caso expone la forma adecuada de creación de clases de operación de proxy para procesos del ERP.

El modelo debe implementar un método wrapper¹⁾ que permita:

1. 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.
2. 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.
3. 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.

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.

• No implementar lógica de negocio en las clases n_cst_proxy

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.

• No implementar lógica de negocio en las clases n_cst_proxy

Este caso expone la forma adecuada de creación de clases de operación de proxy para procesos CRUD (simples) del ERP.

El modelo debe implementar los siguientes métodos wrapper²⁾:

• 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:

1. 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.
2. 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.

• No implementar lógica de negocio en las clases n_cst_proxy

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.

• No implementar lógica de negocio en las clases n_cst_proxy