CreateOrUpdate architecture

Hi,

I'm with a doubt regarding architecture in outsystems.

I have a espace where I have the CreateOrUpdate server actions. For example there is a server action createOrUpdateSection. This server action receives an input parameter "Section" of type Section and 3 output parameters :(FormInvalid, FormInvalidMsg and CreatedOrUpdatedMsg). 

In this server actions there are some validations if the validation fails the FormInvalid becomes true and the FormInvalidMsg stores the respective invalid form message. If there are no validaiton errors the CreateOrUpdate entity action is called with the input parameter "Section" and then the "CreatedOrUpdatedMsg" becomes with a text like "Section created". In the espace module for the frontend in the screen action the CreateOrUpdateSection action is called and after there is an if "CreateOrUpdateSection.InvalidFields", if true there is an invalid feedback message. This works fine.

My doubt is how to change this and instead of this 3 output parameters have something more generic so that if the action was used by a service or something work better. 


Solution

Hi,

Normally that is called a "wrapper". I used with (if I only have one entity to create or update) 1 input (record type) and 2 outputs: 1 of the record identifier generated or updated and 1 structure with 2 attributes: HasSuccess and ErrorMessage.

In this situation I have something generic and that can propagate the error in case it exists.

The part of IsValid for the forms, I leave that for the form and submit actions itselfs. If you have the correct mandatory fields defined in your entities and the correct data types, the form validation works and it's more accurate, because can be focused in the field with the error.


Hope this can help.


Best regards,

Ricardo M Pereira

Agree with what Ricardo had suggested, generally, I also design the wrapper with one input parameter of entity record type and one output parameter of its Entity Identifier. In case you want to design it more generic as per your scenario you can take IsValid and ErrorMessage Output parameter as Recardo suggested.

Sachin

mvp_badge
MVP

Just to complement. 

I understand the desire of having a single place to 'validate' the form data. 

But in this case, first thing I see is a merge between 'interface' and 'logic'. 

The validation at the wrapper level is a good idea, but in this case the objective should be avoid creating bad data in the database, not alert the end user. 

The wrapper should be executed always with correct input data. Bad data should trigger an exception (log the problem) and return a simple error for the caller. 

The reason, as stated by our colleagues here, is that the validation of the form data should be done at the interface level, where the developer has direct access to the form and input widgets. 

If bad data get to the wrapper, the reason is bad interface design, or a tentative of tampering data. Thus why I think it's important, at the wrapper, to validate and log possible errors. 

Reutilization of code/interface is important and a best practice, but there is a point where you actually start loosing the benefits that are actually what you are trying tonachieve, like a less complex code (simpler maintenance and fast development). 


In the end, this simplification will also make your wrapper easier to use in other contexts than the screen.


Cheers.

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