One pattern that is usually followed is that for every entity, we expose them as public but read only. For that entities, we create our own CRUD actions to give us more control on database manipulation. 

My suggestion is that we can have some scaffolding actions that automatically create that server actions to be called from external modules, for example, right click on the entity -> generate CRUD actions.

I would prefer to customize the existing entity actions.

Much like the OnBeforeRequest/OnAfterResponse methods of REST services are able to change the request/response, we could have a way of customizing the logic for persisting and retrieving the entity from the database.

I also prefer customizing the existing entity actions the REST services alike. This leaves scaffolding intact and ensures that the added logic is always executed. 

We also create our own public crud server actions. Within the entity's espace one still can use the entity actions, to prevent this we must check the usage during code reviews.

When a new entity is created a few elementary actions are created.

It's a good habit to use these actions in a set of business level actions and avoid using these elementary actions directly.

I think it would be nice to create these business actions automatically and provide them with calls of their elementary level actions.  At this time it's possible to disallow the usage of the elementary actions on another level than the business layer.  People cannot skip the business layer.

Hi,

Great idea, but I think there are similar ideas already floating about...

Yes, there are a number of existing ideas around this.

J.Ja

The fields CreatedBy, CreatedAt, UpdatedBy and UpdatedAt are often required. 

We spend a lot of time adding this fields and creating actions that encapsulate CRUD actions and fill these fields.

I propose a wizard that when creating an entity allows the user to:

• select the automatic addition of the fields CreatedBy, CreatedAt, UpdatedBy and UpdatedAt
• select the automatic generation of actions that encapsulate the CRUD actions and fill this fields.

