Cómo construir mi primer workflow en SAP Cloud Platform

Cómo construir mi primer workflow en SAP Cloud Platform

Lee este post antes de empezar este tutorial si necesitas tener claros los fundamentos básicos de los elementos de workflow.

  1. Creamos un nuevo proyecto de workflow (recuerda habilitar en el espacio las extensiones de workflow management).
yo

  • Project name: Es el nombre del nuevo proyecto de SAP Cloud Platform que construirás para el nuevo requerimiento del cliente. En mi caso lo he llamado myWorkflow.
cd myWorkflow
yo

  • Module name: nombre del módulo (carpeta) donde se instalarán toda la estructura de carpetas para crear el proyecto de workflow.
  • Workflow Name: nombre del archivo .workflow.

En el archivo mta.yaml, cambiamos la propiedad service-plan a lite ya que estamos usando una cuenta trial.

_schema-version: "3.2"
ID: myWorkflow
version: 0.0.1
modules:
  - name: myWorkflow
    type: com.sap.application.content
    path: myWorkflow
    requires:
      - name: workflow_mta
        parameters:
          content-target: true
resources:
  - name: workflow_mta
    parameters:
      service-plan: lite
      service: workflow
    type: org.cloudfoundry.managed-service

2. Una vez esta información se haya introducido, llegarás al editor de workflow (haciendo doble click en el archivo .workflow generado si no se abre automáticamente), donde podrás ver la sección Workflow Properties

  • Subject: Es importante especificar algún subject porque (además de que es obligatorio) te ayudará a identificar la instancia del workflow iniciada.
  • Business key: Es un parámetro opcional, pero es bueno especificarlo ya que te ayuda a descifrar las instancias de workflow generadas en tiempo de ejecución basadas en el escenario de negocio y datos.

Eventos del workflow

Los eventos del workflow impactan al proceso del workflow en cada fase, desde lanzar el workflow hasta terminarlo. SAP Cloud Platform Workflow soporta actualmente cinco tipos de eventos:

Start event

Representado por un círculo fino, el start event lanza el proceso del workflow. En SAP Cloud Platform Workflow, cada Workflow tiene un único lanzador de este evento. Por ejemplo, pensemos en el caso de lanzar un evento de workflow  cada vez que se genere un cliente potencial en el sistema SAP Hybris Cloud for Customer. Sigue los siguientes pasos para crear un start event para el workflow:

  1. Ve al editor del workflow, y de la paleta de herramientas a la izquierda, elige el icono del círculo. Te dará cinco opciones. Click en la primera opción, Start Event. Esto fijará el icono en el cursor. Arrástralo al panel y haz click de nuevo para soltar el Start Event en el panel.
  2. Luego, proporciona un nuevo nombre y descripción al start event. Por defecto, el sistema proporciona un nombre como StartEvent. Puedes mantenerlo o cambiarlo de acuerdo a tus requerimientos de negocio. El ID, sin embargo, no se puede cambiar.
  3. Guarda los cambios.
SAP Cloud Platform Workflow API

Una manera de iniciar una nueva instancia de workflow y trabajar con las tareas es usando el API de SAP Cloud Platform Workflow en https://api.sap.com/. Puedes usar este API para lanzar un workflow basado en una UI custom, Ve a https://api.sap.com/y busca “SAP Cloud Platform Workflow”:

Seleccionamos Workflow API for Cloud Foundry. Vamos a Workflow Instances:

Como ejemplo, el método POST proporcionado por esta API se puede ussar para iniciar una nueva instancia de workflow. El workflow se lanza a través de la llamada a la API, y se proporciona un payload para esto.

Esquema modelo

{
  "definitionId": "string",
  "context": {},
  "attachments": {
    "rootFolder": "string",
    "groups": {
      "additionalProp1": {
        "folder": "string",
        "refs": [
          {
            "objectId": "string"
          }
        ]
      },
      "additionalProp2": {
        "folder": "string",
        "refs": [
          {
            "objectId": "string"
          }
        ]
      },
      "additionalProp3": {
        "folder": "string",
        "refs": [
          {
            "objectId": "string"
          }
        ]
      }
    }
  }
}

Esquema modelo (con Payload)

{
  "id": "13",
  "definitionId": "LeaveRequestWorkflow",
  "definitionVersion": "2",
  "subject": "Leave Request for Alice",
  "businessKey": "s021445",
  "status": "RUNNING",
  "startedAt": "2016-11-01T19:59:59.000Z",
  "startedBy": "Alice",
  "completedAt": null
}
Lanzar el Workflow desde el Tile de Monitor Workflow

