Recent issues using progressive capture on Hornbill service portal

[Victor]

Some of our customers have reported and have been affected recently by a set of issues with progressive capture when using the service portal. The range of issues varied from captures not loading when using the catalog item, captures progressing to a certain point at which the capture because unresponsive, and or users being unable to complete the capture as it once again became unresponsive. The issue appeared to be intermittent, affecting some progressive captures but not others and occurring at apparently random intervals and having captures manifesting the issue just for same captures to progress with no issues when tried at a different time.

As you might imagine, the nature of the issue and the behaviour proved to be a bit problematic and posed a range of challenges for our support and development team in investigating these issues.

When we began our investigation, the main challenge we faced was in replicating the issue in a local instance. Replication would be the first approach in troubleshooting as it can provide the most information about an issue and how it can be addressed. Despite the initial efforts the issue did not manifest for support and development teams locally and what was soon proved to be more problematic was that the issue did not manifest for us when following the exact steps and using the same user context in a live instance. This would be one of the worst outcomes in the initial investigation as it does not give any meaningful information as to what the possible cause would be.

The next approach was to look at how the functionality is designed and build to see if anything can be identified as the potential root cause and direct investigation efforts into these areas.

The caching mechanism was first identified as a potential root cause. This was due to the fact that on some occasions clearing the HB data cached in the browser resolved the issue for some users but either this did not work for other users or for the users that had it resolved the issue started manifesting again after some time.  While this clearly indicates there is something with the caching mechanism, we could not exactly establish if the root cause lays in this area, and possibly there is some other mechanism behind the caching mechanism that is causing the issues.

During the investigation at some point, we did manage to replicate the issue locally which was very beneficial for troubleshooting efforts however, this was quickly shadowed by unexpected behaviours. While the support team could replicate the issue reliably, the development team using the same instance, same user and the same capture could not.

The next approach was to do a code review of the PC engine, we identified the key information which eventually allowed us to find the root cause for the issue and how it can be addressed. One of the actions performed by the PC engine is to load in the browser a set of JS (Java Script) modules. Among many things, these modules are responsible for the PC functions such as loading the forms, defining the behaviour of the Previous/Next buttons, or defining the behaviour of the Finish button. If these JS modules are not loaded in the browser when the PC initiates, then the PC will not effectively work and it will generate issues such as the one experienced here. The key piece of information here was that one of the main modules would only be loaded IF the capture was containing a standard Service Manager form, these being the default forms that can be added in a capture when designing it. Soon after we started to look and see if the captures that we knew were causing issues had any of default forms and we found that in fact all of them were comprised of only custom forms. Based on this information we have immediately created a set of test cases that eventually replicated the issue in the exact form and manifestation that was initially reported. At this time development is addressing this scenario and a fix is in progress that will be deployed in all live instances as soon as possible.

This has been a challenging investigation to identify the issue due to the aspects described above. We unreservedly apologise for all the troubles this has caused you and your users. If you have any queries or questions please let us know.

[Paul H]

Any progress on this issue please?

 

[Victor]

@Paul H the fix mentioned here was deployed Thursday (04/08). As far as we know and based on feedback from affected users, the fix addressed the issue(s).