Un vistazo a las nuevas características de Oracle SOA Suite 12.2.1

Nuevas características de Oracle SOA Suite 12.2.1

Es la semana de Oracle Open World 2015, el mayor evento de Oracle del año. La sede es la ciudad de San Francisco, que durante una semana completa experimenta noticias importantes acerca de los nuevos productos y lo que viene en el camino para el resto de 2015 y el inicio de 2016.

Precisamente durante esta semana, Oracle ha lanzado la versión más reciente de Oracle SOA Suite 12c, la 12.2.1.

La siguiente información es obtenida directamente del sitio de la documentación de Oracle. Es una lista de las nuevas y más importantes características de esta nueva versión de Oracle SOA Suite 12c.

Es importante hacer notar que no se listan todas las características, para obtener el resto de la información es necesario hacer una detallada revisión de la documentación de Oracle. El propósito de la entrada es únicamente tener un pequeño resumen.

WebLogic Server 12.2.1
Oracle SOA Suite 12.2.1 corre sobre la nueva versión de WebLogic Server, también 12.2.1. Este release cuenta con algunas características muy interesantes:

• Multi-tenancy: nos da la posibilidad de compartir la infraestructura a múltiples organizaciones. Estas organizaciones son grupos conceptuales de participantes. Al permitir que un único dominio soporte distintos participantes (tenants), es posible hacer más eficiente el uso de recursos y al mismo tiempo eliminar los obstáculos que típicamente se presentan cuando se intenta compartir múltiples aplicaciones. Por ejemplo: el impacto de aplicaciones múltiples, las diferencias de seguridad, mezclas de datos y retos de administración.
• Java EE 7: es completamente compatible con la implementación de Java Enterprise Edition versión 7. ésta versión permite a los desarrolladores hacer uso de lo más novedoso de las APIs Empresariales de Java, que incluye nuevos modelos de programación.
• JDK 8:  está certificado para el uso con JDK 8.0 update 40 o superior.
• Docker: está certificado para correr dentro de un contenedor Docker. Docker es una tecnología de contenedor basado en Linux que permite crear rápidamente configuraciones de dominios de WebLogic tanto single-node como en cluster. Se puede montar sobre máquinas virtuales, tanto para ambientes de desarrollo como para ambientes productivos.

In-Memory SOA
Es posible aprovechar el caché de Coherence de WebLogic para ejecutar procesos de negocio no transaccionales en memoria. Esto mejora el rendimiento y la escalabilidad de los procesos de negocio. Las operaciones de lectura y escritura se realizan fuera del caché. También se mejora el rendimiento y la gestión de las bases de datos, ya que el costo asociado con la lectura y escritura a disco se reducen considerablemente.

In-Memory SOA permite a los procesos de corta duración, vivir en la memoria. El estado del proceso se escribe únicamente cuando existe una falla, o por lo regular, en intervalos diferidos haciendo uso de un hilo de tipo write-behind. La información del estado de BPEL es deshidratado y rehidratado hacia y desde el caché.

Parches a instancias en ejecución
Oracle SOA Suite 12.2.1 soporta el parcheo a instancias en ejecución, esto permite parchar las instancias que se encuentran corriendo de un compuesto y recuperar las instancias con fallas después de aplicar el parche en tiempo de ejecución. Únicamente se pueden incluir aquellas correcciones en el parche, que son compatibles con Composite Instance Patching. Usa el rol SOA Patch Developer en JDeveloper para realizar las correcciones y crear el parche.

 Composite Instance Patching permite realizar correcciones urgentes a los compuestos, pueden aplicarse a instancias de largos tiempos de ejecución. Es posible realizar cambios sin abortar las instancias que ya se están ejecutando. Por ejemplo, si se parcha una instancia que es usada en un proceso de negocio y ésta ha sido corregida con el parche, por ejemplo una transformación en un BPEL, entonces el proceso de negocio toma el cambio de las correcciones aplicadas a la instancia.

Cuando se está diseñando el parche en JDeveloper, el modo SOA Patch Developer deshabilita automáticamente los cambios que no pueden ser implementados en el parche.

Algunos cambios que sí se pueden incluir en un parche son los siguientes:

• Cambios a transformaciones XSLT que no se encuentren asociadas a algún esquema en particular.
• Cambios en las políticas de fallas.
• Sensores de datos.
• Análisis de datos.
• Cambios compatibles en BPEL como actividades de transformación, operaciones de asignación, etc.
• Propiedades de configuración de adaptadores JCA.

Debugging de mapeos XSLT
Es posible realizar debug sobre los mapeos XSLT usando el SOA Debugger. Se pueden agregar breakpoints en puntos estratégicos dentro del mapeo XSLT. En tiempo de debug, la ejecución se detiene en los breakpoints para que sea posible verificar los datos y la salida.

