Gestión de los cambios de flujo para los casos en curso 

En este enfoque, configura un ticket que se adjunta dentro del mismo flujo, cambia a una nueva etapa o reinicia la etapa existente. Las asignaciones en curso avanzan a una asignación diferente cuando se vuelven a procesar con la versión actualizada.

Debe ejecutar un trabajo de procesamiento en bloque que localice cada asignación obsoleta en el sistema afectada por la actualización. Para cada asignación afectada, el procesamiento en bloque debe llamar a Assign-.OpenAndLockWork seguido por Work-.SetTicket, pxChangeStage o pxRestartStage. Por ejemplo, puede ejecutar una figura Utility (Utilidad) que reinicia una etapa (pxRestartStage).

El ejemplo a continuación muestra una actividad de asignación en bloque que usa SetTicket:

Después de configurar la actividad, usted despliega el flujo actualizado y ejecuta la actividad de asignación en bloque.

Ejemplo

En este ejemplo una pequeña oficina de suscripción de seguros procesa aproximadamente 50 asignaciones por día, la mayoría de las cuales se resuelve en dos días. Además, no hay procesamiento nocturno. Usted ejecuta procesos en bloque porque la cantidad de asignaciones no resueltas es relativamente baja y se pueden obtener los bloqueos necesarios durante la noche. No es necesario usar el método Commit (Confirmar).

Ventaja	Una actividad de proceso por lotes dirige las asignaciones realizando la lógica fuera del flujo. No necesita actualizar el flujo agregando una figura Utility (Utilidad) al flujo existente. La actividad le permite mantener la lógica del procesamiento en el flujo, facilita las actualizaciones y también la configuración y el mantenimiento del flujo en App Studio.
Desventaja	Puede que no sea práctico si el número de asignaciones es grande o si no hay un período de tiempo en el que se garantice que el procesamiento en segundo plano adquiere los bloqueos necesarios.

Para las reglas específicas de casos, la diferenciación del estado actual de un flujo de su estado futuro deseado se logra mediante la referencia de clase dinámica (RCD). 

En la creación de casos, el valor de diferenciar la propiedad, pxCreateDateTime, se establece inmediatamente. En combinación con el valor de diferenciación que se establece, cambia el pxObjClass del caso. La función data transform pyDefault para el caso puede determinar el año actual usando la siguiente lógica:

<var>Param.CurrentYear</var> = @toInt(@String.substring(@DateTime.CurrentDateTime(),0,4))

Posteriormente, cambie la propiedad pxObjClass del caso utilizando la siguiente lógica:

.pxObjClass => .pxObjClass + “-Y” + Param.CurrentYear

Aunque este enfoque requiere que se cree una clase para cada año, no se comporta de la misma manera que las circunstancias actualizadas.

Una forma de evitar la creación de una clase para cada año es omitir uno o más años al apuntar a la clase padre directa si no se realizaron cambios de flujo en esos años que puedan afectar los casos en curso. En lugar de usar siempre Param.CurrentYear, el año más reciente en el que ocurrió la especialización de clase se puede determinar usando una página de datos con la siguiente lógica:

Param.ContractYear = D_ContractYearToUse[ObjClass:Primary.pxObjClass, StartYear:Param.CurrentYear].ContractYear 

.pxObjClass =>.pxObjClass + “-Y” + Param.ContractYear 

La lógica en D_ContractYearToUse puede ser la siguiente:

.ContractYear = Param.StartYear

Para cada página en D_StartsWithClassNameDesc[ObjClass:Param.ObjClass].pxResults 

Param.Year = <the last 4 characters in> pyClassName 

IF (Param.Year solo tiene dígitos AND Param.Year <= Param.StartYear) 

THEN Primary.ContractYear = Param.Year 

Salir de Transform (Transformar) 

Ventaja: las clases definidas en el ruleset stack de una aplicación constituyen información de nivel del solicitante y son compatibles con la capacidad del Diseñador de casos de mostrar el estado actual de un caso. Lo hace junto con cómo está configurada la pestaña Cases & data de la regla de la aplicación.

