Getting Task Information via API

bob · August 13, 2018, 2:01am

I am try to follow the instructions in this Camunda Blog post:
https://blog.camunda.com/post/2015/08/start-and-complete-process-with-rest-api/

But the call to getting task information only returns an empty array, either via POST or GET.

The call is:

http://[SERVR IP]:8080/engine-rest/task/?processInstanceId=7a4b0886-9e9a-11e8-95a3-a202dc723aa6

And the value for proessInstanceId is copied from cockpit.

According to the docs (that I’ve found) I should get a JSON back. But only get back an empty array.

Any ideas as to why this may be?

Thanks,

Bob

Niall · August 13, 2018, 6:19am

It’s possible that you have a process instance which has no active user tasks.

Are you able to find the task if you simple query for all tasks?
http://[SERVR IP]:8080/engine-rest/task

bob · August 14, 2018, 12:31am

Hi Niall,

Thanks for the note.

To answer your second question: No. Can’t find any of the tasks when I send the [http://Server IP]:8080/engine-rest/task using Postman, I get an empty array back with Status 200. Same results for POST or GET.

Below is the process I followed using Postman. May be you can see something that I’ve been missing over the past 10 hours! I have masked the server ip for obvious reasons. However, this is a demo server. So if you really want access, it’s not a problem.

I am using community 7.9.0.

Also, this is a really simple model. I have attached it to this email. Hopefully it’ll upload or otherwise get to you.

Thanks for any and all help. This is now my roadblock and any pointers will be appreciated.

Bob

Step 1: Use Postman to start the process (Already deployed using the modeler)

Method: POST

URL: http://IP:8080/engine-rest/process-definition/key/verifyUser/start

Body: Raw, JSON(application/json)

{

“variables”:{

 "userName" : {

   "value" : "username",

   "type": "String"

        },

 "password" : {

   "value" : "password",

   "type": "String"

},

"userVerified" : {

 "value" : "NoK",

 "type" : "String"

}

},

“businessKey” : “0001”,

“withVariablesInReturn”: true

}

RETURN:

Status: 200

Body:

{

"links": [

    {

        "method": "GET",

        "href": "http://IP:8080/engine-rest/process-instance/ed14e97a-9f54-11e8-ab74-a202dc723aa6",

        "rel": "self"

    }

],

"id": "ed14e97a-9f54-11e8-ab74-a202dc723aa6",

"definitionId": "verifyUser:1:ea6336f9-9f54-11e8-ab74-a202dc723aa6",

"businessKey": "0001",

"caseInstanceId": null,

"ended": false,

"suspended": false,

"tenantId": null,

"variables": {

    "password": {

        "type": "String",

        "value": "password",

        "valueInfo": {}

    },

    "userVerified": {

        "type": "String",

        "value": "NoK",

        "valueInfo": {}

    },

    "userName": {

        "type": "String",

        "value": "username",

        "valueInfo": {}

    }

}

}

In Cockpit, I see the process started. It is waiting on the first Service Task (since the worker is not running)

Step 1: Use Postman to follow the blog to Get a Task

Method: GET (same results with POST)

URL: http://IP:8080/engine-rest/task/?processInstanceId=ed14e97a-9f54-11e8-ab74-a202dc723aa6

Body: Raw, JSON(application/json)

{

}

Or nothing at all, same results.

RETURN:

Status: 200

Body:

[]

genericLogin.bpmn (5.72 KB)

bob · August 14, 2018, 2:18am

Hi Niall,

This may be a little bit more information.

I’ve been playing around with this in the Cockpit and Tasklist apps.

Seems like (not sure) that the only tasks that show up on the Tasklist are User Tasks? Is this true? (The documentation does not seem to differentiate in the API docs, but maybe I missed something.)

If this is a “feature,” then how can I get a list of Service Tasks that are in the wait state?

Thanks again,

Bob

Niall · August 14, 2018, 6:25am

Task list and in fact all calls via the Task REST endpoint only refer to to User Tasks other tasks types e.g. Service Tasks can be quieried for differently depending on how they’re implemented.

If you’re implementing Service Tasks via a Java Class it’s likly it’s never actually waiting at that task - it’s completed within a transaction.

If you’re implementing Service Tasks using the External Task pattern then you can look for them using this call: https://docs.camunda.org/manual/7.9/reference/rest/external-task/get-query/

So what are you trying to achieve exactly?

bob · August 14, 2018, 7:19pm

Thanks for the note Niall. Much appreciated.

I am using external tasks with the REST Api and Node. I will see if /external-task/get-query might work.

What I am trying to do is actually really simple! It’s a login pattern. I want to get the user info via a web form (not a Camunda embedded form), then authenticate the credentials via an external task and, finally, return a OK or NotOK back to the web form. The kind of thing that happens billions of times a day on the web. The workflow is important (and the reason why we are considering to embed/use a workflow engine) because different of our customers have different login workflows. For example, some have 2FA requirements, others do not, etc. Furthermore, over 90% of our app (in the logistics space) is implementing some sort of workflow. I am looking at Camunda as possibly be the internal workflow engine, so we don’t have to hardcode workflows.

The login process is an example of the kind of pattern we need to implement – something starts out a workflow process, a set of data is produced, and that data is visualized via a web app, or triggers other workflows.

This pattern seems rather “normal” to me. However, it also seems clear that I’m missing something about how Camunda works, or its intended use cases. Unfortunately, so far, working with Camunda has been an exercise in frustration. I would certainly be grateful for any pointers/documentation/books/videos, etc. that could make it easier for me to understand how to work with Camunda. For the record, I have watched all the videos, took your webinar a couple of weeks ago, and read a lot of the documentation. Yet, I still feel like I am missing something very fundamental.

Thanks, and have a wonderful day,

Bob

Niall · August 14, 2018, 9:23pm

This videos are a good place to start. https://camunda.com/learn/videos/

All the documents you’ll need are at docs.camunda.org.

We even have a getting started guide, in case you prefer following documented instructions: https://docs.camunda.org/get-started/quick-start/

bob · August 14, 2018, 9:50pm

Thanks again Niall.

Yep. I had watched and reviewed all of these. But thanks just the same.

I am going to give this a little more time, more because I am curious about what it is that I’m missing. This is a competitive evaluation and I’ve developed the same login process in two other BPMs with very little effort.

What might help your customers, if I may be so bold as to suggest this, is to have a “full loop” demo/tutorial that shows how the Camunda technology can interoperate with Web technologies. Anything that can start from a web page, then use the workflow engine to do something, then return the data to the web page would, in my view, tremendously helpful to your customers. Particularly those who are attempting to learn/evaluate your product.

My gut tells me that Camunda is perhaps the best Open Source solution out there. I like a lot of the features, and particularly the REST and node.js support. But, at the end of the day, there is a tradeoff between great tech and how much effort it takes to use it in a real world use case.

Have a wonderful day.

Bob

Niall · August 15, 2018, 6:19am

Generally I assume that by following the REST API video tutorial you would be able to get an understanding how a front end would communicate with camunda, regarding tasks and process state.

Also if you want to see how a front end communicates to the back end - tasklist and cockpit both use the REST API for everything they they do. So for anything you want to achieve you should use that as an example.

bob · August 15, 2018, 7:27am

Thanks for this, and again for all your kind notes Niall.

I’ve actually been doing exactly what you suggested – that is looking at Cockpit and Tasks web apps and trying to synch up my understanding with what those apps show.

There are a few issues – some are minor. Others, so far, been a source of confusion. The one that continues to baffle me is how to discover, using the REST API, when a Service Task is in wait state. The Cockpit clearly knows how to do this. When I kill a worker task, the corresponding service task remains in wait state and I can see this in the Cockpit. But, so far, I haven’t been able to find the right REST API call/configuration to do this in my code.

Why is this important? From a practical perspective, knowing when a task is stuck makes a difference in error handling. I faked a work around by inserting a User Task as the next task after a Service Task. Since I can check if a user task is in wait state or not, this got me around the problem. But it’s not a permanent fix.

There are a bunch of issues like this. While I acknowledge that some of this is probably because I am knew to Camunda, building a very simple “full loop,” where data is collected via web page, passed on to the engine, and some data is returned to the front-end by the Camunda engine, has so far been a bit of, shall we say, adventure!

But maybe some good will come out of this exercise. I of course will publish everything I did, and the code for the full-loop on my blog and will send you a link. Maybe that’ll help someone else in the community.

Have a wonderful day,

Bob

:–)