Redirect user to a task form using Appian WebAPI

Question

Hi team, 
 Use Case: User wants to access specific Appian task form from the external system. The task is not readily available. But, based on the request, the process would get triggered and a task is generated. 
 So, the ask here is to create a web API which initiates the process which generates the task, get the task ID, and constructs the task form link, and lastly redirects the user to the link that is just generated. 
 
 Is this possible using Appian's Web API? 
 
 Thanks, Akshar

Eliot Gerson · Accepted Answer

bleh. that's my mistake--I wasn't thinking clearly and forgot that a POST request needs a form. I think you can still hack your way around it, BUT I would *strongly* encourage you to put in the work to keep things clean and handle edge cases. I need to emphasize that just because we can trick the system into treating a post like a get, it doesn't mean we necessarily should. Having said that, I was able to test out the following approach and get it to work: * Create a web api POST request to start your process. We'll call this "A". 
 * Create an integration object that invokes our rule A. Let's call this "B". For the "usage" option, select "queries". In this case, we are lying to the system, and it is extremely important that we put in appropriate guardrails to compensate for this. An example of such a guardrail would be a node early in the process that checks whether a process has already been started with the identifier we're passing in, and terminates itself if it realizes that it is a duplicate process. You could also theoretically put this check in rule A. In either case, you'd still want to be very wary of race conditions. In my own testing, I didn't have any issues with B getting executed multiple times, but if we've selected the "query" option, this is not guaranteed, and we shouldn't count on it. * Create a web api get request that will retrieve the task, given the identifier we used to start the process, and redirect us to the desired final url (e.g. the form for the task). We'll call this "C". 
 * Create a web api get request. We'll call this "D". "D" will look something like this: load(local!result:rule!B(
onsuccess:a!httpResponse(
 statusCode: 200,
 headers:{},
 body: ""
),
onError: a!httpResponse(
 statusCode: 500,
 headers:{},
 body:""
)),
a!httpResponse(statusCode: 301,
headers: a!httpHeader(name:"Location",value:"https://example.com/suite/webapi/C"),
body:"")
) 
 The reason for putting rule!B in a load is that the return type for rule!B (our integration object) is not the expected return type for a webapi. But that also means we're ignoring the actual result from B--including any errors. I would, again, encourage you to take the time to parse out the result from B and add appropriate logic to handle different possible outcomes. So, to summarize: the approach I've described should do what you want, but you'll need to add error handling, pay special care to race conditions (for example, what happens if the GET request is made before the task has been generated? what happens if two requests are made to start the same process? etc), and make sure to keep the logic lightweight and snappy . Parsing the response body, for example, is the sort of thing where it's possible to get carried away and put in overly complex, non-performant logic.

Josh · Answer

Have you tried responding to an API invocation with a HTTP Redirect Status Code ? That might get the browser to redirect the user for you.

Redirect user to a task form using Appian WebAPI

Top Replies