Add creation time to process instances

[ThorbenLindhauer]

This issue was imported from JIRA:

Field	Value
JIRA Link	CAM-10825
Reporter	EQya0w4 What is this name? This pseudonym name was generated based on the user name in JIRA to protect the personal data of our JIRA users. You can use this identifier to search for issues by the same reporter.
Has restricted visibility comments	true

---

Context

User tasks have a "created at" timestamp.
I'm wondering why this is missing on other objects, most notably process instances.

You can access the data from the history, but it would be more efficient to just have it on the object itself.

User Story (Required on creation)

As a operator, I want to see the process instances create time.

Functional Requirements (Required before implementation)

• Update create and update sql scripts
• Java, REST, and Open API

Technical Requirements (Required before implementation)

Limitations of Scope

Hints

Links

Breakdown

Pull Requests

Preview Give feedback

No tasks being tracked yet.

Dev2QA handover

• Does this ticket need a QA test and the testing goals are not clear from the description? Add a Dev2QA handover comment

[ThorbenLindhauer]

This comment was imported from JIRA and written by user akwW3DR

What is this name?

This pseudonym name was generated based on the user name in JIRA to protect the personal data of our JIRA users. You can use this identifier to search for issues by the same reporter.

---

For external tasks I have a hacky workaround. I get the lock time by requesting the "lockExpirationTime" and than substract the lock time from the external task client. A lock time or create time without workaround would be awesome.

[ThorbenLindhauer]

This comment was imported from JIRA and written by user EQya0w4

What is this name?

This pseudonym name was generated based on the user name in JIRA to protect the personal data of our JIRA users. You can use this identifier to search for issues by the same reporter.

---

That really is a hack, that results in wrong information in many cases. It only works if the task client locks it right after creation and only until that client finishes processing it.

[ThorbenLindhauer]

This comment was imported from JIRA and written by user akwW3DR

What is this name?

This pseudonym name was generated based on the user name in JIRA to protect the personal data of our JIRA users. You can use this identifier to search for issues by the same reporter.

---

Sure to get the create time it doesn't work like that. However if you only want to get the lock time for the current task in your external task client code it works quite well, because the "lockExpirationTime" is calculated when the "fetchAndLock" happens. fetchAndLockTime = lockExpirationTime - externalTaskLockDuration

[ThorbenLindhauer]

This comment was imported from JIRA and written by user @koevskinikola

---

Hi EQya0w4,

Thank you for the feature request. Adding a created_at column for runtime Process Instances/Executions and External Tasks would lead to duplicating data since, as you say, it's already present in the historic tables.

Can you provide more information on the use-case, and what is the gain of adding this information in the runtime table, or how much is the current overhead when querying the historic data?

Best,
Nikola

[ThorbenLindhauer]

This comment was imported from JIRA and written by user EQya0w4

What is this name?

This pseudonym name was generated based on the user name in JIRA to protect the personal data of our JIRA users. You can use this identifier to search for issues by the same reporter.

---

For process instances our main use case is to retrieve a list of active process instances sorted by creation time.
For this we could theoretically use the history, but the history space is much larger and there is no index on start_time there.
Further the history is not guaranteed to be present (if people choose to omit it from being created in the first case)
We can work around it, but we do have certain process definitions where we intentionally do not create history.

Everything is more complicated with external tasks.

"act*hi_ext_task_log_pkey" PRIMARY KEY, btree (id*)
"act*hi_ext_task_log_proc_def_key" btree (proc_def_key*)
"act*hi_ext_task_log_procdef" btree (proc_def_id*)
"act*hi_ext_task_log_procinst" btree (proc_inst_id*)
"act*hi_ext_task_log_rm_time" btree (removal_time*)
"act*hi_ext_task_log_root_pi" btree (root_proc_inst_id*)
"act*hi_ext_task_log_tenant_id" btree (tenant_id*)
"act*idx_hi_exttasklog_errordet" btree (error_details_id*)

We can't efficiently retrieve a single task, becuase there is no index on the task id.
We can't get a list of active tasks with creation date because they are stored in different log entries. We would have to get all start and end events and manually find out if a task has a start log entry but no end log entry.

Having the timestamps on the active instances (the ones we need to operate on) would make life much easier for us (let us actually implement features...)

[ThorbenLindhauer]

This comment was imported from JIRA and written by user @koevskinikola

---

Hi EQya0w4,

Thank you for the nice explanation. I understand the use-case and requirement, so I will forward it for decision making.

Best,
Nikola

[ThorbenLindhauer]

This comment was imported from JIRA and written by user @ThorbenLindhauer

---

Hello EQya0w4,

We have discussed this feature request in our product management and agree that this would be a nice addition to the runtime APIs. Would you be interested to make a contribution?

Best regards,
Thorben

[Nandanrshenoy]

@ThorbenLindhauer ,
I would wish to contribute towards this feature. Kindly let me know If I proceed?
For now I could see that this fix is needed for Process instance and External task.
Could you please confirm on the same.

Thanks and Regards,
Nandan Shenoy

[yanavasileva]

Hi @Nandanrshenoy,

Thank you for your interest.
Create time for external tasks has been already added with #3896.
So I adjusted the ticket to include process instance only for now.
Feel free to continue with a contribution for this.

Best,
Yana