Archivo
Cabeceras personalizadas y procesos Oracle BPEL
En el momento de definir nuestros servicios web, nos podemos encontrar con la necesidad de incluir cabeceras personalizadas que aporten información añadida a las distintas operaciones del mismo.
Si estos servicios van a ser consumidos por una aplicación SCA, como puede ser un proceso BPEL, recomiendo seguir el siguiente consejo: incluir nuestra cabecera en la definición el mensaje.
Seguimos el orden de definición del WSDL para explicar nuestro caso. Si nos ceñimos a los elementos del contrato que nos conciernen, empezamos por la definición de mensajes.
Es común crear un mensaje que represente nuestra cabecera personalizada para reutilizarlo e implementar el siguiente formato:
<wsdl:message name="HeaderPersonalizado"> <wsdl:part name="cabecera" element="client:miCabecera"/> </wsdl:message> ... <wsdl:operation name="operacion1"> <soap:operation style="document" soapAction="http://xmlns.Avanttic.com/Blog/HeaderPersonalizado/operacion1"/> <wsdl:input> <soap:body use="literal" parts="payload"/> <soap:header message="client:HeaderPersonalizado" part="cabecera" use="literal"/> </wsdl:input> <wsdl:output> <soap:body use="literal" parts="payload"/> </wsdl:output> </wsdl:operation>
Aún siendo correcto, generar un contrato con este formato implica que el envío de la cabecera desde un proceso BPEL sea ligeramente más complejo. Veamos los pasos que realizaríamos para este caso:
- Generar una variable del tipo miCabecera:
<variable name="miCabecera" element="client:miCabecera"/>
- Asignar los valores correspondientes a la cabecera mediante la actividad Assign.
- Asignar esta variable a la cabecera de la actividad Invoke.
En este punto nos encontramos con la particularidad de que la IDE de JDeveloper no permite realizar este paso y es necesario acceder al código fuente de la actividad y agregar la propiedad bpelx:inputHeaderVariable:
<invoke name="Ejecutar" partnerLink="ServicioWeb" portType="client:HeaderPersonalizado" operation="operacion1" inputVariable="Ejecutar_InputVariable" outputVariable="Ejecutar_OutputVariable" bpelx:invokeAsDetail="no" bpelx:inputHeaderVariable="miCabecera"/>
Veamos ahora otra forma de pasar nuestra cabecera siguiendo la recomendación inicial: incluir la cabecera en la definición del mensaje.
Leer más…
ADF tips: Integrando Web Services y Business Componets
A veces nos encontramos con la necesidad de mostrar en la misma fila de una tabla campos procedentes de diferentes fuentes de datos (‘data sources’). Puede darse el caso, por ejemplo, de que necesitemos cruzar mediante una operación ‘JOIN’ dos tablas que se encuentran en distintas Bases de Datos. También es posible que algunos atributos se encuentren en la B.D. y el resto deban obtenerse mediante un Web Service. Este post muestra los pasos a seguir para implementar una solución para este segundo escenario.
Vamos a describir de forma concisa el problema:
- Disponemos de una tabla en la B.D. donde se registran a modo de log todas las conexiones a nuestro sistema. Se guardan dos atributos, la fecha de conexión y la dirección IP de la máquina que se conectó.
- Tenemos que diseñar una pantalla que presente de forma tabular el log de conexiones con las siguientes columnas: fecha, IP y una tercera columna con el nombre del país al que pertenece la dirección IP.
Los dos primeros campos, los tenemos, pero la información correspondiente al tercero, ¿de dónde la obtenemos? Muy sencillo: existen varios Servicios Web que nos proporcionan este dato, uno de los más conocidos es GeoIP. Trabajar con él será fácil: nosotros le damos una dirección IP y el WS nos responde con el nombre del país.
¿Y cómo pegamos lo uno con lo otro, y en que lugar? El punto de encuentro está claro: en la capa del modelo, exactamente en el mismo ViewObject donde se realiza la consulta sobre la tabla de Log; añadimos un nuevo atributo llamado Country y guardamos los cambios. Una vez hecho esto, editamos la clase que implementa el registro del ViewObject y sobrescribimos el método getCountry() para que se comunique con el Web Service, consiga el país y lo devuelva. No lo hará directamente, usaremos un JavaBean para ocultar y envolver las llamadas al servicio.
Hay que hacer notar, que estamos planteando un caso muy sencillo, basta con utilizar un ViewObject de sólo lectura y no basado en entidad. Si los campos de la B.D. tuvieran que ser modificables, entonces diseñaríamos una vista basada en entidad y todo lo dicho para la columna externa (Country) seguiría siendo válido. Otro caso de uso un poco mas complicado contemplaría la posibilidad de trabajar con WS que proporcionan operaciones CRUD (create, read, update, delete). Entonces crearíamos entidades basadas en Web Services (y tendríamos que trabajar a nivel de entidad ocultando el origen de datos a los ViewObjects), pero eso lo dejamos para un futuro post.
Pongámonos manos a la obra:
1. Creamos un proyecto nuevo en nuestra aplicación y a partir del WSDL del servicio construimos un proxyService (de tipo JAX-WS, con el ‘endpoint‘ de la versión 1.2)
2. Creamos un JavaBean, para envolver la llamada al servicio. A partir de este Bean tendremos la posibilidad de crear un DataControl que nos permita trabajar de forma declarativa con los datos las estructuras del WS. El método getGeoIP() se encarga de hacer la llamada a la operación del WS que nos interesa.
3. Diseñamos el ViewObject (LogView1) a partir de la tabla Log y le añadimos un atributo nuevo, Country.
4. Sobrescribimos el método getCountry() en la implementación del registro de LogView1, para que obtenga a través d nuestro JavaBean el país correspondiente a la dirección IP.
5. Diseñamos la página con la tabla de log, arrastrando y soltando el DataControl correspondiente a la vista LogView1 sobre la página, ejecutamos y vemos el resultado final.
Presentación homogénea de columnas que provienen de diferentes fuentes de datos
De esta forma en cinco sencillos pasos hemos conseguido resolver el problema. Seguramente no es muy eficiente llamar al servicio para cada fila, para mejorar esta situación usaremos nuestro JavaBean. Teniendo en cuenta que este tipo de servicios web ofrece operaciones que permiten pasar como parámetro listas de elementos en vez de elementos individuales y de igual manera devuelven listas de resultados, podremos invocar la operación del WS una vez y mantener en un HashMap la lista de paises, evitando así una invocación por cada registro.
Ejecutar un servicio securizado desde otro Proxy Service
Recientemente nos hemos encontrado con la necesidad de ejecutar, desde un Proxy Service, una operación en un servicio securizado con Oracle Web Service Manager (OWSM). Desde un Proxy Service, no podemos especificar las credenciales a utilizar en la invocación o enrutado a otro servicio proxy.
La solución planteada e implementada ha sido la de crear un Business Service con un Service Account asociado que haga de intermediario entre ambos servicios, consiguiendo así especificar las credenciales para el consumo de dicho servicio
Crear Service Account
Dado que se pretende ejecutar una operación en un servicio securizado, se ha de crear una Service Account (cuenta de servicio si tenemos el entorno traducido) con las credenciales necesarias, en nuestro caso y con la finalidad de simplificar el ejemplo, de tipo estático.
Generar Business Service
Creadas las credenciales, es cuestión de crear un servicio de negocio o Business Service para que haga de puente entre nuestros dos servicios proxy. En el apartado de Configuración de transporte HTTP seleccionamos el tipo de seguridad correspondiente y la cuenta de credenciales creada anteriormente:
Configurar Proxy Service
Una vez podamos consumir las operaciones securizadas del servicio, se puede integrar en cualquier servicio proxy que tengamos creado agregando un routing, publish o service callout a nuestro servicio proxy.
De este modo, con tres sencillos pasos, conseguimos ejecutar servicios securizados desde otros proxy services.
soapUI: Probar Web Services de forma rápida y efectiva
Cuando nos dedicamos a realizar proyectos de integración de sistemas mediante Web Services, lo más probable es que nos pasemos una buena parte de nuestro tiempo probando el funcionamiento de los mismos, ya bien para testear el buen funcionamiento de los servicios que implementamos, o bien para hacer pruebas de los servicios que debemos consumir.
Por tanto, es importante disponer, en nuestro arsenal de herramientas, de una herramienta que nos permita realizar estas pruebas de una forma rápida. Hoy os sugiero utilizar la que estoy utilizando yo actualmente en distintos proyectos: soapUI.
En primer lugar, las ventajas que veo a soapUI son las siguientes:
1) Existe una versión libre que cubre las necesidades de test básicas.
2) Nos permite generar con facilidad el esqueleto de una petición. Sólo debemos rellenarla con los valores que queremos probar y listo.
Estadísticas de tiempo de un servicio en el ESB 10gR3
A veces, querremos obtener una pequeña estadística de tiempos de llamada a nuestros servicios. Si hemos publicado y consumimos estos servicios en Oracle Enterprise Service Bus 10g, éste nos ofrece la posibilidad de darnos el tiempo en milisegundos que ha consumido cada uno de los servicios implicados en el servicio:
Por tanto, a través de la consola podríamos hipotéticamente filtrar todas las llamadas a servicios de nuestro interés e, instancia a instancia, recopilar los tiempos que cada una de ellas ha tardado en procesarse y sacar la estadística a partir de estos datos. Es decir, un proceso largo y tedioso.
¿Es posible obtener estos datos de una forma más automatizada? La respuesta es que sí. Hay que ir a la fuente de los datos.
Facilitando el consumo de nuestros Web Services basados en PL/SQL
Una de las cosas más importantes a la hora de desarrollar web services es proporcionar un contrato detallado describiendo las operaciones y parámetros de nuestro servicio. Este contrato se describe mediante lenguaje XML en un fichero de tipo WSDL (Web Service Description Language). Cuanto más precisa sea la definición del servicio en su contrato, menos problemas tendremos de interpretación entre lo que entienden los que desarrollan el servicio y los que lo consumen. Además, un contrato preciso permite a los consumidores utilizar herramientas de generación automáticas que les facilitan la tarea de llamar al servicio, pudiéndose concentrar en la lógica de la interacción y no en la tecnología.
JDeveloper, desde su versión 9, proporciona herramientas para publicar web services basados en packages PL/SQL. De este modo, es fácil reaprovechar la lógica de negocio embebida en nuestras bases de datos Oracle. El único problema que tiene el wizard de JDeveloper, es cuando se trata de generar el contrato para un servicio que devuelve directamente una estructura XML, es decir, un objeto de tipo XmlType. En este caso, y ante la incapacidad de averiguar cuál es la estructura que devuelve el PL/SQL, JDeveloper pone en el contrato que el método devuelve cualquier XML (un elemento de tipo any o anyType de XSD).
Si queremos aplicar buenas prácticas, deberemos modificar el contrato generado para que contenga la descripción de la estructura que realmente devolvemos (y que nosotros, en calidad de proveedores del servicio, conocemos). En este post, explicamos cuáles serían los pasos a realizar.
Llamar a un Web Services desde Oracle Forms
Una de las ventajas que aporta Forms en tres capas ya desde la versión 9i pero en especial en la nueva versión 11g, es la integración con otras tecnologías.
En este post vamos a ver lo sencillo que es integrar forms, una tecnología de más de 20 años, con una de las tecnologías que han irrumpido últimamente en el mundo del desarrollo de aplicaciones y de soluciones TI empresariales, que no es otra que SOA y en concreto Web Services.
Para consumir un Servicio desde Forms hay que seguir los siguientes 4 pasos.
Nuestra red social |
|
|
