Skip to Content

In my previous blogs, you learnt how to integrate your custom application UI as user task in workflow that is then shown in My Inbox app. While this is one part of the story, in another part you may want to start the workflow from your external user interface or any SAP Cloud based application.

You have modelled the workflow and deployed it in SAP Cloud Platform. Now, how will the workflow be triggered ? – It could be via an external application or other SAP Cloud Applications. For example: when the user form is filled and a button is clicked then a workflow has to be started – say an approval workflow for leave or approval for travel expenses or workflow for asset repair or extended approval workflow from SAP SuccessFactors application when the new hire is created etc.

From external application you can start the workflow by using publicly available Workflow Runtime API and making a small configuration in your external application. From SAP Cloud Applications, you can either directly call the workflow REST-based service via HTTP/HTTPS protocol or via SAP Cloud Integration service. For more details on the latter, you can refer my blog

 

In this blog, I will guide you on how-to start a workflow instance from your application. I am assuming you have an SAPUI5 application and have some action defined in the application to start the workflow, say a button click.

Here you go:

  1. Open the SAPUI5 application in SAP WebIDE Full-stack
  2. Define the destination route in neo-app.json in routes array:
    {
        "path": "bpmworkflowruntime",
        "target": {
            "type": "destination",
            "name": "bpmworkflowruntime",
            "entryPath": "/workflow-service"
        },
        "description": "Workflow Service Runtime"
    }
    ​

 

  1. In the button action in Component.js or view.controller.js or where you have the action implementation do the following: (a) write the javascript function to call the API for fetching the XSRF token and (b) write the javascript function to call the API to start the workflow with desired initial payload
    _fetchToken: function() {
        var token;
        $.ajax({
            url: "/bpmworkflowruntime/rest/v1/xsrf-token",
            method: "GET",
            async: false,
            headers: {
                "X-CSRF-Token": "Fetch"
            },
            success: function(result, xhr, data) {
                token = data.getResponseHeader("X-CSRF-Token");
            }
        });
        return token;
    }
    ​

     

    »  where URL is <workflow-runtime-destination>/rest/v1/xsrf-token. You can find the destination in Connectivity –> Destinations in SAP Cloud Platform cockpit.

    »  bpmworkflowruntime is the default destination with ApptoAppSSO authentication type

    »  For more information on the workflow runtime API, refer the official API documentation

    _startInstance: function(token) {
        var model = this.getView().getModel();
        var inputValue = model.getProperty("/text");
        $.ajax({
            url: "/bpmworkflowruntime/rest/v1/workflow-instances",
            method: "POST",
            async: false,
            contentType: "application/json",
            headers: {
                "X-CSRF-Token": token
            },
            data: JSON.stringify({
                definitionId: <your workflow ID>,
                context: {
                    text: inputValue
                }
            }),
            success: function(result, xhr, data) {
                model.setProperty("/result", JSON.stringify(result, null, 4));
            }
        });
    }
    

    »  <your workflow ID> is the ID workflow. You can open the workflow SAP Web IDE and see the properties of the workflow to find the ID.

    »  inputValue is the initial payload with which the workflow starts. It can be your entire application model, a subset of your model or a completely new model.

    »  The only thing you have to ensure that the data model you pass must be of JSON type as the workflow API works on JSON body.

     

  2. Finally, implement the button action to get the CSRF token and then call the public workflow runtime API to start the workflow with the token:
    buttonAction: function() {
        var token = this._fetchToken();
        this._startInstance(token);
    }
    ​

    Once the action is performed and the workflow has started successfully, you will see the response from API as:

    {
      id =13,
      definitionId=LeaveRequestWorkflow,
      definitionVersion=2,
      subject=Leave Request for Alice,
      businessKey=11203,
      status=RUNNING,
      startedAt=2017-12-03:40:60:40.000Z,
      startedBy=Lorin,
      completedAt=null
    }
    ​

 

