Question
NTT Data
US
Last activity: 31 Dec 2018 9:52 EST
Reducing Number of Offline Enabled Access Group- Performance Improvement
My Question is reducing number of offline enabled access group in an mobile application would improve performance ?
Generally even build mobile application - not many accessgroup we enable offline enabled, normally one access group for mobile users, other access groups for desk /laptop web users, since same application going to use for both mobile and non mobile users.
But reducing number of offline enabled access group in an mobile application would improve performance ? -each offline enabled access group -associated portal definitely need synchronization, so minimizing the no of offline enabled access groups may help , your thoughts please
NTT Data
US
Somebody from Pega correct me, if more offline enabled access group more users accessing application more synchronization required. If minimize offline access group - reduce less synchronization. but again all the users instead of spread across multiple access groups , all in one access group again won't do same synchorinization as multiple offline access groups?
Pegasystems Inc.
US
When you build an offline enabled application using Pega, all the build does is package the assets and provides a URL. If a user is going to use the offline application, then they will, as a best practice, have a default access group that is offline mobile enabled, and they can only have one default access group. The access group then determines the portal that will be accessed as well.
So, if your users require more than one portal based on the requirements of the application, then there will need to be more than one access group. it is the case types and functionality sets required, particularly in the portal and related harness, that drives the requirements for the number of access groups. This does NOT necessarily mean that more access groups means more users. You could have 100 users and divide them across 10 access groups or have them in one access group. It still 100 users.
When you build an offline enabled application using Pega, all the build does is package the assets and provides a URL. If a user is going to use the offline application, then they will, as a best practice, have a default access group that is offline mobile enabled, and they can only have one default access group. The access group then determines the portal that will be accessed as well.
So, if your users require more than one portal based on the requirements of the application, then there will need to be more than one access group. it is the case types and functionality sets required, particularly in the portal and related harness, that drives the requirements for the number of access groups. This does NOT necessarily mean that more access groups means more users. You could have 100 users and divide them across 10 access groups or have them in one access group. It still 100 users.
What does drive performance is the size of the package being distributed during synchronization. By providing more access groups that pinpoint only the functionality needed by a group of users, you may be able to more closely manage the number of rules and size of data set that is being synchronized. If you have users of an application that are not using parts of the offline application and you do not anticipate them doing so, then you may want to create a new access group with a different portal, harness, etc. that only grants access to the functionality actually used.
Bottom line is that the access group, itself, is not really a driver of performance. It is the expected size of the package that is most critical.
Hope this helps.
NTT Data
US
Thank you, so it means reducing number of offline access group won't help synchronization, won't help to improve performance, correct.
Pegasystems Inc.
US
In isolation, this is correct as the number of access groups does not directly govern package size. In fact, it is more likely that increasing the number of access groups to allow packaging at a more granular level may aid in performance than in reducing them.