With CDTs I can do something like this to initialise a CDT with all fields set to blank/null
cast( 'type!{urn:com:appian:types}CustomType', {} )
Is anyone aware of a similar approach with records? Casting {}, null(), or a!map() to a record type just returns null
In this use case I won't know the field names to be able to use them. I only have the record type
**Edit: Adding more context
If the record type has fields A, B and c then each of those fields needs to be set with null/blank (which is what would happen with the CDT).
eg the value returned is recordType!CustomType(a: null, b: null, c: null)
Discussion posts and replies are publicly visible
Use the record type constructor with empty parentheses:
recordType!YourRecordType()
This doesn't work. It simply returns a blank record type. None of the fields are initialsed
Got you!There's no direct equivalent for Record Types. Unlike CDTs, you cannot initialize a record type with all fields set to null without knowing field names.If you want to set fields explicitly, you must do it field-by-field like this:
recordType!Employee( name: "", age: null, email: "" )
You are correct! To work with local variables of record type we need to reference record fields using reference everywhere needed.
nathanp119 said:In this use case I won't know the field names to be able to use them. I only have the record type
Typing in recordtype!recordName.fields.... is the only way to know the field names and use with local variables indexing.
I personally try to work as much as possible with rule inputs instead of local variables Or, call a reusable constructor rule instead of ad-hoc expressions wherever needed!
Why is that important? What do you want to achieve?
Validation of payload from external systems before writing the data, eg if payload from external system doesn't match the record type / CDT being written then return a 400.With older apps that use CDTs, we can store the type #, then get the keys from a blank initialised CDT (using the cast method above) and compare it to the keys in the JSON payload. With records, it seems we'd need store all the record field names to be able to compare them, which makes it more difficult to manage in the long run if fields change with code changes.
OK. Thanks.
If I understood the requirements correctly, the function a!keys() can help you dynamically get the fields from record. Using the output you can match the keys with payload keys. Here is a sample expression for reference.
a!localVariables( local!recordData: a!queryRecordType( recordType: recordType!recordName, pagingInfo: a!pagingInfo(1, 1), fields: a!selectionFields( allFieldsFromRecordType: recordType!recordName, includeRealTimeCustomFields: true(), includeExtraLongTextFields: true(), selectFields: recordtype!relatedRecordFields ) ).data, a!keys(local!recordData[1]) )
If the requirement here is to meet the 'contract first' paradigm (where you validate incoming payloads as a prerequisite to dispatching for processing if valid or responding with HTTP 400 - bad data - if invalid), then I'd encourage you to use JSON Schema validation as this provides a declarative method for validating payloads. Cast or map your incoming message to JSON and then use the schema validation available in this plug-in to conduct your validations.
This solution will only work if there is data stored (and if I fix what appears to be the AI generated code). For initial requests when the table is empty this would fail