Hi Mohamed,

I tested your application and the member count increased like expected. But you don't have to reload the screen after joining a team. Instead you can just refresh the aggregate and reset the local variables of the popup:

Another little improvement I want to suggest is to return the team id, name and new member count in server action JoinTeamAction. This will allow you to give a better feedback to the user like "You joined team TEAMNAME." and also use ListIndexOf to find the respective team entry in GetTeamsByUserId and overwrite just the relevant record on the client side (optimistic update).

Hope this solves your problem, Sebastian

Hi Mohamed,

here is the improvements I would suggest:

Server Action JoinTeamAction

• You can combine both aggregates into one by joining the entities Team and UserInTeams with option "With or Without" and the following condition:
  Team.Id = UserInTeams.TeamId and UserInTeams.UserId = GetUserId()
  This way, you are selecting the team by its code and the user assignment of the current user when existing.
• You should check if the team could be found by its code and otherwise throw an exception.
• If the user is not already assigned, you can simply add it and return the Id of the team to indicate to which team the user was added. If the user was already added, do nothing and also don't return the team Id.

Screen Action JoinOnClick

• If the team could not be found, an exception was thrown and will end the flow and by default will show an error message.
• If the user was already assigned, we just need to close the popup. I also recommend resetting the local variable Teamcode to start with an empty popup when it is opened again.
• If the user was added, the server action returns the Id of the team, so we can search for it in the screen aggregate. If found we can simply increment the UserCount. Anyhow, at the end we want to close the popup as well.

Entity Team

• As you are searching for teams by their code, the code should be unique. To ensure this, you should add an unique index to the entity.

The explained process is known as optimistic update, where you update the locally selected data instead of reloading it from the server side. In your case the improvements above save you

• an unnecessary database roundtrip in the server action,
• a refresh of your screen aggregate and thus one additional server callback and a database roundtrip.

If an optimistic update is not possible or might be inefficient, you can of course trigger a server callback to refresh the data in the screen aggregate. You can see this in my first answer. This is done by adding Refresh Data from the tool bar and select the appropriate aggregate to refresh or simply drag and drop the screen aggregate to the flow.

Please find attached your customized oml file. Hope this answers all of your questions, if not please let me know.

Kind regards, Sebastian