Artículos: Service-Oriented Architecture

Inicio
Ir a contenido
Ir a búsqueda

Iniciar sesión Cuenta
Cuenta de Oracle

Cerrar sesión
- Cuenta
- Ayuda
Cuenta de Oracle

Gestione su cuenta y acceda a contenido personalizado.
Iniciar sesión Crear una cuenta

Cuenta de Cloud

Acceda al panel de la nube, gestiono pedidos y más.
Iniciar sesión
País
Llamar

Integración de Oracle Business Process Management con Oracle Policy Automation:
Reglas de negocio en lenguaje natural, integración y orquestación para la agilidad de los procesos negocio.

Por Rodrigo Mondaca R.
Publicado en febrero 2012

Hoy en día existe una gran tendencia hacia la simplicidad, eficiencia y efectividad de las herramientas de TI que por diversas razones son más cercanas a los usuarios de negocio. El modelado de procesos de negocio, el diseño de las interfaces y el análisis de dichos procesos así como las reglas de negocios asociadas son tareas que cada vez con mayor frecuencia realizan usuarios que no tienen necesariamente un conocimiento técnico de la plataforma que sustenta la solución tecnológica. En particular, en el caso de los motores de reglas, si bien la definición de las reglas de negocio debiesen pasar en algún momento por el área de TI, el dinamismo y la rapidez con que éstas debiesen ser embebidas por los procesos de negocio hace que gran parte del ciclo de vida de una regla asociada a un proceso esté dominada por usuarios de negocio. Bajo este escenario es que cobra total sentido la interacción entre Oracle Policy Automation y Oracle Business Process Management para enfrentar el dinamismo de los procesos de negocio basados en políticas o reglas que evolucionan en el tiempo y que provienen en su mayoría desde el área de negocios.

Como Oracle podemos ofrecer una solución integrada que permite un modelado eficiente y colaborativo para el área de procesos, una orquestación ágil y completa para el área de TI y una transparencia y administración de todas las políticas y reglas para el área de negocios.

Índice

1. Descripción del artículo
2. Breve descripción de productos
3. Descripción de OPA y métodos de integración
4. Ejemplo integración OPA-BPM via WebServices
5. Anexos

1. Descripción del artículo

En este artículo se discutirán las formas que Oracle Policy Automation (OPA) brinda para su integración y se mostrará paso a paso cómo integrar OPA con Oracle Business Process Management (BPM) utilizando OPA Determination Server.

2. Breve descripción de productos

Oracle Policy Automation: OPA es una herramienta de desarrollo y ejecución de reglas de negocio resolviendo el problema de tomar las políticas y/o reglas de negocio para incorporarlas de manera eficiente a los procesos empresariales de modo de obtener resultados precisos, coherentes y auditables. Puede que las políticas y/o reglas automatizadas tengan que coincidir con una determinada legislación, reglamentos o simplemente con la necesidad de reflejar las últimas políticas internas de la empresa. Por ejemplo, determinadas políticas pueden ser diseñados para calcular los montos de pago, tomar decisiones sobre la elegibilidad, o calcular las calificaciones de riesgo.

OPA está compuesto por 3 pilares fundamentales:

Oracle Policy Modeling: Entorno de desarrollo completo e integrado para el desarrollo de reglas, normas y aplicaciones basadas en políticas.
Oracle Policy Automation: Motor que ejecuta y disponibiliza las reglas.
Oracle Policy Connectors: Conjunto de conectores pre-construidos para Siebel, CRM on Demand y SAP Java connector.

Oracle Business Process Management: Oracle BPM11g es una plataforma de gestión de procesos creada para soportar las estrategias empresariales de mejora continua de cualquier tipo de proceso de negocio. No importa la naturaleza del proceso: centrado en personas, basado en documentos, orientado a tecnología o de índole colaborativa; Oracle BPM11g permite su definición y automatización centrándose en las capacidades de flexibilidad, rastreo, facilidad de uso y medición requeridas por el negocio y sustentadas en una Arquitectura Orientada a Servicios que permite a TI alinearse con los cambios que demanden los procesos.

