Las organizaciones pueden crear, automatizar y gestionar flujos de trabajo en un entorno de nube con la ayuda de SAP Workflow Management, un servicio nativo de la nube ofrecido por SAP.

Ofrece un enfoque de código bajo/sin código, que permite tanto a los usuarios empresariales como a los desarrolladores crear, modificar y automatizar flujos de trabajo sin tener una experiencia sustancial en codificación.

Si bien SAP Workflow Management es una herramienta poderosa para automatizar y administrar flujos de trabajo en un entorno de nube, como cualquier tecnología, también tiene algunas limitaciones, como el manejo de flujos de trabajo complejos, integraciones complejas, rendimiento, manejo de grandes volúmenes de datos, soporte fuera de línea, automatización y pronto. Además, se encontró que la curva de aprendizaje es alta en casos prácticos. SAP ha anunciado el retiro de SAP Workflow Management y ha introducido una herramienta más moderna, integral y “amigable para los ciudadanos” llamada SAP Build Process Automation. Las diferencias clave entre SAP Workflow Management y SAP Build Process Automation se resumen en esta tabla

Debido a que la capacidad de SAP Workflow Management ha sido reemplazada por SAP Build Process Automation, la dirección a seguir para los clientes de SAP Workflow Management es crear nuevos flujos de trabajo en SAP Build Process Automation. Los flujos de trabajo existentes creados en SAP Business Application Studio se pueden consumir en SAP Build Process Automation. SAP ha proporcionado algunas opciones de migración. Sin embargo, existen algunas limitaciones en estas opciones de migración. Si bien la solución SAP Workflow Management estaba disponible en los propios centros de datos de SAP (para Neo) y en varios hiperescaladores (para Cloud Foundry), SAP Build Process Automation está disponible solo en centros de datos limitados de Cloud Foundry.

Echemos un vistazo rápido al proceso de migración a SAP Build Process Automation, de la siguiente manera:

• Flujos de trabajo: Aunque la solución ideal habría sido convertir fácilmente los flujos de trabajo existentes desarrollados con SAP Workflow Management, lamentablemente no es posible. Debido a una arquitectura interna diferente, los modelos de flujo de trabajo existentes no se convertirán automáticamente en el generador de procesos en SAP Build Process Automation; más bien, los nuevos flujos de trabajo deberían crearse en SAP Build Process Automation. Sin embargo, los flujos de trabajo creados en SAP Business Application Studio se pueden modificar en SAP Business Application Studio e implementar en SAP Build Process Automation.
• Reglas del negocio: Los proyectos de reglas comerciales de una subcuenta de SAP Workflow Management deben importarse a una subcuenta de SAP Build Process Automation y deben volver a implementarse como servicios de reglas en una subcuenta de SAP Build Process Automation. Las asignaciones de usuarios y roles dentro de la subcuenta de SAP Build Process Automation también serán necesarias para realizar modificaciones, implementaciones y administración adicionales de estas reglas. Las reglas de negocio implementadas directamente para SAP S/4HANA deben volver a crearse como proyectos en la subcuenta de SAP Build Process Automation antes de poder usarse.
• Escenarios de visibilidad de procesos: Los escenarios de visibilidad del servicio SAP Workflow Management deben importarse a un proyecto de proceso empresarial y luego volverse a implementar. Una vez importados correctamente, se pueden ajustar al igual que los escenarios de visibilidad creados como parte del proyecto de proceso de negocio en SAP Build Process Automation.

Nota del editor: esta publicación ha sido adaptada de una sección del libro. Flujo de trabajo para SAP S/4HANA de Sabyasachi Dutta, Nilay Ghosh, Kousik Goon, Sandip Jana, Arindam Mukherjee, Srinivas Rao, Yogeendar Rao, Yogesh Sane, Naveen Veshala y Kiran Viswanathan.