Hi everyone,
With Appian 25.3, a new version of a!queryRecordType() was introduced, and the previous version is still available as a!queryRecordType_25r2(). This evolution brings more control and clarity over which fields are retrieved.
a!queryRecordType()
a!queryRecordType_25r2()
25.2 - a!queryRecordType_25r2()
25.3 - a!queryRecordType()
a!selectionFields()
In our applications, most queries are wrapped in a reusable rule that takes a single fields input. Callers of these wrappers don’t (and shouldn’t) need to worry about the function version or its internal implementation.
To align with the new function, the wrapper needs to:
This way:
ri!record
ri!fields
if( and( a!isNotNullOrEmpty(ri!fields), a!isNotNullOrEmpty(ri!record) ), rule!LGTCP_RejectNulls( input: a!forEach( items: a!keys( a!update( ri!record, ri!fields, a!forEach(ri!fields, null) ) ), expression: if( typeof(fv!item) = 284, /* Record field */ fv!item, null ) ) ), null )
ri!input
cast( /*Record Relationship*/ a!listType(298), if( a!isNotNullOrEmpty(ri!input), rule!LGTCP_RejectNulls( input: a!forEach( items: ri!input, expression: if(typeof(fv!item) = 298, fv!item, null) ) ), {} ) )
a!queryRecordType( recordType: <RECORD_TYPE>, fields: a!selectionFields( allFieldsFromRecordType: { if( a!isNullOrEmpty( rule!ExtractBaseRecordFields( record: <RECORD_TYPE>(), fields: ri!fields ) ), <RECORD_TYPE>, {} ), rule!ExtractRecordRelationships(input: ri!fields) }, selectFields: ri!fields, includeRealTimeCustomFields: true ),
Discussion posts and replies are publicly visible
Be extremely cautious with includeRealTimeCustomFields defaulted to true in generic query rules. Without an existing rigorous performance testing regimen, it will not be obvious that the custom record field is the root cause of performance issues since it will appear that "every" query to the record type (via the generic rule) is performing poorly. It's the equivalent of doing SELECT * in a complex SQL query / view, but without the benefits of an explain plan.
includeRealTimeCustomFields
true
SELECT *
If the rule is purpose-built, then this is less of a concern since the use cases are more specific . However, in generic rules that are used everywhere, later introductions of real-time record field(s) to the record type will likely cause unexplained performance issues in the data fabric across every part of your application that uses the generic query rule - even for a dataset of only 100k rows, and even after Data Fabric 2.0 (25.1). Don't ask me how I know .