Modelación Orientada al Proceso para SOA, Parte 2: Patrones de procesos

Diseños para aplicar la infraestructura de descomposición a nuevas situaciones

Conozca un conjunto de patrones de procesos empresariales alineados a SOA que usan la técnica de descomposición descrita en la Parte 1. Cada patrón pertenece a una capa de la infraestructura de descomposición. Hay patrones para procesos de consumidores, de larga duración y de actividad humana y para procesos de corta duración. En esta serie, aprenda una técnica nueva de descomposición de procesos empresariales que puede ayudar a especificar procesos empresariales que estén alineados a una Arquitectura Orientada a Servicios (SOA).

Ruud Schoonderwoerd, Tư vấn, IBM

Ruud Schoonderwoerd photoRuud Schoonderwoerd es consultor de administración y arquitecto de TI para IBM Global Business Services en el Reino Unido. Trabaja en programas grandes de TI en sitios de clientes de IBM, con enfoque en BPM, SOA y métodos de entrega.



18-08-2011

Patrones de procesos

Parte 1 describió una técnica de descomposición de procesos que puede usar para alinear los procesos empresariales a una arquitectura objeto basada en la Arquitectura Orientada a Servicios (SOA). Esa técnica organiza los procesos de acuerdo con una pila de capas débilmente acopladas que se asemeja mucho a una pila de soluciones SOA, como muestra la Figura 1.

Figura 1. Pila de procesos alineados a SOA
Pila de procesos alineados a SOA

Ese artículo exhibe a la técnica al demostrar patrones de procesos empresariales que la usan. Los patrones son una forma muy útil de representar aspectos comportamentales recurrentes de las soluciones de TI y pueden ser aplicados a modelos de proceso.

Patrones de Van der Aalst

Muchos profesionales consideran idénticos los "patrones de procesos empresariales” y los patrones descubiertos por Wil van der Aalst y Arthur ter Hofstede (también conocidos como “patrones de van der Aalst"). Los patrones de Van der Aalst proporcionan los conceptos que una notación completa de modelación de procesos empresariales, o plataforma de BPM, debe soportar. Son útiles para evaluar las posibilidades de esas notaciones o plataformas (consulte Recursos).

Este artículo no enfoca los patrones de van der Aalst, sino lo que es (o no es) un modelo de proceso bien proyectado — independientemente de la notación o plataforma — a través de los principios de descomposición explicados en la Parte 1.

Se ofrecen esos patrones como ejemplos; también podrá aplicar la infraestructura de descomposición a nuevas situaciones.

Se organizan los patrones de acuerdo con las capas de la Figura 1, comenzando por la capa de procesos de consumidores.

Se facilitan las siguientes informaciones respecto a cada patrón en este artículo:

Problema
¿Qué problema el patrón intenta resolver?
Solución
Informaciones adicionales acerca de la solución más allá del diagrama de procesos. ¿Por qué esa solución es mejor que las demás?
Controlador del proceso
Qué controla el flujo del proceso en ese patrón y cómo, normalmente, se implementa el proceso.
Reutiliza
Otros patrones reutilizados en el patrón.
Ejemplo
Un ejemplo de dónde se puede usar ese patrón.

Notación

Los patrones de procesos empresariales usan la Notación de Modelación de Procesos Empresariales (BPMN) V1.1. BPMN (consulte Recursos) es el estándar de la industria para la notación gráfica de procesos y es soportado por una gama amplia de herramientas de modelación de procesos, como IBM® WebSphere® Business Modeler.

La BPMN que se usa aquí fue ampliada (según lo permitido por el estándar) con los iconos mostrados en la Figura 2.

Figura 2. Clave para los diagramas
Clave para los diagramas

El estándar BPMN soporta dos tipos de subprocesos: incorporados e independientes. Los subprocesos incorporados pertenecen al proceso padre. En realidad, son una parte contraída de ese proceso. Los subprocesos independientes pueden ser usados en varios procesos. Sin embargo, en los patrones siguientes, siempre que se usa la notación de subproceso (“+” dentro de un cuadrado), significa una llamada a otro proceso, que es independiente.

