write directly from interface to DB

This works, but you can store data only in a saveInto of a SAIL component. Our approach is to only use this if necessary and stay with the "old" way of storing data in process. Most of the time we want to do more things with the data to store and putting complex logic inside a SAIL form makes maintenance tougher.

The main issue with what you've created is concurrent writes and data locking; how would your interface handle these?

Each interface manage only one request ID
Each task can be closed by one person of a group ... Also DB manages transactions ...
Why could I have this issue ?

These are my opinions, there are pros and cons:
Pros:
1. Certainly, it will reduce the load on process execution engines - since no process instances will be needed to launch just for writing to the database. And you do not need to create a process model for it.
2. The function is asynchronous - so it wont block the SAIL UI when its writing to the DB.
3. Can be used on all kinds of SAIL UI and Web APIs.

Cons:
1. If it fails - it will fail silently- this is both a good thing and a bad thing - in case of the "old way", you at-least get an alert. In this case, the alert will be in the logs only, it wont be available in the Appian designer. This can cause hard to detect issues, and fixing them.
2. Agree with stefanh791 - that more than often we want more processing to be done on the data before we write to DB. That's a good point - although one could argue that we can create an expression rule which will encapsulate all the processing logic before writing to the DB.
3. I am more worried about the case of "side effect". This function causes side effect in the sense that it updates/writes the data - it modifies something in the system. This is desirable in some cases: eg: you want to edit the record data from the summary dashboard directly, instead of creating a related action to do it.
But, consider a scenario - let's say you have a tempo report. Somewhere in the interface for the tempo report, you have used the a!writeTodataStoreEntity() function. Now, its possible that this function is writing to the database, and the tempo report is using the same database table as its source. This can be confusing. Imagine a scenario - you click on the slice of a piechart(which shows percentages), the data gets updated asynchronously in the background. You click once again on the slice of report - the data is fetched again.
This time it will show different data! The user may wonder how did the percentages of the slices change immediately. Yes, this is a contrived example - but it is totally possible.
4. You need to make sure that you refresh the interface with updated data - if you are using this function, the database will be updated asynchronously. The interface may then need to show the updated data - of course the function provides "onSuccess" and "onError". But, I have not found it straightforward to refresh the data on the interface as soon as the function updated the database.

@eliav I suggest you have a read here: en.wikipedia.org/.../Record_locking

Cons, point 1 : we should manage function returned values (successs or error).
Cons, point 2 : how you said we can you rules to manipulate data and then write to DB ...
Cons, point 3 : what is the difference if you delegate a smart service to change data ind db?. Nothing avoids that a smart service changes in back ground data that someone is looking in a report or something else ...
Cons point 4: the button submit is synchronous, it call the function and when the function finishes returning "success" or "error" it goes ahead to execute other statements.. if you try to use a grid structure in a with function you can see the new added or uploaded value direclty in the page :)

@eliav, I have tried using the returned values returned by onSuccess and onError. In case of a!writeTodataStoreEntity, the value returned is in fv!storedValues. I tries saving it to a local variable, and showing some message on UI when data is written successfully(based on the value that I am saving in the local variable onSuccess). It did not work. Its possible that I am doing something wrong.

The variable fv!storedValues will be populated only when the a!writeTodataStoreEntity function executes successfully - and this happens in async manner. Maybe that is why it is not working as expected.

About Point 2: I was saying that we can have a expression rule which will contain the processing logic - which we usually do in script tasks in Process model before writing to DB. The same can be done in an expression rule and the transformed value be passed to a!writeToDataStoreEntity.

The fv!storedValues if of the same type you use to write in the data store function
It works because if you try to read the ID attribute you can see the next key , so the data is wrote ...

Yes, agree that the data is written. I am trying this - when the data gets written, I want to give a short message - "Data Saved". And this should happen only when the data gets written by the function. For that I am trying to toggle a Boolean variable in the onSuccess (since we can have saveInto in it). But, it does not seem to work.

Sorry Chetany,
the on success documentation says


onSuccess (Any Type): A list of saves or an HTTP response to execute after the smart service executes successfully. Created with a!save() or a!httpResponse(). The stored values are available in the function variable fv!storedValues.


So I tried to do that

a!writeToDataStoreEntity(cons!NCContainmentAction,local!newContainmentAction,{a!save(ri!done,"true")}),

by defining a done ri variable
And it works