El SOA Debugger proporciona capacidades de debug remoto para mapeos de XSLT que hayan sido desplegados en el servidor de aplicaciones. También puede ser usado con los proyectos de Oracle Service Bus.

E2E JSON y JavaScript
Los compuestos SOA pueden utilizar E2E JSON. Esto significa que la interfaz REST puede recibir el mensaje de entrada en formato REST y transportarlo al engine de BPEL sin transformarlo a XML. El componente de BPEL puede usar alguna acción de JavaScript, y también usar JavaScript en condicionales e iteraciones para interactuar directamente con los objetos JSON. La referencia REST puede recibir el mensaje en formato REST desde el BPEL engine y transportarlo hacia el endpoint externo sin transformar el mensaje.

Las interfaces REST y los componentes BPEL soportan E2E JSON. Sin embargo, si se usan otros componentes, como Mediator, es necesario usar el estilo de los compuestos de la versión 12.1.3, que internamente mapean los recursos y verbos REST en operaciones de WSDL y esquemas, y transforman los mensajes de entrada en XML.


Referencias del sitio oficial de Oracle

Para mayores referencias acerca de estas nuevas características de Oracle SOA Suite 12.2.1, no dejen de consultar la documentación oficial de Oracle:

• http://docs.oracle.com/middleware/1221/wls/NOTES/whatsnew.htm#NOTES107
• http://docs.oracle.com/middleware/1221/soasuite/develop/GUID-6B218606-0B51-4E3B-BF5E-FDC11E8EF2B5.htm#SOASE-GUID-382A688E-62BB-4C14-8618-A1CF1A53D23A
• http://docs.oracle.com/middleware/1221/soasuite/develop/GUID-F2B6386E-0F68-4797-96D2-196800394FEF.htm#SOASE-GUID-4010E817-DF41-4CCC-B9CC-196EE6AB8905
• http://docs.oracle.com/middleware/1221/soasuite/develop/GUID-83DAC40D-A3FE-4530-8832-9C51FA63DE9D.htm#SOASE-GUID-C139673A-B884-4E55-A459-6874EF04E67E
• http://docs.oracle.com/middleware/1221/soasuite/develop/GUID-F11C4900-67D6-4434-83AC-8EB1D52BE238.htm#SOASE88068

Integración de Oracle SOA Suite 12c con Salesforce (sin Cloud Adapter)

La forma más sencilla de integrar Oracle SOA Suite con Salesforce en la versión 12c, es a través de Oracle Cloud Adapter for Salesforce.

El objetivo de la entrada del blog, es mostrar la parte difícil de esta integración, haciéndolo por la vía tradicional.

Para comenzar, debemos entender tres parámetros de seguridad que usa Salesforce para la autenticación:

• Usuario: Salesforce proveé un identificador único para cada usuario dentro de alguna organización. Este usuario es una dirección de correo electrónico
• Contraseña: La contraseña es una concatenación del password con el token de seguridad de Salesforce. Este token de seguridad es generado una vez que se resetea la contraseña del usuario. Por ejemplo, si la contraseña de un usuario es 123 y el token de seguridad es A12cfB83; entonces la contraseña para poder autenticarse en Salesforce deberá escribirse como sigue: 123A12cfB83
• Token de Seguridad: El token de seguridad es generado al mismo tiempo que se restablece la contraseña. Esto se puede realizar desde la interfaz de usuario de Salesforce. El token de seguridad es enviado a la dirección de correo electrónico del usuario.

Para poder interactuar con el servicio de Salesforce es necesario descargar el WSDL Para descargar el WSDL es necesario ejecutar los siguientes pasos:

• Ingresar a la cuenta de Salesforce (www.salesforce.com) con el usuario y password proporcionados para efectos de la integración.

•  Dar click en el menú del usuario y seleccionar Setup.

• Debajo de AppSetup, expandir Develop y dar un click en API para visualizar la página de descarga de WSDL.

 

• Dar click en Generate Enterprise WSDL y almacenar el WSDL en el directorio de nuestra preferencia.

 Para la interacción con los métodos de los servicios empresariales de Salesforce, es necesario autenticarse. La autenticación requerida es de una sola vía (One-way authentication) y mediante un certificado.

Para obtener el certificado que vamos a usar para la autenticación, es necesario ejecutar los siguientes pasos:

• Una vez que hemos ingresado al portal del Salesforce con un usuario y contraseña válidos, en el navegador podremos observar el ícono de un candado, como se muestra en la siguiente figura:

 

•  Debemos dar click en el candado y aparecerá una ventana. Damos un click en view certificates.
• Aparecerá otra ventana que nos da el detalle del certificado. Abrimos la pestaña Details y seleccionamos Copy to File:

 

