It is necessary to create incidents to a specific execution ( processInstance).
Technical errors should not be modeled in bpmn - instead we need to create technical errors to a corresponding execution.
This can be done via runtimeService or REST API in Camunda. To provide this feature for integration services we need several steps:
Details
Request a digiwf-integration-incidents topic
Create a new consumer (not with the function router and type mappings) listening to the new topic
Due to the fact we are using DLQs in the integration service we will receive a lot of different message body’s. Therefore we can only access message headers, but this is totally fine. Extract the MessageName and processInstaceId from the headers and create a incident for the corresponding processInstanceId.
Technical hints
create a new incidents package in the digiwf-connector-core module. You can copy the message package. It will be almost the same
create a IncidentService Interface that is implemented in digiwf-camunda-connector module. You can almost copy everything from the MessageServiceImpl.
extends the *-rest module to easily test the whole setup without the need of a sample integrations service that throws errors. You can copy the message package
Description
It is necessary to create incidents to a specific execution ( processInstance). Technical errors should not be modeled in bpmn - instead we need to create technical errors to a corresponding execution. This can be done via runtimeService or REST API in Camunda. To provide this feature for integration services we need several steps:
Details
digiwf-integration-incidents
topicTechnical hints
incidents
package in the digiwf-connector-core module. You can copy the message package. It will be almost the same