Query rule substitute

Hi, 

As you know Query Rule has been deprecated in newer versions of Appian. I need a function that will mimic the exact behaviour of Query rule including the return type. 

I have tried using queryEntity() but the return type is not the same as query rule so i am facing a lot of issues. 

Please help! 

TIA 

  Discussion posts and replies are publicly visible

  • Hello,

    See documentation

    https://docs.appian.com/suite/help/20.2/Query_Recipes.html

    If you want to return the same data type, then you need to add as well the cast() function.

  • The default output format of a queryentity is a datasubset, in order to get the data in the same format of a query rule, you can try to slice the data part of the query entity result. 
    You can either use the index function like index(local!output,"data",null) or just local!output.data. This would give you a dictionary type object. You can directly use in a CDT type rule input.
    As mentioned below by you can use cast on top of the result set if you need to convert the output to a specific cdt.

    Also query rules used to return all the columns whereas queryentity only returns specific columns, this can be achieved by not passing any query selection parameter to the queryentity.

  • Keep in mind also that traditional query rules will pass back a "dataSubset" type whenever pagingInfo is passed in.

    Given this, I've previously set up a standard QE recipe which I usually make a new version of for each CDT i might be querying.  In that QE expression rule, I run the query entity as normal (using the passed-in pagingInfo if it was given, and a generic set otherwise); then I return the whole dataSubset if the pagingInfo was provided, and return just the ".data" result from the query entity otherwise.

    Note that this does return basically an "any type" dictionary instead of a type-cast CDT.  I've almost never had an issue with this - it does mean that a very few things need to be manually typecast when these are used.  You could take the subsequent step of typecasting your ".data" output as the CDT type, but this creates its own issues (such as, if the QE returns a selected set of columns instead of all columns).

    What exactly is your use case for needing the exact return type?  What issues is this causing?

  • Hi Mike Schmitt, thanks for your response. 

    I have executed the same QE logic where i am fetching all the columns and using .data 

    I am able to retrive the data and display on the interface. But when I try to SaveInto the column it gives me the following error. Say if the column name is "ABC", then the error is this -

    Could not display interface. Please check definition and inputs. Interface Definition: Expression evaluation error [evaluation ID = SM7UJSZM] : An error occurred while executing a save: java.lang.IllegalArgumentException: Invalid index: Cannot index property 'ABC' into type Dictionary

    I have tried to use cast as well giving the type of the datatype but still getting the same error. 

  • It sounds like you're saving your query result into a local variable.  Local variables take on the datatype of whatever they contain.  So I think typeof() of your local variable would return "Dictionary".  In that case, I wouldn't try wrapping the query entity expression rule in a cast() function, but I would try wrapping the call to that query entity rule in a cast() right there in your local! definition.  typeof() might be a good test to run first to make sure that part is working.

    What's possibly occurring is you sometimes return a null for a particular column, and so when Appian is building a Dictionary in particular, it saves space by not saving the null.  Either that or it's the fact that for Dictionary to work it requires both key AND value.  None of the Dictionaries in your list of them need to have identical sets of keys.  But if you cast it as a list of CDT, they all DO have to have the same keys.

  • Cannot index property 'ABC' into type Dictionary

    This is a standard error message when you're trying to access a property that doesn't exist - usually if you have the column name wrong, or if your query has resulted in zero rows.