BizFlow and WebMaker issues

Hi kidder,

This does seem strange.

I assume when you talk about different cases this is referring to Process Instances in BizFlow?

The base functionality in the WebMaker apps stores the WorkitemContext details for the current Process Instance in Session Cache to enable the required functionality.

Therefore if a user has browser pages open for different Process Instances at the same time, and interacts with both of them, then corruption could occur if they are all using the same browser session.

Could this have happened in this situation?

If this was the case though, I would expect all the data to get corrupted, not just the NINO value. Is this value being stored as a Process Variable? If so, are there any other Process Variables with the same names in both Processes, and are these also getting corrupted?

Do you by chance have any logs from the transactions that caused this corruption? Or are you able to replicate the situation?

Regards,
Gerard

Hi kidder,

Thanks for the additional information.

As the new WM page is opening in the same browser page (ie only ever one WM instance open) then you shouldn't be getting these errors.
My guess would be this is possibly some kind of timing issue where a transaction from the first process instance (possibly due to a partial page load) is happening at the same time as the new load.

Ideally we would need the WM developer logs for the point at which the data gets corrupted to track down exactly why this is happening, but I appreciate this is not feasible for a live system.

While you couldn't clear the cache on every page load as this would break functionality there are a couple of changes I would suggest making to see if they help.


By default the WorkitemContext cache is cleared when new details are detected from BizFlow in the GetWICDetails controller (within the get_BizFlowService-Access_Service_from_GetWICDetails-Controller_rule rule).
I would look to add a new rule to the view-Page_Painter agent as well so that these details are cleared out even earlier when receiving a new request from BizFlow.
Add a rule right at the start of these view rules that performs two Remove Cache actions. One for the 'workitem_context' cache id, and one for the 'bizflow_details' cache id. (Both with Session scope.)
You then need to add a condition to this rule so that it only fires when receiving a new request from BizFlow. To do this you need to check for the presence of a Control value that will only be passed in from BizFlow. (eg /mvc:eForm/mvc:Control/mvc :s essioninfo).

In addition I would also suggest changing the processing in the SaveWICDetails controller so that it cancels with an error if the process ID of the incoming data doesn't match that of the cached data.
To do this I would copy the existing check_session_expired rule, but change the condition so it is comparing the two process IDs, eg by using an XPath like /mvc:eForm/mvc :D ata/WorkitemContext/Process[ID != /mvc:eForm/mvc :D ata/cached_wic/WorkitemContext/Process/ID]
You would also need to change the error message in the set error details for display to user action accordingly.

After making these two changes you can then redeploy and test the project and see if the behaviour is improved. I appreciate that this may not be that easy to determine for this intermittent error though!

Hopefully these notes give you enough information to make the changes, but please let me know if you need more details. You can access these more hidden controllers from the 'Advanced Project Settings...' Design menu option.


If these changes do seem to help, then you may want to look at applying them to other projects, and setting up a new base template that includes them, etc.
For now though, please let me know how you get on with this project, and we can go from there.

Regards,
Gerard

Hi kidder,

From what I can tell that looks ok.
I don't think these should affect the normal behaviour, but I would still recommend doing your usual testing to make sure! :)

Regards,
Gerard

Hi kidder,

Sorry, you are right.
By default only the values on the form will be included in the submitted WorkitemContext structure, so if the process ID hasn't been added as a hidden field then the check would fail as you are seeing.

I guess the easiest way around this would probably be to just add the process ID as a hidden field on the page. (Or adjust/add submission bindings if it is already present.)
Alternatively you could change the Binding Mode configuration for the action, and use the Maintain Additional Data options to keep the complete WorkitemContext data. You would then need to remove the blank structure from the action document.

I'm sorry this means additional changes are required. (I probably should have tested the new rules before suggesting them!)
I do still think it is worth doing though to try and see if it helps resolve the intermittent problem you are seeing.

Regards,
Gerard