Establecimiento de reglas de negocio

Las reglas empresariales son piezas de lógica personalizada que se utilizan para ampliar la solución FSM para casos específicos de cliente. La lógica estándar en FSM se describe como "monolito" y no se puede modificar. Por lo tanto, las reglas empresariales solo se pueden ejecutar además de o sobre la lógica estándar de FSM. Las reglas de negocio se crean a nivel de empresa y se ejecutan en ese contexto.

Antes de ejecutar una regla empresarial, algo debe desencadenarla. Ese desencadenador puede ser un evento específico o una programación predefinida. Los eventos específicos pueden, por ejemplo, hacer referencia a modificaciones en la base de datos de la empresa, entradas de un sistema integrado o eventos publicados por microservicios de FSM.

Una vez iniciada la regla empresarial, se recopilan los datos, se verifican las condiciones y se ejecutan las acciones.

Las reglas empresariales pueden ayudar a automatizar los procesos empresariales. Algunos ejemplos específicos de casos de uso para reglas empresariales son:

• Enviar notificaciones, SMS o correo electrónico
• asignar un flujo de trabajo a una actividad
• adjuntar Smartforms a las actividades
• generar informes
• crear actividades de seguimiento
• invocar programación automática

Cada empresa de FSM viene con varias reglas de negocio integradas y de muestra/demostración. Las reglas integradas se pueden activar tal cual o servir de ejemplo para sus propias ampliaciones.

Las reglas empresariales (BRs) se pueden encontrar en la pestaña correspondiente de la página Empresa. La lista Reglas empresariales se puede buscar, clasificar y filtrar. Desde aquí, las SP se pueden activar o desactivar, crear o eliminar, y cargar o descargar.

Puede modificar una regla empresarial de muestra editando una de las reglas existentes o crear una desde cero con el botón Crear. Se recomienda utilizar la regla empresarial de muestra como base para iniciar el Customizing de FSM para su caso empresarial.

Las partes principales de una regla empresarial son la configuración principal, la sección de desencadenador y la sección de acción. Estas partes se pueden describir de la siguiente manera:

Opciones principales: Esta sección contiene el código, el nombre y la descripción de la regla empresarial. También contiene indicadores para activar la regla empresarial y si las ejecuciones omitidas deben grabarse en log. Por último, contiene información sobre el estado de la regla empresarial y las personas de contacto técnicas, a las que se debe informar si la regla empresarial se encuentra en un estado de salud crítico.

Desencadenador: es en esta sección donde define el evento que activa la regla empresarial. Incluye el tipo de objeto de datos, las variables, las condiciones y otros parámetros para la regla empresarial. Cuando se cumplan las condiciones, la aplicación responderá ejecutando la acción especificada en la sección de acción.

Acción: En esta sección se define la respuesta de la aplicación al evento especificado en la sección de desencadenador. Por ejemplo, si ha especificado en la sección de desencadenador un evento que se produce en el objeto Crear para una llamada de servicio, en la sección de acción puede seleccionar Acción y Enviar SMS y hacer que la notificación se envíe a un destinatario específico.

Las opciones principales para las reglas empresariales se describen a continuación.

• Código: Esto es opcional. Se puede utilizar como identificador de la regla empresarial. La mejor práctica es mantenerlo corto.
• Nombre: el nombre de la regla empresarial.
• Descripción: Una descripción de la regla empresarial. El marcado simple se puede codificar manualmente, por ejemplo, para saltos de línea, fuente en negrita o viñetas.
• Activado: Una opción sí o no. En caso afirmativo, la regla empresarial estará activa.
• Contacto técnico: Incluirá direcciones de correo electrónico de las personas de contacto para preguntas técnicas sobre la definición/ejecución de la regla de negocio. Se recomienda añadir varios contactos técnicos. La persona o personas enumeradas también serán el punto de contacto para el Soporte de SAP en caso de que la regla empresarial esté causando un uso excesivo de los recursos u otros problemas del servidor.
• Porcentaje de umbral de error: Este campo permite a un usuario ajustar el umbral, en porcentaje, en el que se informa a los contactos técnicos de una regla de negocio de las reglas de negocio con ejecuciones fallidas. Si el campo se deja vacío, se aplicará un valor predeterminado del 50%.
• Registrar ejecuciones omitidas: Una opción sí o no. En caso afirmativo, las ejecuciones omitidas se mostrarán en el log de ejecución, al que se puede acceder en la vista de actualización. El número de logs de ejecución omitidos está limitado a las últimas 100 entradas de log omitidas por regla empresarial. Los más antiguos se borran automáticamente mediante la parametrización de empresa SAP.FSM.BusinessRules.MaxSkippedLogsToKeep. En esta opción, puede definir otro límite, pero con un máximo absoluto de 1000.
• Tipo: Actualmente hay dos tipos de reglas empresariales admitidas:
  • Tipo Dos: Este tipo de regla de negocio ofrece soporte completo de Javascript.
  • Tipo tres: Este tipo de regla empresarial se basa en la nueva arquitectura de microservicios y admite varios tipos diferentes de variables, eventos y acciones en comparación con las reglas empresariales de tipo dos. Siempre que sea posible, se recomienda utilizar el tipo tres. Para obtener más detalles, consulte la documentación más reciente.

