Make a process singleton

Appian processes are not alike to operation system threads. There is no synchronization mechanism and you have to do it manually on external object like CDT. You can put a check query at your start form to prevent starting a new process every time. But the result for two simultaneous calls can be the same because no transaction yet updated the process. In this case you should have an action that updates the database (@Version annotation), so one update will pass, and others will fail.

Another way I can think of is to use a process with a timer. Any user can click "start" which will update boolean flag in a CDT and this timer can run every few seconds starting another process if the flag is on and using own flag (process variable) to prevent duplication. From user perspective there will be some pause between "start" and process start.

Thank you for clarifying the "behavior" of the process sergeiz.

I think my last attempt will be the following :

1) Trigger through process to process messages instead of timers (more clear than a polling alternative).

2) When triggered offer a gateway that will query a flag (external object CDT like mentionned through a version annotation). If true proceed, if false end process.

Do you have a quick example of the @Version annotation? Not familiar with the notion.

It is a simple annotation for a CDT field. See docs.appian.com/.../Database_Schema_Best_Practices.html

In the end here is what we did and it seems to work perfectly :

1) Start the process in the background the moment it is published (with a delay on the start event set to now())
2) We hit a receive message node that listens for the event to be triggered
3) The moment we receive a message we create a task (gets to the create task node)
--> If other messages are received the process is still locked to the create task node, not creating additional tasks
4) During the task the user can do some actions which loops back to the task as long as it's not completed/finished

When the user finishes the task but right after an event is trigerred (a message is sent to the message node) the task is recreated correctly and only one task is running at a time.

Another particular thing I like to mention is that the task is an UI of all records created (when a record is created a message is sent to this process thus creating the "singleton task"). Through the UI the user can set a status to "finish" all the said records. Once all records are finished he can then "finish" the task and the process returns to listening for messages on creation of records (and thus the task is not shown anymore since there is no more records to manage at all). The nice thing about this is let's say the user has an empty grid under the task and in the UI he's about to click on "finish" to terminate the task. Well if "meanwhile" a record was created and his UI didn't refreshed when clicking on finish to terminate the UI will submit the form but instead simply refresh the UI and voila the grid displays the newly added record without terminating the task.

This was actually a surprise to me but makes it all perfect for the user experience (because when there's a record he can't finish the task anymore he needs to manage the said record/records).

In the end here is what we did and it seems to work perfectly :

1) Start the process in the background the moment it is published (with a delay on the start event set to now())
2) We hit a receive message node that listens for the event to be triggered
3) The moment we receive a message we create a task (gets to the create task node)
--> If other messages are received the process is still locked to the create task node, not creating additional tasks
4) During the task the user can do some actions which loops back to the task as long as it's not completed/finished

When the user finishes the task but right after an event is trigerred (a message is sent to the message node) the task is recreated correctly and only one task is running at a time.

Another particular thing I like to mention is that the task is an UI of all records created (when a record is created a message is sent to this process thus creating the "singleton task"). Through the UI the user can set a status to "finish" all the said records. Once all records are finished he can then "finish" the task and the process returns to listening for messages on creation of records (and thus the task is not shown anymore since there is no more records to manage at all). The nice thing about this is let's say the user has an empty grid under the task and in the UI he's about to click on "finish" to terminate the task. Well if "meanwhile" a record was created and his UI didn't refreshed when clicking on finish to terminate the UI will submit the form but instead simply refresh the UI and voila the grid displays the newly added record without terminating the task.

This was actually a surprise to me but makes it all perfect for the user experience (because when there's a record he can't finish the task anymore he needs to manage the said record/records).