Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Get Process Instance API to return Process Definition Key value in the API response #4049

Open
1 task
Nandanrshenoy opened this issue Jan 19, 2024 · 14 comments
Assignees
Labels
scope:core-api Changes to the core API: engine, dmn-engine, feel-engine, REST API, OpenAPI type:feature Issues that add a new user feature to the project.

Comments

@Nandanrshenoy
Copy link

Nandanrshenoy commented Jan 19, 2024

User Story

As a developer I would like to have the process definition key associated with a process instance API response
In the current day scenario to achieve this , I would need to first make a call to the Get Process Instance API(https://docs.camunda.org/rest/camunda-bpm-platform/7.21-SNAPSHOT/{url}/process-instance/{id}) through which the Definition ID can be retrieved and then subsequently make a call to the Get Process Definition API(https://docs.camunda.org/rest/camunda-bpm-platform/7.21-SNAPSHOT/{url}/process-definition/{id}) to retrieve the Process Definition Key.
Adding the PDK value in the Get Process Instance API response will avert making the additional call to Get Process Definition API

Functional Requirements (Required before implementation)

Get Process Instance API response is updated so that it returns the Process Definition Key.

Technical Requirements (Required before implementation)

Update the camunda rest API for Get Process Instance to accommodate the Process Definition key in its response https://docs.camunda.org/rest/camunda-bpm-platform/7.21-SNAPSHOT/{url}/process-instance/{id}

Limitations of Scope

Hints

Links

Breakdown

Pull requests

  1. Nandanrshenoy
@Nandanrshenoy Nandanrshenoy added the type:feature Issues that add a new user feature to the project. label Jan 19, 2024
@Nandanrshenoy
Copy link
Author

I will be involved in incorporating this feature.As such kindly request you to assign this ticket to me.

@yanavasileva yanavasileva self-assigned this Jan 22, 2024
@yanavasileva
Copy link
Member

yanavasileva commented Jan 22, 2024

Hi @Nandanrshenoy,

Thank you for raising this feature.

I will be involved in incorporating this feature.

Great to hear that, please don't forget to link the ticket to your pull request.
Hint from my side, the Java API will need updates as well. Let me know if I can support you during the process of providing the contribution.

As such kindly request you to assign this ticket to me.

The tickets are being processed by the team, no need for an action here.

Best,
Yana

@yanavasileva yanavasileva added the scope:core-api Changes to the core API: engine, dmn-engine, feel-engine, REST API, OpenAPI label Jan 22, 2024
@Nandanrshenoy
Copy link
Author

Hi @yanavasileva ,
Thanks for your support and inputs.
I will definitely touch base with you in case I need some support while making this contribution.

Regards,
Nandan Shenoy

@Nandanrshenoy
Copy link
Author

@yanavasileva ,Could you kindly assign this feature to me, as I have already started working on it.

Thanks and Regards,
Nandan Shenoy

@yanavasileva
Copy link
Member

@Nandanrshenoy
Tickets cannot be assigned to someone outside of the team. For contributions, the pull requests are assigned to the author and reviewed by a team member. The reviewer is responsible to reflect the progress in the ticket status.
So no actions for you, just link the pull request to the ticket once you open it.

@Nandanrshenoy
Copy link
Author

Nandanrshenoy commented Feb 16, 2024

@yanavasileva ,The Initial analysis for the proposed code changes to accommodate Process definition key in Get API Process instance call has been summarized below. Kindly have a look and let me know if I am missing any detail.

Request Flow :
Rest Controller and service Implementation : The flow of request first starts from ProcessInstanceRestService which exposes the ProcessInstanceQuery interface as a REST service.
Package details : org.camunda.bpm.engine.rest
Module Name : camunda-engine-rest-core
Interface : ProcessInstanceRestService

image

Implementation Class : ProcessInstanceRestServiceImpl
Package Name : org.camunda.bpm.engine.rest.impl
Module Name : camunda-engine-rest-core

image2

Code Changes : No code changes would be required at RestController and Service Implementation end.

Resource and ResourceImpl  : 
The call from the rest controller navigates to the resource interface represented by ProcessInstanceResource .The getProcessInstance() method with in the implementation class ProcessInstanceResourceImpl invokes the data mapping layer implemented through Mybatis.

image3

Code changes: The ProcessInstance POJO class which is returned from the Data access layer , needs to have a place holder for the definitionKey.This in turn needs to be mapped to the ProcessInstanceDto for end user to retrieve this value.

DAO layer changes: MyBatis Entity and Data Mapper

The ProcessInstanceQuery interface class allows programmatic querying of Process Instances. In case of Get Process Instance API call based on instance ID, the ProcessInstanceQueryImpl class is only set with process instance ID as a query criteria.

The Mybatis Data mapper file which deals with various operations on Process instances and executions employs the ExecutionEntity class to respond to Get Process Instance API call.

Code changes:
Since the Definition Key is part of ACT_RE_PROCDEF and not present in ACT_RU_EXECUTION table , the mapper data file (Execution.xml) needs to be modified so that the definition key value is shared back along with the existing execution table details. The response of this execution which is of type "org.camunda.bpm.engine.impl.persistence.entity.ExecutionEntity" also needs to be modified to accommodate this additional information.

image4

@yanavasileva
Copy link
Member

@Nandanrshenoy, thank you for the detailed summary. On first read it the analysis look correct.
Let me double check the details before you start with the implementation.

@yanavasileva
Copy link
Member

Hi @Nandanrshenoy,

Before continuing, I want to make sure you considered using the historic data.
If you have enabled the history via configuring the history level in your process engine (history level), it's possible to query for the historic process instance and its response contains the required process definition key, along with the PD id, name and version:
https://docs.camunda.org/rest/camunda-bpm-platform/7.20/#tag/Historic-Process-Instance/operation/getHistoricProcessInstance

Let me know if that will work for you, in that case we can avoid introducing the key in the runtime tables.

Best,
Yana

@Nandanrshenoy
Copy link
Author

Hi @yanavasileva,

Thanks for your inputs.
Querying the history table will give us the process definition key but it’s known fact that calls targeted towards history tables comes with a price i.e performance issues.
If I am interested in only getting the active instances from client(both UI and system), then querying the history table for such active instances will be another additional API and time consuming as it houses both ACTIVE and COMPLETED instances. In our case, UI uses definition key as one of the filters on ACTIVE process instance grid.
In addition to this, we have some requirement where instances may or may not have history enabled where it becomes bottleneck to get the Process definition Key.
I totally understand that, there are filters which I can apply but that doesn’t take away the performance concerns related to when querying History tables.

On the other hand ,with the feature that we are implementing, we are no-where planning to introduce Process Definition Key field in the ACT_RU_EXEC table. The database schema doesn’t change. There is a join that already is happening between the ACT_RU_EXEC table and ACT_RE_PROCDEF when Get Process definition based on Process ID is being executed(Get Process List/Post process List uses the same sql) and we are planning to utilize this feature to just get that addition value of PDK programmatically. Kindly let us know your thoughts.

Thanks and Regards,
Nandan Shenoy

@yanavasileva
Copy link
Member

Hi @Nandanrshenoy,

I agree with the performance concerns when querying the historic tables. I wanted only to lay out all of the possibilities to rule out the need of code change.

The change now is fully argumented, please continue with the contribution as planned. Please check the contribution guidelines: https://github.com/camunda/camunda-bpm-platform/blob/master/CONTRIBUTING.md

Best regards,
Yana

@yanavasileva
Copy link
Member

I am closing the ticket due to inactivity.
We can reopen the ticket, once a pull request is raised on the topic.

@yanavasileva yanavasileva closed this as not planned Won't fix, can't repro, duplicate, stale Mar 12, 2024
@yanavasileva yanavasileva removed their assignment Mar 12, 2024
@Nandanrshenoy
Copy link
Author

@yanavasileva,
The PR against this feature will be raised soon.Thanks.

Regards,
Nandan Shenoy

@Nandanrshenoy
Copy link
Author

@yanavasileva ,
The external PR has been raised.PFB the PR details.
#4222

Requesting your support to kindly review the PR.

Thanks and Regards,
Nandan Shenoy

@Nandanrshenoy
Copy link
Author

@yanavasileva ,
Requesting your support to kindly review the PR.

Thanks and Regards,
Nandan Shenoy

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
scope:core-api Changes to the core API: engine, dmn-engine, feel-engine, REST API, OpenAPI type:feature Issues that add a new user feature to the project.
Projects
None yet
Development

No branches or pull requests

2 participants