NOTAS JBOSS

RACC

IMPORTAR INTERFAZ DESDE REPOSITORRIO RACC

File -> Import -> “git” -> -> Clone_URI -> escribimos la URL del repositorio (la que
viene en la web). Si la interfaz que quiero importar pertenece a un repositorio nuevo
tengo que crearlo:

CREAR UN NUEVO WORKSPACE

Primero me creo una carpetita en mi local (dentro de JBOSS en workspaces y la llamo
como al workspace que voy a crear)
File -> switch workspace -> other -> busco la carpeta anteriormente creada y OK

EXPORTAR – IMPORTAR CAMBIOS A REPOSITORIO

Exportar:
-Desde el padre: botón derecho -> Team -> Synchronize workspace. Veremos lo nuevo
que hay modificado (si los paquetes tienen flechitas es que sí). Si el synchronize falla
volver a intentarlo.
-Cambiar vista: window -> show view -> other -> escribir “git” -> selecciono “Git
Staging”
Si no hay ningún error (flechas rojas) ni cosas para bajar (flechas azules) …
-Desde la pestaña de unstaged arrastro a la de staged. Habrá archivos que no
quiera pasar y que no arrastraré, entre ellos los de forma: .setting, .project y .classPath.
Estos desde local los ignoramos (botón derecho ignore). Se creará un archivito
ignore.guit que ya sí arrastraremos.
Importar:
-Botón derecho en el padre -> team -> Synchronize -> y pulsamos pull

DESPLEGAR y VER ERRORES

 Desplegar una interfaz ya creada
-Nos metemos en Nexus Repository -> oxygen.fuse.releases (para el ejemplo) y
miramos la versión mayor que existe.
JBOSS: en el pom.xml del padre cambiamos la versión a un número mayor al del
repositorio que hemos visto anteriormente.
-Para compilar: desde el archivo que queremos desplegar
(interfaz/datamodel) pulsamos botón derecho -> run as -> Maven build… ->
escribir “Clean Install” y arriba añadirle al final – Clean Install. Así se crea el .jar
que se instala en el repositorio Maven local.
-Para desplegar: Hacemos igual que antes pero escribimos “deploy”. De
esta manera aparece el cambio de versión en Nexus.

Hawtio (desarrollo): Buscamos en profiles el perfil que nos hemos creado para nuestra
int-> pulsamos Details y en “artifacts” le damos a editar (lápiz de la derecha) y
escribimos al final la nueva versión.

Putty (pantalla negra): nos metemos en putty y escribimos el IP de desarrollo o

integraciones…. (lo tenemos en el Datos.txt en desarrollo o en el mismo DiseñoTécnico:
no siempre fiarse de este), la URL y el puerto (este se encuentra en el container -> URL
-> SSH).
-En la pantalla negra escribimos usuario y contraseña (admin y admin) y
después “log:tail”. Esperamos a que salga Done.

-Cada container publica en un puerto. Para ver este puerto: desde Hawtio -> container
-> nos metemos en la carpeta P_CFG_”…” -> org.ops4j.pax.web.properties (a la izqda.)
. También viene en el IP del DT (IP: puerto/cxf/services/).
-Con este IP construimos una URL que al introducir en un buscador nos dará un
wadl/wsdl. Esta dirección wadl al pulsar nos dará algo (un json por ej) que es el que
meteremos en soapUI.

SoapUI: lo usamos para lanzar los request. Estos están en src/test/resources. Los
parámetros los cogemos de aquí y pegamos en SoapUI (en caso de SOAP). Si hacemos
un rest los parámetros vienen la misma URL.
-Pulsamos el botón REST o SOAP dependiendo del tipo de int que sea y
pegamos en el body el resultado del wadl. El método utilizado (get, post,…) viene
en el DT. Si nos da algo de respuesta es que está desplegado. Si me pide usuario y
contraseña para poder runear meto el de Datos.txt.
-En la pantalla negra (“en el log”) vamos viendo lo que pasa y los errores. Son
los logs que tenemos en el blueprint. Si da error vamos viendo los logs tanto en
Putty como en el blueprint para saber a partir de cuándo da este error.
- Ya en el Putty vamos viendo los errores. Cada vez que cambie algo debo de cambiar la
versión del pom y volverlo a desplegar (ya solo deploy). Antes de desplegar otra vez:
borrar el container en hawtio y volver a crear otro para quitarnos de problemas. Aquí
cambiar la versión a mano porque ya lo he hecho con deploy.

 Desplegar una interfaz creada desde 0