• Eventos: el evento que desencadena la regla empresarial. Las opciones para objetos incluyen lo siguiente:
  • Eventos basados en CRUD para un objeto de datos determinado (crear, actualizar, borrar o una combinación de los mismos). Desencadenadores de este tipo:
    • En Creación de objeto: Si se selecciona, la regla empresarial se desencadenará al crear un objeto nuevo.
    • En Creación o actualización de objeto: Si se selecciona, la regla de negocio se desencadenará al crear un objeto nuevo o al actualizar/modificar un objeto existente.
    • En actualización de objeto: Si se selecciona, la regla de negocio se desencadenará en la actualización/modificación de un objeto existente.
    • En actualización o eliminación de objeto: Si se selecciona, la regla de negocio se desencadenará cuando se actualice o elimine un objeto existente.
    • Al eliminar objeto: Si se selecciona, la regla de negocio se desencadenará cuando se elimine un objeto existente.
    • En Carga de objeto desde conector ERP: Si se selecciona, la regla empresarial se desencadenará cuando los datos del objeto (por ejemplo, el interlocutor comercial) se carguen con el conector ECC Proaxia.
  • Programada: Si se selecciona, la regla empresarial se fijará para que se ejecute en los momentos e intervalos especificados.
  • Eventos FSM: los eventos de gestión de servicios de campo son eventos empresariales que publican los servicios de SAP Field Service Management en caso de que se produzca una ocurrencia relacionada.
• Tipo de objeto: El objeto de transferencia de datos (DTO) asociado con el evento. Para obtener una visión más detallada de estos DTO, consulte el modelo de datos.
• Orden: el orden en el que se ejecutan las reglas de negocio cuando son desencadenadas por el mismo evento.
• Ejecución:
  • Asincrónico (se produce después de la sincronización con la aplicación de cliente).
  • Sincrónico (se produce durante la sincronización con la aplicación cliente). Las reglas empresariales sincrónicas se utilizan en combinación con una acción de validación y pueden provocar retrasos en la sincronización con aplicaciones de cliente (por ejemplo, móvil).
• Ejecución de retraso (Sec): puede definir una regla empresarial que se ejecutará con un retraso de hasta 600 segundos. Solo las reglas empresariales con el tipo de ejecución "asincrónica" se pueden retrasar, excluidas las reglas empresariales programadas. Tenga en cuenta lo siguiente antes de utilizar un retraso:
  • Una regla empresarial solo se ejecutará una vez que se alcance la duración de un retraso.
  • Como el retraso solo define la duración mínima que se debe alcanzar, puede ser que la ejecución asincrónica de una regla empresarial se retrase más de lo definido.
  • Si hay reglas empresariales desencadenadas por el mismo evento (es decir, la actualización de una actividad) y definidas con diferentes retrasos, no se garantiza que el orden de ejecución se base en la duración de los retrasos definidos.
  • Para garantizar que las reglas empresariales se ejecutan en un orden específico, una mejor alternativa es utilizar el campo de orden.
  • Si combina utilizando un retraso y un orden en las reglas empresariales desencadenadas por el mismo evento, el orden solo se tendrá en cuenta para las reglas definidas con el mismo retraso. Esto garantiza que estas reglas se desencadenen en el mismo momento y, a continuación, se pueda tener en cuenta el orden correcto de las reglas. El sistema no puede tener en cuenta el orden de las reglas desencadenadas en diferentes momentos debido a diferentes retrasos.
  • En general, se recomienda utilizar los retrasos con precaución. Las ejecuciones retrasadas suponen una carga adicional en el sistema, lo que puede afectar al rendimiento del sistema.
• Cláusula WHERE de CoreSQL: Este campo aparecerá cuando el tipo de evento sea "programado". Se recomienda utilizar este campo para determinar los objetos para los que se debe ejecutar la regla. Para cada registro de objeto encontrado, las variables y condiciones se resolverán y las acciones se ejecutarán en consecuencia.
• Frecuencia: Este campo aparecerá cuando el tipo de evento sea "programado". Aquí puede introducir la frecuencia con la que se debe desencadenar la regla empresarial cuando se cumplen las condiciones.

