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

Parents
  • 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!

  • 0
    Certified Lead Developer
    in reply to appianfreak
    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.

    I believe you that it works, in general, but that's not the reason I'm asking.  I want to know what the exact output is, since there are a few different possible mistakes I've commonly seen (and made myself a few times) that I want to verify against -- which I'd have to see the exact output of the rule in order to be sure of.

  • I feel like an idiot. I said it was working. Yeah...working INCORRECTLY!

    My filter is not getting applied to return only 1 Record with Id = 4. I do have filter defined with "Always". Problem is whether I pass argument or not, always ALL records are getting returned. So obviously on my Record Display when I'm calling rule without arguments it returns all and I say "it is working", but when I pass only parameter = 4, it STILL returns everything when executing in the Process Model, which is obviously the problem.

    Code is below. If you can kindly spot where I have (obviously) messed up

    a!queryEntity(
    entity: cons!VEHICLE_DSE_VFM,
    query: a!query(
    logicalExpression: a!queryLogicalExpression(
    operator: "AND",
    filters: {
    a!queryFilter(
    field: "id",
    operator: "="
    )
    },
    ignoreFiltersWithEmptyValues: true
    ),
    pagingInfo: a!pagingInfo(
    startIndex: 1,
    batchSize: 50
    )
    ),
    fetchTotalCount: false
    )

    PS - In the Query Editor, when I pass argument it DOES return only 1 row, but the generated SAIL query does not work when used within Process Model.

Reply
  • I feel like an idiot. I said it was working. Yeah...working INCORRECTLY!

    My filter is not getting applied to return only 1 Record with Id = 4. I do have filter defined with "Always". Problem is whether I pass argument or not, always ALL records are getting returned. So obviously on my Record Display when I'm calling rule without arguments it returns all and I say "it is working", but when I pass only parameter = 4, it STILL returns everything when executing in the Process Model, which is obviously the problem.

    Code is below. If you can kindly spot where I have (obviously) messed up

    a!queryEntity(
    entity: cons!VEHICLE_DSE_VFM,
    query: a!query(
    logicalExpression: a!queryLogicalExpression(
    operator: "AND",
    filters: {
    a!queryFilter(
    field: "id",
    operator: "="
    )
    },
    ignoreFiltersWithEmptyValues: true
    ),
    pagingInfo: a!pagingInfo(
    startIndex: 1,
    batchSize: 50
    )
    ),
    fetchTotalCount: false
    )

    PS - In the Query Editor, when I pass argument it DOES return only 1 row, but the generated SAIL query does not work when used within Process Model.

Children
  • 0
    Certified Lead Developer
    in reply to appianfreak

    Well, the first thing I see is that your queryFilter has nothing being passed in for the "value" parameter - you'd need to at least add that, or else it wouldn't do anything.

  • +1
    Certified Lead Developer
    in reply to appianfreak

    BTW, when you post code, you should consider using a Code Box, by hitting "Insert" -> "Insert Code".  This will preserve formatting/indenation, and give a nice size-constricted display box to keep the comment from wasting an undue amount of space within the conversation.

    For instance, here's the same code as above, except I've added the filter value (and set the applyWhen parameter as well).  I used "ri!inputId" but you can use whatever your rule input is called.

    a!queryEntity(
      entity: cons!VEHICLE_DSE_VFM,
      query: a!query(
        logicalExpression: a!queryLogicalExpression(
          operator: "AND",
          filters: {
            a!queryFilter(
              field: "id",
              operator: "=",
              value: ri!inputId,
              applyWhen: not(isnull(ri!inputId))
            )
          },
          ignoreFiltersWithEmptyValues: true
        ),
        pagingInfo: a!pagingInfo(
          startIndex: 1,
          batchSize: 50
        )
      ),
      fetchTotalCount: false
    )

    Edited to add:  I also notice you're not referencing the ".data" of the rule's dataSubset output (as I suspected earlier, which is why I was asking you to post the sample output of this rule to confirm).  So, before you can expect get any data properly saving into your in-process PV, you will need to add ".data" either within the expression rule (at the very end of the a!queryEntity() call), or in the process model itself after the expression rule call.  I.E.,

    rule!VFM_getVehicleById(inputId: pv!updateId).data
  • Thank you for the Code Box tip!

    Is it possible for the Query Editor to generate the code I now see I'm missing? I was imagining Appian automagically inserts it when query is run. Obviously I see I'm wrong now.

    I needed to include the rule input against the filter for the generated SAIL expression to include it! Doh!

    On to next problem.

  • 0
    Certified Lead Developer
    in reply to appianfreak
    Is it possible for the Query Editor to generate the code I now see I'm missing?

    I don't have much experience using the (relatively new) Query Editor as I'm used to just writing any necessary query entities by hand.  In general my suggested approach for using it would pretty much always be to use it only to quickly establish a basic query that works, and then tweak it per your needs in the Expression Rule editor (and also test it there, etc).

  • The frustrating part I've found about Appian, is that things stop working at random for no reason. Just after I made the change you told me, it worked twice and then again without me changing anything, it stopped working. Most of the times unpublishing / publishing application solves the issue, but not today. 

    The process model picked up the modification to the getVehicleById(), then I removed the debut TEXT pv and now it will not pickup the change.

    It's the weekend...Anyways, thanks again for your help. Learned something today.