write directly from interface to DB

eliav over 8 years ago

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

Discussion posts and replies are publicly visible

0 eliav over 8 years ago

But, in my opinion, you should check the fv!storedValues.ID value
This value is empty before to write on DB, after writeToDataStoreEntity invocation it is filled with the new value of the DB sequence
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 eliav over 8 years ago

@philb sorry but I can't understand what you mean ..
What is the difference if you use a smart service to write into DB ?
A process , started in background, can change data meanwhile another user is viewing a report or something else in the same table ..
Data transactions are managed by DB so is not possible to have deadlock or something else on DB ... in any case I think the situation is equal to a smart service that performs a write operation ...
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 marky over 8 years ago

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.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel