Toda la información de producto en wiki.bizagi.com aplica para Bizagi BPM Suite 9.1.X.
Para las nuevas versiones de Bizagi BPM Suite (10.X y superior) visite la Guía de Usuario.
 

Scopes

De


Transacciones de larga duración o Scopes

Bizagi es una herramienta colaborativa que permite que muchos usuarios estén trabajando sobre un mismo proceso al mismo tiempo. Para garantizar la integridad de la información, Bizagi maneja un concepto llamado Transacciones de larga duración. Esta es una tecnología esencial cuando mucha gente trabaja simultáneamente en un proyecto impidiendo que los distintos usuarios editen los mismos datos y en Bizagi se llaman Scopes.

Para ello, la información de todas las actividades son guardadas en el Scope y van a la base de datos únicamente cuando los usuarios dan clic en Siguiente, es decir, cuando están seguros de que se quiere terminar con la actividad.

Cuando un usuario está entrando información en el Portal de Trabajo en una actividad es posible guardar (Save) la información para continuar con el caso mas adelante dando clic en el botón Guardar Sin embargo, esta información aun no ha sido validada, ya que las reglas que aseguran la integridad de los datos se ejecutan es cuando el usuario da clic en Siguiente (Next), es decir cuando el usuario está seguro de que quiere terminar esta actividad.



Entre las expresiones de validación están las expresiones que validan la obligatoriedad de los campos.



En el caso de que el usuario de clic en Guardar (Save) la información va a permanecer en el Scope de la actividad y no en la base de datos.

El mecanismo para acceder a la información de cualquier proceso es XPath. El XPath navega los datos del proceso en cualquier parte: formas, reglas de negocio, expresiones, cartas, notificaciones, etc.

Hay algunas situaciones dentro de las actividades en donde se requiere actualizar o consultar información en o desde un sistema externo y presentarlo inmediatamente en la forma web sin salir de la misma actividad del proceso. En esos casos se debe tener en cuenta lo siguiente :

1. En el caso de envió de información o validación de información que está en Bizagi, hacia un sistema externo (Bizagi es el desencadenador) se deben utilizar expresiones para obtener dicha información. Para ello se deben utilizar los métodos WithScopess.

2. Si se está actualizando información directamente desde un sistema externo a una actividad en Bizagi, el XML que enviá el sistema externo debe invocar la capa SOA de Bizagi e indicar el Caso y la actividad en Bizagi en el que se desea hacer la actualización.


Ejemplo 1 de Scopes : Comunicarse con Sistemas Externos

En el siguiente ejemplo, se explica como funcionan los métodos WithScopess de la capa SOA de Bizagi para consultar un sistema externo.

Vamos a suponer que en un proceso de Solicitud de Compras se requiere saber si los productos están en un stock en el momento en que el usuario solicita los productos. En este caso, se puede crear un Botón en la forma que ejecute una expresión en la cual se toman los datos del Scope de los productos solicitados en la tabla, se crea el XML para invocar el servicio externo y luego se toma la respuesta del servicio externo y se guarda en el Scope de Bizagi para mostrar en la misma tabla cuáles productos están en Stock y cuales no.


1. Verificamos el modelo de datos de nuestro proceso para poner el Flag (atributo) InStock.



2. Creamos los esquemas dentro de Bizagi Studio que van a ser utilizados para llamar la interfaz.. Se debe generar el esquema teniendo en cuenta que se parte de la entidad aplicación del proceso (en este ejemplo, Purchases) y el archivo de transformación (XSL) se crea según el esquema del servicio externo. Si desea mas información sobre como crear estos esquemas, puede ir al articulo de Xml Schemas 



3. Modificamos la forma de la actividad Crear Orden de Compra (Create Purchase Request) para que muestre el atributo en la tabla y también colocamos un campo tipo Botón debajo de la grilla para llamar la expresión.




4. Creamos la expresión que será ejecutada en el botón. Se deben crear dos variables al principio de la regla de negocio (). Luego, vamos a crear la regla con dos cajas de expresión y una caja de Interfaz. En la primera caja de expresión vamos a obtener la información utilizando los métodos de Bizagi SOA WithScopess, luego esa información la transformamos  y la enviamos al servicio externo utilizando la caja de Interfaz.









