Interface - Process Model: The 'On Success' variable is not displaying the final value of the variable

Can you provide more detail on what you are seeing vs. expecting from the onSuccess saves, and/or share your code? If you are exceeding the activity chaining limit then that is likely your issue (from the a!startProcess docs "...and the values of process variables (such as fv!processInfo.pv.employeeId) once all initial activity-chaining is complete"). If possible it would be best to avoid chaining through so many nodes.

Echoing Dan's reply - this feature isn't really meant for situations where massive chaining / looping is happening.  Any chaining effect will break after the 50th flow connector, so the best approach would be to design around this in such a way that it isn't critical to get the final value passed back into your interface, if you have to perform hundreds of loops in-process.  Can you share a bit more detail around your use case / what you're trying to accomplish in general, that this is required?

Certainly, I have the following variables: local!tasks (all Tasks that need to be analyzed - 100 Tasks), local!modifiedTasks (tasks with new dates, should be 100 Tasks):

This is inside the toggle button:

a!startProcess(
processModel: cons!PROCESS_MODEL,
processParameters: {
initialTasks: local!tasks,
},
onSuccess: {
a!save(
local!modifiedTasks,
fv!processInfo.pv.modifiedTasks
),
}
)

What I am seeing are 15 tasks, but what I am expecting is 100 tasks.

In the process model, I could observe in the 'modifiedTasks' variables: 100 tasks.

Well, it's a functionality for creating a Gantt chart in which you display up to 100 tasks. The toggle button activates a preview that updates the start date of the tasks to a working day ahead, and also manages the concept of dependencies: Task 1 starts on Monday and ends on Tuesday, Task 2, which depends on Task 1, should start on Wednesday and end on Thursday, Task 3, which depends on Task 2, starts on Friday and ends on Monday and of course it enters the loop because if there are more dependencies below, for example Task 5, which depends on Task 2, it should take the updated date from Task 2. Recursion was attempted but there was a performance problem, and now we have this limitation of the 50 nodes. Is the any advise for this?

Thanks for the extra context here and on your other reply - what Smart Services are you using within your process model to update the task? A screenshot could also help. Are these Appian tasks or some kind of DB-driven tasks? If this is a strict requirement for your front-end design then the best way to address this will be to redesign the process model to avoid looping.

Thank you. Well, the iterative loop is inside the red square. Here, all the tasks that need to be updated are analyzed. Tasks will have their start dates updated to the next workday after their last dependency’s end date. No, I am not working with a database because it's only a preview. After the user decides they are satisfied with the new order or the tasks, there is another button, with another process model, that updates all dates in the database.

It looks like those are two script tasks to update the tasks/dependents, and then an XOR to iterate through your list. Are you able to redesign this to be a single script task that uses a!forEach instead? That is generally preferred over looping in a process model when possible, and in your case will avoid hitting the node chaining limit.

Thank you for your recommendation. Just to confirm, is there any way to obtain the final variable from the process model, isn't there?

yahairat said:

Just to confirm, is there any way to obtain the final variable from the process model

If you were able to refactor the process model to avoid that loop (i.e. do the looping internally in a script task in a single epxression rule, if possible), then you'd probably get the final PV value returned at your calling interface.

Can you share anything more about what's happening inside the two looping nodes?  Often (though maybe not always) a loop like this can potentially be replaced with an expression rule that handles necessary looping via an a!forEach() call, etc.

Sure, in the "Update each Task" process, I input each Task from the array tasksToUpdate using its index (tasksToUpdate,pv!index, null). Then, I send this input to the expression that generates the new date. The updated task is then appended to the modifiedTasks array. In the 'Update dependents' process, all dependents of the task being analyzed in this loop should be modified to reflect the new updated date. This loop continues until all tasks have been analyzed. Initially, I attempted to implement a recursive rule expression, but it was not possible because I needed the newly updated date to affect the dependents, and saving was not feasible due to the immutability of variables in the foreach loop.