Previous Related Blogs
Understanding Custom UI Integration with SAP Cloud Platform Workflow
Part1A: Build your Custom HTML5 application in SAP WebIDE for Workflow
Part1B: Using your Custom HTML5 application as User Task in Workflow
Part1C: Working with Task APIs in your Custom HTML5 application

To report this post you need to login first.

11 Comments

You must be Logged on to comment or reply to a post.

  1. Christian Breitsprecher

    Hi Archana,

    Is it possible to use the workflowInstanceId as part of the business-key?
    I have tried to set-up the business key using $.info.workflowInstanceId, but it is not being evaluated as it seems.

    (0) 
    1. Archana Shukla Post author

      Hello Christian,

      Business key can be defined only based on the workflow context. For Example: ${context.OrderID} etc.  What is the need of defining the workflowinstanceid as business key?

      (0) 
      1. Christian Breitsprecher

        Hello Archana,

        Thanks for your reply.

        We would need it in order to correlate the intermediate messages in bigger processes. The problems we see with using the context information are that:

        a) we don’t always have a clear business key in the context data
        b) sometimes we require  the same intermediate message event in one process using different correlation conditions (for signal-type of events)
        c) different subprocesses might have different data available for callbacks to the main process. If we only have the context data as correlation condition this might not fit the data available in the subprocesses
        d) Broadcasts would require different correlation conditions as compared to intermediate message events only addressing one concrete instance

        Therefore we would see the ability to use the workflowInstanceId as an additional correlation criteria as highly beneficial.

        (0) 
        1. Krassimir Kondarev

          Hi Christian,

          yes, I fully understand the request.As of today it is not possible to set the value of the business key after instance start. We are planing to enable this in the future and then you will be able to set the business key value based on the instance id.

          However, this sounds more like a workaround to me. I think what you actually need, is to be able to send messages to workflow instances based directly on the workflow instance id. Is this assumption correct? If yes, please let me know and I will prioritize it accordingly.

          Best regards,

          Krassimir

          (0) 
          1. Christian Breitsprecher

            Hi Krassimir,

            Thank you for your feedback!

            If I understand you correctly, you would enable an option no intermediate message event level to either correlate according to the business key or the workflow instance ID or both, right?

            I think that would be a good step in order to resolve some of the cases mentioned above.

            The ideal and most flexible solution would probably be if we could define correlation conditions based on context information (including header information like workflow instance Id) using logical expressions for each intermediate message event (similar to Process Orchestration).

            Best regards,

            Christian

            (0) 
            1. Krassimir Kondarev

              Hi Christian,

              yes, this is correct, we plan to have multiple options for matching a message to a workflow instance, however I cannot give you concrete timeline as of today.

              Best regards,

              Krassimir

              (0) 
  2. Shilpa Koralagundi

    Hi Archana,

    Where can  i see the list of completed processes?(Like Manage Process in NWA).

    In “Workflow Monitor” tile, I cannot see “COMPLETED” processes. When I see the Network logs of Workflow Monitor, I see that the service is called only with the below “RUNNING/ERROR/SUSPENDED” parameters. Is this expected?

    https://flpportal-p1234567trial.dispatcher.hanatrial.ondemand.com/sap/fiori/bpmworkflowmonitor/wfs/v1/workflow-instances?%24top=100&status=RUNNING&status=ERRONEOUS&status=SUSPENDED&containsText=

    When i try the below URL, I see all the completed workflow instances. 

    https://flpportal-p1234567trial.dispatcher.hanatrial.ondemand.com/sap/fiori/bpmworkflowmonitor/wfs/v1/workflow-instances?$&status=COMPLETED

    Thanks,

    Shilpa.

    (0) 
    1. Archana Shukla Post author

      Yes Shilpa,
      Completed instances cannot be seen via Monitor Workflow app. This feature is currently under development and you would be able to soon filter (from all the available instances) for completed workflow instances as well. For now, you can only use Workflow Instance APIs to get the completed instances (which you already did :))

      Regards,
      Archana

       

      (0) 

Leave a Reply