Is the increment of Case/TaskIds for system / background tasks avoidable?

mhoffmann

Hi there,

as far as I know from years of working with Axon Ivy, every process start, regardless of its nature, is leading to an increment of the task and caseid. This leads to a almost absurd drift between real processes on highly used platforms because every display process and every process start seems to be a case or task by nature.

For quite some time I wonder why the architecture of Axon Ivy does not distinct between real business processes and system processes for this.

Further, I'd argue that - from a logical perspective - these ids should be on a process basis and not assigned globally, which is probably why the UUID makes technical sense, but zero sense from a user perspective.

The aspect of security in regard to consecutive numbers is however also the wrong point to argue: An enterprise solution should always prefer proper access control over security by obscurity.

Are there any plans for the future to adjust this behaviour? I've seen a lot of processes with an own identity table for consecutive numbers, but I still feel that this is something Axon Ivy should offer out of the box in the future.

I don't want to sound too harsh, but the whole infrastructure in that regard feels like a huge technical debt.

Christian Strebel

I think you are right that distinguishing between real business processes and system processes could be beneficial. However, even that alone would still not provide a truly suitable business identifier.

You are also right that tasks and cases need a proper security concept based on access control. We are working on that. In this context, the UUID serves a different purpose: while it is not very user-friendly, a securely generated UUID is hard to guess and can help prevent certain types of enumeration attacks.

Today, the usual recommendation is:

Treat the case/task ID as a unique technical internal ID within an engine.
Use the UUID when referencing cases or tasks from external systems, because we can guarantee that it remains stable, even if engine databases are merged or the underlying database system changes.
Introduce a separate business ID as a custom field on the task or case whenever users need readability, consecutive numbering, or domain-specific meaning, and display that value in the portal instead.

That said, I agree that the platform could offer better native support for business-facing identifiers for tasks and cases. The challenge is that requirements in this area vary a lot between projects. If you have concrete examples of how such a feature should work in practice, that would be very helpful input for evaluating possible product improvements.

mhoffmann

Christian Strebel
Thanks for your feedback and your recommendations, which is what we already heed, although I personally still didn't have a use case where the UUID would have made sense on any customer engine, but I understand why it makes sense also thanks to the blog post you guys created back then.

Regarding the business-facing identifiers: When I give this a second thought, I think it's hard to build a generic solution which will suit the needs of everyone. One of our customers needs a specific number for their accounting software consisting of a prefix in relation to the corporate body where every corporate body has its own identity seed. To build this generically would probably be more headache than any use for anyone.

That said, I think that process model case identifiers would be a good point to start so that every process model has its own consecutive numbers to keep them shorter and more human friendly. Regarding tasks, I think that the need here varies way too much to be useful in a generic fashion, at least from what I've experienced. Also to have starts which create a caseId only after e.g. the user dialog was ended in a successful fashion would probably be good in that regard.

In terms of technical ids, I think the current situation is already pretty well solved other than literally everything being a case or task from a technical perspective whereas simple viewing process starts already count as such. From my rather naive point of view, I'd say making process starts attach to a caseId by parameter without creating their own id would be a good thing, especially for viewing processes. It would allow to have the case scope directly available without having to include snippets to distinct it in the view itself. This could be bypassed by using the case in a variable instead of the ivy godobject, but yeah, it's just some redundancy one wouldn't need.

In the end, I can see and understand that making this good for everyone is much more of a challenge than to fulfill the needs of the projects I worked on.