Posted: 3 Jan 2018 12:08 EST Last activity: 13 Apr 2018 12:41 EDT
Discussion : What to keep in pyWorkPage and in top level pages
I have heard from some people that we should keep the data in pyWorkpage only whatever required for flow processing but not the raw application data.
In one way its good to store less data on pyworkpage which saves memory .Downside is every time ,we need to pull data from different sources (eg External DB or Service calls) which takes longer time to load the data.
Here would like to hear other people thoughts like what to keep in pyworkpage and when we can go for top level page
This sounds similar to having access to large data pages during off-line mobile processing. You would not want to be forced to download an entire large data page all at once and each time you access it. Instead you would want to be able to incrementally load only the data that changes. This reference data needn't be stored within the case. Excerpt from the CREATING MOBILE SOLUTIONS course below.
ENABLING OFFLINE PROCESSING IN A MOBILE APP How to manage reference data with large data pages
Using large data pages to store reference data in your application can help improve the performance of a mobile app. Only individual records of the large data page that have changed are synced, not the entire set of records. Large data pages also enable more efficient memory management. Only records needed to render a specific screen on the mobile device are loaded to the device's memory, leaving the remaining parts of reference data in the device's permanent store.
Critical transaction data I would agree is important to store within the case using embedded pages or pagelists.
By "critical" I mean the type of information you would want to see when opening a case in "Review" mode.
Other case-related data that is only accessed on demand, plus consumes a large amount of memory, can be stored outside the case and retrieved when needed.
For on-demand data that could potentially be referenced by multiple cases, as within a case hierarchy, you can define a Data- class that extends Link-.
For on-demand data that is always case-specific you can define a Data- class that extends Data-WorkAttach-.
Storing data outside the case, as opposed to storing it in the BLOB and reporting against it using a Declare Index, does require more effort. The extra effort involves having to Obj-Save the data separately during case processing context since FinishAssignment only saves the case. Maintaining referential integrity also requires more effort.
A Data-WorkAttach-extending class can be leveraged to invoke integrations that run in the background without impacting the case.
As opposed to queueing a Standard Agent using the case as a step page, queue the Standard Agent with a step page where the class extends Data-WorkAttach-.
You need to Obj-Save that step page when doing so, otherwise the Standard Agent would not be able to reopen it. Be sure to have set pxRefObjectKey = Primary.pzInsKey, i.e., your case’s pzInsKey. Consider using a GUID Property as the Data- class's key.
In the Standard Agent activity you can then reopen the case read-only using pxRefObjectKey. The reopened case is used to obtain request information. Once the request information is captured the case page can be removed. Invoke the connector but store the response within the Data-WorkAttach- extending Data- class.
I have some Critical transaction data as mentioned above in the thread and I am using a grid to show the data in an offline enabled app, but for some reasons it doesn't show when I login as an offline user. Any reasons why this may not show up ? I have verified the logs and it loads to show no results when I verify the same on the clipboard it has data.
Why do you mean by offline APP? If the data is at the thread level. you will not be able to access in different thread context. Have a caching mechanism to copu the data to node level parameterized with rulesetlist hash so that we can access the same data is different user context.