En los diagramas de proceso de este artículo, se puede abreviar la palabra “transacción” como "Txn."

Siguiendo el orden de las capas de la Figura 1, el resto de este artículo trata de:


Patrones de proceso de consumidor

Los patrones de proceso en la capa de consumidor son diseños de procesos específicos para aplicaciones que representan los canales de entrada de una empresa. Invocan servicios de procesos empresariales que son implementados por otros procesos empresariales de corta o larga duración u operaciones de servicio implementados por actividades automatizadas. Toda la lógica específica para canales y aplicaciones reside en esta capa.

Transacción de autoservicio

Figura 3. Transacción de autoservicio
Transacción de autoservicio
Problema
Necesita modelar el proceso de ingresar una transacción comercial a través de formularios de una interfaz de usuario basada en la Web. Se puede invocar la misma transacción empresarial a través de canales diferentes.
Solución
El modelo de proceso es un flujo de interfaz de usuario con llamadas a servicios de validación antes de la ejecución de la transacción. Combinado al patrón ejecutar transacción, este patrón ayuda a posibilitar la separación entre los procesos empresariales específicos para el canal y los independientes del canal. También evita el trabajo manual innecesario de corrección de errores, generado por transacciones Web falladas, al reportar los errores al usuario.
Controlador de proceso
Capa del consumidor, flujo de pantalla. Normalmente, se implementa eso a través de cualquier tecnología de interfaz de usuario, como Java™Server Pages (JSPs) con un controlador de flujo de página.
Reutiliza
Ejecutar transacción, un patrón de proceso de corta duración.
Ejemplo
La mayoría de las transacciones online involucran el relleno de formularios, como un proceso de pedido o una solicitud de hipoteca.

Transacción de teclado con remisión

Figura 4. Transacción clave con remisión
Transacción clave con remisión
Problema
Es una variación del patrón de transacción de autoservicio que se mencionó anteriormente. En este caso, un asistente está tecleando los detalles de una transacción, provenientes de un formulario de papel o de una conversación telefónica con el cliente. Si la transacción resulta en errores, el asistente puede optar por remitirlo a otra persona, como un supervisor o especialista.
Solución
El usuario puede remitir la transacción a un especialista en el caso de que haya problemas. Eso normalmente ocurre si se rechazan las validaciones o si la transacción en sí (si es de corta duración) retorna una excepción a nivel empresarial.
Controlador de proceso
Capa del consumidor, flujo de pantalla. Normalmente, se implementa eso a través de cualquier tecnología de interfaz de usuario, como JSPs con un controlador de flujo de página.
Reutiliza
El patrón de proceso de corta duración ejecutar transacción y el patrón de proceso de larga duración resolver problemas en la transacción.
Ejemplo
Alguien trata de comprar un teléfono celular en una tienda pero, debido a alguna razón desconocida, la transacción de pedido no es aceptada por el sistema central. Para no perder el negocio, el asistente de la tienda remite el pedido a las operaciones centrales, pero recibe el pago del cliente (como uno de los pasos anteriores del proceso) y, en cambio, entrega el teléfono. Luego, las operaciones centrales pueden resolver cualquier problema pendiente con la transacción de pedido para que el aprovisionamiento de red pueda ocurrir.

Transacción de papel con gestión de contenido empresarial (ECM)

Figura 5. Transacción de papel con ECM
Transacción de papel con ECM
Problema
Un formulario de papel llega a la organización y es enrutado al departamento de ECM para escaneo, almacenamiento y extracción de datos.
Solución
El aspecto clave de ese patrón es la invocación de una transacción a través de los datos extraídos, como muestra la Figura 6. Ese patrón presupone que el punto fuerte del sistema de ECM no es el área de manejar las excepciones empresariales provenientes de esta transacción. Se invoca una variación de la transacción que tiene la resolución de problemas incorporada, a través de un mecanismo del tipo "disparar y olvidar".
Controlador de proceso
Capa del consumidor, sistema de ECM.
Reutiliza
Ejecutar transacción con resolución de problemas, un patrón de proceso de larga duración.
Ejemplos
Procesamiento de cambios de dirección enviados en un formulario de papel a una organización gubernamental.

