get value of a process variable or task output that is the result of completeTask via webapi

Certified Associate Developer

Hello community,

I have a webapi that updates an instance of a process model by completing an open task.

this task has a input for a main category, example {"fruit", "vegetable"}

the task output: Based on input, (a decision rule is called with ac!category as a parameter).  example category("fruit), result: Apple, Banana, Orange is stored in a pv.

I would like to pass the result / task output or the value of the pv as a result/response of the webapi.

I tried to retrieve the result by calling an expression that gets the pv value from a process report, this doesn't work because the data is not updated yet.
fv!processInfo doesn't apply here because it's not an start process api. (guess that's the reason, it doesn't work)

How can I make this work?

Kind Regards,

Erik

  Discussion posts and replies are publicly visible

Parents Reply Children
  • 0
    Certified Associate Developer
    in reply to Stefan Helzle

    I guess I can call the decision rule in the api as wel, and leave it also in the task output to store it in the pv.
    That is what you mean right? 

  • 0
    Certified Lead Developer
    in reply to erikb0001

    As I do not know what the overall design is, it is difficult to give any recommendations. It feels awkward to have a process instance in parallel to a user clicking in some external portal. Trying to keep that consistent feels like trouble in the long run.

    I think, that for each interaction in the frontend you can define some logic to be executed in Appian aka backend. And for my understanding decision tables and expressions would be a better fit.

    A typical API (REST-like) leaves the status to the client (frontend) and the logic to the backend. Now when your frontend needs to find out which item to show in a dropdown, it should call an API in the backend and hand over all data necessary to determine this.

  • 0
    Certified Associate Developer
    in reply to Stefan Helzle

    This is indeed what needs to be build:A typical API (REST-like) leaves the status to the client (frontend) and the logic to the backend. Now when your frontend needs to find out which item to show in a dropdown, it should call an API in the backend and hand over all data necessary to determine this. Then the data necessary depends on the open task in the process model. So the update webapi is called several times after the process starts. So i have one Api to start process and one dynamic webapi to update / interact with the instance of the process model. 

    So the solution here is to put the logic in the webapi?

    Kind Regards,

    Erik

  • 0
    Certified Lead Developer
    in reply to erikb0001

    I do not understand why you need a process instance in the background. That would be state handling. And we just agreed that state should be the frontends job.

    I would try to keep the logic in decision tables and/or expressions and create an api which calls them depending on input from frontend.

  • 0
    Certified Associate Developer
    in reply to Stefan Helzle

    Okay got it, the outcome of the expression has nothing to do with the process instance. I am afraid it's an requirement to let Appian do the state handling as well later in the process. It isn't an issue now so I can proceed based on you advise. Besides if the pv is not real-time affected / changed by the call itself I can still use the data in the process report.

    Kind Regards,

    Erik