Para poder desplegarla debemos de crear primero un perfil en Hawtio y para eso
tenemos que usar fabric8:
JBOSS: en el pom.xml del padre cambiamos la versión a un número mayor al del
repositorio que hemos visto anteriormente. Si es nueva será la 0.
-Para compilar: desde el archivo que queremos desplegar
(interfaz/datamodel) pulsamos botón derecho -> run as -> Maven build… ->
escribir “fabric8:deploy”. Esto crea automáticamente el perfil en Hawtio. Esto lo
haremos para la integración y el datamodel (este último si no ha sido creado
antes). (*) Si no me reconoce el Datamodel hacerle clean install (botón derecho
sobre Datamodel -> run us -> Maven build…-> escribimos “clean install”. Una
vez que se cree el perfil pulsar sobre él en “detail” y borrar el Datamodel que le
asocia.
-Para desplegar: Hacemos igual que antes pero escribimos “deploy”. De
esta manera aparece el cambio de versión en Nexus.
Hawtio: en profiles se debe de haber creado un perfil. Nos metemos en details y
borramos el Datamodel que se genera.
En containers -> pulsamos add -> y cremos un container buscando y pulsando el perfil
creado. Aparecerá con la versión ya cambiada porque lo hemos hecho con fabric8. Esto
lo hacemos para la integración y para el datamodel (si este no estaba ya creado).
Ya en el Putty vamos viendo los errores (ver pasos Putty). Cada vez que cambie algo
debo de cambiar la versión del pom y volverlo a desplegar (ya solo deploy). Antes de
desplegar otra vez: borrar el container en hawtio y volver a crear otro para quitarnos
de problemas. Aquí cambiar la versión a mano porque ya lo he hecho con deploy y no
se cambia sola.

 Subir a integración
Cuando queremos subir a integración y no a desarrollo: hacer nuevo fabric8 : deploy
pero cambiando en el pom el IP (en jolokiaURL) por el de integración (viene en
datos.txt). También hay que hacer las pruebas en SoapUI para integración (cambiando
solo el IP).
 CREAR INTERFAZ DE CERO
(Voy a ir pasando desde una int modelo las carpetas que quiera a una carpeta creada
por mi para mi int en mi git. Si refresco en JBOSS el repositorio donde la he metido me
debe de aparecer)
-Según modelo parecido copio el pom.xml padre en el git del mío (en mi local dentro
de mi user) y le hago modificaciones con Notepad.
-Blueprint: En <module…/> cambiamos el nombre del <datamodel> y en la línea
de abajo el nombre del adaptador que creamos <”S_CRM_...”>. Lo de <report tool/>
que está debajo también del adaptador, lo dejamos. Lo demás que hay en module lo
borramos.
-Vamos desde mi local en mi PC copiando carpetas desde el modelo y pegando
en mi git. Copio el datamodel, borro todo menos el pom (en él sí que borro los
paquetes que venían <packets…/> y el source (le quitamos sus carpetas test y main).
-En JBOSS: le damos a F5 sobre el padre y aparecerá nuestro datamodel. Para
pasar nuestro proyectito a Maven: botón derecho sobre el proyecto -> import ->
escribimos “Maven” -> Existing Maven Project -> aceptar. Le damos a Alt + F5 para
Maven update.
-Copiamos también a nuestro local el model del repositorio que vamos a usar y
le dejamos solo el source y el pom. Desde notepad le voy cambiando los nombres
como hemos hecho antes para el datamodel.
-Creación de modelos de entrada y salida:
-Datamodel /resources -> creo un json schema donde meteré el esquema
obtenido en el convertidor.
-Main/java/ -> creo paquetes de entrada (org.web….) y salida (org.crm….). En
ellos irán los modelos java del convertidor.
Convertidor 1: JSON -> JSONschema
Convertidor 2: JSONSchema -> objeto JAVA (pojo)
-Cuando convirtamos: quitar los “required”en el mismo convertidor, poner
nombre del paquete donde lo guardo. (En el caso de listas (list) crearé una clase guid
de salida para la lista en concreto (es decir, haré su pojo por separado del resto).
-Sobre los paquetes org.web y org.crm pulso botón derecho -> copy cualified name.
-Pego estos nombres en el pom del datamode (donde va el import, request (el
org.web)) y en el pom de nuestro servicio (donde van los responses y export) pegamos
el de salida.
-En src (asecas) / main / fabric8 / env.configuration.properties cambiamos nombre por
el de nuestros servicio y en blueprint donde llama a estas properties también (en
concreto donde pone prefix/sufix.
-En src / main / resources meto las adapter properties que vienen en el DT.
-EnvconfigurationCRM es otro aparte del nuestro para CRM que metemos desde
HAWTIO y que llama desde blueprint.
-CRM: Postman. CRM actúa a modo de base de datos y pedimos acceder a estos. Para
acceder a esta tenemos una CRMApi.java
Abrimos la carpeta token y enviamos (send). Nos dará un pedazo de numero y
letras que se usa para comunicarnos con CRM.
Para consultar algo, como por ejemplo clientes: En ENV hacemos un get y en la
pestaña Pre-RequestScript metemos detrás de “var query = ____” lo que
queremos filtrar (lo que viene en el DT).
A nosotros nos llega un guid value y con él se hace una consulta a CRM (con el
valor del guid y el de los otros: data inicio, data fin …
-En Blueprint:
-Tenemos que definir el web service (donde publicamos) en el blueprint, en la
parte <cxf…….cfx/>. Usa la clase serviceClass. Cambiar aquí el nombre por el del
endpoint de entrada (viene en el DT).
-En route de <recepción> cambiar el id del web service (el que también
habíamos puesto en el cxf) donde pone from. Llega el json (el de entrada del
DT) a través de las operaciones publicadas en WEB.
-<PreaccionesIda>: Se envía a la cola de monitorización (se monitoriza) la
request.
-En <route mapeoPeticion/>: mapeo desde el JSON de entrada (web-json) al
modelo de datos de CRM. A veces habrá mapeo.
-< process ref= RequestProcesor>:
- Pasamos el JSON de entrada a modelo java (Request). Copiamos
del modelo el <bean> del dataFormat que usa el unmarshall y
cambiamos nombres y clase. En su respectiva <route>
cambiamos también el id.
- Se realiza una comprobación de los campos (que estén
debidamente rellenos). En estas comprobaciones metemos las
respuestas de error que están en el DT en json. En concreto
estamos metiendo en el body el json.
-Tener en cuenta si hay listas, …
-Si tuviéramos transcodings lo que iría en el preProcessor podríamos
meterlo aquí (estableceríamos los valores que van a llevar transcoding):
-<inOut>/: envío a cola de transcodificación (en caso de transcodif).
Después de darse inOut tenemos string, hay que hacer
-ref=PostProcessor. Aquí se coge el valor de la cabecera que devuelve la
BD y lo mete en el modelo Request.
 -marshall de jsonRequest
-En <PostaccionesIda/>: Se hace un update RequestHeader
-En < func.enviar-recibir/> hace un get al CRM para coger el token y lo guarda
con un header en <inOut>.
-Hace unmarshall de jsonrequest para que a CRM le llegue en clase java

Para otros casos:

-Creamos un processor (RequestProcessor): definimos un <bean/> en el que metemos
el enlace de la carpetita del processor y le doy un id. En la <route/> lo llamo
escribiendo en ref el id que le he dado previamente.
-En el processor tenemos ya el objeto java, queremos cogerlo y comprobarlo. Para esto
meto en el processor el .java de la Request y sobre él modifico (hago como una request
de la request).
-<CRMSender/>: Lo que metemos en CRMsender va a ser lo que
enviamos a CRM (básicamente los get (consultar), put (actualizar) y
post). Esto lo hacemos con clases java de CRMApi (están implementadas
en este paquete).
Al CRMSender le llega la request rellena en formato json (puesto que
previamente se le ha hecho un unmarshall en blueprint).
Se crea al principio un jsonRequest (String jsonRequest =
exchange.getIn().getBody(String.class); ) donde está esta request.
Ahora tenemos que pasar este json a la clase request.java para que CRM
lo entienda. Para esto creamos una request vacía de tipo request que
hayamos creado para el adaptador
(org.web.”nombredeladaptador”.Request request; ).
Con esto hacemos el cambio de json a clase request.java:
if (jsonRequest != null && !jsonRequest.isEmpty()) {
try {
request = mapper.readValue(jsonRequest,
org.web.recuperarTarea.Request.class);
} catch (Exception e) {
throw new Exception("Json Request has incorrect
format");
}
} else {
throw new Exception("Json Request is Empty");
}
Se va creando la respuesta (la del DT): se va consultando los guid a CRM
y metiendo en result lo que nos va dando. Para esto se crea una
responseList (en el que metemos por cada guid un result). Después
 elaboramos la respuesta con SetResponse donde metemos la
responseList y los otros parámetros (fecha ini,…)
 En transcoding…
Tenemos un preprocesor y un postprocesor.
-Preprocesor: En el preprocesor SOLO se monta el transcoding (no se hace), es
decir, digo con qué valores quiero hacer la consulta a la base de datos. Se
establecenla entidad, el valor y la property destino.
Las entities y las properties las establecemos en
src/main/java/.com/fun/en una clase “MCDMappingProperties.java”
En el mismo preprocessor se crean metoditos para cada uno de los
valores que le vamos a hacer transcoding donde decimos cual es la
entidad origen y la propiedad destino. Cremos así una
Cabeceratranscoding que se envía a transcoding.
Estos métoditos usan la clase MCDTranscodingUtil.java (me la importo
de algún proyecto) para hacer las lógicas de intercambio de cabeceras
(relación entre la cabecera entity y la cabecera prop).
-Envío a transcoding (aparece en el blueprint). Se hace la consulta a la base de
datos con la entidad y el valor que devuelve la base de datos se mete en la
property definida.
-Postprocessor: Coge el valor de property (con un getHeader) y lo mete en el
modelo. Para esto hay que hacer seteos para cada valor. Con un metodito de
nuevo.
En el transcoding no hay dozer porque no se está haciendo un mapeo en sí.
Tanto en preprocessor como en postprocessor tenemos la clase Request.java.
 AGBAR

Para migraciones de sector (de 6.1 a 6.3):

- De la carpeta donde están los 6.1 cogemos la carpeta de src y el pom. Borramos de la
carpeta src todo lo que no es la integración en la que estamos centrados. Copiamos y
pegamos la carpeta de configuration dentro de la de src y borramos lo que no
necesitamos, por ejemplo la carpeta local.
- En el .pom:
o Al que hemos pegado (el antiguo) le cambiamos el nombre. Copiamos y
pegamos otro pom del ejemplo que vamos a seguir para generar el 6.3 y a ese
sí que le llamo .pom.
o Básicamente el pom será igual al del modelo 6.3 que hemos cogido, le
cambiaremos: los groupID, artifactID, …
Por ejemplo las dependences necesarias aquí serán quartz2, ftp, blueprint y
zookeper
o Las properties que usa están definidas en la carpeta de configuration. A esta
carpeta le cambio el nombre con el de mi int nueva y acabando en .properties
En 6.3 tenemos mounts (mnt, accesos directos a carpetas (a través del programita
mobaXterm). Estos mounts tienen que estar creados por alguien.
Las properties que aparecen en 6.1 no se cambian (es decir las URL de los directorios, los
passwords,…) son los mismos pero se les llama de manera distinta en 6.3.

- En el blueprint: También tomamos un ejemplo ya hecho pero añadiendo las props que
usa nuestra int… (Muestro algunas de las cosas que se hacen pero si cojo el modelo ya
vienen hechas) :
o Se eliminan las propiedades por defecto

o Para acceder a las propiedades de la int (las que están en la carpeta

configuration) desde el blueprint:
 Si estoy dentro del camelContext: {{….}}
 Si estoy fuera: ${….}
o Dejamos el filtro

- <camelContext>: en el caso de los que hemos estado haciendo nos quedaremos con
una sola ruta ya que se sintetizan las dos que están en 6.1 a una sola en el 6.3.
o Le pongo nombre a la ruta

o Quito los id que aparecen dentro de la ruta

o En el ejemplo dentro de la ruta me quedarán básicamente el from y el to.

Después de cada uno de ellos pongo un log.
 o En el from aparece: “master: nombre de la int:{{input.meta4.file}}.

 Master se pone para que los nodos no intenten acceder a al vez al

fichero. Input.meta4.file es la property general que establecemos y
dentro de ella es donde se modifican el resto de propiedades.
 En config/propiedades meto esta propiedad general donde irán las
otras correspondientes al fil (recordar que en 6.1 teníamos samba y
esto en 6.3 no exite, por lo que se sustituía por file (que es esta
propiedad general) que tiene asociadop las siguientes propiedades:
mounts, crons, filtro, …

o En el to: en el ejemplo se trata de un ftp. LOS FTP se mantienen en 6.3.

Desplegar en AGBAR:
 Usamos:
-mobaXterm: lo usamos para conectarnos a los servidores (con los mounts). Creamos
una sesión donde ponemos IP, puerto y password (vienen en el datos.txt).
-FileZilla Client. Lo usamos para los ftp. Ponemos los datos de las propiedades de la
integración en el programa para entrar en el directorio donde dejo el archivo. Adí
puedo probar la int.

 Importamos desde jboss el Maven: sobre la int botón derecho: import-> Maven->
existing moven Project. Cuando se cree le damos a botón derecho: run as-> Maven
build y hacemos Clean Install. Sobre la int Le hago Maven, clean install y refrescamos
(f5) para ver el .jar generado.

 Creación de perfil en Hawtio (dev): Hawtio-> wiki-> + create-> fabri8profile-> le damos

el nombre de la int-> create

 Ese perfil estaría vacío y tenemos que meter las cosas a mano:
Metemos primero en parents el feature.camel para poder meter después el
resto de features. En el ejemplo: quartz2, ftp, blueprint, zookeper. Vamos
añadiéndolas en Add+ y le damos a Save changes-> done.
Le damos dentro del perfil a: créate-> PropertiesFile-> y le meto el contenido
de las propiedades. Metemos el archivo de propiedades a mano (copio y pego
el contenido en sí) y le pongo el nombre que tiene en jboss.
 Para las pruebas: creamos en el contenedor test un perfil para la int (buscandolo del ya
creado).

Para las pruebas:

Nos metemos en mobaXterm para acceder a los contenedores: apps/jboss-
fuse/instances/test/deploy. Ahí será donde arrastre el .jar que me cree anteriormente en jboss
(desde el mismo jboss puedo arrastrarlo).
Para ver como está saliendo la prueba abrimos el Putty (ssh) y le metemos el puerto del
container de test y escribimos developer/developer.

PROBAR LAS MIGRACIONES (con ejemplo con procureo)

En hawtio tenemos ya hecho el perfil:
Añadimos el perfil al contenedor test.
Genero el .jar desde jboss
Abro el moba (añadirle la sesión) y el putty.

En las properties viene la extensión del fichero que tengo que dejar y la ruta donde dejarlo.
Para la mía: meta4-java
Añadimos en el contenedor test mi perfil (add).
Miramos las properties y la ruta de origen (/mnt/aplicaciones/test)