Usted está aquí:
Cambios de procesos de negocio en un plan de orquestación
Cuando implementa una implementación por fases de Dynamic Revenue Orchestrator, cada fase de implementación puede cambiar un proceso de negocio o requerir múltiples configuraciones para coexistir.
Ediciones necesarias
| Disponible en: Lightning Experience |
| Disponible en: Ediciones Enterprise, Unlimited y Developer de Revenue Management |
Una condición es una regla que comprueba un atributo del pedido, producto o cuenta y determina si se aplica un paso, grupo de pasos o escenario. El atributo que seleccione determina cómo se comporta la condición: utilice una condición basada en fecha para un único corte entre todos los pedidos, una condición de atributo de producto para lógica que varía por tipo de servicio, una condición de atributo de cuenta para pilotos o segmentos específicos, una condición de valor de pedido para flujos de trabajo basados en riesgo y una condición de evento clave de negocio que se aplica cuando se produce un pedido o evento de realización. Combine condiciones cuando un cambio depende de más de un factor. Para obtener más información sobre las condiciones de construcción, consulte Comprender las condiciones de ejecución para la realización de pedidos.
Siempre que necesite sustituir, agregar o cambiar un proceso de negocio en un plan de orquestación durante una fase de implementación, no modifique la configuración activa vigente. Los pedidos de larga duración a menudo siguen en curso cuando se produce la siguiente fase de implementación, y la modificación puede interrumpirlos. En su lugar, aplique una condición a cada cambio y, donde el cambio sea significativo, ejecute las configuraciones antigua y nueva en paralelo.
Las configuraciones heredadas se retiran a continuación de forma natural cuando finalizan sus pedidos. Proporcione tiempo para pruebas de sandbox, actualizaciones de documentación y notificaciones de clientes cuando un cambio afecta a niveles de servicio, y dé más tiempo de prospecto para cambios más grandes, como la sustitución de un proceso de negocio o la introducción de un nuevo escenario.
Los siguientes patrones son recomendaciones que puede adaptar a su propia implementación, no la única forma de realizar estos cambios. Para cada uno, modele el cambio de modo que se aplique a nuevos pedidos sin interrumpir pedidos que ya se están ejecutando. Una única fase de implementación puede combinar más de uno de estos cambios: seleccione la combinación que se ajusta al escenario de negocio y los tipos de pedidos en vuelo de modo que el riesgo permanezca mínimo.
- Sustituir un proceso de negocio existente
- Implemente la sustitución como un nuevo grupo de pasos o escenario y enrute nuevos pedidos a él con una condición. Mantenga el grupo de pasos existente para pedidos que ya lo utilizan y retírelo después de que se completen esos pedidos.
- Agregar un nuevo proceso de negocio
- Agregue un nuevo grupo de pasos (o un nuevo paso para una llamada externa) y vincúlelo a un escenario con una condición de modo que solo sea apto para los pedidos que lo necesiten. Los pedidos que ya están en vuelo no se ven afectados.
- Cambiar el modo de ejecución de un proceso de negocio, como manual a automatizado
- Modele la nueva ejecución como una nueva definición de paso o un nuevo escenario controlado por una condición, en vez de modificar el paso de ejecución vigente. Los nuevos pedidos utilizan la ruta automatizada y los pedidos en vuelo se completan con el proceso que iniciaron.
- Cambiar parte de un proceso de negocio
- Aplique condiciones a los pasos específicos que cambian, de modo que solo los pedidos aptos seleccionen el nuevo comportamiento. Las condiciones suprimen los pasos antiguos para nuevos pedidos en vez de eliminarlos mientras los pedidos en vuelo aún hacen referencia a ellos.
- Sustituir el sistema de realización detrás de un proceso de negocio
- Cuando el cambio sustituye un sistema descendente o backend completo, seleccione el nivel de aislamiento. Si aún se aplica el mismo producto técnico, enrute nuevos pedidos a un escenario o grupo de pasos diferente, como al sustituir un proceso de negocio. Si la lógica de realización debe estar completamente separada (por ejemplo, porque los pedidos en vuelo necesitan seguir corrigiéndose o cancelándose en el sistema antiguo hasta que se completen), enrute a un producto técnico diferente en su lugar, utilizando una regla de ejecución basada en un producto o atributo de pedido. Para obtener información acerca de cómo seleccionan las reglas de ejecución un producto técnico, consulte Tipos de relaciones de descomposición. Para configurar la condición detrás de una regla de ejecución, consulte Definir reglas de ejecución para una regla de descomposición.
Por ejemplo, este es el aspecto del patrón "Cambiar parte de un proceso de negocio" cuando el cambio está insertando un nuevo paso ejecutado condicionalmente en un proceso existente:
Seleccionar cómo modelar un proceso de negocio nuevo o de sustitución
Cuando un patrón anterior presenta un proceso de negocio nuevo o de sustitución, decida si modelarlo como un grupo de pasos o un paso. Su elección determina la facilidad con la que puede cambiarlo de nuevo más adelante.
- Como grupo de definición de paso de realización
- Modele un proceso de negocio que se ejecuta completamente en Salesforce como un grupo de definición de paso de realización, también denominado grupo de pasos. El grupo de pasos contiene los pasos ordenados del proceso. Un proceso de negocio más grande no tiene que asignarse a un solo grupo de pasos: múltiples grupos de pasos pueden representar cada uno un fragmento de él. Para obtener más información sobre la definición de grupos de pasos y pasos en un plan de orquestación, consulte Definir componentes de plan de orquestación.
- Como paso
- Modele un proceso de negocio que llama a un sistema de realización descendente o externo como un único paso dentro de un grupo de pasos, como un paso de llamada.
Un escenario de realización vincula productos a los grupos de pasos que se ejecutan para un pedido. Agrupe pasos por etapa del ciclo de vida desde el principio: identifique los pasos comunes entre productos primero, luego divida solo la lógica específica del producto en grupos de pasos separados y aplique condiciones a nivel del escenario cuando sea posible. Esta estructura facilita agregar rutas de lógica más adelante sin volver a factorizar.
Mantener múltiples configuraciones de un proceso de negocio
Una fase de implementación a menudo significa que más de una configuración del mismo proceso de negocio debe coexistir durante algún periodo. Seleccione el modelo de coexistencia que se ajuste al tiempo que necesitan las configuraciones antigua y nueva para ejecutarse juntas.
- Coexistir a largo plazo
- Mantenga los escenarios paralelos indefinidos, enrutados por condiciones duraderas. Utilice este modelo cuando el negocio pretenda mantener ambas variantes, por ejemplo, para diferentes productos o regiones.
- Coexistir hasta que se completen los pedidos en la configuración antigua
- Suprima la configuración antigua para nuevos pedidos con una condición y permita que los pedidos en ejecución envejezcan en ella. Después de que se completen todos los pedidos que hacen referencia a la configuración antigua, retire el grupo de pasos, los pasos o el escenario antiguos. Dynamic Revenue Orchestrator bloquea esta eliminación mientras que los pasos incompletos aún hacen referencia al grupo de pasos, los pasos o el escenario; no fuerce la sustitución de metadatos para omitir el bloque, ya que corre el riesgo de dañar los pedidos en vuelo. Compruebe periódicamente si hay pasos suprimidos y escenarios retirados cuyos pedidos se completaron y elimínelos. Los planes con muchas condiciones agregan latencia de procesamiento y pueden acercarse a límites de plataforma, especialmente para pedidos de alta escala. Para consultar límites específicos, consulte Límites de Orquestador de ingresos dinámico.
- La nueva configuración sustituye a la antigua después de un corte
- Utilice una condición basada en fecha de modo que los pedidos antes del corte utilicen la configuración antigua, y los pedidos en o después del corte utilicen la nueva. Este modelo proporciona una transición limpia y basada en tiempo sin mezcla de lógica.
Cuándo utilizar código para un cambio de orquestación
Puede gestionar la mayoría de los cambios de planes de orquestación utilizando una configuración (modificación de escenarios, definiciones de pasos, condiciones y dependencias de pasos) en vez de código personalizado. Los cambios de configuración son más seguros de implementar en una implementación por fases porque puede controlarlos con condiciones y ejecutarlos en paralelo con la lógica existente. Utilice código personalizado, como Apex o Flow, solo cuando el cambio requiera lógica que las condiciones no puedan expresar.
| Tarea | Cómo utilizar código |
|---|---|
| Transformar datos | Utilice código para remodelar, asignar o enriquecer datos de carga que un paso pasa a un sistema descendente. |
| Calcular un valor de negocio | Utilice código para cálculos que van más allá de la comparación de valores de campo de una condición, como precios o lógica de aptitud. |
| Llamar a un extremo de integración | Utilice código para conectar un paso a un sistema de realización externo a través de una llamada. |
| Aplicar un contrato de API | Utilice código cuando un paso debe producir o consumir una solicitud específica o un contrato de respuesta que requiere un sistema descendente. |
La modificación de la lógica subyacente, como Apex o Flow, manteniendo la misma definición de paso es segura solo si el contrato de entrada y salida permanece idéntico. Cualquier cambio en parámetros o propiedades de carga requeridas puede provocar un error en un paso de ejecución.
Repercusión de los cambios a nivel de entidad por estado de pedido
Los patrones y modelos de coexistencia anteriores funcionan modificando una o más de cuatro entidades: escenarios de realización, definiciones de pasos, condiciones y dependencias de pasos. Esta tabla enumera el efecto completo de cada cambio a nivel de entidad en pedidos nuevos, en ejecución y suplementarios, de modo que puede comprobar el resultado del cambio específico que está realizando.
| Entidad | Tipo de cambio | Nuevos pedidos | Ejecución de pedidos | Pedidos suplementarios |
|---|---|---|---|---|
| Escenario de realización | Agregar un nuevo registro | Se aplica al nuevo pedido. | Sin impacto. | Los nuevos grupos de pasos con pasos se agregan a un plan si el escenario es apto para un pedido suplementario. |
| Eliminar un registro | El grupo de pasos vinculado no se tiene en cuenta en el plan. Los pasos que pertenecen a ese grupo de pasos no se crean. | Sin impacto. | Los pasos que se crearon porque existía este escenario se cancelan o descartan, dependiendo del estado de ejecución del paso. | |
| Cambiar producto o grupo de pasos en un registro existente | La nueva configuración se aplica al nuevo pedido. Se evalúan nuevas condiciones, si las hubiera, y se crean los pasos. | Sin impacto. | Los pasos que se crearon bajo la configuración antigua se cancelan o descartan, dependiendo del estado de ejecución del paso, y los nuevos grupos de pasos con pasos se agregan al plan si la nueva configuración es apta para el pedido suplementario. | |
| Condición en escenario de realización | Agregar una nueva condición | Se evalúa la nueva condición y, si es apta, se crean los pasos. | Sin impacto. | Si el escenario deja de ser apto debido a la condición, los pasos se cancelan o se descartan, dependiendo del estado de ejecución del paso. |
| Eliminar una condición | Las definiciones de pasos que forman parte del grupo de pasos se utilizan para crear nuevos pasos. | Sin impacto. | El escenario puede empezar a ser apto. Si es así, los pasos se agregan durante el proceso de reconciliación de planes del pedido suplementario. | |
| Cambiar criterios de una condición existente | Se evalúan los nuevos criterios. Basándose en el resultado, los pasos se crean o se ignoran. | Sin impacto. | Si el escenario comienza a cumplir los requisitos según los nuevos criterios, los pasos se agregan durante el proceso de reconciliación de planes del pedido suplementario. Si deja de ser apto, los pasos se cancelan o se descartan, dependiendo del estado de ejecución del paso. | |
| Definición de paso de realización | Agregar un nuevo registro | Los pasos se crean para la nueva definición de paso. | Sin impacto. | Los pasos se crean para la nueva definición de paso. |
| Eliminar un registro | No se permite eliminar si los pasos incompletos hacen referencia a él. | No se permite eliminar si los pasos incompletos hacen referencia a él. | No se permite eliminar si los pasos incompletos hacen referencia a él. Si se completa el paso, las compensaciones se insertan en el plan. | |
| Agregar un nuevo paso | Si el escenario es apto, el paso se agrega al plan. | Sin impacto. | Si el escenario continúa apto, el paso se agrega durante el proceso de reconciliación de planes suplementarios. | |
| Eliminar un paso | La definición del paso eliminado se ignora. Si cualquier plan tiene un paso incompleto basado en la definición de paso concreta, la definición de paso no se puede eliminar. | No se permite eliminar si los pasos incompletos hacen referencia a él. | El paso se cancela o se descarta, dependiendo del estado de ejecución. Si cualquier plan tiene un paso incompleto basado en la definición de paso concreta, la definición de paso no se puede eliminar. | |
| Cambiar tipo de paso | El paso se crea con el nuevo tipo de paso. | Sin impacto. | Ignorado durante la reconciliación de planes. | |
| Cambiar ámbito de paso | Los pasos se crean en el nuevo ámbito. | Sin impacto. | El pedido suplementario se rechaza. | |
| Cambio de punto de no retorno (PONR) | Los pasos se crean con el nuevo valor PONR. | Sin impacto. | Ignorado durante la reconciliación de planes. | |
| Cambiar el grupo de pasos de corrección o cancelación | Los pasos se crean con referencia a los grupos de corrección y cancelación. | Sin impacto. | Ignorado durante la reconciliación de planes. | |
| Cambiar Apex, Flujo, definiciones de integración o reglas de asignación | Los pasos se crean con referencia al nuevo Apex o Flujo. Se utiliza la versión activa más reciente del flujo. | Los pasos de ejecución actuales ejecutan la versión antigua si la ejecución se inició antes de que se cambiara Apex o Flow. Si el paso se ejecuta después del cambio, se ejecuta la nueva versión. Si el contrato (entrada, salida o condiciones previas y posteriores) cambia para la nueva implementación, el paso puede fallar. | Depende de si el contrato del paso (entrada, salida o funcionalidad implementada) cambia. Si es así y el paso se ejecuta, el paso puede fallar. Si cambia la clase o el flujo Apex en la definición pero deja la clase o el flujo Apex antiguo tal cual, los pasos pueden ejecutarse sin problemas, dependiendo de otros cambios en clases, configuraciones y subflujos dependientes. | |
| Agregar una nueva condición | Se hace referencia a la nueva condición desde el registro de paso de realización que se crea. | Sin impacto. | Las condiciones agregadas a la definición después de crear el paso se ignoran. | |
| Eliminar una condición | El registro de paso de realización se crea sin una referencia a la condición. | Las condiciones (ejecutar o reanudar en valores de búsqueda de conjuntos de reglas) que se eliminan de la definición también se eliminan de los pasos de ejecución. | Las condiciones eliminadas de la definición después de crear el paso se ignoran y se evalúa la condición antigua. | |
| Cambiar criterios de una condición existente | El registro del paso de realización hace referencia al conjunto de reglas. | El registro del paso de realización hace referencia al conjunto de reglas. Un cambio en la condición afecta a la ejecución omitiendo o ejecutando el paso. | El paso de realización almacena solo la referencia al conjunto de reglas. Si los criterios cambian, los nuevos criterios se evalúan durante la ejecución de la orquestación. | |
| Definición de dependencia de paso | Agregar una nueva dependencia entre pasos existentes | Se aplica al nuevo pedido. | Sin impacto. | El nuevo registro de dependencia se agrega durante la reconciliación del plan. Este registro de dependencia podría afectar o no a la ejecución de orquestación real. |
| Agregar una dependencia entre un paso existente y un paso recién agregado | Se aplica al nuevo pedido. | Sin impacto. | El nuevo registro de dependencia se agrega durante la reconciliación del plan. | |
| Agregar una dependencia entre un paso recién agregado y un paso existente | Se aplica al nuevo pedido. | Sin impacto. | El nuevo registro de dependencia se agrega durante la reconciliación del plan. Este registro de dependencia podría afectar o no a la ejecución de orquestación real. | |
| Agregar una dependencia entre dos pasos recién agregados | Los pasos se crean con registros de dependencia de pasos de realización entre ellos, siempre que los pasos tengan el ámbito correcto. | Sin impacto. | El nuevo registro de dependencia se agrega durante la reconciliación del plan. | |
| Eliminar una dependencia | Los pasos se crean sin ningún registro de dependencia de paso de realización entre ellos. | Sin impacto. | Un registro de dependencia, una vez creado, no se elimina. | |
| Cambiar ámbito de dependencia | Se aplica al nuevo pedido. | Sin impacto. | Sin impacto. |