Transacción de empresa a empresa (B2B) en lote con errores rechazados

Figura 6. Transacción B2B en lote con errores rechazados
Transacción B2B en lote con errores rechazados
Problema
Una empresa expone una interfaz a organizaciones externas para recibir ciertas transacciones en formato de lote.
Solución
Se extraen del lote los datos referentes a transacciones individuales y se les invocan individualmente, uno por uno, como procesos empresariales de corta duración. Las excepciones resultantes de las transacciones son cotejadas y fusionadas para devolución a la organización que llama.

El canal de B2B reutiliza la misma lógica de transacción que está disponible también para los otros canales. Por cuestiones de rendimiento, en casos de volúmenes extremadamente altos, implementar el patrón a través de los principios de SOA que fueron mencionados tal vez no sea la mejor solución. En lugar de eso, la implementación puede, por ejemplo, basarse en scripts que operan directamente en la base de datos.

Controlador de proceso
Capa del consumidor, plataforma del tipo ESB.
Reutiliza
El patrón de proceso de corta duración ejecutar transacción.
Ejemplo
Una organización de telecomunicaciones móviles envió a servicios de directorio sus asignaciones de números referentes a la semana anterior. Los servicios de directorio procesan ese lote de acuerdo con el patrón.

Hay muchas variaciones en ese caso de ejemplo de B2B.

  • Transacción en lotes con errores corregidos

    En ese caso, se envía la transacción como en el patrón transacción de papel con gestión de contenido empresarial (ECM).

  • Transacciones individuales de B2B

    Normalmente, se proporcionan interfaces como un servicio web (a través del protocolo SOAP sobre HTTP) y el proceso constaría de un único paso que envía la transacción.

Aunque aquí se usa un modelo de proceso para ilustrar la reutilización de procesos o servicios por parte del canal de B2B, ésa no es siempre la mejor forma de modelar un canal de B2B.


Patrones de procesos de larga duración

Los procesos en la capa de procesos de larga duración son invocados directamente por la capa de consumidor, o como resultado de eventos en la capa de procesos de corta duración. Los procesos de larga duración se invocan a través de servicios de procesos empresariales en la arquitectura de referencia de SOA. Normalmente se implementan a través de una plataforma de gestión de procesos empresariales (BPM).

Ejecutar transacción con resolución de problemas

Figura 7. Ejecutar transacción con resolución de problemas
Ejecutar transacción con resolución de problemas
Problema
Un proceso de consumidor necesita ejecutar una transacción pero no tiene la posibilidad de manejar las excepciones (problemas) que puedan surgir.
Solución
Un proceso de larga duración que incluye la ejecución de la transacción como un subproceso de corta duración y maneja las excepciones correspondientes como un subproceso de larga duración. Ese patrón permite el procesamiento de transacciones con resolución de problemas y sin acoplamiento fuerte entre las dos funciones.
Controlador de proceso
Capa de proceso empresarial (de la arquitectura de referencia de SOA), proceso de larga duración orquestado, implementado a través de un motor de BPM.
Reutiliza
El patrón de proceso de corta duración ejecutar transacción y el patrón de proceso de larga duración resolver problemas en la transacción.
Ejemplo
Transacciones de B2B en las cuales los asociados de negocios no cuentan, ellos mismos, con recursos de corrección de errores. Transacciones offline basadas en papel.

Acuse de recibo de validación

