How to control Case ID?


Hi Community!

Actually I use Bonita Server with Wildfly 7.5.4, I would like to know how I can control the increase in ID in cases because every time it restarts server the ID increase in 1000 maybe it just grows in 10.

If anyone can help me with that I would appreciate it.


Submitted by delphine.coille... on Fri, 03/20/2020 - 11:48

Hi Claudia,

The caseId is the unique attribute of a process instance (Case) which takes Long value. Each time you launch a process it will create a case with a unique ID (generated by Bonita engine) In order to manage cases and you can either use engine API or REST API bpm API ( to search for your cases or delete instances for example.

Though I have a question: when you are logged as an admin and go to the admin portal, what is the state of your cases? Don't you have cases in failed mode?

1 answer


Not sure about what exactly you are wishing to do in regards to id management, but chances are you can't do anything.

The ids for all the objects in the database are managed in memory by a sequence manager. When the engine starts, it requests in the database a range of available ids, that it saves in memory, and allocates then as required. For example if it gets a range of 1000 for caseids, it will assign X001,X002,X003 and so on to new cases, up to X999 (note that X can be any number). When it reaches the end of the range it does another request in the db, and so on.

This allows to limit the amount of requests in the database, and gives some consistency in ids attribution (caseIds are close to other caseIds, processids to other processIds etc.).

The drawback is that, while the range is attributed in db, it is accessed in memory. So when you restart the server, the engine will request new ranges, that will be different from ranges it got before the shutdown. It's a technical detail, and therefor a non modifiable behavior.

The only thing that you can do is modify to set a range size for each objects (the bonita.platform.sequence.x parameters). The main use case is, if for example your processInstance table doesn't have a lot of activity, you can reduce the range from the default 20000 to something you deem more appropriate (at the price, if you are mistaken, of additional requests in the db in production). It won't allow you to have continuous numbers after a server restart however.