Este capitulo contiene información relacionada con el proceso de creación de componentes 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 que serán expuestos en servicios SOAP Powerbuilder. Tener presente que sólo se explicara el proceso de implementación de la arquitectura y se excluirán los demás procesos asociados a la creación. Para más información favor consultar los pasos del Check List Component

El primer paso consiste en definir la estructura del repositorio del componente. La información relacionada oncesta actividad puede ser consultada en el siguiente link Crear Componente

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 las clases base de operación del componente las cuales deben ser extendidas (heredadas) del paquete de 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 las clases base (tener presente el numero asociado a cada clase para identificar el tipo)

1. Clase Lanzadora: Es generada automáticamente al crear el proyecto en ella se registran los metodos que serán expuestos en el servicio.
2. 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.
3. Clase Controladora: Este tipo de clases realizan validaciones, provven metodos de utilidades e invocan las clases de la lógica del negocio.
4. Clase de Logica del Negocio: Contiene el código powerbuilder de los procesos del ERP.

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

• Los parametros de entrada y salida son string en formato json.
• 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.

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 Resolución y Orquestación de Servicios.

A continuación se visualiza la imagen de la implementación del Componente Login.

• 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

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.

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

Estas clases contienen el código Powerbuilder de los procesos del ERP.

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