Get request enumeration

Hi,

I’d like to create a rest data endpoint that contains an enumeration.
When creating a datadefinition there is no possibility to select an enumeration (for example gender) in the recordtype field. Or is there another way to do this ?

Hi Arnold,

That is true and intentional - data definitions themself are supposed to return a Record of some type - enums are not record types, they are kind of property of a record.

However, the data definition can contain fields that return Enum data types. For example, we know person has a property “Gender” (Gender is enum)

Here is an example data definition configuration:

I have a Data definition that returns Persons:
image

Then among the fields, there are 3 that use the Gender property of the Person

Gender object (sequence 90) - returns the gender object of the record itself, that would return basically the ID of the enum value (0,1,2 etc.) - accessed with this.gender (where in this context this is a person record)
gender_id - returns the id of the gender object (basically the same as the above) accessed with this.gender.id
gender_description - returns the value for this enum value with id (in this case Male/Female for example); accessed with this.gender.description)

If i run the REST data definition endpoint that uses the Data definition above I get the following result:

For 1), we see that the Gender enum property on that Persons record is set to Male (id 0 from the Genders enum)

For 2) we see that nothing is set on the Gender enum property on that Persons record

Does that help ?

Greetings,
Miroslav

1 Like

One more addition i forgot about that could be useful.

If you set the data definition field to be of any enum type (that would be the gender_object from above), using the metadata endpoint (application_url/whatever/rest/metadata) you can see the description of the enum:

For example:
https://staging01.novulo.com/training01/rest/metadata
My persons endpoint has the field “gender_object”, return type on the Data definition field is “Gender” (the enum)
The metadata says, it will return an integer value (0,1), the description says int 0 means male, int 1 means female:
image

1 Like

Hi Miroslav,

Thanks for your quick reply, greatly appreciated :slight_smile:
However I do not want to export persons but the enum itself via a rest api.
I know that enums are not database tables but are hardcoded in the architect, however it is also possible to query an enum in the expression debugger like gender:load(0).description.
I would like the rest api output in the case of gender enum to look something like below, is there a possibility do to this somehow ?

[
{
“id”: 0,
“description”: “Male”
},
{
“id”: 1,
“description”: “Female”
}
]

Hi Arnold,
Unfortunately, I don’t think there is a clean way to do what you want…
Data definitions are not build and configured for such thing…

Maybe you can try something with process endpoints… Here is an idea.

  1. Create a Process component “GetAllEnumValues”
  2. Parameter of type string, named “enum_name”
  3. Using expression tools plugin → evaluate Expression action
    • In the plugin configuration set the expected result type to List< Mixed >
    • In parameters, set the expression (required) parameter to something like:
      • “{”.concat(trigger.enum_name).concat(“,<<"id",this.id>,<"description",this.description>>”).concat(“}”)
  4. Add return value of type List< Mixed > and name it enum_values
  5. In the Return action - use the output from the EvaluateExpressionAction.result, i.o.w. set the return value of the process enum_values to : evaluateexpression.result
  6. Create the Process endpoint after you update your application.

When you run the Process endpoint with the enum name you should get something like:

Here is a picture of my process:

And

image

Note that a lot of shortcuts have been taken, the evaluate expression can return success false (for example if you don’t pass for the enum_name parameter actual enum name, or if for some reason the enum doesn’t have .description ), make sure to handle it in your process.

This is the only way I could think of to achieve what you want.

Greetings,
Miroslav

1 Like

For some reason the Record type field on the data definition explicitly filters out enumeration types, even though they are technically record types. When I set it to an enum type through the import engine, it seems to work just fine.

Not exactly a “clean way”, but maybe it helps.

image

{
  "success": true,
  "error": null,
  "httpcode": 200,
  "response": [
    {
      "id": 0,
      "description": "Male"
    },
    {
      "id": 1,
      "description": "Female"
    }
  ]
}
1 Like

@Wim , Thanks I got this to work now, I did not use the import engine but used sql to set the recordtype field (update datadefinitions set record_type = ‘gender’ where id = 30). I can now export the enum with this.
I will create an SR to include enums in this field.
However its returning the dutch description, does it look at the language of the application somehow (even though i’m not logged in, running this through postman). Is there also a possibility to return the dutch and the english description of the enum ?

{
“success”: true,
“error”: null,
“httpcode”: 200,
“response”: [
{
“id”: 0,
“description”: “Man”
},
{
“id”: 1,
“description”: “Vrouw”
}
]
}

Hi Arnold,

REST requests fallback to the first language defined in the Webconfig key “languages”, sounds like the first one in your application is “nl-NL”.

For rest requests you could also set the culture yourself. I.e. default is nl-NL, but you want the english translations - then you can do the request with additional header.


If i remove this header:

I don’t know if you can get both translations in the same request, maybe Wim can assist with that.

1 Like

@Miroslav , thanks for your explanation that is very helpful.
In fact we had a discussion this morning if it would be possible to use a process for get endpoints that populates the data, you perfectly explained that !

Hi Miroslav,

Makes sense that the request falls back to what is defined in web.config.
Both translations in the same request would be perfect but we can also do 2 calls with a different language, that is a good workaround for us.

Thanks,
Arnold