La segunda forma de lanzar SAP Cloud Platform es desde el tile Workflow Definitions. Una vez dentro del tile, puedes iniciar el workflow haciendo click en el botón Iniciar nueva instancia. Esto sacará un pop-up donde puedes poner el contexto del JSON, que es simplemente el payload que podemos pasar en el start event del workflow. En el pop-up, click en Iniciar nueva instancia para lanzar el workflow.

 

Desde SAP Cloud Platform Ingtegration

Otra forma de lanzar SAP Cloud Workflow es desde SAP Cloud Platform Integration, el iFlow puede usar HTTP sender/HTTP receiver. En esta interfaz, primero tienes que preparar el contexto de la petición o el cuerpo necesario para lanzar el workflow. Luego, extrae el token XSRF usando el paso de la respuesta de la petición y la interfaz. Aquí, el endpoint para la respuesta de la petición es la URL host para el servicio SAP Cloud Platform Workflow. El siguiente paso es hacer una llamada HTTP POST para la URL host del servicio SAP Cloud Platform Workflow.

 Intermediate Message event

Si el intermediate message event está implementado y es encontrado por SAP Cloud Plaftorm Wokrflow, el workflow para y espera por el mensaje antes de que los siguientes pasos del proceso sean ejecutados. Este evento es representado por un círculo fino con un sobre dentro.

Por ejemplo, digamos que la determinación de un aprobador ha fallado y se envía una notificación al administrador del workflow para gestionar a los aprobadores como lógica de negocio. En este caso, se puede configurar un intermediate event para reiniciar el workflow una vez que el administrador gestiona el aprovador y envia el mensaje al workflow para iniciar el proceso.

Intermediate timer event

Cuando usamos el intermediate timer event dentro del flujo de una secuencia (flujo normal) de un proceso, indica que el proceso esperará. Un intermediate timer puede definirse para esperar una cantidad de tiempo fija – 30 días, 20 segundos, etc. Un intermediate timer event puede también representar un retraso hasta una hora o fecha fijada.

Terminate and End Events

Un end event se representa por un círculo grueso vacío, así como un terminate event se representa por un círculo grueso con un pequeño círculo sólido en su interior. La diferencia básica entre estos dos eventos es el checkbox Terminate en el panel End Event Properties. Si deseleccionas el checkbox, el evento se vuelve en un end event. Por otro lado, sigue siendo un terminate event. La diferencia funcional entre estos tipos de eventos es que el end event marca la terminación de un workflow, sin embargo el terminate event marca la terminación o el final de una rama dentro del workflow. Un workflow puede tener muchas ramas, y en algunas condiciones particulares puedes querer terminar esta rama y proceder con otras. Los pasos para crear estos dos eventos son los mismos que para el start event.

Tareas del Workflow

Cada SAP Cloud Platform Workflow se compone de una serie de pasos que forman el proceso de negocio end-to-end. Una tarea de SAP Cloud Platform Workflow es un paso de actividad que puede ejecutarse dentro de una definición de un workflow. En términos simples, todos los workflows envuelven diferentes niveles de interacción con usuarios o internamente para calcular y proceder con los siguientes pasos. Las tareas se usan para cumplir estas interacciones. Actualmente, SAP Cloud Platform proporciona tres tipos de tareas: user tasks, service tasks, y script tasks.

User tasks

Una user task es un paso de actividad de usuario que envuelve una interacción de usuario. Estas tareas aparecen en las tareas de My Inbox, donde el procesador de la tarea puede completar la instancia de la tarea y visualizar la descripción de la tarea. Esta acción puede tomar cualquier formulario, así como aprobación/rechazo o asignación de los valores necesarios para el usuario y la continuación del workflow. Sinalmente, en la sección de interfaz de usuario de las propiedades de la user task, puedes proporcionar las tareas UI se despliega en SAP Cloud Platform.

Sigue este ejemplo para crear una tarea de usuario de workflow en SAP Business Application Studio.

 

Recipients: Ten en cuenta que esta es una tarea de usuario, y necesitas alguien que actúe sobre la tarea en la aplicación My Inbox. Para añadir un usuario, necesitas proporcionar los IDs del recipient. Un ID es el ID único del usuario en SAP Cloud Platform. Puedes también añadir el nombre de un grupo en lugar de especificar el ID del usuario separado por comas.

Service tasks

Una service task es un paso en un workflow que no requiere de ninguna intervención de usuario y se ejecuta por el workflow en si mismo. Una service task puede usarse para procesar alguna actividad, por ejemplo, consumiendo los servicios expuestos (como RFC/BAPI, OData, REST, HTTP, IDoc, etc) de los sistemas backend existentes (soluciones cloud u on-premise). Cuando el control llega a la service task, la configuración proporcionada se ejecuta inmediatamente, y el control se mueve hacia adelante.

