Skip to main content
yahairat
yahairat
April 9, 2024
Question

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

  • April 9, 2024
  • 12 replies
  • 0 views

Hi everyone!

I am facing the following issue: I have a toggle button that activates a startProcess!, which is a Process Model designed to update the dates of a list of tasks. This list can contain more than 100 tasks which should be analyzed one by one in an iterative loop in the process model. However, I have noticed that the onSuccess variable, which should be displayed in a grid is not correct . This problem might be due to exceeding the 50-node limit. I have checked the process, and everything appears to be correct including the onSucess variable. Can you advise me on any way to retrieve this variable with the correct values?

12 replies

daniell
daniell
April 9, 2024

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.

    yahairat
    yahairatAuthor
    April 9, 2024

    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.

    mikes0011
    mikes0011
    Brainy
    April 9, 2024

    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?

      yahairat
      yahairatAuthor
      April 9, 2024

      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?

      daniell
      daniell
      April 9, 2024

      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.

      harshk1671
      harshk1671
      April 10, 2024

      After going through the problem statement looks like you have a process with defined logic to take 100 tasks as input and return 100 modified tasks as output after writing in DB.
      If the above problem statement is correct and you do not need primary key of task 1 to define logic for task 2 then can you divide it as follows:

      1. Do the logic of task modification in SAIL as you already have it.
      2. Use an asynchronous process call to write it in DB.

      This way you will get the modified tasks same time and it will write it in DB in a separate call.

      Terms & ConditionsAccessibility statement