Hora de la acción desencadenada: el sistema le permite desencadenar una regla empresarial programada hasta 4 veces por hora (XX:00, XX:15, XX:30, XX:45).

La ejecución de reglas empresariales se optimiza para conservar mejor los recursos del servidor (CPU, memoria, etc.).

Frecuencia y tiempo de ejecución: según el subconjunto de datos que se procesarán y las acciones definidas en una regla empresarial, el tiempo de ejecución varía de una regla a otra. Para proteger los recursos del sistema en la nube, es posible que se omita la ejecución de una regla empresarial. Esto puede suceder cuando se desencadena la misma regla para la ejecución mientras la ejecución de la regla anterior aún se está ejecutando.

Para evitarlo, el programa de reglas empresariales debe configurarse para que [TriggerTime]+[ExecutionTime] no cumpla con el siguiente [TriggerTime].

Para evitar que las acciones definidas no se ejecuten debido a una regla empresarial omitida, se recomienda encarecidamente definir las condiciones desencadenantes de forma que las condiciones desencadenantes no puedan verse influenciadas por otro proceso. En otras palabras, las condiciones desencadenantes deben cumplirse en cualquier momento siempre que las acciones deseadas de las reglas empresariales no se ejecuten.

Si se establece una frecuencia para una regla empresarial con una condición, se ejecutará con la frecuencia indicada cuando se active la regla.

Las variables se utilizan para leer datos necesarios para la correcta ejecución de la regla empresarial. Los datos de las variables se pueden utilizar en variables, condiciones y acciones subsiguientes.

Una variable consiste en una consulta en CoreSQL (igual que Query API), funciones Javascript o una combinación de las mismas. Los valores de las variables se resuelven durante la validación y ejecución de reglas. Una vez que se ha definido una variable resuelta, se puede hacer referencia a la variable y sus propiedades mediante javascript. Por ejemplo, ${activity.code} se refiere al campo "código" de una variable definida previamente llamada "actividad".

Algunas variables vienen predefinidas y hacen referencia a lo siguiente:

• El objeto desencadenante relevante
• Datos de objeto "antiguos" frente a "nuevos"
• El usuario, la empresa y la cuenta actuales

Se accede a las opciones de la empresa y a las opciones de usuario a través de las variables ${company.settings} y ${user.settings}. Por ejemplo, para recuperar el idioma que el usuario definió en la aplicación web, use ${user.settings.Cockpit_SelectedLanguage.data}.

Las variables personalizadas se pueden definir de la siguiente manera:

• Objeto: un registro individual de un tipo determinado
• Matriz: permite la selección de muchos objetos individuales utilizando una consulta compleja
• Valor: normalmente consiste en una cadena de texto/valor codificado o definido por una función javascript que se resuelve durante la ejecución.

Las variables de objeto y matriz se especifican de la siguiente manera:

• Tipo de objeto (DTO)
• Versión de objeto
• Cláusula CoreSQL WHERE o una consulta CoreSQL completa.

En el modo de consulta avanzada, se pueden definir consultas CoreSQL complejas. Para acceder al modo avanzado, pulse el icono de la llave inglesa. Al utilizar el modo avanzado, todos los tipos de objeto y sus versiones deben definirse explícitamente, por ejemplo, Activity.40;ServiceCall.26. Todas las consultas definidas se pueden inspeccionar y ejecutar en la interfaz API de consulta mediante el icono de triángulo.

La consulta CoreSQL o cláusula -WHERE puede contener fragmentos de código javascript, contenidos entre paréntesis: ${ ... }

Las variables de valor pueden contener, por ejemplo, una cadena de texto, un fragmento de código Javascript o similar.

Se admiten los objetos y campos personalizados (también conocidos como campos y objetos definidos por el usuario). Se puede hacer referencia a ellos en variables (mediante la cláusula WHERE), condiciones y acciones para todos los objetos disponibles.

Las condiciones se definen con operadores lógicos y relacionales integrados y pueden comparar lo siguiente:

• Variables y sus propiedades
• Cadenas de texto
• Números
• Valores booleanos
• Funciones JavaScript

Las condiciones se evalúan después de la resolución de las variables. A continuación, si se cumplen todas las condiciones, se ejecutan las acciones. Sin embargo, si no se cumple una de las condiciones, se omitirá la ejecución de la regla empresarial.

