Hi,
in 2024.06 we used the property mgmtp.a12.workflows.extension.set-status-event-publishing.enabled=true to enable using DocumentBeforeUpdateEvent during SetStatusOperation. In 2025.06 there is no way to use the DocumentBeforeUpdateEvent. We used this Event to manipulate the persistedDocument in the DocumentBeforeUpdateEvent. In 2025.06 the manipulation of persistedDocument in the Event is ignored, because the SetStatusOperation saves only the field in the DocumentPart. This is a very big problem for us. Have you any help for us?
Kind regards, Mario
Unverified — could not be double-checked with the component team at the time of writing.
The property mgmtp.a12.workflows.extension.set-status-event-publishing.enabled was removed with 2025.06. Therefore, the SetStatusOperation used in the setStatusDelegate can no longer be configured to publish DocumentBeforeUpdateEvent, DocumentAfterRepositoryUpdateEvent and DocumentAfterUpdateEvent, and no replacement property was introduced. See Workflows > Migration Instructions > 2025.06 > Workflows Extension (GetA12).
The extension itself offers no replacement hook either. The events published by workflows-extension (GetA12) are TaskBeforeAssignEvent, TaskAfterAssignEvent, TaskBeforeCompleteEvent, TaskAfterCompleteEvent, ProcessBeforeStartEvent, ProcessAfterStartEvent, ProcessBeforeMessageSendEvent and ProcessAfterMessageSendEvent. None of them covers the set status operation.
What still triggers your listener is the Data Services operation itself. MODIFY_DOCUMENT (GetA12) fires DocumentBeforeUpdateEvent, DocumentAfterUpdateEvent and DocumentAfterRepositoryLoadEvent, and it takes the complete document instead of DocumentParts. Therefore, your manipulation is persisted with the updated document. PARTIAL_MODIFY_DOCUMENT (GetA12) fires the same events. However, it takes DocumentParts, so I would expect the same effect that you see now.
From my point of view, there are two ways to get your manipulation back. Both need a custom delegate, because delegates run in the Workflows Engine and reach Data Services only over JSON-RPC. The Java Client (GetA12) section documents RpcOperationsClient and RequestBuilderFactory for invoking RPC operations.
-
Replace the Set Status Delegate Template by a custom delegate that writes the status via MODIFY_DOCUMENT. Your existing listener then works unchanged, including the manipulation of the persisted document.
Costs: you own and maintain the delegate, and the document is computed and validated as a whole. The setStatusDelegate deliberately does not perform a full validation (GetA12), so that a status can be written into a not yet valid document for Context-Based Validation Rules. If you rely on that, this option changes the behavior.
-
Keep the setStatusDelegate and model the manipulation as a separate step: a Service Task with a custom delegate that calls MODIFY_DOCUMENT after the status change.
Costs: every status change produces two updates and two document versions, every process that changes a status has to model the step, and a status change from anywhere else does not get the manipulation.
If the manipulation has to happen for every status change, I would recommend the first option, because the second one has to be repeated in every process.
Hi,
thank you for the fast response, we will use the first option.
Just for my understanding: in SetStatusOperation line 102 there is a documentService.update, in 110 you do a documentRepository.update, with this, all changes in the document from documentService.update will be overwritten by documentRepository.update?
Kind regards, Mario
Yes. Line 109 wraps the value computed in line 100, not the document returned by line 102, whose return value is discarded. Both writes run in the same @Transactional and DefaultDocumentRepository.update replaces the whole content column, therefore the stored document is the state before line 102, without the metadata update and the computation that Data Services applied.
Important: even on the normal update path only DocumentBeforeUpdateEvent.getUpdatedDocument() is consumed, in DefaultDocumentService.documentBeforeUpdate. getPersistedDocument() is never called in dataservices-core:38.4.3, therefore your listener has to call setUpdatedDocument(...).
In workflows-extension:11.6.5 (2024.06-ext10) the service call and the repository call were an if/else on eventPublishingEnabled, so with the property set to true line 110 never ran. With 12.0.0 (2025.06-ext0) property and branch were removed and both calls run unconditionally.
Hi,
I still haven’t understood what documentService.update is used for, though; it’s actually obsolete
?
Kind regards, Mario
As far as I understand it correctly, the first update call is used to trigger the document update events. However, the operation states that it changes only the value. Due to the computation updates it may change more. Therefore, the repository update is used to write the document with the updated status field only (I ignore the metadata update here, of course).
The reasoning why it is handled this way is unclear for me. The same result could be reached with DocumentComputationStrategy.NO_COMPUTATION in a single call. In addition, the index is written from the computed document while the content column is written from the other one, therefore both differ. AssignTaskOperation, RemoveMetadataOperation and CreateMetadataOperation call documentService.update and do not write a second time.
Note: This is my reading of the source code and it is not confirmed with the Workflows component team.