Question
Legato Health Technologies
IN
Last activity: 11 Dec 2017 4:24 EST
Recents section isn't updating with the claim created
We have this functionality in smart dispute application wherein the case-id should reflect in the recents section whenever a new case is created and also when any case is accessed through worklist or workbasket. At this point of time, the case id does get updated when it is accessed through worklist or workbasket but the newly created cases don't reflect in the recents section. However, this wasn't the case a while back when all the said scenarios used to work fine.
The design time configuration for recents section includes the use of pyRecents section of Data-Portal class whose grid is sourced from Declare_pxRecents page, i.e. everything out of the box. Not sure why this design is creating problems after a while and not from the start of the development. Any suggestions for the newly created cases to reflect in recents section?
Accepted Solution
Legato Health Technologies
IN
Raised a SR for the same since all the implemented rules were out of the box with no custom changes. Got a confirmation saying this is as expected behavior. Claims would show up in the recents section only when accessed explicitly through worklist or workbasket and not when just created.
PEG
US
This is the type of issue where a Tracer log will be invaluable. If you do not yet have the new Tracer viewer, it is light years ahead of the runtime Tracer functionality. It can be downloaded from the PDN here: https://github.com/pegasystems/pega-tracerviewer/releases
The tool is pretty intuitive. After you gather the Tracer output, save the XML, and then open it with the Tracer Viewer. The ability to search in all of the pages that are traced is invaluable.
I always trace with all events and all rulesets enabled. If you open the settings panel, go to the bottom, and set the number of lines of output to zero, nothing will appear in the runtime Tracer, and the command will finish executing in almost the same time as it usually does when you are not tracing; this avoids the sometimes horrible delays until the Tracer finishes. I usually wait about one minute after the command completes before pausing the Tracer and then saving it -- there is no visual indication that the Trace has finished!
Be aware that the only way to stop accumulating into one Tracer file that will be saved and start a new one is to close the Tracer window by clicking on the "X" in the upper right corner. Merely clearing the Tracer does not wipe out the internal log that will eventually be saved. So closing the Tracer and reopening it should become part of your routine if you don't want your Tracer files to be even larger than they need to be.
This is the type of issue where a Tracer log will be invaluable. If you do not yet have the new Tracer viewer, it is light years ahead of the runtime Tracer functionality. It can be downloaded from the PDN here: https://github.com/pegasystems/pega-tracerviewer/releases
The tool is pretty intuitive. After you gather the Tracer output, save the XML, and then open it with the Tracer Viewer. The ability to search in all of the pages that are traced is invaluable.
I always trace with all events and all rulesets enabled. If you open the settings panel, go to the bottom, and set the number of lines of output to zero, nothing will appear in the runtime Tracer, and the command will finish executing in almost the same time as it usually does when you are not tracing; this avoids the sometimes horrible delays until the Tracer finishes. I usually wait about one minute after the command completes before pausing the Tracer and then saving it -- there is no visual indication that the Trace has finished!
Be aware that the only way to stop accumulating into one Tracer file that will be saved and start a new one is to close the Tracer window by clicking on the "X" in the upper right corner. Merely clearing the Tracer does not wipe out the internal log that will eventually be saved. So closing the Tracer and reopening it should become part of your routine if you don't want your Tracer files to be even larger than they need to be.
I would trace both a "good" and a "bad" use case. I would look for the work object id in the Recents page for the good case and see how it gets there -- then compare with the bad case, and see at what point the processing goes south. Remember, with the Tracer Viewer, you can search everywhere for occurrences of any string. You may want to, in the Tracer settings panel, add the Recents data page as a specific page to always Trace; the option is near the bottom of the Settings panel.
Pegasystems
US
You'll want to focus in on which logic is being invoked to populate the recents-list in your good situation, and figure out why that logic isn't similarly populating the recents-list for the bad situation. By both studying the trace, and using rule-content search and reference-rules, you should be able to determine where the recents-list populating is supposed to occur.
Accepted Solution
Legato Health Technologies
IN
Raised a SR for the same since all the implemented rules were out of the box with no custom changes. Got a confirmation saying this is as expected behavior. Claims would show up in the recents section only when accessed explicitly through worklist or workbasket and not when just created.
