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.
- 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 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.
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:
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:
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.
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:
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.
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.
Existe una manera de obtener el proyecto para entender mas su implementación.
ResponderBorrarSaludos.