Sigue este ejemplo para crear una tarea de servicio de workflow en SAP Business Application Studio.

Script Tasks

Las script tasks son un paso del proceso SAP Cloud Platform Workflow que se ejecuta por el workflow mismo en forma de script. Cuando el control llega a esta tarea, el script codificado dentro se ejecuta. La script task puede usarse para procesar un input del contexto del workflow y guardarlo como una variable de salida que puede usarse en los siguientes pasos. Esencialmente, la script task se usa para modificar los datos del contexto del servicio del workflow o implementar una lógica empresarial ligera. Las script task usan JavaScript para leer y modificar las variables del contexto del servicio SAP Cloud Platform Workflow.

Sigue este ejemplo para crear una tarea de servicio de script en SAP Business Application Studio.

Gateway Controls

Necesitamos objetos de flujo gateway para controlar el flujo de la ejecución en el workflow. Están disponibles dos tipos de controles gateway:

Exclusive Gateway

Puedes usar un exclusive gateway para evaluar todas las secuencias de salida si el control del workflow continúa por la rama donde la condición es evaluada a true.

Si habéis realizado el tutorial de los puntos anteriores, vamos a hacer una prueba con este mismo proyecto, en caso contrario puedes hacerlo aquí o descargar el proyecto de este git rama “main”.

Vamos a añadir un control exclusive gateway al flujo actual donde, si la variable notFormatted = true, directamente ejecute la tarea de usuario que hemos creado en nuestro proyecto, si no por defecto seguimos con el flujo que teníamos antes de este cambio.

Si marcamos el flag de default siempre se ejecutará esta rama, a no ser que se cumpla alguna condición de las otras ramas.

Cuando usas un exclusive gateway, uno de los flujos de la secuencia tiene que estar marcado por defecto. Esto es obligatorio, porque cuando no se encuentre requerimiento o sea verdadera ninguna condición, el flujo de la secuencia que esté marcado por defecto se ejecuta. Una flujo de secuencia que esté marcado como por defecto no tendrá ninguna condición.

Para probarlo, como siempre, vamos a Workflow Management y iniciamos una instancia del workflow, además indicamos la variable notFormatted en el contexto y la marcamos como true.

Cuando visualizamos el log de ejecución de la instancia del workflow podemos ver las tareas ejecutadas. En este caso, como notFormatted se ha marcado a true se ejecuta directamente la tarea de usuario:

Si instanciamos el workflow notFormatted = false pasando la variable a false, el proceso del workflow ejecutará también la tarea Change creator:

 https://github.com/saradasilva/sapworkbench-WF-serviceTask/tree/gateway

Parallel Gateway

En contraste con exclusive gateway, un parallel gateway puede usarse para manejar múltiples secuencias de workflow al mismo tiempo. Además, un parallel gateway es útil para mezclar múltiples secuencias ejecutándose en paralelo.

Seguimos usando el mismo proyecto que el punto anterior, pero vamos a usar un parallel gateway para paralelizar dos tareas de usuario:

Para probarlo nos vamos a Workflow Management e iniciamos instancia con el siguiente contexto:

{
"notFormatted": false
}

En el flujo del workflow podemos ver que se han lanzado dos tareas de usuario a la vez:

 

Determinación de agentes

En cualquier workflow que crees en SAP Cloud Platform Workflow, necesitarás determinar el agente en una user task para que el workflow se dirija hacia el agente correcto, quien puede actuar en ella. En SAP Cloud Platform Workflow, el agente se puede determinar de dos formas posibles:

  • Determinación usando una Script task
    Consideremos un escenario donde el aprovador se determine dependiendo de la región. Cuando inicies el workflow, puedes ajustar la lista de aprobadores para las regiones durante el tiempo en que el workflow sea lanzado. En este caso, podrías tener una script task en el lugar donde obtienes la región devuelta de SAP SuccessFactors usando una service task. La lógica de negocio dentro de la script task puede usarse para ajustar el nuevo aprobador en el contexto del workflow, cuya user task puede usarse en el próximo paso.
  • Determinación usando una Service task
    Determinar el agente a partir de una service task también es posible. Por ejemplo, puedes llamar una API en SAP SuccessFactors que te devuelva el manager del empleado.

Con esto deberíais aprendido las bases para empezar vuestro primer proyecto en SAP Platform Workflow ¡espero que os haya ayudado tanto como a mi hacerlo!

 

Facebooktwitterlinkedinmailrss

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *