Migrating Wrapper Rules to Appian 25.3 a!queryRecordType()

Certified Senior Developer

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.

Key difference between the two versions

25.2 - a!queryRecordType_25r2()

  • When no fields are specified, all base record fields are returned automatically.
  • Even if only relationship fields were passed, the base record fields would still come back unless explicitly narrowed down.

25.3 - a!queryRecordType()

  • When no fields are specified, only the primary key (id) is returned.
  • To retrieve all fields, the new a!selectionFields() function should be used with its allFieldsFromRecordType parameter.

Why this matters for wrapper rules

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:

  1. Identify base record fields in the fields input. If none are present, automatically include the base record in allFieldsFromRecordType.
  2. Identify relationships in the fields input. These should also be passed into allFieldsFromRecordType.
  3. Always pass the requested fields to the selectFields parameter.

This way:

  • If callers specify base fields, only those fields are retrieved.
  • If callers specify no base fields, all base fields are retrieved by default.
  • Relationships continue to work as expected.

Expressions we are testing

Detecting base record fields

  • ri!record: an empty instance of the base record containing no fields
  • ri!fields: the same list of fields passed to the wrapper rule

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
)

Detecting relationships

  • ri!input: the same list of fields passed to the wrapper rule

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)
      )
    ),
    {}
  )
)

Implementation

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
  ),

Open questions for the community

  • Has anyone else approached this migration in a different way?
  • Do you see a simpler or more robust method to distinguish base fields vs relationships in the fields parameter?
  • Any best practices for structuring wrapper rules around the new a!queryRecordType()?

  Discussion posts and replies are publicly visible

Parents
  • 0
    Certified Lead Developer

    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.

    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 Grimacing.

Reply
  • 0
    Certified Lead Developer

    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.

    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 Grimacing.

Children
No Data