Bizagi ofrece poderosas reglas de negocio que se pueden implementar en varios lugares durante todo el proceso para llevar a cabo acciones, encaminar sus procesos, gestionar las interfaces de usuario y asignar usuarios.
Hay muchas maneras de definir una regla y que tengan exactamente los mismos resultados. Usted debe aplicar la más eficiente y flexible.
Esta sección ofrece algunas pautas para construir reglas enfocadas en reducir al mínimo el impacto en el rendimiento de la aplicación y permitirle a los procesos adaptarse fácilmente a las condiciones cambiantes del negocio.
Diseño de las reglas de negocio eficientes y gobernables
Cuando se definen reglas de negocio, se deben tener en cuenta los siguientes principios básicos:
2. Implemente un código eficiente
A continuación encontrará pautas útiles a seguir estos principios y ayudar a la definición y administración reglas.
Recomendaciones generales
•Todas las reglas de negocio para enrutamiento de procesos se construyen en Bizagi.
•Si una regla de negocio existe en otro sistema.
oSolicite al cliente que exponga la regla de negocio y consúmala desde Bizagi.
✓Recomendación: Use servicios web.
✓Alternativa 1: Use la librería de componentes de Bizagi como fachada.
➢Invoque un API proporcionado por el cliente.
➢Use un componente para acceder a una fuente de datos externa (por ejemplo, procedimientos almacenados).
oSi el sistema será reemplazado en un tiempo corto.
✓Recomendación: Construya la lógica en Bizagi.
•Si una regla de negocio tiene una alta demanda computacional.
oDebe ser implementada en otro sistema y consumida desde Bizagi.
✓Recomendación: Impleméntela como un servicio web.
✓Alternativa 1: Use la librería de componentes de Bizagi como fachada.
➢Invoque un API proporcionado por el cliente.
➢Use un componente para acceder a una fuente de datos externa (por ejemplo, procedimientos almacenados).
•Si una regla de negocio que se cambia frecuentemente por los usuarios de negocios
oSe puede hacer dentro o fuera de Bizagi
✓En Bizagi, si no hay otro sistema que pueda implementarla o no tiene una interfaz de usuario que permita la modificación por usuarios de negocios.
✓En un sistema externo, si tiene una interfaz para los usuarios de negocios y se puede consumir desde Bizagi.
➢Recomendación: Impleméntela como un servicio web.
➢Alternativa 1: Use la librería de componentes de Bizagi como fachada.
▪Invoque un API proporcionado por el cliente.
▪]Use un componente para acceder a una fuente de datos externa (por ejemplo, procedimientos almacenados).
•Si requiere una nueva regla de negocio y debe ser consumida por otros sistemas.
oSe puede construir en Bizagi si no es de alta demanda computacional.
oOtros sistemas pueden acceder a él a través de la capa SOA (sólo reglas de negocio, esto no aplica para las expresiones o funciones).
Nomenclatura para expresiones
El uso de prefijos en las reglas tiene dos funciones, explicar el objetivo de la regla y dónde se está utilizando; siga esta guía para seleccionar el prefijo apropiado:
Tipo de regla |
Prefijo |
Ejemplo |
|---|---|---|
Visibilidad, requerida, editable, transición |
Is_ |
Is_CustomerVIP, Is_Allowed |
Botón de una regla |
Exe_ |
Exe_CalcRates |
Regla de eventos (On Enter, On Exit) |
Evt_ |
Evt_ProcessElements |
Regla de eventos (On Save, Submit on change) |
Sav_ |
Sav_RecalculateFlags |
Reglas de Librería |
Finance.CreateElements, Common.FilterElements |
|
Reglas de filtros |
Fil |
Fil_CustomerVIP, Fil_Requests |
1. Diseñe reglas flexibles
Las reglas de negocio se utilizan para modelar las condiciones del negocio. Como estas condiciones están en constante cambio, es fundamental crear reglas que se puedan cambiar fácilmente.
Planee cuidadosamente qué cambios en su proceso se pueden afrontar y construya las reglas de forma que se puedan adaptar fácilmente para responder a las condiciones cambiantes del negocio.
Use políticas
Utilice Políticas para modelar reglas de negocio que se enfrentan a condiciones cambiantes del negocio. El uso de las políticas en lugar de expresiones ofrece la ventaja de permitirle a los usuarios administrarlas fácilmente desde el Portal de Trabajo. De esta manera, se pueden realizar cambios en los valores o en la lógica en tiempo real para adaptarse instantáneamente a las condiciones actuales del negocio.
La siguiente imagen muestra una expresión y una tabla de decisión (política) que se utiliza para valorar la evaluación del riesgo de una solicitud de préstamo basado en una evaluación de crédito. Tanto la expresión como la tabla de decisión funcionan para este propósito, pero si los valores de la evaluación de riesgos cambian para responder a las condiciones de negocios, no se puede acceder a la expresión desde el entorno de producción para modificarlos. Por el contrario, mediante el uso de una tabla de decisión, los usuarios pueden cambiar fácilmente estos valores desde el Portal de Trabajo.
Use Vocabularios
Los vocabularios son definiciones que obtienen o establecen toda la información utilizada en las Políticas o en las Expresiones. Si una regla de negocio no puede ser modelada como una política, pero sus parámetros necesitan ser cambiados con frecuencia para adaptarse a las condiciones del negocio, puede utilizar expresiones que incluyan vocabularios.
Los vocabularios se pueden invocar desde Expresiones o Políticas y pueden ser administradas en el ambiente de producción por los usuarios finales desde el Portal de Trabajo.
La imagen de abajo muestra dos maneras de asignar la duración de una actividad. La duración de esta actividad depende de un SLA del cliente (Service Level Agreement).
En la imagen superior, la duración de la actividad se define como un valor fijo, si el SLA cambia, la expresión tiene que ser modificada en el ambiente de desarrollo y luego ser llevado al ambiente de producción, a través de deployment.
En la imagen inferior, se utiliza un vocabulario para definir la duración. Si el SLA cambia, un usuario administrador puede acceder al Portal de Trabajo y modificar el valor del vocabulario para reflejar al instante la nueva condición en el proceso.
No asigne una instancia de entidad mediante el uso de ID
Cuando tenga una instancia de entidad, no la asigne con un ID.
Se deben utilizar los objetos en su lugar.
Reutilice reglas de negocio
Las reglas de negocio pueden ser reutilizadas a lo largo de un proceso. En muchos casos, se sigue la misma lógica en diferentes etapas del proceso y no tiene sentido construir la misma regla una y otra vez. Reutilice las reglas cada vez que se necesiten, de esta manera, si se requieren cambios sólo se modifica una vez y se reflejan los cambios en donde se utiliza la regla.
Use reglas de librería
La reglas de librería son reutilizables para todo el proyecto, ya que se definen de forma global. En las grglas de librería es obligatorio utilizar Me como primer parámetro y NO otro objeto.
Declare todas las variables
Use la opción de declaración de variables para inicializar aquellas que vaya a usar en su Expresión. Recuerde seleccionar un tipo de variable y darle un valor inicial.
2. Implemente un código eficiente
Algunas situaciones complejas pueden requerir la implementación de código en Bizagi. Para estos casos, tenga en cuenta que hay prácticas que afectan altamente el rendimiento de la aplicación. Tenga en mente estas prácticas cuando implemente reglas de negocio para hacer su aplicación más rápida y mejorar la experiencia del usuario:
Evite la manipulación de una gran cantidad de registros a la vez
Al utilizar métodos para obtener un conjunto de registros, asegúrese de que se utilizan los filtros y que sólo traen los registros que usted realmente necesita.
Esto debería evitar grandes iteraciones a través de un conjunto y debe promover un acceso rápido a la información necesaria. No es usual manipular una cantidad considerablemente grande de registros; pues esto significaría que es probable que haya una forma mejorada para cubrir un requisito de negocio.
Evite los for anidados
Las Iteraciones anidadas pueden tardar mucho tiempo para procesar y crean problemas de rendimiento.
Evite la combinación de las siguientes funciones en una única expresión
▪una iteración (for) dentro de la iteración de las funciones addRelation y removeRelation
▪dentro de la iteración de las funciones addRelation y removeRelation
▪dentro de la iteración, utilizando Coleccionde de XPaths con filtros
La combinación de estas funciones puede tomar mucho tiempo para procesar y crear problemas de rendimiento.
Opciones: Guarde la Colección XPath con su filtro en una variable y manipule la variable en la expresión.
Ejecute las funciones newcollectionitem y deletecollectionitem al principio de la expresión y no dentro de la iteración. Asigne el XPath de la colección, incluyendo su filtro, en una variable y manipule la variable en la expresión.
Evitar la manipulación de archivos adjuntos en reglas
Tenga en cuenta que se manejar directamente los archivos adjuntos dentro de las reglas de negocio pueda implicar trabajar con bytes. En muchos casos, estos datos adjuntos tendrán un tamaño de archivo grande lo que podría exigir más recursos por la aplicación que resulta en deficiencias de desempeño.
Evite el uso de método CEntityManager para manipular entidades que no sean entidades paramétricas
Cuando el uso de XPath no aplica para el requerimiento del negocio y use CEntityManager y sus métodos es estrictamente necesario, asegúrese siempre de incluir filtros.
Tenga en cuenta que se recomienda el uso de CEntityManager para realizar búsquedas en las entidades paramétricas en la búsqueda de un registro específico típicamente relacionada con una clave de negocio (por ejemplo, código). Preste especial atención cuando se utiliza este tipo de métodos con entidades virtuales, ya que esto puede implicar rastrear el tiempo de respuesta de la regla y, finalmente, revise la indexación en la fuente de datos externa.
Evite el uso de varias expresiones ejecutadas en On Save / Evite expresiones OnSave con la carga de trabajo de procesamiento pesado
Las expresiones On save se ejecutan cada vez que el formulario se guarda o un se ejecuta un Actualizar al cambio. Si hay cálculos complejos o patrones que toman mucho tiempo para procesar al guardar, el portal de trabajo presentará problemas de rendimiento. Evite el uso de expresiones en las actividades de OnSave que ejecuten un procesamiento pesado (es decir, ejecución de cálculos sofisticados, manipulación de información múltiple o invocación de interfaces u otros componentes).
Teniendo al mínimo el uso de expresiones OnSave representará un mejor rendimiento cuando se recargan las formas. Utilice expresiones OnSave para realizar acciones que implican cómo se muestra la información cuando no aplican Acciones y Validaciones.
Opciones:
•Guarde el XPaths de la colección en una variables y manipúlelas, en lugar de manipular el XPath directamente.
•Utilice las funciones newcollectionitem y deletecollectiontiem fuera de la iteración.
•Cambie las acciones OnSave por acciones On exit donde sea posible.
Evite la invocación de servicios de Bizagi en expresiones
Algunos proyectos tienden a usar la capa SOA de Bizagi dentro de las expresiones para utilizar los servicios de Bizagi. Los Servicios Bizagi están disponibles para ser utilizados directamente sin necesidad de invocar la capa SOA, usted debería utilizar estos métodos (por ejemplo CHelper.setEvent).
Llamar a los servicios de Bizagi desde los procesos de Bizagi se considera una mala práctica, y debe ser evitado, ya que va a crear una sobrecarga innecesaria.
Invoque las operaciones de Me antes de los ciclos.
Para tener un mejor desempeño, cuando se manipulen datos dentro de un ciclo, extraiga en una variable la entidad de proceso y después, utilice la variable dentro del ciclo.
MAL
var max = 1500;
for (var x = 0; x < max; x++)
{
var Newrecord = Me.newCollectionItem("ProcessEntity.RelationshipToTheCollection");
Newrecord.setXPath ("Column","Value");
}
BIEN
var max = 1500;
var PEntity = Me.getXPath("ProcessEntity");
for (var x = 0; x < max; x++)
{
var Newrecord = PEntity.newCollectionItem("RelationshipToTheCollection");
Newrecord.setXPath("Column","Value");
}
Evite el uso de colecciones para guardar registros temporalmente
Para evitar problemas de desempeño, no utilice el método addRelation en una acción de una actividad de una tarea si la va a remover utilizando el método deleteRelation en la siguiente tarea.
Muchas personas pueden trabajar en un proceso durante su ciclo de vida. Se deben construir las reglas de negocio de manera que cualquier persona pueda entender la lógica seguida y su verdadero propósito. Tome en cuenta las siguientes recomendaciones para facilitar la comprensión de las reglas de negocio mucho más fácil:
De a las expresiones un nombre y una descripción
Es muy importante ser capaz de identificar el propósito de una regla para asegurar la comprensión de la lógica seguida por un proceso y permitir su reutilización a lo largo de los Procesos. Siempre diligencie las propiedades de nombre y descripción de las reglas de una manera clara que describeasu propósito principal y cualquier otra información pertinente.
Comente el código
Con frecuencia cuando se utiliza código, comprender lo que otra persona escribió antes de usted puede ser un reto. Cada persona tiene su propio punto de vista y captura la lógica de negocio en las reglas de diferentes maneras.
Cuando utilice código en expresiones, tenga en cuenta que usted no será la única persona que tiene que entender la lógica seguida. Utilice los comentarios para describir el propósito de sus líneas de código en las expresiones y ahorrar tiempo y esfuerzo a otras personas que tratan de entender la forma en que una condición fue modelada.
Las siguientes imágenes muestran una expresión con y sin comentarios. Nota cuán fácil es entender la lógica de la expresión al utilizar comentarios.
4. Usar CHelper.setAttrib solo cuando sea necesario
Para modificar atributos de registros específicos de una entidad no relacionada con el Modelo de Datos puede utilizar la función CHelper.setAttrib. Sin embargo, use esta función con cuidado.
•CHelper.setAttrib escribe directamente en el modelo de datos tan pronto como se ejecuta una expresión. Es decir, tan pronto como se ejecuta CHelper.setAttrib, la información se persiste en el modelo de datos, omitiendo el Scope de la tarea y está disponible para otras tareas/informes/etc. Para obtener más información sobre los Scopes, visite Scopes.
•La función CHelper.setAttrib se usa para actualizar registros obtenidos usando getXPath(“entity-list”), porque getXPath(“entity-list”) es de solo lectura.
•Cuando la expresión que ejecuta la función CHelper.setAttrib es parte de una acción que tiene varias expresiones/plantillas/interfaces, todas deben completarse correctamente porque el valor persistirá en el modelo de datos.
•Cuando el registro especificado para actualizar no existe, la función no fallará. Bizagi ignorará la instrucción y continuará. De ser necesario, deberá verificarse la existencia del registro antes de la sentencia a actualizar.
•No combine CHelper.setAttrib con funciones XPath como CHelper.setXPath en una sola sentencia. Esto se debe a que los Xpaths funcionan a nivel de Scope, mientras que setAttrib funciona directamente en el modelo de datos.
•Si necesita actualizar un atributo en el Scope de la tarea Y debe usar setAttrib, usted debe actualizar el atributo usando AMBOS métodos: XPaths (que actualizan el Scope) y setAttrib (que actualizan el modelo de datos).
XPath: <Solicitud de Crédito.kpStatus> = 1;
setAttrib: CHelper.setAttrib("Solicitud de crédito",<Solicitud de crédito.Id>,"kpStatus ",1);
Ejemplo
Un banco ofrece múltiples productos crediticios a sus clientes. Una vez que se aprueba y entrega un producto, se realizará un seguimiento mensual con el fin de evaluar si el cliente cumple con los pagos pactados a tiempo. Si el cliente cae en mora en repetidas ocasiones, todas sus solicitudes en progreso se penalizan y por lo tanto difícilmente serán aprobados.
Para identificar si una solicitud ha sido penalizada, se utiliza un atributo Booleano en el modelo de datos. Este atributo debe actualizarse en todas las solicitudes en progreso del cliente cuando este caiga en mora.
Para actualizar este valor usted puede hacer uso de la función CHelper.setAttrib. Esta función asigna un valor a un atributo dado de un registro específico de una entidad.
Los parámetros de esta función son:
•sEntityName: Nombre de la entidad.
•oEntitYKey: Id del registro específico dentro de la entidad.
•sAttribName: Nombre del atributo de la entidad.
•oAttribValue: Valor a asignar.
Y la sintaxis es:
CHelper.setAttrib(sEntityName ,oEntityKey, sAttribName, oAttribValue);
Incluya una expresión como una acción de actividad.
Primero obtenga la lista de casos en progreso del cliente que será penalizado.
Luego, en cada solicitud actualice el atributo que identifica si una solicitud ha sido penalizada. Para hacerlo navegue la lista de solicitudes y utilice la función CHelper.setAttrib.
//Obtenga la lista de solicitudes del usuario evaluado
var IdCustomerEvaluated=<CustomersFollowUp.CustomerEvaluated.Id>
var parameters = new FilterParameters();
parameters.AddParameter("@idRequester", IdCustomerEvaluated);
var ListOfRequests = Me.getXPath("entity-list('CreditRequest', 'idRequester=@idRequester')", parameters);
//Actualice cada caso
for (var i=0;i<ListOfRequests.size();i++)
{
CHelper.setAttrib("CreditRequest",ListOfRequests[i].getXPath("Id"),"RequestPenalized",true);
}
Last Updated 1/26/2022 4:15:59 PM