Starting workflow instance from CAP service

[js2]

I'm wondering if its possible (and if any examples exist) for starting a CF workflow instance from a CAP application?

I can see examples (and the open sap cap course - week 4) cover calling external services but these are always OData services with an edmx file that can be used with the `cds import` command.

(According to `cds help import`: "Currently only OData EDMX input is supported".)

The workflow APIs (https://api.sap.com/api/SAP_CP_Workflow_CF/overview?name=SAP_CP_Workflow_CF&type=JSON∾tion=download&artifactType=REST) are REST API's only (not OData).

Alternative options would be to code the rest call directly in the UI5 app (though architecturally it seems better to do this from the cap service) or to fire an enterprise messaging event (which my cap service is doing anyway) and using CPI to capture that event and call the workflow api.

[js2]

Thankyou david.kunz2 and pdominique-bio. Will investigate this method. The fact that cds import states it only works with edmx files had me thinking I could only work with OData.

[david_kunz2 · Accepted solution]

Hi Jason,

It's also possible to send REST calls to remote services. You just need to set up a destination and connect to the service. In your code you can then send requests like the following.

const response = await tx.get('/Authors?$select=name')

More information can be found here: https://cap.cloud.sap/docs/guides/consuming-services#rest-and-odata

Best regards,
David

[js2 · Accepted solution]

Hi david.kunz2 - when defining the external rest service in the package.json there is a parameter called "model". The cap documentation just states that this is the "model The CSN model of the external service". How do I create the cdn model for the external service when its not an odata service (where cds import will do the work)?

The CAP documentation seems to skip this. I've re-watched the relevant sessions form the CAP open sap course and it also only shows this working wiht an odata service and `cds import`.

[david_kunz2 · Accepted solution]

HI Jason,

It's optional. For sending requests like `tx.get('/Authors?$select=name')`, you don't one.

Best regards,
David

[js2 · Accepted solution]

Hi again david.kunz2

I believe I have it all setup correctly now using the following:

const workflow = await cds.connect.to('workflowService')
const response = await workflow.tx(req).post('/v1/workflow-instances', {
            "definitionId": "IncidentFlow",
            "context": {
                "recipient": "test@test.com",
                "incident": {
                    "ID": "4e99b230-e7a4-44ef-aff4-90b4c1a17ebe",
                    "title": "Test by Jason",
                    "description": "This is a description",
                    "lti": false,
                    "location": "Perth",
                    "status_code": "SENT"
                }
            }
        })

However, I'm getting an error from the cap service when it attempts to call the workflow service via the destination:

ERR [2020-11-19T03:36:42.353Z | ERROR | 1346235]: Error: Failed to build HTTP request for destination: failed to build headers!
ERR Caused by:
ERR Error: Failed to build authorization header for the given destination. Make sure to either correctly configure your destination for principal propagation, provide both a username and a password or select "NoAuthentication" in your destination configuration.

I have setup the destination using OAuth2UserTokenExchange as the authentication method and got the client id, secret key etc from a service key on the workflow instance. this may be the issue?

[david_kunz2 · Accepted solution]

Hi Jason,

Did you bind your app to the XSUAA service?

Best regards,
David

[js2 · Accepted solution]

Yes - see safetyincidents-uaa in the mta:

## Generated mta.yaml based on template version 0.4.0
## appName = safetyincidents
## language=nodejs; multiTenant=false
## approuter=
_schema-version: "3.1"
ID: safetyincidents
version: 1.0.0
description: "A simple CAP project."
parameters:
  enable-parallel-deployments: true

build-parameters:
  before-all:
    - builder: custom
      commands:
        - npm install --production
        - npx -p @sap/cds-dk cds build --production

modules:
  # --------------------- UI MODULE ----------------------------
  - name: safetyincidents-ui
    # ------------------------------------------------------------
    type: nodejs
    path: app
    parameters:
      memory: 256M
      disk-quota: 256M
    requires:
      - name: safetyincidents-uaa
      - name: srv-api
        group: destinations
        properties:
          forwardAuthToken: true
          strictSSL: true
          name: srv-api
          url: ~{srv-url}

  # --------------------- SERVER MODULE ------------------------
  - name: safetyincidents-srv
    # ------------------------------------------------------------
    type: nodejs
    path: gen/srv
    requires:
      # Resources extracted from CAP configuration
      - name: safetyincidents-db
      # enterprise messaging
      - name: safetyincidents-em
      # Authentication
      - name: safetyincidents-uaa
      # destination to workflow api
      - name: safetyincidentworkflow
      # workflow instance
      - name: workflow_mta
    provides:
      - name: srv-api # required by consumers of CAP services (e.g. approuter)
        properties:
          srv-url: ${default-url}

  # -------------------- SIDECAR MODULE ------------------------
  - name: safetyincidents-db-deployer
    # ------------------------------------------------------------
    type: hdb
    path: gen/db
    parameters:
      buildpack: nodejs_buildpack
    requires:
      # 'hana' and 'xsuaa' resources extracted from CAP configuration
      - name: safetyincidents-db
      - name: safetyincidents-uaa

resources:
  - name: safetyincidentworkflow
    type: org.cloudfoundry.managed-service
    parameters:
      service-plan: lite
      service: destination

  - name: workflow_mta
    type: org.cloudfoundry.existing-service
    parameters:
      service: workflow
      service-plan: lite

  # services extracted from CAP configuration
  # 'service-plan' can be configured via 'cds.requires.<name>.vcap.plan'
  # ------------------------------------------------------------
  - name: safetyincidents-db
    # ------------------------------------------------------------
    type: com.sap.xs.hdi-container
    parameters:
      service: hana # or 'hanatrial' on trial landscapes
      service-plan: hdi-shared
    properties:
      hdi-service-name: ${service-name}

  - name: safetyincidents-em
    type: org.cloudfoundry.managed-service
    parameters:
      path: ./enterprisemessage.json
      service: enterprise-messaging
      service-plan: default

  - name: safetyincidents-uaa
    type: org.cloudfoundry.managed-service
    parameters:
      service: xsuaa
      service-plan: application
      path: ./xs-security.json


<br>

Destination:

[david_kunz2 · Accepted solution]

Hi Jason,

Can you please provide the whole log of the Cloud SDK output?

What should happen in principle is that the incoming token is forwarded to the Cloud SDK (we use that internally), which processes the request. Maybe the full log can give us more insights.

Thanks and best regards,

David

[js2 · Accepted solution]

david.kunz2 Here's the log output (cf logs <app_name>) from the moment I click save on the entity (which triggers the CAP handler that makes the external call to the workflow api): https://www.dropbox.com/s/1c04imcwt8zmhq8/cf_log.txt?dl=0

(as too big to post here)

[david_kunz2 · Accepted solution]

Hi Jason,

I think we need some help from the Cloud SDK colleagues, can you add the tag? Thanks!-

[js2 · Accepted solution]

Thanks david.kunz2 have added the sap cloud sdk tag. 😉

[js2 · Accepted solution]

Will create a separate question for this destinations issue I think - will link it back to this conversation.

https://answers.sap.com/questions/13195320/unable-to-call-external-service-sap-workflow-servi.html

[js2 · Accepted solution]

To anyone watching please see the comments on question https://answers.sap.com/questions/13195320/unable-to-call-external-service-sap-workflow-servi.html which describes the solution.

[pierre_dominique2]

Hi Jason,

Yes you can implement custom handlers to achieve this. There's also a library to help with that: https://github.com/sapmentors/cds-scp-api

Pierre