Omitir muchas ejecuciones de reglas empresariales aún cuesta recursos del sistema, porque BR aún reaccionó al evento/desencadenante, resolvió las variables y verificó las condiciones.

Una regla empresarial puede ejecutar hasta 100 acciones que se ejecutan en secuencia si se cumplen las condiciones de la regla empresarial. Hay muchos tipos diferentes de acciones, cada una con sus propios parámetros de entrada específicos. Los parámetros de entrada se rellenan con datos de las variables, funciones JavaScript, valores de codificación fija, etc.

A continuación se enumeran algunos ejemplos de acciones.

• Webhook/FSM webhook: estas acciones devuelven una variable de respuesta, que se puede utilizar en acciones subsiguientes.
• Ejecutar operación condicional: consiste en una condición que determina si la acción siguiente se ejecuta u omite.
• Crear/Actualizar/Eliminar objeto: se admiten los objetos personalizados y se hace referencia a ellos en el campo de tipo de objeto.
• Generar informe de lista de verificación: por cada instancia de lista de verificación cerrada en la actividad seleccionada, la aplicación generará un informe y lo adjuntará a la actividad.
• Validar: se utiliza en reglas de negocio sincrónicas para evitar que ocurra algo antes de confirmar los datos correspondientes en la base de datos. Por ejemplo, un cliente móvil/web que sincroniza algunos datos nuevos o modificados.

Las acciones de webhook de FSM se limitan a las API que requieren autenticación FSM. Una ventaja de esta acción es que ya no necesita definir una acción Webhook explícita para determinar un token de autorización para OAuth2. Solo debe introducir el ID de cliente y el secreto para asegurarse de que se utilizan las credenciales adecuadas.

En la sección Variable, el código consistirá principalmente en CoreSQL, con el fin de recopilar los datos relevantes. A lo largo de toda la regla empresarial, incluidas las consultas de CoreSQL, Javascript se puede utilizar: ya sea de forma independiente o para hacer referencia y manipular datos contenidos en variables previamente definidas. Todo lo que hay entre un signo de dólar y corchetes se interpreta como JavaScript ${...}. Las funciones de JavaScript deben basarse en el estándar ECMAScript 6.0.

Después de haber completado las secciones de desencadenador y acción de la regla empresarial, puede seleccionar Guardar. La aplicación solo valida los campos obligatorios, por lo que una regla de negocio guardada correctamente no indica automáticamente que la regla de negocio es válida. Sin embargo, el registro se guardará y podrá modificar la regla de negocio según sea necesario hasta que sea válida.

Para ayudar a garantizar que la regla empresarial funcione como se esperaba, es necesario validarla. La función de validación le permite simular la ejecución de reglas empresariales y ver cómo se están resolviendo las variables. Además, la función de validación verifica si la sintaxis básica de su regla es correcta. Sin embargo, las llamadas API no se ejecutan y los resultados no se confirman en la base de datos.

Para ir a la pantalla Validación, seleccione Validar. En la pantalla de validación, debe especificar los datos de entrada necesarios. Normalmente, esto significa seleccionar un registro de objeto relevante de la base de datos. Una ventana emergente permite al usuario seleccionar un objeto mostrando una lista de posibles ID de objeto. Sin embargo, normalmente es necesario encontrar primero un objeto relevante con la API de consulta, de modo que se conozcan las propiedades relevantes y se pueda simular el comportamiento de la regla empresarial en consecuencia. El campo de persona se puede utilizar para evaluar el impacto de los permisos del usuario o cuando las opciones del usuario y otros datos son relevantes.

Cuando se hayan introducido los datos necesarios, seleccione Validar. Durante la validación, todas las variables de la regla empresarial se resolverán y se mostrarán en la pantalla. Los fragmentos de JavaScript se ejecutarán y sustituirán por sus resultados/salida. Los errores provocan una interrupción del proceso y se mostrarán en la parte superior de la pantalla.

Después de una validación correcta, el siguiente paso es ejecutar la regla empresarial manualmente, en un entorno de prueba. Para ir a la pantalla de ejecución manual, seleccione Ejecutar.

Al igual que durante la validación, debe seleccionar los datos de entrada relevantes. Cuando haya terminado, seleccione Ejecutar.

A diferencia de la validación, la función de ejecución manual no muestra las variables resueltas. Además, todas las acciones se ejecutan de forma efectiva y los resultados se confirman en la base de datos. En función de su regla empresarial específica, la ejecución se puede evaluar verificando el log de ejecución, la base de datos o la IU web.

Una vez que la regla empresarial se haya probado correctamente en modo manual, puede activarla. Esto hace que la regla empresarial se ejecute completamente automáticamente, según las opciones de desencadenador.