camunda / camunda-modeler

An integrated modeling solution for BPMN, DMN and Forms based on bpmn.io.
https://camunda.com/products/modeler
MIT License
1.5k stars 481 forks source link

Leave the default value of Time to Live as NULL #4025

Closed tonny1983 closed 9 months ago

tonny1983 commented 10 months ago

Problem you would like to solve

Currently, the modeler will use a default value -- 180 (days) -- as the time to live in History cleanup. It causes the process engine issuing a warning message:

WARN  org.camunda.bpm.engine.cfg - ENGINE-12016 definitionKey: XXXXXX; You are using the default TTL (Time To Live) of 180 days (six months); the history clean-up feature will delete your data after six months. We recommend adjusting the TTL configuration property aligned with your specific requirements.

even if the value (180 days) is just what I want to use.

In most business environments, the TTL of a process instances is defined by the business organizations who own them or the regulations promulgated by the authorities. It might be better to define the default value in the process engine level, and it is just what the behaviour of the process engine now (the value of historyTimeToLive configuration property will be used if time to live is NULL). If some processes require different TTL with the configuration of the process engine, it can define a new value in the process definition because the value in the process definition will overwrite the configuration value of the process engine.

There has been an issue which suggests to provide a configuration property for modeler which users can change the default value (180) of the TTL in modeler. It is very useful but not enough. As there might not be ONE using modeler in just ONE place, it should be a disaster scene that the first thing for people using modeler is to configurate the default value of TTL in flags.json.

Also, the warning message (Time to live must be defined.) might cause confusions. As just mentioned, if historyTimeToLive is provided in the process engine, the value can be NULL in the process definition. Again, there is another configuration property --enforceHistoryTimeToLive--, and if it's value is false, the TTL can be NULL also.

Proposed solution

  1. Leave Time to Live as NULL in modeler
  2. Modify the warning message to prompt users about the configuration properties in process engine
  3. Provide the ability to set default history time to live value in flags.json as the issue mentioned

Alternatives considered

N/A

Additional context

Modeler ver. 5.17.0 Process Engine ver. 7.20.0

nikku commented 10 months ago

@tonny1983 Please attach important information, including the engine version and modeler version you use.

tonny1983 commented 10 months ago

@nikku I've added the required information under the Additional context.

nikku commented 10 months ago

Thank you. I forwarded your request to the C7 team.

What we wanted to accomplish is to be clear that HTTL is now required (one way or the other, i.e. it will always be there for any of your processes) while it was optional in the past.

We may refine this, based on your and others feedback.

tonny1983 commented 10 months ago

I would like to clarify the current behavior of modeler more detailly.

  1. There is a default value of Time to live which value is 180 (days).
  2. If deleting the value viz. leave it as NULL, there shows a warning said Time to live must be defined.. However, this process defintion can be saved as BPMN file without any problems and can also be deployed to process engine according to the settings of the engine.
nikku commented 10 months ago

@tonny1983 And your feature request is:

tonny1983 commented 10 months ago

@nikku I appreciate for your great Summarizing, and it is exact what I want.

HarishMalavade commented 9 months ago

Hi All...I am working on this issue...I or one of my colleague will raise the PR soon...I was able to fix it in my local

prajwolbhandari1 commented 9 months ago

@tonny1983 Thanks for your clarification

I want to summarize your proposed solution:

1) Leave Time to Live as NULL in modeler - i.e get rid of the modeler's message (Time to live must be defined.) 2) Modify the warning message to prompt users about the configuration properties in process engine. - i.e take out the warning message ? ( can you clarify on this? ) 3) Provide the ability to set default history time to live value in flags.json as the https://github.com/camunda/camunda-modeler/issues/3869 mentioned. i.e initially, the value in flags.json file will be empty, if users want HTTL other than default (engine configuration), they can put the value in flags.json file.

Is this correct? Can you be more specific in # 2 ?

toco-cam commented 9 months ago

Hey there,

FYI - This is why we target to educate users to either define HTTL for each diagram (BPMN, CMMN, DMN) or as a global engine setting. The challenge is that the Modeler is unaware if there is a global engine setting defined for the target engine the diagram is deployed to. We are currently discussing options for improving the user experience for this.

Linking for visibility - the adjusted behavior should be consistent for DMN / CMMN and BPMN - https://forum.camunda.io/t/issue-engine-22004-unable-to-transform-dmn-resource-rules-f-dmn-deploy-error/49675/11

tonny1983 commented 9 months ago

Hi @prajwolbhandari1 Thanks a lot for your summarization which is exactly what I prefer.

For point 2, it bases on the facts that the TTL configuration properties on the process engine side will affect the behavior of the models. The current warning message -- Time to live must be defined. -- should be true if enforceHistoryTimeToLive is not false and historyTimeToLive has not been provided on the process engine side. Otherwise, a model with null HTTL can be deployed to the process engine without any problems.

On the other side, the warning message would cause another confusion that the HTTL should be provided in the model regardless of the process engine settings. As I mentioned, the HTTL setting in the model has the higher priority than the historyTimeToLive setting in the procee engine which is a suitable behaviour that business orgnizations will define a general HTTL for the most of their processes (using historyTimeToLive configuration property) and for some special processes to define their own HTTL in the models. Therefore, in most cases, "Time to live" has been exactly defined in the process engine and there is no need to define it again in the model.

I hope this can claify my meaning, and I'm very glad to provide futher information if necessary.

Thanks for your reply again!

prajwolbhandari1 commented 9 months ago

@tonny1983 Thanks for further clarification. We are working on this and expect a PR soon on both modeler and engine side.

Thank you again.

prajwolbhandari1 commented 9 months ago

@tonny1983 how about this warning message that you mentioned earlier:

WARN org.camunda.bpm.engine.cfg - ENGINE-12016 definitionKey: XXXXXX; You are using the default TTL (Time To Live) of 180 days (six months); the history clean-up feature will delete your data after six months. We recommend adjusting the TTL configuration property aligned with your specific requirements.

This warning is used only when the HTTL is used from the modal not from the engine. Should we get rid of this?

nikku commented 9 months ago

Thanks both of you! I'd ask you to cross-check https://github.com/camunda/camunda-modeler/issues/4062, as this is the direction we want to pursue. It includes making the HTTL configuration in Modeler optional, and hint the user that they shall set it.

The hint will be an informative message that can be disabled via a flag for those that fully configure it through the engine.

nikku commented 9 months ago

Superseeded by https://github.com/camunda/camunda-modeler/issues/4062.

tonny1983 commented 9 months ago

@prajwolbhandari1 The warning message occurs when using default configuration of HTTL in engine and default HTTL value (180) in the modeler. In my opinion, it is just a suitable warning that informs users who may have not noticed HTTL yet, because they seem not to change the configuration.

@nikku Thanks a lot for your kind information. I'm very glad that the new issue really does what I need.

prajwolbhandari1 commented 9 months ago

@tonny1983 yeah I agree. Thank you.