Oracle BPM11g comprende componentes para modelar y simular procesos desde el punto de vista de los usuarios de negocio e implementarlos en una arquitectura orientada a servicios para su adecuada ejecución en una plataforma SOA robusta, flexible, segura y escalable. Oracle BPM11g permite la colaboración entre las personas de negocio responsables de los procesos y las áreas tecnológicas a fin de automatizar y optimizar los procesos de negocio. El resultado es una mayor eficiencia y agilidad, menores costos para la organización y la gestión de diversos procesos en una sola plataforma. Oracle BPM aprovecha las inversiones existentes de TI y está especialmente adaptado para usuarios de la línea de negocios.

3. Elección de la vía de integración con OPA

Existen diversas formas de integración con el motor de reglas, la elección de la manera en que se realizará la integración dependerá principalmente de dos factores. En primer lugar, como está pensado el procesamiento de registros por el motor de reglas, es decir, si se procesa en lotes o en línea y en segundo lugar del desempeño que se requiere de dicho procesamiento. En la figura 1 se ilustran las cuatro formas de llamar al motor de reglas mediante distintos protocolos.

Figura 1:Tipos de integración con Oracle Policy Automation

Para una integración en línea se recomienda utilizar Oracle Determination Server y Oracle Web Determination. La diferencia entre estos dos es que Oracle Web Determination es una solución web preconstruida orientada a constuir formularios dinámicos en forma de entrevistas para recoger los datos necesarios por la regla modelada, mientras que Oracle Determination Server es un archivo de aplicación web (.war file) que se puede desplegar en cualquier Servidor de Aplicaciones Java EE. El archivo war se obtiene directamente de Oracle Policy Modeling y es generado en el momento en que la regla es compilada como muestra la Figura 2:OPA Build and Run Determination Server. Cabe destacar que Oracle Policy Modeling trae incorporado un Servidor Web de Aplicaciones Tomcat.

Una vez desplegada esta aplicación lo que se obtendrá será una lista de archivos WSDL asociada a las reglas compiladas. Como muestra la figura Figura 3: Available Services se generarán distintos archivos WSDL asociados a distintas versiones de OPA y a la forma en que el contrato es especificado encontrando una forma llamada “general” que utiliza nombres generales para las distintas variables y “specific” que contendrá el nombre de las variables que se hayan definido en el modelo de datos modelado previamente en Oracle Policy Modeling, si este modelo de datos no existe sólo se tendrán archivos WSDL genéricos.

Figura 2: OPA Build and Run Determination Server

Figura 3: Available Services

La regla que se utilizará en esta prueba es una que trae OPA de ejemplo llamada SimpleBenefits que consta de dos reglas, ambas retornan una variable boolean como respuesta. La que se utilizará en este caso considera como dato de entrada la edad de una persona y como muestra la Figura 4: Regla SimpleBenefits en Word, si esta edad es mayor que 13 años y menor que 20 años califica a dicha persona como “Teenager” respondiendo un valor de “true” de lo contrario la respuesta es un “false”

Figura 4: Regla SimpleBenefits en Word

4. Integración vía Web Service con Oracle BPM

En el siguiente ejemplo se muestran los pasos para integrar Oracle Determination Server con un proceso implementado en BPM. El proceso consiste en un requerimiento en que el solicitante debe indicar su edad, en base a esto se ejecuta una regla que esta modelada en OPA la cual indicará si el solicitante es calificado como “Teenager” o no. En caso de ser catalogado como “teenager” será necesaria una aprobación por el usuario U2, de lo contrario esta actividad será omitida y la solicitud sólo necesitará una revisión para completar el proceso.

Como muestra la Figura 5: Modelo del proceso en JDeveloper, dentro del proceso se efectúa una llamada a un servicio web que ejecutará la regla. La tarea “review” mostrará un resumen de los datos y arguments de salida de OPA para verificar que la regla se efectuó correctamente.

Figura 5: Modelo del proceso en JDeveloper

Desde el punto de vista de componentes la Figura 6: Vista de componentes de servicios ilustra la llamada al servicio.

Figura 6: Vista de componentes de servicios

Para implementar la llamada al servicio “OPA Service” se deben tener las siguientes consideraciones:

Es recomendable realizar la implementación mediante transformaciones como muestra la Figura 7: Utilizando transformaciones para la implementación del servicio dentro del proceso.

Figura 7: Utilizando transformaciones

El archivo WSDL generado por Oracle Determination Server es extenso ya que considera todas las excepciones posibles por lo que es sumamente recomendable probar el servicio web antes de comenzar la implementación. En este caso, el XML de entrada para probar servicio web de la regla que se está utilizando es el siguiente:

