APX
SESSION II
INDICE Intr trod oduc ucci ción ón Ar Arqu quit itec ectu tura ra On Onliline ne 01 In 1.1 Revisión de principales principales componen componentes tes 1.2 Transacciones 1.3 Librerías 1.4 Conexiones a BD 1.5 Desarrollo de documentos
Ejem empl plos os On OnLi Line ne 02 Ej 2.1 Data trans transfer fer object object (DTO (DTO s) ´
2.2 Cre Creaci ación ón de tra trans nsaci acione ones s 2.3 Creación de librerías de lógica de negocio negocio aplicativa aplicativa 2.4 Uso de utilería de logs 2.5 Conexión Transacción --> Librería 2.6 Crear Librería JPA
INDICE Intr trod oduc ucci ción ón Ar Arqu quit itec ectu tura ra On Onliline ne 01 In 1.1 Revisión de principales principales componen componentes tes 1.2 Transacciones 1.3 Librerías 1.4 Conexiones a BD 1.5 Desarrollo de documentos
Ejem empl plos os On OnLi Line ne 02 Ej 2.1 Data trans transfer fer object object (DTO (DTO s) ´
2.2 Cre Creaci ación ón de tra trans nsaci acione ones s 2.3 Creación de librerías de lógica de negocio negocio aplicativa aplicativa 2.4 Uso de utilería de logs 2.5 Conexión Transacción --> Librería 2.6 Crear Librería JPA
Intr ntroduc oducción ción Arqui A rquite tectur ctura a Onli nline ne
01
REVISIÓN DE PRINCIPALES COMPONENTS Componentes Online:
➔ Unidad Funcional: Corresponde ➔ Servicio Backend APX :
con componente mínimo de despliegue en PaaS.
Expone la interfaz RestFul de la API que representa.
➔ Transacción APX: Una
transacción es la unidad aplicativa a ejecutar en APX Online. Define la Unidad Transaccional a nivel de lógica aplicativa. Encapsula la lógica de negocio y el acceso a los datos. Publica su interfaz para poder ser utilizada por terceros.
➔ Librería APX:
➔ DTO: Representación
en forma de Bean de una Entidad de Negocio.
4
01
REVISIÓN DE PRINCIPALES COMPONENTS Online: La Aplicación dispone de utilidades de Arquitectura que facilitan el acceso a las fuentes de datos.
Srv. Backend APX
Utilidades APX
TRX BBDD LIB LIB LIB
PUBLIC LIB
Motor Reglas Otros
Estrategia de Desarrollo : Todo acceso a datos debe de encapsularse en una librería para facilitar su reutilización y control de acceso.
5
01
REVISIÓN DE PRINCIPALES COMPONENTS Utilidades de la Arquitectura APX Online :
La Arquitectura APX Online dispone de una serie de utilidades, como pueden ser: –
Utilidades expuestas por librerías “especiales”: Se tratan de librerías cuya utilidad puede ser recuperada por el usuario desde dicha librería. Estas librerías se verán en el apartado “Creación de librerías” – – – – –
Librerías de BD relacionales Librerías JPA Librerías Motor de Reglas Librerías MongoDB Librerías de Conectores » Interbackend » Gestor Documental » Generador de Documentos »
–
…
Utilidades comunes a todas las librerías: Estas utilidades pueden ser usadas desde cualquier librería, sean del tipo que sean. Estas utilidades se verán en el apartado “utilidades comunes”: – Errores y Warnings – Recuperación/Salida información – …
Creación de Serv. Backend
01
CREACIÓN DE SERV. BACKEND MENÚ PRINCIPAL
La creación de un Servicio Backend dentro de la Arquitectura APX Online se realiza mediante las opciones:
La implementación del servicio Backend se autogenera desde los editores de las transacciones que utiliza, asociando cada operación sobre una entidad en cada una de ellas. Esta clase por tanto no debe modificarse directamente. 8
Creación de DTO
01
CREACIÓN DE UN DTO MENÚ PRINCIPAL
Un DTO es la representación Java de una Entidad de Negocio. Se puede crear con las siguientes opciones:
Antes de crear un DTO hay que validar si este ya está disponible a nivel de Modelo Canónico de Datos (QMCD).
10
Creación de Transacciones
01
CREACIÓN DE TRANSACCIONES MENÚ PRINCIPAL
Posibles formas de crear una Transacción a través de diferentes opciones de menú.
12
01
CREACIÓN DE TRANSACCIONES ASISTENTE DE CREACIÓN (I)
La “T” debe mantenerse para cumpl ir la nomenclatura
La descripción debe tener un sentido funcional 13
01
CREACIÓN DE TRANSACCIONES ASISTENTE DE CREACIÓN (II) •
Todos los campos son obligatorios y tienen sus restricciones correspondientes. Código de aplicación: debe ser de 4 caracteres. Nombre de la transacción: debe tener 4 caracteres (comenzando por “ T” y tres números) debe contener dos caracteres – Versión: numéricos. – País: debe tener 2 caracteres. – Descripción: debe ser especificada y debe tener – –
un sentido funcional
•
La etiqueta Nombre de la transacción nos indica el nombre que tendrá la clase que implemente la transacción.
•
El Paquete indica el nombre del paquete Java en el que se va a ubicar esta clase. Ambas etiquetas se autogeneran completando los campos de texto.
al
ir
14
01
CREACIÓN DE TRANSACCIONES ASISTENTE DE CREACIÓN (III) El asistente permite crear campos de entrada y de salida, simples o compuestos para las transacciones. Para ello es necesario indicar, de forma obligatoria: -
Nombre Tipo (String, Long e Int) Tamaño (valor distinto de 0) Obligatoriedad (Opcional u obligatorio)
Con el prot oco lo QP05 se permite anidamiento múltiple. Desde ASO, el protoc olo de comun icación siempre será QP05, por tanto esto es transparente para el desarrol lador 15
01
CREACIÓN DE TRANSACCIONES ASISTENTE DE CREACIÓN (III) Cuando la transacción es consumida desde un servicio Backend se debe indicar un identificador descriptivo de la operación que va a implementar. El asistente permite definir en detalle todas las opciones para la exposición Restful de la transacción (Verbo http, campos de entrada y de salida, Códigos http, Query params…)
16
01
CREACIÓN DE TRANSACCIO TRANSA CCIONES NES ASISTENTE A SISTENTE DE CREACIÓN (Y IV) Al finalizar el asistente se construye un proyecto Java Maven con todas las dependencias necesarias para el desarrollo de la transacción desde su inicio. Por otro lado se abre para su edición el archivo Java generado por el asistente que define la transacción.
17
01
CREACIÓN DE TRANSACCIO TRANSA CCIONES NES ESTRUCTURA ESTRU CTURA DEL PROYE PROYECTO CTO GENERADO: GENERADO: ESQUE ESQUEL L ETO
• src\main\java.- Contiene el código fuente de la lógica aplicativa. El asistente genera genera el paquete por defecto de
la arquitectura conteniendo: -
la clase Java que implementa la transacción la clase abstracta de la que hereda esta.
• src\main\resources .- Contiene los recursos y carpetas
generados para su uso: -
el ar arcchi hivo vo de manifiesto el archivo XML de parametrización de la transacción El arc archiv hivo o de con config figura uració ción n multi-idioma
• src\test\java.- Contiene los paquetes que definen las
clases usadas para los test unitarios de la transacción, por defecto una vez ejecutado el asistente se encuentra el paq paque uete te po porr de defe fecto cto que co conti ntiene ene un úni único co tes testt definido que se usará para hacer las pruebas unitarias de la transacción.
Contie tiene ne los rec recur ursos sos y car carpe petas tas • src\test\resources.- Con necesarios para la ejecución de pruebas unitarias.
•
La carpeta target, almacenará el JAR de la transacción siempre que la transacción se compile.
18
01
CREACIÓN DE TRANSACCIO TRANSA CCIONES NES ESTRUCTURA ESTRU CTURA DEL PROYE PROYECTO CTO GENERADO: GENERADO: PRUEBAS PRUEB AS JUNIT J UNIT (I)
Las pruebas unitarias (JUnit) están definidas en la clase UUAAT00101ESTransactionTest,
donde:
- UUAA.- Identifica el código de la aplicación - T001.- Id Iden enti tifi ficca el res estto del código de la transacción - 01.- Es la versión de la transacción que queremos ejecutar - ES.- Identifica el país de la transacción - TransactionTest.- Es un sufijo indicativo de que se trata de un test Por de deffec ecto to se cr crea earrá un tes estt qu quee lan la nzará la transac acci ción ón sin nin inggún parámetro de entrada.
19
Creación de Librerías
01
CREACIÓN DE LIBRERÍAS MENÚ PRINCIPAL
Posibles formas de crear una Librería a través de diferentes opciones de menú.
21
01
CREACIÓN DE LIBRERÍAS ASISTENTE DE CREACIÓN
•
Todos los campos son obligatorios y tienen sus restricciones correspondientes. – –
Código de aplicación: debe ser de 4 caracteres. Nombre de la librería: debe tener 4 caracteres (comenzando por “R” y tres números)
– – –
•
Versión: recomendable con formato X.Y.Z Arquitectura: Online (para Jobs: Batch) Tipo: pueden seleccionarse varias (o ninguna)
La etiqueta Nombre de la librería nos indica el nombre que tendrá la clase que implemente la librería. Esta etiqueta se autogenera al ir completando los campos de texto.
La “R” debe mantenerse para cumpl ir l a nomenclatura 22
01
CREACIÓN DE LIBRERÍAS GENERICO • El propósito de una librería, es que el desarrollador pueda codificar la lógica aplicativa de su transacción, sin que para ello sea necesario ningún
. • El esqueleto básico de una librería está compuesto por un proyecto que contiene el interfaz que se usará desde las transacciones o librerías que la invoquen, y la parte de la implementación donde estará localizada toda la lógica de negocio de las librerías. • Los ficheros que componen la librería son los siguientes: UUAAR000Abstract la clase abstracta donde están definidos los servicios que usa la librería. No tiene que ser acceso a datos, ni utilidad proporcionada por la Arquitectura
Creación de Conexiones a BD
01
CAPA DE ACCESO A DATOS DESACOPLADA
APX IMS/CICS
DATA ACCESS LAYER DECOUPLED
Conectores XA Driver ORACLE
MongoDB
Elastic Search
✓
✓
REPLICACION
ETL
REPLICA
Acceso a datos a través de JDBC o JPA La Arquitectura se encarga de gestionar la ejecución del commit/rollback
01
CREACIÓN DE LIBRERÍAS ASISTENTE DE CREACIÓN: LIBRERÍA JPA (I)
Pueden definirse varios no mbres lógi cos, cada uno asociado a una DB diferente
26
01
CREACIÓN DE LIBRERÍAS ASISTENTE DE CREACIÓN: LIBRERÍA JPA (II)
•
El propósito de esta librería es que el desarrollador pueda acceder y manipular BD relaciones a través del API de persistencia JPA
•
Si se selecciona la opción de JPA, será necesario indicar un nombre para el recurso lógico de acceso a DB (se explicará más adelante)
•
Tras esto, se generará el esqueleto de la imagen. Cada uno de los puntos se explicará en los siguientes apartados.
•
Cabe destacar la creación de: La carpeta “Domain” para lógica de negocio • El fichero “persistence.xml” • La clase “JpaUtilsFactory” para las pruebas JUnit •
27
01
CREACIÓN DE LIBRERÍAS ASISTENTE DE CREACIÓN: LIBRERÍA JPA (III)
•
Para usar la utilidad de APX Online referente a JPA, desde la clase de lógica de negocio: this.jpaUtils.get("db1").createNamedQuery(query) this.jpaUtils.get("db1").XXX()
• •
Se recuperará el nombre del recurso lógico contra el que se quiera ejecutar la Query Cada nombre de un recurso lógico, representará una conexión con una DB diferente
28
01
CREACIÓN DE LIBRERÍAS ASISTENTE DE CREACIÓN: LIBRERÍA JPA ( IV)
•
Para las librerías de tipo JPA, se creará en /src/main/java un paquete llamado “domain”
•
En este paquete se deberán incluir todas las clases de entidades JPA generadas
29
01
CREACIÓN DE LIBRERÍAS ASISTENTE DE CREACIÓN: LIBRERÍA JPA (V)
•
Para las librerías de tipo JPA, se creará en /src/main/resources un fichero de persistencia llamado “persistence.xml” • •
En este fichero se deberán incluir todos los nombres de las entidades JPA usadas en la librería para acceder a DB El nombre de la unidad de persistencia no deberá ser modificado
30
01
CREACIÓN DE LIBRERÍAS ASISTENTE DE CREACIÓN: LIBRERÍA JPA ( Y VI)
31
01
DESARROLLO DE DOCUMENTOS
Ejemplos OnLine
05
DATA TRANSFER OBJECT (DTO S)
Desarrollar el DTO, TipoBienDTO, con las propiedades:
long codigo String name long especialidad String nivelServicio String fechaAlta String fechaModifica
02
CREACIÓN DE TRANSACIONES
Desarrollar las transacciones:
MAPPT001 MAPPT002
Ver archivos: Transaccion_MAPPT001-01-MX.xlsx y Transaccion_MAPPT002-01-MX.xlsx
02
CREACIÓN DE LIBRERÍAS DE LÓGICA DE NEGOCIO APLICATIVA
Desarrollar librerías:
MAPPR001, e implementar el método de alta y consulta de la información de tipos de bien. MAPPR002, e implementar el método de alta y consulta de la información en la BD.
Ver archivos: MAPPR001*.java y MAPPR002*.java
01
CREACIÓN DE LIBRERÍAS COMPONENTES DE LAS LIBRERÍAS: PROYECTOS
•
Para todos los tipos de librerías se generarán dos proyectos: • •
•
Proyecto con la interfaz del servicio a publicar Proyecto con la implementación del servicio a publicar
Los nombres de dichas librerías serán: • •
UUAARXXX-X.Y.Z --> Nombre de la librería interfaz, con: UUAARXXXIMPL-X.Y.Z --> Nombre de la librería implementación, con: • • • •
•
UUAA: UUAA de la librería R: Se añade por defecto para indicar que se trata de “rutina” X.Y.Z: Versión de la librería IMPL: Se añade por defecto para indicar que se trata de la implementación
Ambas librerías tendrán que ser desplegadas para una correcta ejecución
37
01
CREACIÓN DE LIBRERÍAS COMPONENTES DE LAS LIBRERÍAS: LIBRERÍA INTERFAZ
•
Para cualquier tipo de librería, el proyecto interfaz solamente tendrá dos secciones importantes: •
Fichero de definición de servicios • • •
•
Por defecto se creará un método “void execute()” Se podrá modificar y crear nuevos métodos para recibir y devolver los datos necesarios Todos estos nuevos métodos deberán comenzar por “execute”. Esto es obligatorio, existe una regla Sonar para su comprobación
Fichero de dependencias pom.xml •
Recupera todas las dependencias con otros proyectos
38
01
CREACIÓN DE LIBRERÍAS COMPONENTES DE LAS LIBRERÍAS: NOMENCLATURA •
Nomenclatura de paquetes: • com.bbva.
.lib.rxxx: Para las interfaces de los métodos ofrecidos por las librerías, para su consumo por transacciones y otras librerías. • com.bbva..lib.rxxx.impl : Para las clases de la librerías que implementan los métodos de las interfaces anteriormente indicadas.
•
Nomenclatura de métodos de la interfaz: • execute[Nombre_elegido_por_app] donde [Nombre_elegido_por_app] es opcional Como se observa la palabra "execute" es de uso obligado como prefijo para cualquier nombre de método.
La longitud máxima del nombre del método es de 48 caracteres
39
01
CREACIÓN DE LIBRERÍAS COMPONENTES DE LAS LIBRERÍAS: CLASE ABSTRACTA
•
Para cualquier tipo de librería, en el proyecto de implementación se generará la clase abstracta: •
Esta clase es autogenerada y no debe modificarse
•
En todos los tipos de proyectos aquí se define el servicio de recuperación de configuración
public void setApplicationConfigurationService( ApplicationConfigurationService applicationConfigurationService)
{ this.applicationConfigurationService = applicationConfigurationService;
}
•
Para las librerías de tipos “especiales” se recuperará el servicio asociado a su tipo, por ejemplo para MongoDB: public void setMongoDBUtils(MongoDBUtils mongoDBUtils) { this.mongoDBUtils = mongoDBUtils;
} 40
01
CREACIÓN DE LIBRERÍAS COMPONENTES DE LAS LIBRERÍAS: CLASE IMPLEMENTACIÓN
•
Para cualquier tipo de librería, en el proyecto de implementación se generará la clase de implementación principal.
•
Esta clase se crea solamente con un método “execute” para que el desarrollador implemente la interfaz vista anteriormente.
•
Al ser una implementación de la interfaz anterior, cualquier nuevo método “execute” que se incluya en dicha interfaz, deberá ser implementado en esta clase.
41
01
CREACIÓN DE LIBRERÍAS COMPONENTES DE LAS LIBRERÍAS: OSGI ARQUITECTURA •
Para todos los tipos de librerías se generará, en /src/main/resources/ un fichero de servicios OSGi de arquitectura, llamado UUAAR001 -arc-osgi.xml .
•
En este fichero se definen los servicios que se importan a la librería desde la arquitectura: •
Para todas las librerías se importará el servicio de configuración
•
Para las librerías “especiales” se importará su servicio asociado. Por ejemplo para JDBC:
•
A su vez, también se define el servicio que exporta la librería como tal:
•
Este fichero no debe modificarse 42
01
CREACIÓN DE LIBRERÍAS COMPONENTES DE LAS LIBRERÍAS: OSGI APLICATIVO
•
Para todos los tipos de librerías se generará, en /src/main/resources/ un fichero de servicios OSGi de aplicativo, llamado UUAAR001 -app-osgi.xml.
•
En este fichero se definen los servicios que se importan a la librería desde la otras librerías.
•
A su vez, también se definirán servicios que la librería recoja de otras librerías.
•
Este fichero no deberá modificarse según se vayan creando interacciones entre las diferentes librerías aplicativas.
•
Sólo las librerías de infraestructura pueden publicar servicios de uso genérico
43
01
CREACIÓN DE LIBRERÍAS COMPONENTES DE LAS LIBRERÍAS: BEANS ARQUITECTURA
•
Para todos los tipos de librerías se generará, en /src/main/resources/ un fichero de beans de Spring de arquitectura, llamado UUAAR001 -arc.xml.
•
En este fichero se definen los beans que se asociarán a los servicios que se recupera de la arquitectura: • •
Para todas las librerías se generará el bean de configuración Para las librerías “especiales” se generarán los beans asociados a su servicio correspondiente
•
A su vez, también se define el bean asociado a la clase, para su exportación vía servicio OSGi.
•
Este fichero no debe modificarse
44
01
CREACIÓN DE LIBRERÍAS COMPONENTES DE LAS LIBRERÍAS: BEANS APLICATIVO
•
Para todos los tipos de librerías se generará, en /src/main/resources/ un fichero de beans de Spring aplicativos, llamado UUAAR001 -app.xml.
•
En este fichero se definen los beans que se asociarán a los servicios que se recuperan e importan de otras librerías aplicativas: •
•
Por defecto se crea el bean asociado a la librería
Aquí también se definirán el resto de beans que el desarrollador necesite para desarrollar su lógica de negocio.
45
02
USO DE UTILERÍA DE LOGS
Desarrollar ver uso en la implementación de la librería: Ver archivos: MAPPR001*.java
01
UTILIDADES COMUNES MANEJO DE TRAZAS(I) LOGGER SLF4j ● Cuando se crea un nuevo componente con el IDE de Desarrollo, por default genera la siguiente línea con la creación de un logger del paquete org.slf4j: Logger LOGGER = LoggerFactory.getLogger(UUAAR000Impl.class); ●
SL4FJ provee varios métodos para manejo de trazas, entre los cuales se encuentran:
• LOGGER.trace(String msg, Object … args) : Imprime
información con el nivel máximo de detalle. Recibe un mensaje y n argumentos (opcionales) para complementar el mensaje a imprimir. • LOGGER.debug(String msg, Object … args) : Permite imprimir datos informativos con detalle fino que son útiles para depurar la aplicación. • LOGGER.info(String msg, Object … args) : Imprime información útil que permite ver el progreso de la aplicación. • LOGGER.warn(String msg, Object … args) : Imprime advertencias o fallos de la aplicación no críticos, los cuales no impiden que la aplicación continúe su flujo. 47
01
48
01
UTILIDADES COMUNES ERRORES Y WARNINGS (II)
•
A nivel de transacciones y de librerías aplicativas, existe la posibilidad de crear errores y avisos controlados
•
En caso de querer mandar un aviso desde una librería o la transacción, sea del tipo que sea, se usará el método addAdvice, que añade el aviso a una lista. Este método no fija la severidad del aviso, puesto que ésta es contextual a la transacción y debe realizarse desde la misma mediante el método setSeverity o setHttpResponseCode.
•
Como concepto de desarrollo y gestión de los errores ocurridos durante el stack de ejecución de una transacción, la severidad de la ejecución lo debe de determinar la propia Tx. Esta tiene el contexto de las librerías que está invocando/orquestando y puede determinar si ante un Advice debe salir por Ok, Error o Aviso.
49
01
INTRODUCCIÓN ERRORES Y WARNINGS (III)
La Arquitectura proporciona los métodos “addAdvice() al Aplicativo para notificar un error o warning en el código de la transacción. Códigos de Retorno de la TX 1. OK (“00”) → OK 2. WARN(“04”) → OK + Código de aviso 3. ENR(“06”) → Rechazado + Código de error (sin Rollback) 4. EWR(“08”) → Rechazado + Código de error (con Rollback) 5. ERROR(“12”)→ Rechazado (error grave) + Código de error
Códigos HTTP vs Códigos de Transacción
1. 200, 201, 202, 204, 206 → Severity.OK 2. 201, 202, 204, 206 → Severity.WARN 3. 404, 409, 422 → Severity.ENR 4. 404, 409, 422 → Severity.EWR 5. 500 → Severity.ERROR
Nota: La severidad ERROR(12) es de uso sólo en Arquitectura, las aplicaciones no pueden utilizarla
50
02
CONEXIÓN TRANSACCIÓN --> LIBRERÍA
Para usar una librería online desde una transacción se tiene que seguir los siguientes pasos:
En
el pom.xml de la transacción invocadora debemos importar la dependencia de la librería a invocar. Si quisieramos por ejemplo invocar a una librería UUAAR001, deberíamos incluir lo siguiente
com.bbva.uuaa UUAAR001 0.0.0
02
CONEXIÓN TRANSACCIÓN --> LIBRERÍA
En el mismo pom.xml tenemos que modificar el maven-bundle-plugin el tag Import-Packages para añadir el nombre del paquete donde está la interfaz:
com.bbva.elara.*;version="${osgi.version.manifest}", com.bbva.uuaa.lib.r001;version="0.0 ”, org.osgi.framework, spring, *
02
CONEXIÓN TRANSACCIÓN --> LIBRERÍA
Para obtener una instancia de la librería que queremos utilizar, en el método
execute de la transacción, para nuestro ejemplo, incluiriamos la siguiente línea:
UUAAR001 libUUAAR001 this.getServiceLibrary(com.bbva.uuaa.lib.r001.UUAAR001.class);
=
donde com.bbva.uuaa.lib.r001.UUAAR001 es la interfaz de la librería a invocar, la cual habrá que incluir en los import de la clase de la transacción
02
CREAR LIBRERÍA JPA
Crear la librería
MAPPR002, e implementar el método de alta y consulta de la información en la BD.
Ver archivos: MAPPR002*.java
02
CONEXIÓN LIBRERÍA --> LIBRERÍA
Para poder invocar a una librería desde otra librería se tiene que seguir los
siguientes pasos. Tomaremos como ejemplo una librería llamada UUAAR001 que será invocada desde UUAAR002
En el pom.xml del invocador debemos importar la dependencia de la librería que contiene el interfaz. El pom.xml será el de UUAAR002IMPL-0.0.0.
com.bbva.uuaa UUAAR001 0.0.0
02
CONEXIÓN LIBRERÍA --> LIBRERÍA
En el mismo pom.xml tenemos que modificar en el maven-bundle-plugin el
tag Import-Packages para añadir el nombre del paquete donde está el interfaz
com.bbva.elara.*;version="${osgi.version.manifest}", com.bbva.uuaa.lib.r001;version="0.0 ”, org.osgi.framework, spring, * NOTA: en caso de que la variable osgi.version.manifest no esté definida en el pom se establecen los paquetes com.bbva.elara con versión 0.0 al igual que los paquetes com.bbva.uuaa.lib.r001.
02
CONEXIÓN LIBRERÍA --> LIBRERÍA Se tiene que modificar el siguiente archivo que se encuentra en el proyecto de la librería invocadora (UUAAR002 en nuestro ejemplo)
/main/resources/META-INF/spring/UUAAR002-app-osgi.xml o en caso de no existir, el siguiente /main/resources/META-INF/spring/UUAAR002-osgi.xml para incluir la línea que recupera el servicio de la otra librería, UUAAR001 en nuestro ejemplo
bean-name="uuaaR001"
Donde: El id es el nombre del bean que se va a crear en el contexto spring. Bean-name se usa en la búsqueda de servicio y tiene que coincidir con la referencia (ref) del servicio que se publica. Este id uuaaR001 es con el que se ha indicado en spring en la librería invocada, y nos lo debe indicar quien nos proporcione la librería. XML Spring : Interface la interface que buscamos. Se tiene que definir indicando el nombre compleo, incluyendo el paquete.
02
CONEXIÓN LIBRERÍA --> LIBRERÍA
En la implementación de la librería UUAAR002, clase UUAAR002Impl.java,
debemos dar de alta una variable miembro privada, del tipo del interfaz de la librería a invocar (UUAAR001 en nuestro ejemplo), previa importación de la misma.
private UUAAR001 UUAAR001;
En la implementación de la librería debemos generar un setter público para un campo que deberá llamarse UUAAR001 de acuerdo a nuestro ejemplo, que es el id que pusimos en el tag osgi:reference del paso 3
public void setUUAAR001(UUAAR001 UUAAR001){ this.UUAAR001 = UUAAR001 }
02
CONEXIÓN LIBRERÍA --> LIBRERÍA
En
el fichero -app.xml de la librería se debe inyectar el bean recuperado, UUAAR001, via osgi en la implentacion de UUAAR002. Para ello se deberá añadir en el bean de la implementacion una nueva propiedad. Donde name debe coincidir con el nombre del metodo set pero sin contener la clausula set del mismo. La propiedad ref se deberá rellenar con valor del campo id del servicio osgi importado, como se indica en el punto 3.
A partir de ese momento podremos invocar los métodos de UUAAR001 desde el código de la librería UUAAR002.
