Create Activiti process engine without h2 or any database

[ksianipar]

I want to know if I can build ProcessEngine without any of the databases (including h2). 
From what I see on below code, it still uses the h2 memory database.
I am not familiar with h2, but it seems that Activiti requires it.

ProcessEngine processEngine = ProcessEngineConfiguration
    .createStandaloneInMemProcessEngineConfiguration()
    .buildProcessEngine();

Is there a way that I can avoid using non-database just to run my process definition?  My workflow is a non-user mode process, so it's a chain of service tasks or (some custom service tasks).

Please let me know if I miss something here.

Thanks in advance.
Konrad

PS: I really like the framework and I am planning to use this for my production codes :-).

[jbarrez]

No, Activiti always requires a database.

There is a lower level API without database, but you loose all the benefits of BPMN2.0. Plus it's not part of the stable public API.

[smirzai]

could you please provide any reference or link to the above mentioned API ?

[trademak]

Hi,

Not really, you would have to go through the source code.
But would it not make sense to use at least an in-memory database?

Best regards,

[cpotter1]

Why does the basic design of Activiti require a physical implementation strategy?  Seems like poor design to me…  seriously…

[ronald_van_kuij]

The statement about poor design is kind of bold isn't it?  And what about physical? in-memory db is not physical is it? The source is open, you can write whatever physical noSQL based implementation and use it and nobody ever said Activiti would not be open to have a more abstract persistence layer, but if there is no need for something do not implement it… Lean you know…

[cpotter1]

in-memory vs not-in-memory is not really an abstraction; its just plain datasources / jdbc.  The fact is there is only one physical strategy.

What we/I am talking about here is nothing more than a interface facade over the sql, parameterized according to the arguments needed to go to the sql query (or other) based implementation… Hell, you can even have the interface methods declared to return sql result sets (http://docs.oracle.com/javase/6/docs/api/java/sql/ResultSet.html) since it's at least an interface-based abstraction.

This approach is lean + flexible.

ps. I didn't intend tone; but it is frustrating because the burden of this is now on my shoulders.  And considering many others have asked for this too it doesn't seem to me as an outlandish request.

[ronald_van_kuij]

I never said not-in-memory vs in-memory was an abstraction, it is not. I is just physical (persistent on disk) vs non-physical. The (additional) abstraction could be implemented yes, and the 'many' requests by others for different persistence is kind of out of perspective, 5 vs thousands(?) of happy users?

And yes, if you want something like this now, including creating the interfaces, make it configurable, write the testcases for it, write the documentation etc (why implement interfaces if something was not meant to be pluggable) the burden is on you, or hire someone to implement it, or… Sorry for that, but it is open source and contributions are always welcome.

And it might be that some work is already done, but not open/ready yet, since some preparations are going on to run activiti 'in the cloud'