How to deal with Workflow Errors after RESTFul service

[PaulDuer]

Hi, we're trying to add a RESTFul webservice call to a new workflow. I am starting with a custom task so that I can run it over and over again.

I am going to read part of the URL from a DB custom table to get the hostname, etc.

Right now, it's erroring out with:

Error - Unable to parse the request/response.Please verify the configuration

I think it's because the URL is all bad.

BUT, I can't catch the error! I tried three different conditionals as you see below. My workflow JUST DIES. I don't need that, I need to catch that error and log it out, do something else.

HELP!

[BorisLekumovich]

What is the product version you are using?

How is the Response tab configured in the Rest node?

You can try checking the Proceed on failure checkbox.

Or, change the logs to debug, run your workflow and check in the aveksaServer.log where is the request being sent to, with what payload and what is the response.

[PaulDuer]

Thanks Boris! We're on 6.9.1 Patch 13.

Yeah I am going to try the Proceed Option next.

[BorisLekumovich]

Checking this checkbox will most likely cause the workflow to reach to the Stop node, but not sure it will bring you closer to figuring the root cause of the error.

I think you will have to look in the logs for the root cause.

[PaulDuer]

Thanks Boris, do you or anybody watching this have an example workflow with one of these nodes in it?

What do I put in the response fields? I don't understand them. I can return XML or JSON. i don't know what PROPERTIES are in this context?

[BorisLekumovich]

Here is an example:

[PaulDuer]

Okay, so I am making PROGRESS!!!

I was able to use a variable to set the URL, but what I learned quick is that I couldn't combine two vars on the URL, so I needed to send the ID param I wanted to use in the WebService as a GET param. That's not a big deal, I am writing the REST Service myself.

I also was able to use the XPath with the XML response type to get back my variable, which rocks out with socks out!

But, now the problem is transitions. Look at the workflow below, I have 3 lines leaving the RESTFul node with Completion codes, but NONE of them get hit. I need to be able to react to errors more than success, but I can't seem to capture success either.

Is Completion code not the right thing?

[BorisLekumovich]

In your completed (runtime) workflow, hit right click and choose Properties

In the Runtime Data tab, you should see 3 variables:

• HTTPStatus
• HTTPStatusMsg
• StatusCode

You can create decision nodes based on their values and then use a transition accordingly for every scenario

[PaulDuer]

Thanks Boris, yeah that was were I was going next too.

However, I think it might not work at all, period. I am testing it right now with a known bad URL. The RESTFul node is just hanging without completing. It's 5 minutes in now and no response.

That won't work for our processes, we'd expect that if the URL was bad and a 404 was returned, we'd pop out of the node quick and be able to switch to a error process.

I am going to keep messing with it. But, I don't see much chance of using this in production.

I was hoping to replace many of our SQL nodes with service calls. We've have a heck of a time with the single quote issues making SQL nodes fail. This was the hope that if we handled the SQL, all would be good.

But, theses workflows are expected to run quickly and if there's failure, to report that!

[PaulDuer]

Okay, so I decided not to give up so EASILY. But I am stuck again.

I see the HTTPStatus publicdata vars after the RESTFul WebService runs, but I can't get them to WORK in a decision node!

Why?

I tried both PublicData_HttpStatusCode and just HttpStatusCode

The VARS are NOT available on the right click menu... very sad here.