search

camunda / camunda-bpm-platform

Flexible framework for workflow and decision automation with BPMN and DMN. Integration with Quarkus, Spring, Spring Boot, CDI.
https://camunda.com/
Apache License 2.0
4.03k stars 1.53k forks source link

Add DecisionInstanceID to API response for evaluating a DRD #2749

Open ThorbenLindhauer opened 2 years ago

ThorbenLindhauer commented 2 years ago

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:

### Pull requests
- [ ] https://github.com/camunda/camunda-bpm-platform/pull/4197
kmannuru commented 4 months ago

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: image

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_DEFID column to get the decisionInstanceId and include in the api response.

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

HarishMalavade commented 4 months ago

@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 commented 4 months ago

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_DEFID 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:

Best, Yana

kmannuru commented 4 months ago

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

kmannuru commented 3 months ago

@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