Have a List - How to Join with Entity and Display in Table Records On Web Screen

I have created a Screen Action that outputs a list of Identifiers.  Works perfectly.  Got exactly the list of identifiers I wanted and expect to get.

List output: List of Room Identifiers

I have an entity that contains the same Identifier type that my Screen Action List outputs.  This Entity has additional information/attributes that I want to display on the Web Screen in a table records widget.  

Entity contains the following: ROOM IDENTIFIER     SEATING CAPACITY   TABLE SHAPE

But I need the table records widget to only display those records from my entity that are in my list from the Screen Action.

My thought was that I could do an aggregate, put in the entity that has all the additional info in it and do a join or filter where I tell the entity to only display the information where the entity identifier = the identifier from my list....but you can't use the screen action output list in the aggregate.

I thought maybe I can use a Structure of type list, but I cannot seem to teach myself how to use structures.  (if there is a good PDF or video link, please let me know!, I seem to be able to create them and populate them, but I can never use the info stored in them them!)  And again, if I try to use an aggregate with my entity, I cannot use a structure as a source, so how can I join/filter using the info in my structure?

Then I thought maybe in the table records widget on my web screen, I could somehow set the source record list of the table records to my structure....but I can't do this either.

If I use a For Each in a screen action with my Identifier List as the record list,  do an aggregate where I filter where IDENTIFIER = List.Current, won't I get a single record output and not a list of records (so my Table Records widget will end up only showing 1 single record and not a list of all records and attributes)?

Should I be doing something in the Screen Action to output some kind of structure that contains ROOM IDENTIFIER     SEATING CAPACITY    TABLE SHAPE rather than only a list of ROOM IDENTIFIER?

So bottom line, how do I create an aggregate where the results of that aggregate are only those records that are the Identifiers list that is the output of my Screen Action?

And less important:  How can I train myself to understand and use structures?


Hello Rob,

Why don't you use a more simple pattern, that is to use an aggregate in preparation to fetch all data you need?
If you are fetching data in a screen action, you for sure can put this query together with a query to the entity, joining the way you are describing, without the requirement of doing all this extra logic.

The pattern is:

1. In the Preparation, executes an aggregate that pulls the data you need, using some filters that include session/screen  variables to decide what to get.
2. Show the info in the Table/List Records or any other thing you want (gallery, carousel, etc).
3. The user change the search parameters -> execute screen action that refresh the preparation aggregate and refresh the table records (or whatever you are using to show data).

Doesn't this seems less complicated for you? There is anything that prevents you of using this pattern?

Eduardo Jauch


Ideally that is a great solution!

But I am going to have to go back and look at my screen action and see if I can simplify it to that level.

At the moment I use a switch depending on the COUNT of Entity IDs.  Then depending on those counts, I perform an aggregate that varies slightly.  I just need to know/track the IDs that come out of all the switches.

It might get a bit complicated, but I could possibly create one aggregate with a combination of ANDs and ORs that might be able to output the correct info.

Will get back on this after I see if I can do it.

Hello Rob,

The biggest problem with your actual approach is that the app will not scale well. It will have severe performance issues.


Eduardo Jauch

Eduardo, you had it exactly correct.  

Just had to bring in all the aggregates as part of a switch into the single aggregate.  Lot of filters and a bit hard to keep track of, but much simpler and it works perfectly!  Many thanks!