Add DecisionInstanceID to API response for evaluating a DRD

[ThorbenLindhauer]

This issue was imported from JIRA:

Field	Value
JIRA Link	CAM-14608
Reporter	@toco-cam
Has restricted visibility comments	true

---

User Story (Required on creation):

As a Software Developer, I want to see the instance ID of a DRD when executing it as a standalone DRD. This allows me to evaluate a DRD independent of a process with a processID as reference.

Functional Requirements (Required before implementation):

Technical Requirements (Required before implementation):

Limitations of Scope (Optional):

Hints (optional):

Discussion and a solution for Java from Bernd - <Retrieving decision instance id - Camunda Platform 7 Process Engine - Camunda Platform Forum>(https://forum.camunda.io/t/retrieving-decision-instance-id/6039/3)

Links:

• is duplicated by https://jira.camunda.com/browse/CAM-14351
• is related to https://jira.camunda.com/browse/CAM-9769
• is related to https://jira.camunda.com/browse/SUPPORT-10216
• https://forum.camunda.io/t/retrieving-decision-instance-id/6039/11

### Pull requests
- [ ] https://github.com/camunda/camunda-bpm-platform/pull/4197

[kmannuru]

I'm working on this requirement. Can someone please help assign the issue to me.

Goal for the request

Update Evaludate Decision API to include decisionInsanceId in the response. Current API that evaluates DMN decision : POST /decision-definition/key/{aKey}/evaluate Current Response:

Proposed Solution

Add decisionInsanceId as the response parameter

Current api evaluates decision from ACT_RU_DECISION_DEF table for a specific key. So we will have to join ACT_HI_DECINST table on DEC_DEF_ID_ column to get the decisionInstanceId and include in the api response.

Links https://forum.camunda.io/t/retrieving-decision-instance-id/6039/11

[HarishMalavade]

@kmannuru based on the current logic it may not be just id_ retrieval from ACT_HI_DECINST table because the history events are published post evaluation and persisted on the listener which is when the decision instance id gets generated. We may need to generate the id before the events are fired along with other attributes like decision def id, definition key etc. then we can return the same id as part of evaluationResult which will ensure the decision instance id can be used to track history of what was evaluated through API as required @ThorbenLindhauer @yanavasileva interested in your perspective on this

[yanavasileva]

Hi @kmannuru,

I'm working on this requirement. Can someone please help assign the issue to me.

Thank you for your interest in working on this. The tickets are being process by the team and assigned to team members only, no need for an action here . When you are ready raise a PR, put the ticket number to the description. A team member will pick up the PR for a review.

Current api evaluates decision from ACT_RU_DECISION_DEF table for a specific key. So we will have to join ACT_HI_DECINST table on DEC_DEF_ID_ column to get the decisionInstanceId and include in the api response.

I dig into the code and I don't think this is a good idea.

@HarishMalavade is on the right track:

the history events are published post evaluation and persisted on the listener which is when the decision instance id gets generated.

Let me know if you need details about the above but I also encorage you to clone the repository and try it out yourself. Further:

We may need to generate the id before the events are fired

On top of my head, I don't think it's a good idea, the id is the primary key in ACT_HI_DECINST so it's get assigned automatically during the persistence. I can't remember if we do such thing anywhere else.

Other thing to keep in mind is we are talking about history, an option exist that this history is not persisted. (ACT_HI_DECINST is not populated when history level is different from full. ACT_RU_DECISION_DEF is a runtime table.)

At the moment, it's not clear (even after reading the complete forum post), the complete use case where/when the decision instance id will be used after retrieving it. Nevertheless, I imagine without breaking the current design of DMN evaluation and data persistence, the HistoryDecisionEvaluationListener can be extended to log/track the id, similar to the suggestion that Bernd made in the forum post.

Here is reference to the relevant classes if you want to have a look:

• https://github.com/camunda/camunda-bpm-platform/blob/master/engine/src/main/java/org/camunda/bpm/engine/impl/history/producer/DefaultDmnHistoryEventProducer.java#L87
• https://github.com/camunda/camunda-bpm-platform/blob/master/engine/src/main/java/org/camunda/bpm/engine/impl/history/parser/HistoryDecisionEvaluationListener.java
• https://github.com/camunda/camunda-bpm-platform/blob/master/engine-dmn/engine/src/main/java/org/camunda/bpm/dmn/engine/impl/DefaultDmnDecisionContext.java#L95

Best, Yana

[kmannuru]

Thanks Yana for your feedback. I'll work on the changes and share the draft PR for your review. Thank you.

[kmannuru]

@yanavasileva I've raised the PR to fix the issue. Please help with the PR review : https://github.com/camunda/camunda-bpm-platform/pull/4197