Figura 8. Acuse de recibo de validación
Acuse de recibo de validación
Problema
Un proceso de consumidor necesita someter una transacción (que representa un pedido en la Figura 8). Es conveniente representar la transacción como un proceso de larga duración. Sin embargo, el cliente necesita saber de inmediato si las validaciones básicas tuvieron éxito o no. También necesita un descriptor de contexto para el proceso, con el objetivo de recuperar las informaciones de estado en una fase posterior.
Solución
Existen varias soluciones. La que se describe aquí es un proceso de larga duración que comienza por validaciones de corta duración, seguidas por un paso que comunica el ID del pedido al consumidor, seguido por el proceso de larga duración para atención de pedidos. Ese patrón permite que un proceso de larga duración retorne un descriptor de contexto o resultados provisionales antes que sus aspectos de larga duración inicien.
Controlador de proceso
Capa de proceso empresarial (de la arquitectura de referencia de SOA), proceso de larga duración, implementado a través de un motor de BPM.
Reutiliza
No se aplica
Ejemplo
La mayoría de las aplicaciones donde se está realizando un pedido y que necesitan una confirmación inmediata del pedido, pero la atención del pedido es un proceso de larga duración.

Existe una solución alternativa para ese problema (que el autor prefiere). Se puede tener un proceso separado de corta duración, como hacer pedido. El resultado del proceso es un evento del tipo "disparar y olvidar" que resulta en el lanzamiento del proceso de larga duración atender pedido. Esta solución, efectivamente, es lo que está en el patrón ejecutar transacción.

Resolver problemas en la transacción

Figura 9. Resolver problemas en la transacción
Resolver problemas en la transacción
Problema
Hay problemas (errores o excepciones) en una transacción que deben ser resueltos por un especialista (o más) en una empresa.
Solución
Tener un proceso de larga duración separado destinado a la resolución de problemas, que es específico para una transacción o para los problemas que surjan (dependiendo de dónde están los puntos en común—el ejemplo presupone la primera alternativa). Sin embargo, es separado de la transacción — por tanto, la aplicación de consumidor puede optar por invocarlo (o no) si la transacción resulta en una excepción o más.

Dependiendo del tipo de problema de la transacción, se asigna el problema a un subproceso de resolución específico para el tipo de problema. Puede ser simple, que involucra un único especialista, o complejo, que involucra sus propios procesos de larga duración. Varios problemas se resuelven en secuencia. La salida de cada subproceso de resolución de problemas es un distintivo que indica lo que se ha hecho con la transacción.

Por ejemplo: una transacción puede haber sido reenviada con éxito, reenviada sin éxito y con problemas restantes o bien totalmente rechazada. Si los problemas permanecen, son reasignados de acuerdo con su tipo. Generalmente no es posible resolver problemas en paralelo, ya que la resolución puede resultar en un cambio en la carga útil de la transacción.

Esa solución posibilita la reutilización en varias formas:

  • Al separar la resolución de problemas de la transacción, varios consumidores — cada uno de ellos atendiendo a usuarios con diferentes niveles de habilidad — pueden invocar ese proceso en diferentes circunstancias.
  • Al tener subprocesos separados y específicos para los problemas, es posible reutilizar los subprocesos en varias transacciones donde pueden ocurrir los mismos problemas.
Controlador de proceso
Capa de proceso empresarial (de la arquitectura de referencia de SOA), proceso de larga duración, implementado a través de un motor de BPM.
Reutiliza
El patrón de actividad humana resolver problema simple y el patrón de proceso de larga duración resolver problema complejo.
Ejemplo
Transacciones de B2B en las cuales los socios no cuentan, ellos mismos, con recursos de corrección de errores. Transacciones offline basadas en papel en las cuales no hay retroalimentación inmediata a los clientes, como ocurre en las transacciones online.

Resolver problema complejo

Problema
Hubo un problema en una transacción que requiere la entrada o la aprobación de varios expertos.
Solución
Actualmente, no hay un patrón específico identificado para este proceso de larga duración. Hay varios casos diferentes que incorporan elementos de otros patrones definidos en este artículo. Está listado en este texto sólo como patrón de referencia.
Controlador de proceso
Capa de proceso empresarial (de la arquitectura de referencia de SOA), proceso de larga duración, implementado a través de un motor de BPM.
Reutiliza
No se aplica
Ejemplo
Revisión por expertos, investigar posibles fraudes, varias aprobaciones.

