In the context of SUPPORT-7897, the consulting team has built a custom solution (based on internal API) that dynamically determines if a call activity spawns a child process instance or directly calls a service.

The last puzzle part for that is to be able to update the CALL_PROC_INST_ID_ of ACT_HI_ACTINST, so that the called process instance is visible in Cockpit in all scenarios.

AT:

• CALL_PROC_INST_ID_ is part of the update mapping of historic activity instances
• The value is only updated if it is not null
• We ensure that we have sufficient test coverage to avoid regressions (see below)

Context:

• We have three types of historic activity instance events:
  • create
  • update
  • end
• Usually, the called process instance id is written with an update event that is generated during execution of the call activity
• Historic activity instance events are always initialized from either runtime state (corresponding execution) or the cache (if a previous event with the same id is still in the cache)
• When the end event is generated, then called process instance is already ended, so its ID cannot be recovered from the runtime state
• When there is a wait state in the called process, then the previous update event is also not in the cache anymore, so we also cannot recover the called process instance ID from the cache
• For that case it is important that we only update the called process instance id if it is not null, or else we overwrite the value with the end event
• Note that adding the update to the existing <if test="eventType == 'update'"> block does not do the trick: If there is no wait state in the called process, then we flush the end event (and not the update) to the database, so the if condition doesn't evaluate to true
• That's why we should ensure that we have sufficient test coverage for the cases