Al hacer doble clic sobre la caja de Interfaz, aparece el asistente para configurar las propiedades de la interfaz. Toda la configuración queda guardada en Sistema – Interfaz de Bizagi para que pueda ser administrada mas adelante.



Seleccionamos el método del Servicio Web



Luego seleccionamos la variable que contiene la información para enviar al servicio externo, en este caso la tiene la variable string SRequest declarada y configurada en el paso anterior.



Seleccionamos el parámetro que va a guardar la respuesta del servicio.



5. Finalmente, tomamos la respuesta del servicio y la guardamos en Bizagi. Generalmente se requiere una transformación para guardar esta información en Bizagi. Mas información sobre transformaciones en Bizagi las puede encontrar en este articulo (link).



El servicio que se esta invocando en este ejemplo, simplemente verifica el código del producto, modifica la información enviada por Bizagi y cambia el valor del tag InStock dentro del mensaje de comunicación. Por esa razón se utiliza el método fromXmlToEntityWithScopess que no realiza transformación alguna antes de guardar la respuesta.

Después de dar clic en el botón de la forma, tenemos entonces que toda la información que viaja y regresa queda solamente en el Scope de Bizagi. Esta información no queda guardada en la base de datos hasta que la actividad termine satisfactoriamente como se explica al inicio del articulo.

Una vez que tenemos un flag en la grilla que nos indica que producto esta en Stock , podemos utilizar este flag para :

Mostrar en una grilla aparte la información marcada con el Flag. Eliminar los registros marcados con el flag. Filtrar o agrupar la grilla para que muestre por separado esta información.



Ejemplo 2 de Scopes : Sistemas Externos Comunicándose con Bizagi

Cuando un sistema externo desea obtener y actualizar información de casos o actividades en Bizagi que aun no han sido terminadas se deben utilizar métodos que obtengan información directamente del Scope y no de la base de datos.

Por ejemplo, vamos a suponer que una aplicación externa a Bizagi requiere obtener las Solicitudes pendientes por autorizar. Esta información esta en la actividad Autorizar Pedido (Authorize Request) en el proceso Solicitud de Compra (Purchase Request).



1. Primero, el sistema externo debe consultar esta información sobre Bizagi. Para eso debe invocar el servicio WorkFlowEngineSOA y el método getActivities.




2. Cuando el sistema externo tenga la respuesta del servicio, ya tiene la información para saber que casos y que actividades estan disponibles con la información requerida.



Si ademas de conocer el estado actual de las actividades, desea también actualizar información de esas actividades debe hacerlo también sobre el Scope y no sobre la base de datos. Para esta situación se debe utilizar el metodo saveActivity del servicio WorkFlowEngineSOA.

4. Supongamos entonces que el sistema externo desea aprobar cierta solicitud pero no puede hacerlo desde la pantalla de Bizagi. En ese caso la aplicación externa debe enviar un XML con la información del caso y de la actividad. Ademas, dentro del tag entities debemos colocar la información que se desea actualizar o crear dentro de la actividad. Para eso, nuevamente nos basamos en el modelo de datos.




Según el modelo de datos, el XML debe llevar el tag de la entidad principal (Purchases) seguido del tag de la entidad maestra (PurchaseRequest) y el campo que queremos actualizar es el estado de la solicitud para lo cual utilizamos la llave de negocio (businessKey) con el valor de AP (aprobado)

Para el caso de aprobar la solicitud en el caso de Solicitud De Productos para el caso PR1009, el cual fue obtenido en el paso anterior, el XML debe lucir así :




Cuando el sistema externo envié este XML al método saveActivity, la actividad sera automáticamente actualizada en el Scope y no en la base de datos.




Para mas información sobre los temas tratados en este articulo, puede dirigirse a los siguientes vínculos :

getActivity

saveActivity

WorkFlowEngineSOA

Capa Soa 

Opciones Avanzadas para Invocar Servicios Web <comments />