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
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.
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
Thanks. From my understanding of that plugin (and please correct me if I'm wrong) I'd still need to store/manage the schema, which if I am going to do I might as well store manage the field names
Yes Atleast one row data is the pre requisite for this. And in the code (that I wrote myself) only the record types and related record reference (line 3,6&9) is modified to hide the record I used. That needs to be replaced with respective record type that you are using!
Thanks for the option.I can't guarantee that there will be one row so will need another option.And sorry for my assumption. I've just noticed that ChatGPT and the likes seems to include functions that don't exist in their code when it's generated.
Actually that selectionFields function does exist, its new in 25.3. (which hasn't been released yet).
Thanks for letting me know. Makes sense as to why I couldn't find a reference to it
Given the rest of the conversation thus far, and based off of your context given, I think you're best off storing the record fields in an expression. If you're making a soft contract that the json schema will follow your data model field names, this should be fairly straightforward.
The reasons that storing record fields in an expression rule won't be as much of a headache:
tostring()
tostring(<record>.<relationship>.<field>)
<field>
It's not a good idea to put unnecessary data fabric calls on a high-frequency API (e.g. for the sake of a!keys() ). The data fabric can get overwhelmed fairly quickly if there are real-time record fields returned in the query or if the record type has even moderately complex row-level security. If this happens, the entire environment will slow down while the API's process.
a!keys()
Thanks. After the first few replies this is what I'd settled on too