Saving dropdown identifier AND attribute - values coming from an integration

Hey everyone,

I'm hoping to get some ideas on the best way to accomplish something.

We're using OutSystems for a particular project where we're mostly building a data collection UI. There's a lot of fields and a lot of dependencies between them (based on value selected on dropdown A, get values for dropdown B, etc.), and the values that populate a lot of the dropdown fields are coming from an external database. We're getting the values through an API and there's too many of them, so having a local cache/copy is also out of the question. 

Following the OutSystems best practices and recommendations, our dropdowns call out functions directly in the source records. Simplified example:

We basically need to hold the data for a bit on the UI side for some user approval etc. and then we're looking into send it downstream back to the master database (OutSystems will only only the data while it's being worked on), so we definitely need to record the associated ids of these records and therefore saving the "Source Identifier Attribute" is required.

However, we also need to list the records while they're temporarily being worked on the OutSystems side, and we obviously don't want to make a call for each of the fields for each of the records (imagine a table with 10 columns, 10 records > 100 calls - not doable). So to the best of my knowledge, we should also additionally save the actual displayed value/label ("Source Attribute"). The values/labels are not exactly expected to change during the period that the data will be on the OutSystems side, so having the labels slighly outdated is not a concern.

I've thought about a few options and to be honest I don't like any of them, so I'm hoping to get some additional thoughts.

1. On dropdown change, call the "Get Values" function equivalent for the dropdown and retrieve the value. Downside: we would be calling the API twice

2. Store the lists on local screen variables, and on dropdown change, retrieve the value. Downside: there's a lot of screen dependencies and fetching the values again and assigning to the local variables every single time is a pain, besides the fact that we would have huge local variables on the screen to hold all these values, which harms performance and user experience

3. Build some javascript to get the dropdown value/label when I'm actually about to save the record and leave the screen. This feels like a workaround but at least I wouldn't have the downsides of the previous two.

I'm open to opinions and suggestions, so please let me hear your thoughts.



Not sure if this is viable, but if there isn't a problem with showing the Identifier in the Combo Box selection to the user, you could concatenate both the identifier and the text value so that your action also returns this compound string (e.g. Id: 3 + Text: Option Number 3 => "3 - Option Number 3"), and later parse the contents after a selection is made in the Dropdown. I am attaching a sample OML as a reference, and perhaps you could explore it further for an even better result (such as figuring out a way of only displaying the Text while keeping the Compound string as the selected variable).

That being said, I would probably really reconsider keeping a local cache/copy of the contents. Obviously I don't know the full story, but even if the data is large, you could look at ways of only importing a subset of it by following some of the recommended Integration Patterns for Core Services (Lazy Load, Cold Cache with only summary fields, etc). 

Remember that good design also entails not hammering your external data source with more requests than necessary, not to mention that once you get past the "ugly" steps of an initial implementation, you would have more flexibility to use the data anywhere without having to bend over backwards for addressing apparently simple use cases, while the end-user probably also gets a better user experience and faster response times.


Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.