write directly from interface to DB

Hi All,
I have developed a SAIL interface that is be able to directly write to DB using the function

a!writeToDataStoreEntity(cons!NCContainmentAction,local!newContainmentAction)

the local!newContainmentAction is an object created locally as

local!newContainmentAction:fn!cast('type!{www.pirelli.com/.../appian}NonConformityContainment',{})

This approach is very helpful because we are able to write directly on DB avoiding many other nodes witch, before using this approach, we used to elaborate data and write to DB
It also seems that SAIL code is simpler and faster to manage because we deal with the object and its attributes

I have never seen this kind of approach in Appian SAIL documentation so I would like to understand if it is correct and if you suggest or not to use it

Thank you in advance

Elia




OriginalPostID-249822

  Discussion posts and replies are publicly visible

Parents
  • I prefer saving in the SAIL form directly, because if something goes wrong with the save, you can immediately notify the user that something went wrong. If the DB save occurs in the process model, the user is not notified that something went wrong and they will be confused about what is happening. In addition, process models have the notoriously difficult process upgrades when a release goes to Prod, which you can avoid by placing most of the logic of the application in SAIL and only using process models for bare-bones pathing. This wouldn't completely eliminate process upgrades, but the simpler the process model, the easier it is to create a process upgrade.
Reply
  • I prefer saving in the SAIL form directly, because if something goes wrong with the save, you can immediately notify the user that something went wrong. If the DB save occurs in the process model, the user is not notified that something went wrong and they will be confused about what is happening. In addition, process models have the notoriously difficult process upgrades when a release goes to Prod, which you can avoid by placing most of the logic of the application in SAIL and only using process models for bare-bones pathing. This wouldn't completely eliminate process upgrades, but the simpler the process model, the easier it is to create a process upgrade.
Children
No Data