Nombre	Prefijo de Id. del trabajo	Clase de implementación
BookEvent	EVENT-	FSG-Booking-Work-BookEvent-Y2022
WeatherPrep	WPREP-	FSG-Booking-Work-WeatherPrep-Y2021
RoomsRequest	ROOMS-	FSG-Booking-Work-RoomsRequest-Y2020

Tenga en cuenta que las reglas de aplicación configuradas como se muestra arriba solo deben usarse durante el diseño y el desarrollo. En producción, la RCD puede usarse para establecer la propiedad pxObjClass que cada tipo de caso debe usar.

Desventajas: hay una gran cantidad de argumentos en contra del uso de este enfoque. Cada argumento se aborda en la siguiente tabla.

Argumento	Contraargumento
La creación de clases requiere tiempo extra	Requiere muy poco tiempo crear una nueva clase y configurarla para extenderse directamente a otra clase. Si necesita crear una clase solo una vez al año, la cantidad de tiempo para realizar esta tarea es insignificante en comparación con otras tareas de desarrollo que se llevarían a cabo durante ese año.
La ruta heredada puede volverse demasiado larga o afectar el rendimiento de la resolución de reglas	No hay restricción en la profundidad de una jerarquía de herencia. Se alcanzan otros límites mucho antes de que la jerarquía de herencia sea un problema.
Las clases adicionales complicarían las futuras decisiones de almacenamiento de la tabla de base de datos	Los grupos de clase, los equipos de trabajo y los registros Data-Admin-DB-Table determinan dónde se conservan los datos.
No escala	El aumento de la cantidad de valores pxObjClass únicos en la misma tabla de base de datos no afecta la arquitectura del sistema.

Este enfoque les permite a los usuarios procesar las asignaciones existentes sin tener que actualizar los flujos. Agrega un nuevo grupo de acceso que se dirige a la versión anterior de la aplicación. Agrega el grupo de acceso a la Id. de operador para cambiar a la aplicación desde el portal del usuario y completar las asignaciones existentes.

En este ejemplo, la aplicación se reconfiguró sustancialmente. Se crea una nueva versión de la aplicación, que incluye una versión del ruleset más actualizada. Las actualizaciones incluyen flujos reconfigurados y la funcionalidad para toma de decisiones y gestión de datos. Se decide crear un nuevo grupo de acceso debido al alcance de los cambios más allá de las actualizaciones de flujo.

 " data-embed-button="image_browser" data-entity-embed-display="view_mode:media.embedded" data-entity-embed-display-settings="" data-entity-type="media" data-entity-uuid="dade108b-56e8-47d8-b5c5-dfdfa9696acd">

Ventaja	Las versiones original y la más reciente de la aplicación permanecen intactas porque no se intenta realizar una corrección retroactiva compatible a las mejoras añadidas a la versión más reciente.
Desventaja	Las correcciones y mejoras deseables incorporadas en la versión más reciente de la aplicación no están disponibles para la versión anterior.

Se debe tener cuidado para evitar procesar un caso creado en la nueva versión de la aplicación cuando se utiliza la versión anterior de la aplicación y viceversa. Tanto los casos como las asignaciones tienen la propiedad pxApplicationVersion. Se pueden implementar reglas de seguridad, como Access Deny (Negar acceso), para evitar el acceso a casos y asignaciones que no corresponden a la versión de la aplicación utilizada actualmente.

La lista de trabajo del usuario puede modificarse para mostrar solo los casos que corresponden a la versión de la aplicación utilizada en ese momento o para mostrar la versión de la aplicación simplemente como una columna de vista de lista de trabajo separada. Del mismo modo, Get Next Work (Obtener el trabajo siguiente) debe modificarse para que solo devuelva las asignaciones de la cesta de trabajo que correspondan a la versión de la aplicación utilizada actualmente.

 Este enfoque conserva determinadas figuras, como Asignación, Espera, Subproceso y Split-For-Each, dentro del flujo, aunque los casos recién creados ya no utilicen esas figuras. La versión más nueva del flujo se reconfigura de manera que los casos nuevos nunca alcancen las figuras utilizadas anteriormente. Sin embargo, las asignaciones existentes siguen su ruta original.

