Question
Toyota
US
Last activity: 22 May 2017 11:44 EDT
Pega MObile Offline- Online Case and Offline Enabled Case Support in 7.2.2
HI ,
Need Design help with Pega 7.2.2, We have a requirement that
1) Case can Start either in offline or online and In Stage 1 -> first 2 screens has to support both in offline & online.
2) After the 2 screens we have 3 rd screen which should be always in online and then other stages(2,3 and 4) will be always only online ( screens means we added Screen flow).
3) Update profile and Worklist has to fetch latest data always.
4) Also Seeing that in 7.2.2 Refresh section and calling Data Transform rules are not calling
***Updated by moderator: Lochan to add SR details***
Pegasystems Inc.
US
Hello Sasi,
Please see this recently concluded "Ask The Expert" session. https://collaborate.pega.com/discussion/ask-expert-offline-mobile
Pegasystems Inc.
US
Hi Sasi,
Your use case is the basic use case that offline was built around. The idea that you would have an agent out in the field collecting data, then an agent in the office processing the actual case afterwards. Offline processing will automatically stop when it reaches something it cannot process offline, such as a routing or utility shape.
For example, in the configuration below, offline processing will stop when it reaches the second stage.
Our expected use case is that field agents and agents in the office would be working from different work baskets. However, if you have the same agents doing both jobs, that is possible too...
To keep assignments from the "online" stages from showing on a user's offline worklist, you can either use different work baskets, or filter them out of the user's worklist when rendering the worklist for offline. See pzIsOfflineEnabled when rule and D_pyUserWorklist data pages. You can modify this data page to have its own custom offline worklist easily enough. Just keep the columns the same.
Hi Sasi,
Your use case is the basic use case that offline was built around. The idea that you would have an agent out in the field collecting data, then an agent in the office processing the actual case afterwards. Offline processing will automatically stop when it reaches something it cannot process offline, such as a routing or utility shape.
For example, in the configuration below, offline processing will stop when it reaches the second stage.
Our expected use case is that field agents and agents in the office would be working from different work baskets. However, if you have the same agents doing both jobs, that is possible too...
To keep assignments from the "online" stages from showing on a user's offline worklist, you can either use different work baskets, or filter them out of the user's worklist when rendering the worklist for offline. See pzIsOfflineEnabled when rule and D_pyUserWorklist data pages. You can modify this data page to have its own custom offline worklist easily enough. Just keep the columns the same.
If you run into any issues, feel free to keep posting them here in the Pega Support Community and we will help you out.
- James Hall
Toyota
US
Hi HALL,
Sorry I did nt get, my actual scenario is like this, user will be able to start the case in offline or online and first stage can be submitted either in online or offline then after submit ion of stage1 it will always be online case. we don want to make ass offline kind of app, from stage-2 onwards it should look like online cases fast response and DT,service call should wotk withour OSCO coding.
this I tried multiple ways but not working out.
Pegasystems Inc.
US
Sasi,
This is exactly the basic use case that OSCO was built around. I am not sure what things you have tried, but it sounds like you may be going about it the hard way.
Most folks would handle this as two case types. One offline enabled, one not. The second case type would get created at the end of the first case type. Usually, the second case type goes to a different work basket because typically the the two cases are handled by different people. You can put a utility on the end of the offline flow to create a parent case type or a child case type and to move one case under the other.
If both parts absolutely need to be handled by the same operator ID with the same case ID, then just create a flag property to set at the end of the offline flow via a utility shape. Then have the user worklist for offline filter out those cases in the DT using what I described in your first post.
So far, your use case sounds like a standard use of OSCO. It does not make sense that you would need to create temporary work objects or be modifying pyStartCase.
- James
Pegasystems Inc.
US
Hi Sasi
I think what James seem to say
1. Keep your stage 1 as-is so that it is both offline and online enabled
2. As of Stage 2 , if you route it to Work queue (as shown in his screen shot) - it "automatically" forces it to be picked up only when in online mode.
Is this something that can work for you ?