Proceso orquestado de atención de alquiler

Figura 10. Proceso orquestado de atención de alquiler
Proceso orquestado de atención de alquiler
Problema
Cuando un cliente alquila algo, es conveniente que la organización siga la jornada del cliente del inicio al fin. El proceso no está bajo el control total de la empresa, ya que depende del cliente para recolectar el elemento alquilado y devolverlo a tiempo. Es posible que el cliente no siga los pasos determinados exactamente cuando sea necesario.
Solución
Se lanza el proceso de alquiler como resultado de un nuevo evento de reservación. Se asigna inmediatamente el recurso que se está alquilando. Lo que sucede después no depende de la lógica empresarial (como el gateway de decisión de BPMN usado en los otros patrones), sino de eventos externos como:
  • El cliente cancela la reservación.
  • El cliente viene a iniciar el alquiler.
  • La hora límite de la reservación vence.
Se usa el gateway de BPMN basado en eventos. El evento que ocurre primero determina el camino del proceso empresarial. Se presupone que el evento uso del recurso iniciado es accionado por un proceso separado de corta duración que registra el inicio del alquiler (por ejemplo: el cliente recolectando el elemento). Se presupone que el evento uso del recurso concluido es accionado por un proceso semejante de corta duración que registra el fin del alquiler.

El evento uso del recurso concluido también puede resultar en un proceso totalmente separado: preparar el recurso para el próximo uso. Eso no forma parte de la jornada del cliente.

Controlador de proceso
Capa de proceso empresarial (de la arquitectura de referencia de SOA), proceso de larga duración, implementado a través de un motor de BPM.
Reutiliza
No se aplica.
Ejemplo
Alquiler de DVD, reservación de hotel, alquiler de auto.

Patrones de actividad humana

Actividades humanas es la capa que representa las actividades en procesos orquestados de larga duración (o procesos de flujo de trabajo) que son realizadas por una única persona. Las actividades humanas aparecen en la lista de trabajo de alguien que tiene el rol adecuado antes que la persona comience a trabajar en la actividad.

Resolver problema simple

Figura 11. Resolver problema simple
Resolver problema simple
Problema
Hubo un problema en la transacción que puede ser resuelto por una única persona. Por tanto, es definido como un problema “simple”, aunque la actividad pueda requerir calificaciones de alto nivel o pericia profesional. Debe definir los pasos realizados por esa persona para manejar el problema. Es posible que se necesite reejecutar la transacción; por tanto, la persona que resuelve el problema necesita retroalimentación inmediata para saber si la transacción fue exitosa o no—y necesita tiempo para actualizar la transacción si es necesario.
Solución
Es una actividad humana que se inicia cuando el usuario la selecciona en una lista de tareas (presentada por una interfaz de usuario de BPM). La actividad está incluida en el proceso resolver problemas en la transacción. Básicamente, el modelo de proceso representa un flujo de pantalla. El resultado de la actividad es comunicado al proceso de larga duración que llama y puede ser cualquiera de los siguientes:
  • La transacción se concluyó exitosamente.
  • Se rechazó la transacción y se informó al cliente.
  • Se salvó la transacción, con una solicitud de más informaciones del cliente.
  • La transacción tiene más problemas que resolver.
  • Se canceló la actividad.
  • Se necesita reasignar la actividad a otra persona.

Los pasos definidos en este texto son realizados por la misma persona y tienen una entrada y una salida claramente definida. La ejecución de la transacción forma para de esa actividad — por tanto, la persona que trabaja en la actividad obtiene retroalimentación inmediata respecto a si fue exitosa o no.

Controlador de proceso
Capa de actividad humana, flujo de pantalla.
Reutiliza
El patrón de proceso de corta duración ejecutar transacción.
Ejemplo
Cualquier proceso que tiene un paso de resolución de problemas realizado por personas.

Patrones de procesos de corta duración

