Process Variable not getting assigned with DSE

I have a rule to fetch DSE from database. Debugged and works fine.

In my process model, I'm using pkId to lookup data using my rule and then assigning it to a process variable. Unfortunately my process variable is not getting assigned. When I debug the process, I don't see any errors and I've double checked my rule for fetching data and that I'm passing id correctly.

On the Data Output tab of my script task I'm calling the rule - rule!GetDataById(pv!myId) with a Custom Output. myId is populated with value e.g. 4, and I see it when I debug

I'm storing the results in process variable for my entity. However, after I let the script task finish and check my process variables, my entity object is empty.

This should just work :-( 

What obvious thing could I be missing?

  Discussion posts and replies are publicly visible

  • 0
    Certified Lead Developer
    my entity object is empty.

    Just to confirm -- what type is the process variable in question?  It almost sounds like you have a PV of type "data store entity"...

  • Yes, of course.

    Sorry, I was avoiding being long winded. Basically I'm going through the Vehicle Fleet tutorial. I created my process model to add new Vehicle. Then I wanted to develop Record Action to Update it. So I modified the process, introduced process variable input to take vehicle Id and then added script task to read Vehicle before feeding my UserInput Task. When I saw the User Input task form show up empty and found out that my pv for Vehicle DSE is not getting assigned. My rule for getVehicleById() I know works because otherwise nothing else would have worked and id is also getting passed to the process from my Record "update" action.

    Hope this clarifies. I realize this is basic, but just can't get it to work.

  • 0
    Certified Lead Developer
    in reply to appianfreak

    If you're trying to save the CDT data attained from the query result, into a PV, you'll need to make the PV a CDT of that type, and not the "data store entity" type (assuming i understand correctly that that's your PV type).

  • Yes of course. See, the pv is indeed of the correct CDT type, because only then am I able to populate data on UserInputTask form and save to Database through the DSE. All this works perfectly.

    To boil it down to code for the Custom Output configured on Data->Output tab of my Script Task which I introduced prior to the UserINputTask

    rule!VFM_getVehicleById(updateId) /* where updateId = 4 (say) based on record selected */

    "save into" vehicle, where vehicle pv is of type CDT. I'm not typing anything, but selecting from UI so I know I'm doing this correctly.

    Basically my Script Task Custom Output configuration is not working. I'm not able to tell if for any reason VFM_getVehicleById() is failing - it really can't because I can see it is getting a valid "updateId" value passed in - or Appian is not saving CDT instance returned into pv!vehicle.

  • 0
    Certified Lead Developer
    in reply to appianfreak

    Sorry, then I misunderstood what you were referring to when you said your PV was "data store entity" type.

    Can you confirm / post a screenshot of the output of rule!VFM_getVehicleById() when passing in an example id, within the expression rule editor?  For example, sometimes people forget to reference the ".data" in the query entity output, to get the CDT type data itself as opposed to the DataSubset returned by default by a!queryEntity.

  • Unfortunately "Security" at my sight is blocking me from pasting screen shots at this time. If/When I'm able I will post the screenshot.  If you can visualize with me. It is exactly like in the Appian tutorial lesson.

    On the Data Output Tab,

    On the left, I have 

    Custom Outputs

    rule!VFM_getVehicleById(pv!updateId)

    On the right, I have Expression Properties...

    Expression: rule!VFM_getVehicleById(pv!updateId)

    Operator: is stored as

    Target: vehicle

  • 0
    Certified Lead Developer
    in reply to appianfreak

    Thanks for clarifying your process model configuration -- that sounds right to me.  But what I'm actually asking for is the exact output of the rule itself.  When you open VFM_getVehicleById, and run it, what do you see in the "Test Output" section?

  • Okay...So this is what I did.

    Instead of setting my updateId process variable to 0, I set it explicitly to 4 (which I know is a good id for a vehicle in database)

    I started process for debugging. I see updateid as 4 on Process Details VAriables tab. So eliminated Record Action not passing data possibility.

    I refreshed to move past the Script Task and land at the User Input Task. By this point, my vehicle pv should have been populated. When I look at my Variables tab again I can see it is *not* populated.

    So I can tell you 4 is a valid Id. I can tell you getVehicleById(4) should not fail. I have tested this and it works. I've removed any doubt 4 was not getting passed from Record Action to Process instance. BUT I cannot tell if when my rule was called to fetch the data whether it worked or not, because the only way to check is looking at what's in vehicle pv.

    Is there a way to debug/trap data returned from the fetch rule *before* Appian populates it into vehicle pv? That would tell me once and for all for whatever reason my fetch rule works everywhere else *but* not from within my Script Task.

  • 0
    Certified Lead Developer
    in reply to appianfreak
    Is there a way to debug/trap data returned from the fetch rule *before* Appian populates it into vehicle pv?

    Yes - as I said before, open VFM_getVehicleById in the Expression Rule editor, enter your id input (4), and click "Test Rule".  Have you done this already?  And if so, what is the exact result?

    If you want to "trap" the rule's output within the process model only (i.e. you think it's already working when viewed from the expression rule editor), you can create a new (temporary) TEXT PV, and save the same query result (wrapped in the toString() function) into it.  This will generally tell you whether any data at all is being returned from the query when the process is run, for instance if it's something that's returning data but not matching the CDT type of the original target PV.

  • Okay, sorry if I'm bad at replying. When I said I know for a fact my VFM_getVehicleById() works it is indeed because I tested it independently by passing 4 as parameter. It returns all the field properties as it is supposed to just fine.

    I will try the TEXT pv trick you suggest and reply back ASAP editing this post. Thank you very much for your patience!