data/logic errors BPM Data/Logic errors due to Unsynchronised/Overlapping operations

[Martyn Houghton]

With increased complexity and volumes of requests on our instance we are seeing more occurrences when operations in the BPM which are sequenced sequentially in the BPM are not completing or committing there changes to the request before the next node is activated, i.e. there operations are overlapping/unsynchronised. Though most of the time this is not critical to the operation of the BPM, but there are times when this is critical as the subsequent node is dependent on the former step.

We have found that with increased volume, we have had more occurrences of issues with the BPM where the logic (decision nodes) or subsequent actions have failed to work as intended or apply the correct route through the BPM due to the update on the request not being completed prior to the next stage.

We have found this occurring in a number of scenarios, some which I have listed below:-

 

Using 'Update Request > Priority' then following it will 'Update Request  > Service Level' will often fail to update the Service Level, as the second step does not pick up the changed priority value. We have had to insert some delaying nodes and a loop to wait for the update to the priority to be committed to the database/cache.

When a request is taken off hold by applying a request or customer portal update, the BPM will resume before the update has been fully applied and the sub status updated as per the setting on the service, which results in get request information node and decision node having the incorrect data, i.e. sub status, so the incorrect logic is applied following the request coming off hold.

Updates to custom fields are not picked straightaway, so when these are injected into objects such as task descriptions, email templates etc, they do not contain the new values.

 

Can we request an enhancement to add a setting to BPM Update and Suspend nodes to force them commit all changes to the database/cache before the node is completed and passes operation on to the next node in the BPM. This can default to the current behaviour but where it is necessary to ensure proper sequential operation this can be enabled.

Cheers

Martyn

 

 

 

 

 

[Martyn Houghton]

This relates to our other post about having the ability to suspend and await expiry form a shorter period than a minute, plus disabling the current linkage to the default working time calendar.

Cheers

Martyn

 

[James.Johnson]

Thank you. I did see that other post and thought it was along the say lines :-)

Thanks again

James

[Victor]

@Martyn Houghton this was/is a very difficult scenario to troubleshoot. However I think we now have one after a bit of effort and development is looking into it.