blimey, it was on the radar, but the merge got it removed somehow :(

I totally support this, it would be nice even if it was just to create the standard wrapper without any filling of fields, we waste too much time doing those wrappers (boring, repetitive work)

Also nice if it could be a bit generic and you could define templates for fields/actions and then have those actions be created when you create an entity or by clicking on the entity and have an option like "Create Templates" 

my 2 cents on the subject.

It is a bit strange that outsystems suggest a certain architecture where you also need to have entities to public=yes, but read-only. This forces us to create almost the boring wrappers around the crud-actions.

If this could be implemented when swapping the public=yes to aks a dialog "create wrappers? or something like that and it will be smart enough to see if there are createdBy, updateBy etc.. it should be rather easy to create the wrappers as we like to see?

99% of the time it's "if id = null then set created on and created by to now and current user, and always set updated by for the same"

What you mean a property of the entity? How would it create actions based on a property?

I *think* it would be something in the advanced properties like "identifier", plural etc...

Yes. IMHO, these 4 fields should be like checkboxes / options in the advanced properties. And when checked, would be created automatically in the entity. 2 possible scenario's:

1. Fields are not changeable by any logic. If user wants that, he could still manually create additional attributes instead of these. So here, fields are filled in automatically (and always!) without the need for setting them in logic
2. Have them be changeable by logic (and even initial setting manually? Although then there would be little benefit of automation of repetitive work)

Actually what i was suggesting were two things:

• be able to automatically generate the fields. 
• something like what we have on eclipse to automatically create methods. 

It would be very helpful if the fields were filled automatically. However, if Outsystems could automatically create generic actions, we would be able to add/change the code for particular situations.

Yesterday i had to create wrappers for 45 entities by hand (had to refactor something), anything that helps in this  would be great :P

My 45 entities are local and dont have createdby/on and updatedby/on fields, it was literally doing an "automated" chore by hand.

I think of those two points the second one is especially useful, the fields you can simply Copy/Paste, the actions take alot more time to replicate.

Thanks for the great feedback we will take it into consideration.

There are a couple of scenarios like Timers and BPT that the user is not logged in, therefore CreatedBy or UpdatedBy either are empty or depend on business rules.

Regarding creating the wrappers is also one thing that is on our radar and is already mentioned on following idea.

Dont forget the Delete actions :P

and for mobile, create all and delete all eheh

Good to know that they will be done eventually, keep up the good work.

Action wrappers for Entities would be awesome, Validation of these actions should also be included based on entity constraints

It would be nice to be able to flag a table as "Audit" in advanced properties, and then have OutSystems automatically capture data and time and userid in an OutSystems table specifically for this purpose maybe through a trigger/stored procedure. Couple it with an Audit component for access. The we could simply just check the box for tables we needed an Audit Trail for and not have all these additional attributes on each table.

In my option, the entity could have:

And, if I pick "Yes", the fields will be created.

It's even better to specify exact attributes here because names could be different

An Entity should have an option to automaticly generate a Entity_CreateOrUpdate action with server side validations, taking into account the properties of the attributes in the Entity (E.g. mandatory fields). In this way, we would have basic validation per entity in the Core Service modules and not only in the End User Modules. 

I agree this can be helpfull, but I think everybody models this kind of functionality in a different way. So it should be configure (folder, name of the created action, which validations) else you'll end up with adjusting a lot.

Well, I disagree with Evert. imho, those wrappers should be structured like already created actions:

<entityname>

-createorupdate

-create

-..

and tbh, i don't care on this low level naming ;)

Instead of validating alterations (add, modify and delete) on tables at several places in parts of modules that approach these tables, it might be better, in my opinion, to perform these validations in special server actions. Maybe it is even better to create a special module for it that is stacked on the ‘Core’ module. Validations, for a specific alteration on a certain table, are always performed the same way in that case, no matter where the server action is initiated (screen, process …).

Having these special server actions, it is also easy to perform inter table validations. The deletion of a record of table A might result into an update of table B. If the update of the B-record is not allowed due to its validations, the deletion of the A-record may not take place either. This implies that the server action ‘ValidationCreateOrUpdateTableB’ is started within ‘ValidationDeleteTableA’. To instruct the caller, an output parameter should return the result of the validation. So, the outcome might be a description about the validation error or just empty if okay.

Introducing the validation server actions will imply that the database actions ‘CreateOrUpdateTable’, ‘CreateTable’, UpdateTable’ and ‘DeleteTable’ should not be used anywhere outside their validation server actions anymore.

The ‘ValidationCreateOrUpdateTable’ server action should check whether the input Id prameters is empty or not. If empty (nullIdentifier), the ‘ValidateCreateTable’ action should be started. When this action returns an empty value (a correct validation and an insertion), a new Id is returned as well. However, when the action returns an error description, the complete action should be cancelled. If the insertion is correct, but the following update is not correct, an abort transaction should be performed to undo the insertion in that case.

Would the use of validation server actions be an option?

Hello René,

First, what is your Idea behind this?

Second, that's what you should do based on your use cases and business logic that your application requires. 

They depend very much on the business logic that you need to implement and aren't equal to everyone. 

The Server actions you talk should be in same module where you have the Entities and only those server actions should be public and your entities should be public and Read-Only.

Abílio Matos

Hello Abilio,

The idea behind it is to have a single point of validation per table access type (create, update, delete).

I was creating an application in which records could be altered on the screen and records could be altered via JSON Restful webservices. For both entry points I was coding validations. So, i decided to call a server action for each validation.

I agree it is even better to store the validation table access actions in the database layer itself. Do you know if there is any documentation (course) about this topic?

René Cornet  

René,

This topic is also approached in 4 Layer Canvas architecture and in several courses, some more encapsulated than others, like the ones from Becoming a Web Developer guided path.

Abílio Matos

This is standard architectural practice.

THAT SAID...

The system does not support it well. For example, the drag/drop stuff more or less breaks down once you start using four layer canvas.

There are a number of related, but not identical ideas (nothing close enough for me to merge these) out there already.

J.Ja

Hi Fernando, 

What I actually intended to say is more about functional validations. Technical validations are performed very well by the current statements for adding, updating and deleting records, but is it also functionally allowed to delete a record,  do I need to update another table when I create a record, ... ? These functional validations should be performed, in my opinion, at one point per table and per table access type. The technical validations are performed during the actual table action.

René

- It'll be be very nice if we can right click on an entity and choose 'generate getters and setters'. The CRUD operations are identical in some content. And the developer can add/remove/complete the code.

This feature will create API's according the best practices and corresponding entity structure in a core component. And it can be more complex with some options.

This would be great if you could with a right click on top of an entity to generate the CRUD actions split by folder for example.

Hey Miguel,

What do you mean by creating CRUD actions? Entity actions already appear under each entity.

Are you talking about creating wrapper actions in specific folders?

Cheers,

Hey Vasco,

I mean having entities as read-only and then create automatically in "Logic" tab all the CRUD action for then consume in other modules instead of using the CRUD actions direct from entities. 

One of the reasons to make this CRUD actions is to match with architecture best practices.

An example:

Thank you,

Cheers,

Miguel Vicente

Oh, got it!

My question is that if these actions are not custom for each scenario/project/customer. If it is, we would just be accelerating the creation of 3 actions that the user would have to review, implement and customize. Wondering how this helper would actually accelerate your work.

Cheers,

Hey, 

90% of the use cases are to set the CreatedBy, CreatedOn, UpdatedBy, UpdatedOn, and IsActive. So in most of the times, we need to spend some time on creating this actions just to assign this fields. 

For sure this will improve developers time at the beginning of their projects and we are also helping them to follow the best practices. 

Disadvantages, when you set your entities as read-only you are unable to create screens with scaffolding. 

Cheers,

Thanks

Completely agree that we need something like this. We always create a save, savecore and validate actions. We need custom action templates!

In all of the clients and projects I've been so far this is something that is always implemented.

I agree to all above that we need action templates, but one problem that should also be solved is that for a readonly entity the scaffolding of screens generates "readonly" screens without add and update.

This should be configurable, we in pricinple always put entities on readonly, but for screen scaffolding to work you need them on readonly false.

Daniel, completely agree!

Edagar, I agree, people always do that. The thing that really bothers me on that flow, the inline ifs... it's a visual language!

What would be great is extending the templating functionality so that it works with more than just espaces. For example being able to set a template for the entity creation could pre create certain fields and pre create the crud operations allowing us to then just add the missing details. Might be worth a new idea of its own.

Hello,

It would be nice to let Outsystems automatically generate getter and setter actions for Create, Update or Delete actions of entities. Maybe the user can do this via a context menu option or a keyboard shortcut.

Being able to right click a CRUD operation of an Entity in a core module and automatically generating a corresponding Server Action to be exposed to the Front End UI module would promote OutSystems Data Architecture best practices in addition to saving a significant amount of time at application creation.

Add the possibility of adding a before and/or after callback to Entity Actions. 

As an example, for an "Item" entity, being able to create an OnBeforeCreateItem and OnAfterCreateItem would allow one to centralize some business rules (e.g. validate the record before, or increase stock after) while people still called the "normal" CreateItem entity action.

This is a lot more obvious than the current pattern of having to make the entity readonly and creating a public Item_Create action, that's not immediate to relate as the CRUD substitute of the Entity action. It's also orthogonal to how REST calls work.

There may be times that you want to maybe do only the CRU of CRUD on an entity that is in a Core module. The only way to expose an entity to anything other than just read is to expose all of it's features. It seems a bit much to lock it down by creating actions for only the operations in CRUD that you want to expose (especially if you only want to say, not expose deleting), so maybe if you turn off Read Only mode, there could be a checkbox for each of the default bahaviors that come with an entity that can easily turn access off and on to them.

You can easily overcome this by creating a wrapper for the action that you want to expose. 

Robert,

Best practices for Core modules entities say that you should always do your server actions for CRUD.

Core Service abstraction

Regards

Abílio Matos

Roman Tkachenko: writing code to replicate already existing behavior is not considered a smart solution in my book. If they are willingly going to provide a fully exposed set of CRUD operations, then the answer should not be: "If you want only certain ones exposed, go write a wrapper to do what we already did for you (oh by the way, if you want all of them though, we'll let you do that)". That's making people do needless work to accomplish something the system could help you manage.

Abilio Matos: I'd like to know why it's a best practice. Say you have absolutely no business logic code that needs to sit between the function and the actual operation happening, why does someone need to do tedious work that already exists in the framework? And that's fine if everyone, including Outsystems, wants to consider it best practice.

I only gave the above idea because Outsystems is obviously OK with exposing everything publicly with no wrappers. However, if they cared so much about "best practices" they could just not allow any exposing of operations and force people to follow what everyone seems to call "best practices". That's the REAL solution. However, since Outsystems insists on allowing exposing the raw operations, then they should at least allow you to remove access to them with a checkbox. There's  no harm in that if they are already going to allow you to expose them all anyway.

Robert, 

That is OutSystems best practice so you need to ask them.

Also, in those wrappers you could do some validations to check if everything is ok and then call the CRUD created automatically by platform. Other thing you have is to control where your CRUD operations happen instead of allow every consumer modulo to do them as they want.

Abílio Matos

Don't get me wrong. I am not bashing what people are considering best practices. I totally get why. However, the fact of the matter is that in spite of these best practices (that even OutSystems agrees with) they continue to let you expose all (or none) of the operations. So, if they are going to continue to do so, I think it would be a useful option to allow you to select which ones, that way you can still lock down which operations are available to developers if you elect not to wrap everything in actions. If they didn't think that was a viable way to expose and utilize entity operations, then they would just block them entirely and force you to write actions. Which is a time-consuming set of work to do for every entity just to keep people from, say, being able to Delete. Like I said, the REAL answer is never let there be a public option, but that isn't the current state of things, so my idea is born of this current state.

There are always valid exceptions to rules and even Best Practices (since BPs are merely guidelines and not even rules).

Will it be a 'useful option'? Yes. 

Is it that bad to have a proxy to the CRUD operations? I don't think so. I would say it's really rare when you need those clean CRUD operations without any additional logic. 

Then don't let people publicly expose them and you enforce Best Practice.

I believe it is better to let users define their own validation rules in a centralized module or make validations entity-based.

Creating multiple "if" statements to support validations in the code is not used anywhere, every platform has its own validation library (i.e. .Net is supported by https://fluentvalidation.net/   which is very useful, or even we can create the validations natively on every model using annotations - attributes-) .

If we can have a tool in OutSystems similar to "Fluent Validation", it will be great!

Thanks.

A topic that is often debated by many developers is why CRUDs are not created automatically, at least with a standard model, which can then be adjusted by Dev if necessary. I think this would be a great asset in terms of implementation.

This is a great idea!

This feature could be done the same way the scaffolding actions are made. Drag and drop an entity in the folder "Server Actions" and it automatically creates default CRUD actions.

If the entity has the attributes "CreatedBy", "CreatedOn", "UpdatedBy" and "UpdatedOn", the scaffolding creates the logic to check if the record is new and it fills the values accordingly.

+1

After creating an Entity and it´s attributes on the _CS Module automatically create the CRUD (Create, Read(Get), Update and Delete) actions in order for the user to turn them into public and be ready to use by other modules, this group of actions should be grouped into folders referring each Entity name.

Example for the FileHeader entity, the SoftDelete action is only if the Entity has the Is_Active(Boolean) attribute, turning it false for the record id on the input:

That could be usefull, and direct the developers to implement and use  CRUD action

Like the option available in Local Storage to Create Action to Sync Data, Entities CRUD actions could have a similar option to create a server action for the selected operation. 

That server action could include the Id as input parameter for Delete and Get actions and the full record for Create and Update actions.

We quite often use CreateOrUpdate actions for our new entities. These actions call a validation action, that returns IsValid and a ValidationMessage, they assemble a ValidationLog based on those messages, etc. and return a Success boolean and the ValidationLog.

For these kind of patterns that need to be implemented for every entity, it would be very useful to configure them once and then bootstrap the actions for every entity you create.

Kind of have a small RPA script in service studio. Like it!

In order to speed up the development with OutSystems it will be great if we could define a template of how we like the core wrappers to be created on an application and then have a button that allows you to automatically create the wrapper by specifying some minimum information such as the related entity and operation to perform such as create, update, etc.

The template should allow for specifying any additional actions that are common across CRUD such as adding CreatedOn, CreatedBy, etc, calling audit actions that store information about the operation performed such log messages (ex. Record created), security checks, etc.

Without the above template definition/automation creating the CRUD in OutSystems results in more time than if you were to perform the CRUD wrappers using code. 

When creating entities, for entites with the CreatedBy, CreationDate, LastChangedBy, LastChangedDate attributes, it would be helpful to quickly create a Save Action.

By selecting this option, a quick action could be implemented like in the following example.

The same option could be applied to an entity delete action.

Hello everyone!

Dragging an Entity Action to the Server Actions folder could create an automated Wrapper Action.

What do you think?

Thank you!

(Example in Attachment Image.)

To be possible to create CRUD actions automatically:

• Save (Create or Update)
• Soft Delete (Only change the IsActive flag)
• Harde Delete (Delete the record)

When setting an entity 'Expose Read Only' to Yes; automatically(or triggered by a checkbox in entity properties) create basic crud wrappers for that entity in the Logic folder. 

I would disagree. Let's assume we have created 20 entities, So you are saying that OutSystems should create 80 Server actions automatically. Don't you think it will make your architecture really messy? It hardly takes around 20 seconds to create a CRUD wrapper.

When you create an entity, you should have wrappers of the CRUD automatically created for entities that you set public.

First off, when setting an entity as Public can the platform default the Expose Read Only to True following the best practices of the platform. This applies for other settings too and should be defaulted based on best practices.

Please make provision for the platform to auto generate default wrapper action when an Entity is set as Public and Read Only as this takes much time and repetitive.

A design pattern that is often used and recommended is to set an entity to 'non-public' and rather wrap each CRUD action in a server action wrapper where inputs can be validated, optional metadata can be added and any side effects can be implemented.

It would be very convenient to right-click on an entity and have an option to automatically create these CRUD wrappers with the respective actions already inside:

Service Studio currently generates CRUD wrapper actions (CreateOrUpdate) for entities. This is really helpful and a common need, as stated in dozens of different ideas around the same topic.

However, the current feature is only triggered when the entity is scaffolded into a screen. Which makes it a bit annoying when you are working on a slightly complex architecture, with service modules, for example.

In order to provide the best experience, the CRUD wrapper actions should be generated through an option in the context menu of an Entity. Or even a customisation option on the built-in CRUD actions.

Like your Idea, This would help a great deal, but I would like to take it a step further :)

https://www.outsystems.com/ideas/12628/inherited-code-wrappers/

Nice idea

When we enable the "Expose read-only" property as "Yes," we typically generate Create/Update/Delete wrappers. It would be highly beneficial if there were an option to generate Server Action wrappers specifically for individual entity actions.

Most of the times we create server action wrappers for entity actions. This is needed because we dont expose entity actions to other modules. It consume lot of time write the wrappers. We can have accelerator like below. To ope the below screen we can right click on entity and click on option like ' Create Server action wrapper'

Sample data action wrapper normally needed to encapsulate EntityAction. This as discussed can be created with the above screen