En este ejemplo, usted ha rediseñado un proceso de modo que los nuevos casos ya no usan las asignaciones Review (Revisar) y Correct (Corregir). Usted las reemplaza con las asignaciones Create (Crear) y Review (Revisar) Purchase Request (Solicitud de compra). Dado que solo necesita eliminar dos asignaciones, usted decide que ejecutar las dos variaciones de flujo en paralelo es el mejor enfoque.

Usted realiza las actualizaciones en la nueva versión de flujo en dos pasos.

Primero arrastre las asignaciones Review (Revisar) y Correct (Corregir) a un lado del diagrama. Elimine el conector de la figura Start (Inicio) a la asignación Review (Revisar). No modifique el conector Confirm Request (Confirmar solicitud). Esto garantiza que las asignaciones en curso puedan seguir procesándose.

Luego, inserte las asignaciones Create (Crear) y Review (Revisar) Purchase Request (Solicitud de compra) al inicio del flujo. Conecte Review Purchase Request (Revisar Solicitud de compra) con Create Purchase Order Smart Shape (Figura inteligente Crear Orden de compra) con la acción de flujo Confirm Request (Confirmar solicitud).

Después puede ejecutar un reporte que verifique si las asignaciones anteriores siguen en proceso. Si no lo hace, puede eliminar las figuras desactualizadas en la siguiente versión del flujo.

Ventaja	Todos los casos usan los mismos nombres de reglas en las distintas versiones.
Desventaja	Este enfoque puede no ser posible debido a cambios en la configuración. Además, puede dar como resultado diagramas de Process Modeler muy cargados.

Este enfoque implica establecer tantas reglas como sea necesario para diferenciar el estado actual de un flujo de su estado futuro deseado. Un tipo de puesta en circunstancia que satisface este enfoque se denomina circunstancia actualizada. Actualizado es cuando se identifica una propiedad dentro de un caso (por ejemplo, pxCreateDateTime). Esa propiedad se usa como Start Date (Fecha de inicio) en un rango de fecha. La End Date (Fecha de finalización) en el rango de fecha se deja en blanco. También se puede usar una propiedad DateTime específica de la aplicación, como.CustomerApprovalDate.

 " data-embed-button="image_browser" data-entity-embed-display="view_mode:media.embedded" data-entity-embed-display-settings="" data-entity-type="media" data-entity-uuid="ee581ed4-2304-4e81-8e64-37ce77dd57ca">

Ventaja

Simple de implementar al principio con App Explorer. No necesita cambiar aplicaciones.

Desventaja

Las desventajas de usar la puesta en circunstancia se muestran en el módulo Diseño para especialización. La principal desventaja es que el Diseñador de casos se ve afectado cuando se usa la condición de circunstancia para fines distintos de la admisión de reglas especializadas del tipo de caso. Las reglas de Case Type (Tipo de caso) no se pueden especializar con la propiedad DateTime, no se permite la puesta en circunstancia actualizada. Esto presenta un problema, ya que los cambios deben llevarse a cabo indefinidamente. Debido a que el alcance del Diseñador de casos es a nivel de solicitante, el Diseñador de casos solo ve las versiones base de las reglas de circunstancias, como los flujos. Siempre que una regla de circunstancia se abra desde otra regla, se muestra la versión base. Para ubicar la variación correcta de circunstancia de la regla base, haga clic en Action > View siblings (Acción>ver relacionados). Cuanto mayor sea el número de reglas de circunstancia, más difícil será visualizar cómo interactúan la colección de reglas de circunstancias similares y las reglas no circunstanciales.

Specialize by circumstance.
 " data-embed-button="image_browser" data-entity-embed-display="view_mode:media.embedded" data-entity-embed-display-settings="" data-entity-type="media" data-entity-uuid="525139d3-9922-4b05-8f75-fb1d386e4edc">