1 <soapenv:Envelope
2     xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
3     xmlns:typ="http://oracle.com/determinations/server/10.2/SimpleBenefits/assess/types">
4     <soapenv:Header/>
4     <soapenv:Header/>
5     <soapenv:Body>
6         <typ:assess-request>
7             <typ:global-instance>
8                 <typ:eligible_low_income_allowance outcome-style="value-only"/>
9                     <typ:eligible_teenage_allowance outcome-style="value-only"/>
10               <typ:claimant_income>
11                   <typ:number-val>13000</typ:number-val>
12               </typ:claimant_income>
13               <typ:claimant_public_housing_client>
14                   <typ:boolean-val>true</typ:boolean-val>
15               </typ:claimant_public_housing_client>
16               <typ:list-child>
17                   <typ:child id="child1">
18                       <typ:child_age>
19                           <typ:number-val>16</typ:number-val>
20                       </typ:child_age>
21                   </typ:child>
22                   <typ:child id="child2">
23                       <typ:child_age>
24                           <typ:number-val>8</typ:number-val>
25                       </typ:child_age>
26                   </typ:child>
27               </typ:list-child>
28            </typ:global-instance>
29         </typ:assess-request>
30     </soapenv:Body>
31</soapenv:Envelope>

Por otro lado, el XML de respuesta para el XML de entrada anterior sería:


1  <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
2      xmlns:i18n="http://www.w3.org/2005/09/ws-i18n"
3      xmlns:typ="http://oracle.com/determinations/server/10.2/SimpleBenefits/assess/types">
4      <SOAP-ENV:Header>
5          <i18n:international>
6              <i18n:locale>en_US</i18n:locale>
7              <i18n:tz>GMT-0800</i18n:tz>
8          </i18n:international>
9      </SOAP-ENV:Header>
10    <SOAP-ENV:Body>
11        <typ:assess-response>
12            <typ:global-instance>
13                <typ:eligible_low_income_allowance type="boolean" inferred="true">
14                    <typ:boolean-val>true</typ:boolean-val>
15                </typ:eligible_low_income_allowance>
16                <typ:eligible_teenage_allowance type="boolean" inferred="true">
17                    <typ:boolean-val>true</typ:boolean-val>
18                </typ:eligible_teenage_allowance>
19                <typ:claimant_public_housing_client type="boolean">
20                    <typ:boolean-val>true</typ:boolean-val>
21                </typ:claimant_public_housing_client>
22                <typ:claimant_income type="currency">
23                    <typ:number-val>13000.0</typ:number-val>
24                </typ:claimant_income>
25                <typ:list-child>
26                    <typ:child id="child1">
27                       <typ:child_age type="number">
28                            <typ:number-val>16.0</typ:number-val>
29                        </typ:child_age>
30                    </typ:child>
31                    <typ:child id="child2">
32                        <typ:child_age type="number">
33                            <typ:number-val>8.0</typ:number-val>
34                        </typ:child_age>
35                    </typ:child>
36                </typ:list-child>
37            </typ:global-instance>
38        </typ:assess-response>
39    </SOAP-ENV:Body>
40</SOAP-ENV:Envelope>

Es importante notar en el XML de entrada las líneas 8 y 9 en las que se les asigna el atributo “value-only” al “outcome-style”. Si estas variables, que son las de salida, no estuviesen inicializadas no se obtendrá respuesta alguna del servicio. A continuación en la Figura 8: XSL visual se muestra como inicializarlas en JDeveloper.

Figura 8: XSL visual

Para finalizar la Figura 9: Prueba proceso, datos de entrada y Figura 10: Prueba proceso, finalización muestran la ejecución de un caso de prueba en que el dato de entrada a la regla es la edad de una persona de 26 años.

Figura 9: Prueba proceso, datos de entrada

Figura 10: Prueba proceso, finalización

Como se puede apreciar la edad ingresada para el caso de prueba es 26 años, de esta forma la respuesta de la regla es “false” ya que una persona con 26 años no es considerado un “Teenager” por lo que de acuerdo al modelo del proceso no es necesaria una aprobación manual. La Figura 11: Traza tabular del proceso y la Figura 12: Traza gráfica del proceso muestran la traza del proceso completo.

Figura 11: Traza tabular del proceso