Los procesos orquestados de corta duración frecuentemente representan transacciones empresariales que tienen una relación directa con los objetivos del cliente. Los patrones a continuación están relacionados con el procesamiento de esas transacciones.

Ejecutar transacción

Figura 12. Ejecutar transacción
Ejecutar transacción
Problema
Necesita un proceso empresarial que implementa una transacción y que puede ser reutilizado en varios canales (consumidores). Esa transacción puede ser hacer un pedido o una solicitud o cambiar los datos de la empresa.
Solución
Los elementos de una transacción contenidos en un proceso empresarial de corta duración. El primer paso en cualquier transacción es realizar validaciones empresariales. Pueden realizarse en paralelo, como muestra la Figura 12, o en secuencia. Se realiza cada validación y se cotejan los resultados para devolverlos a la aplicación que llama en caso de anomalía. Después de las validaciones se actualizan los sistemas subyacentes, en paralelo, como se muestra, o en secuencia.

Muchas transacciones requieren un proceso de atención. En ese ejemplo, será lanzada "entre bastidores" como resultado del evento que se generó. Se devuelve el ID de transacción al consumidor para interrogar el estado de los procesos de atención.

Ese patrón se aplica a varios tipos de transacción, como hacer un pedido, solicitar una hipoteca o una licencia de conducir. Permite que las solicitudes online de los consumidores obtengan retroalimentación inmediata respecto al éxito de la transacción. El usuario puede aplicar correcciones e intentar reenviar. Las aplicaciones offline para consumidores (por ejemplo: las que no tienen usuario) pueden reutilizar esa función y asegurar que se resuelvan los problemas al llamar un proceso que usa el patrón resolver problemas en la transacción o al llamar un proceso que usa directamente el patrón ejecutar transacción con resolución de problemas.

Controlador de proceso
Capa de procesos empresariales, proceso de corta duración, implementado a través de un motor de BPM o un código personalizado (Java, por ejemplo).
Reutiliza
No se aplica.
Ejemplo
Hacer un pedido.

Ejecutar transacción con compensación

Figura 13. Ejecutar transacción con compensación
Ejecutar transacción con compensación
Problema
El mismo problema de ejecutar transacción, pero también necesitamos asegurar que la transacción sea atómica, lo que significa que los servicios llamados desde dentro del proceso retroceden al estado anterior si uno de ellos falla.
Solución
Es una versión avanzada de ejecutar transacción. Un evento de compensación desencadena los eventos intermedios individuales dentro del proceso. Cada uno de esos eventos intermedios resulta en la llamada a la función deshacer de los servicios que la tienen. Aunque los pasos de validación ejecutados antes de las acciones de confirmar (las actividades de "actualizar sistema") deben asegurar que las acciones de confirmar sean exitosas, en la práctica no se puede confiar en eso todo el tiempo. Ese patrón implementa un enfoque muy cuidadoso para cubrir las anomalías de las confirmaciones.
Controlador de proceso
Capa de proceso empresarial, proceso de corta duración, implementado a través de un motor de BPM.
Reutiliza
No se aplica.
Ejemplo
Hacer un pedido.

Resumen

Este artículo demostró los patrones de procesos empresariales que usan una técnica de descomposición para alinear los procesos empresariales a una arquitectura SOA. Ha conocido patrones que puede usar al definir procesos empresariales y que deben implementarse en una solución SOA como la arquitectura de referencia IBM SOA. Cada patrón representa un proceso que forma parte de esas capas de proceso: proceso de consumidor, proceso de larga duración, proceso de actividad humana y proceso de corta duración.

Recursos

Aprender

Obtener los productos y tecnologías

Comentar

  • Participe en el foro de arquitectura de TI para intercambiar recomendaciones y técnicas y compartir otras informaciones relacionadas con el tema amplio de la arquitectura de TI.

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=SOA y servicios web
ArticleID=453823
ArticleTitle=Modelación Orientada al Proceso para SOA, Parte 2: Patrones de procesos
publish-date=08182011