How to send Selected fields from CDT to API

The easiest way would be to only index the fields you want. For example, you can use the type constructor to insert directly the fields you want to use like this:

load(
  local!data: a!fromJson_19r2(ri!autoCaseCreationInput),
  type!TYMP_fileDetails(
    field1: index(local!data, "field1", null),
    field2: index(local!data, "field2", null),
    ...
  )
)

It's a little tedious, but it would allow you to get exactly which fields you want. If local!data could contain an array of files, then you could use a!forEach() around the expression I defined above like this:

load(
  local!data: a!fromJson_19r2(ri!autoCaseCreationInput),
  a!forEach(
    items: local!data,
    expression: type!TYMP_fileDetails(
      field1: index(fv!item, "field1", null),
      field2: index(fv!item, "field2", null),
      ...
    )
  )
)

Thanks a lot Peter.

note that index() will always return a list, even if there's only one (or even none) of the items you're indexing on. This may then have implications for how the data is then passed on to your API (e.g. if the API is expecting JSON and is being strict on whether the data being passed is singular then this may cause a problem)

In this example though, you don't have to worry about it because I included a single CDT type constructor (which would ensure that the final value returned is not an array). Also, if your JSON includes a list of values, the second expression should handle the list while ensuring the index() only returns one value for each iteration.

Not to kvetch about it overly, but for code clarity reasons we should really be teaching people to make use of the property() when referring to CDT/dictionary properties, and reserve index() for actual indexing (i.e. positional within an array).

Interesting, I'm not sure I've ever used that function before Although it does say at the bottom of the docs for the property function: See also index(): This function acts as an alias to the property() function especially when applied over custom data types.

This is one of my personal best practices for code clarity (which I enforce when possible with dev teams i'm on or managing) -- it becomes especially important when needing to nest array indexing with property fetching or vice versa (i've seen up to 3 or 4 nested index() calls before, where a majority of them are actually fetching properties). 

Since the functions are apparently an alias for each other, I believe there's no reason not to use the proper name for the proper context.

This is one of my personal best practices for code clarity (which I enforce when possible with dev teams i'm on or managing) -- it becomes especially important when needing to nest array indexing with property fetching or vice versa (i've seen up to 3 or 4 nested index() calls before, where a majority of them are actually fetching properties). 

Since the functions are apparently an alias for each other, I believe there's no reason not to use the proper name for the proper context.