Appian Community
Site
Search
Sign In/Register
Site
Search
User
DISCUSS
LEARN
SUCCESS
SUPPORT
Documentation
AppMarket
More
Cancel
I'm looking for ...
State
Not Answered
+1
person also asked this
people also asked this
Replies
13 replies
Subscribers
7 subscribers
Views
6777 views
Users
0 members are here
Share
More
Cancel
Related Discussions
Home
»
Discussions
»
User Interface
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
OriginalPostID-249822
Discussion posts and replies are publicly visible
Parents
0
chetany
A Score Level 1
over 8 years ago
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.
Cancel
Vote Up
0
Vote Down
Sign in to reply
Verify Answer
Cancel
Reply
0
chetany
A Score Level 1
over 8 years ago
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.
Cancel
Vote Up
0
Vote Down
Sign in to reply
Verify Answer
Cancel
Children
No Data