Appian Community and Appian Academy are being upgraded. From July 24–August 3, the Appian Community will be in read-only mode. During this time, the site will be read-only and user registration will be disabled. We apologize for any inconvenience this may cause, but a more secure, stable, and performant Community experience is coming soon!
The new Appian Community launches August 3, followed by Appian Academy on August 7. During the migration, Appian Community Edition, Appian Academy, Documentation, Certifications, Instructor-led Customer Training, Partner Sales Training & Accreditation, and Forum (for Appian Partners and Customers only) will remain available.
Hi
I have a requirement where I need to invoke an asynchronous API that returns a jobId in the response. After a certain wait time, I need to call a second API to check the status of the job by passing the jobId received from the first API. This status API should continue to be invoked at regular intervals until the job completes successfully.
All of these steps must be completed before the form is submitted, as activity chaining needs to be maintained.
Our current plan is to use a Start Process smart service to initiate the asynchronous operation and capture the process ID. I can then use Query Process Analytics at configurable refresh intervals to monitor the process status until the second API returns a successful response. Once the process completes, I can retrieve the results and display them to the user in a grid.
Is there any better approach than this /any drawback in this approach. Anyone had similar requirement? Please sugget.
Discussion posts and replies are publicly visible
Hi DDharsana
Your approach is technically feasible, but the deciding factor is how long the external job typically takes.
If the job usually completes within a few seconds, I'd consider polling the status API directly from the interface (using a refresh variable or refresh interval) until the job completes or a timeout is reached. This avoids introducing another process model solely for polling.
If the external job can take longer (tens of seconds or minutes), then using a separate process model is more appropriate. However, I'd be cautious about relying on activity chaining for a long-running asynchronous operation, since activity chaining is intended for short-lived interactions and may not be reliable for extended polling.
Your proposed approach of starting a process and monitoring it via Query Process Analytics can work, but it does add complexity and requires handling retries, maximum wait times, failures, and process timeouts.
Out of curiosity, how long does the external job usually take to complete? That will largely determine the most suitable design.