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
Replies
29 replies
Subscribers
7 subscribers
Views
6158 views
Users
0 members are here
Share
More
Cancel
Related Discussions
Home
»
Discussions
»
General
Pagination - Memory threshold issue.
saicharanb
over 7 years ago
We have a query as below
rule!WFT_getRequestDetailsBySearchParams(ri!process,ri!subprocess,ri!action,ri!requestor,ri!company,ri!reference,ri!sapRefNo,if(isnull(ri!fromDate),todatetime(date(2010,10,10)),ri!fromDate),if(isnull(ri!toDate),todatetime((today())),ri!toDate+intervalds(23,59,59)),ri!monetaryValue,ri!priority,ri!wftRequestID,ri!salesOffice,ri!requestStatus,ri!pageInfo)))
In the above query how is "ri!pageInfo" working? I could not find any parameters like batch size set for pageInfo. Please help how does it work for the above query.
How does pageInfo decrease the load on Appian? I have referred the below link, but did not understand much, Please help me on this.
forum.appian.com/.../System_Functions.html
OriginalPostID-254399
Discussion posts and replies are publicly visible
Parents
0
sikhivahans
over 7 years ago
@saicharanb As per my observation so far, you have been working on the Forms Designer and Paging Grid Component in particular. I believe you are trying to target the performance improvement and also trying to know how the pagingInfo works:
How it works:
1. When it comes to Paging Grid Component that belongs to Forms Designer, data!pagingInfo is the property that takes care of pagination and documentation at https://forum.appian.com/suite/help/16.2/Forms_Designer_Components.html#executing-the-data-set-expression might help you understand this.
2. When it comes to pagingInfo, the startIndex will be 1 initially. Batch size parameter will be controlled by 'Rows per page' attribute of the Paging Grid Forms Designer Component. And with regards to sort, the configuration in the query(or target) rule should take care of this initially(You may also change this default sort behavior by making use of the approach as mentioned at https://forum.appian.com/suite/help/16.2/Forms_Designer_Components.html#specifying-a-default-sort-column). Now the data!pagingInfo keeps track of all the changes in sort and startIndex which we achieve in SAIL by updating the values of Paging Info variable in the 'saveInto' of gridField.
How to overcome the performance issue:
1. Get all the data in the process. Use the BEST practices(batching the data, looping the process in case of large amounts of data) to retrieve data so that this won't hamper the performance, let's say the entire data is stored in a variable called 'queriedData'. While configuring the Paging Grid on the form, use the todatasubset(pv!queriedData,data!pagingInfo). The only difference we are trying to make here is, instead of trying to pull the entire data in the form, we are pulling the data in the process before we hit the form, that too, in the best possible way which thereby overcomes the performance issues and an improved user experience is the additional benefit.
Why retrive all the data in the process:
I believe one might get a doubt as to why we are ending up in retrieving all the data in the process. This is because, in the SAIL, we do have an ability to store the pagingInfo in a variable, update it in 'saveInto' and provide it to the data sorurce rule every time and store fresh values in the data subset variable which could happen all the time when we use with() and on demand when we use load(). As we don't have this kind of mechanism in the Forms Designer(as far as I remember, there isn't any) we use data!pagingInfo which will take care of all the aspects whose startIndex, batchSize, sortInfo will be derived as I have explained earlier. That's why we query the data beforehand in the process so that we don't end up querying a huge amount of data in the form which causes performance issues and a bad user experience. Please note that this works well only for large amounts of data sets and when the data set is small, querying in the form should be fine.
In case if you have any issues in implementation, I would suggest expanding as much as you can on the objects, that is, the definition of the rule, the configuration in Process Model without which giving suggestions might become difficult.
Cancel
Vote Up
0
Vote Down
Sign in to reply
Verify Answer
Cancel
Reply
0
sikhivahans
over 7 years ago
@saicharanb As per my observation so far, you have been working on the Forms Designer and Paging Grid Component in particular. I believe you are trying to target the performance improvement and also trying to know how the pagingInfo works:
How it works:
1. When it comes to Paging Grid Component that belongs to Forms Designer, data!pagingInfo is the property that takes care of pagination and documentation at https://forum.appian.com/suite/help/16.2/Forms_Designer_Components.html#executing-the-data-set-expression might help you understand this.
2. When it comes to pagingInfo, the startIndex will be 1 initially. Batch size parameter will be controlled by 'Rows per page' attribute of the Paging Grid Forms Designer Component. And with regards to sort, the configuration in the query(or target) rule should take care of this initially(You may also change this default sort behavior by making use of the approach as mentioned at https://forum.appian.com/suite/help/16.2/Forms_Designer_Components.html#specifying-a-default-sort-column). Now the data!pagingInfo keeps track of all the changes in sort and startIndex which we achieve in SAIL by updating the values of Paging Info variable in the 'saveInto' of gridField.
How to overcome the performance issue:
1. Get all the data in the process. Use the BEST practices(batching the data, looping the process in case of large amounts of data) to retrieve data so that this won't hamper the performance, let's say the entire data is stored in a variable called 'queriedData'. While configuring the Paging Grid on the form, use the todatasubset(pv!queriedData,data!pagingInfo). The only difference we are trying to make here is, instead of trying to pull the entire data in the form, we are pulling the data in the process before we hit the form, that too, in the best possible way which thereby overcomes the performance issues and an improved user experience is the additional benefit.
Why retrive all the data in the process:
I believe one might get a doubt as to why we are ending up in retrieving all the data in the process. This is because, in the SAIL, we do have an ability to store the pagingInfo in a variable, update it in 'saveInto' and provide it to the data sorurce rule every time and store fresh values in the data subset variable which could happen all the time when we use with() and on demand when we use load(). As we don't have this kind of mechanism in the Forms Designer(as far as I remember, there isn't any) we use data!pagingInfo which will take care of all the aspects whose startIndex, batchSize, sortInfo will be derived as I have explained earlier. That's why we query the data beforehand in the process so that we don't end up querying a huge amount of data in the form which causes performance issues and a bad user experience. Please note that this works well only for large amounts of data sets and when the data set is small, querying in the form should be fine.
In case if you have any issues in implementation, I would suggest expanding as much as you can on the objects, that is, the definition of the rule, the configuration in Process Model without which giving suggestions might become difficult.
Cancel
Vote Up
0
Vote Down
Sign in to reply
Verify Answer
Cancel
Children
No Data