•  Se abrirá el wizard para exportar el certificado. Presionamos el botón Next y elegimos la opción Base-64 encoded X.509 (.CER):

• Damos click en next y elegimos la carpeta donde deseamos guardar el certificado.

Hasta este punto, hemos completado una parte para la autenticación. Exportamos el certificado que vamos a presentar, al consumir el servicio de Salesforce.

El siguiente paso, es importar el certificado en nuestro servidor (WebLogic) para que al ejecutar nuestro servicio de integración, Oracle SOA Suite presente el certificado y se pueda autenticar con Salesforce.

Para realizar esto, es necesaro ejecutar las siguientes acciones:

• En una ventana de línea de comandos, navegar hasta la ruta de nuestro servidor, donde se encuentra el trust store. Esto generalmente es debajo de: MW_HOME\wlserver\server\lib.
• Ejecutar el siguiente comando: keytool -import -trustcacerts -alias SalesforceCA -file <Ruta donde se almacenó el certificado> -keystore Demotrust.jks -storepass DemoTrustKeyStorePassPhrase
• Para confirmar que el certificado se ha importado correctamente, debemos observar en la ventana de la línea de comandos el mensaje de confirmación.
• Reiniciar el servidor para que los cambios tengan efecto.

Hasta este punto, nuestro servidor de SOA debe ser capaz de hablar con el servidor de Salesforce, ya que éste último autentica con el certificado que acabamos de importar.

Finalmente, estamos el posibilidad de ejecutar algún método del WSDL empresarial que descargamos de Salesforce en pasos anteriores. Para efectos de esta prueba y dado que tenemos la información necesaria para iniciar una sesión en Salesforce (usuario y contraseña), utilizaremos el método login del WSDL que descargamos.

En JDeveloper 12c crearemos una aplicación de tipo Service Bus llamada Salesforce y un proyecto, también de tipo Service Bus, llamado SalesforcePoC:

 

En el proyecto creamos una serie de carpetas para mantener correctamente organizados los artefactos del proyecto: BusinessServices, ProxyServices, Resources (XSL, XQuery, etc), WSDL y XSD. De tal forma que nuestro proyecto deberá verse como en la figura anterior.

Dentro de la carpeta WSDL, colocamos el WSDL empresarial de Salesforce que descargamos en pasos anteriores (esto lo hacemos directamente en el explorador de Windows copiando y pegando el archivo directamente en la carpeta del proyecto).

Creamos un XSD y un WSDL que represente el formato de nuestros mensajes de entrada y salida de nuestro servicio y los métodos que contendrá (en este caso sólo colocamos un método que se llama login). Este WSDL es independiente del WSDL empresarial. Es el contrato propio del servicio que vamos a construir y tendrá el mensaje de entrada y salida que mejor nos convenga. Como se muestra en las siguientes imágenes:

El siguiente paso es crear el Business Service que representa al servicio de Salesforce. Para esto usaremos el componente HTTP de nuestra paleta. Seguiremos el wizard, basando el Business Service en el WSDL empresarial que descargamos de Salesforce y que ya tenemos en nuestro proyecto.

 

Posteriormente, creamos el pipeline y el proxy, basados en el WSDL que construimos. Lo haremos haciendo uso del componente pipeline de la paleta. Usaremos el wizard para la creación tanto del pipeline como del proxy. No olvidemos que se debe crear basado en el WSDL que nosotros construímos.

Finalmente, implementamos el pipeline con la lógica correspondiente para el método de login. Para esto agregaremos un operational branch (tedremos un único método: login, ya que así definimos nuestro WSDL).

Antes de hacer la llamada al servicio de Salesforce (mediante un service callout), debemos crear un mensaje de entrada del método login del WSDL empresarial. Para esto, usamos una transformación de XQuery (hay que recordar que el método login recibe como entrada el nombre del usuario y la contraseña, que es una concatenación del password y el token de seguridad, esta implementación la hacemos directamente en el XQuery). La actividad assign del flujo de mensajes, hace uso de esta transformación.

Una vez que hemos formado el mensaje de entrada correcto al servicio de Salesforce, hacemos la llamada (service callout).

Finalmente, una vez que el servicio de Salesforce responde, usamos una actividad de tipo replace para que por medio de otra transformación de XQuery, podamos convertir el mensaje de salida de Salesforce al formato del mensaje de salida de nuestro servicio.

 

Desplegamos el servicio y ejecutamos las pruebas correspondientes.

Nota importante: Adicional, en nuestro caso, incluimos un manejo de errores para poder capturar las excepciones del servicio de Salesforce y transformar este mensaje a un mensaje de falla con formato definido para nuestro servicio.