Evaluation of Activiti for a relatively small need

[p_bonanno]

I'm evaluating Activiti (and BPM in general) for some processes I'm developing, and I'm in the "build vs buy" dilemma…
I know little about BPM, so if my questions are already covered, please point me at the right places.
My processes are a series of SOAP webservices. There will not be human interaction, all the services are started by HTTP requests.
Every process is about 5-6 tasks with some async call. At this time, there will be 4 processes (but this number could grow).
Being a financial context, with legal implications, I want to be sure to introduce as few bugs as possible , so I'm evaluating Activiti.
The processes will run inside a web application driven by Spring. I read the Activiti guide and it's integration is crystal clear.
My hope is to implement only the steps (as Java tasks) and then coordinate them with Activiti and get (as much fast as possible!) solid execution, auditing and errors recovery.
Aside technical questiones, I'd like to better understand pros and cons of using a BPM in my case:
1) Is BPM suitable for processes of this size, i.e. has it some drawbacks? (I think of not, but suggestions are welcome)
2) How much is simple to have an audit/report of every single process called in the past, with all relevant data (which I'll save on DB)?
3) How is managed a process fail? Is it possible to define a repeated execution, while it ends correctly? I.e. is this managed by the tool or programming is needed?

Thanks for your help

–
Pietro Bonanno

[frederikherema1]

1) BPM is certainly suitable for processes of this size. If you're processes get more complex over time, you're ready for the growth of complexity. If you write the state-engine yourself, you'll run into issues when requirements change in the future.

2) With historyLevel set to full, all activities that are executed are audited, all tasks completed, all processes run and all variables set in them -> this is all you need for reporting and auditing.

3) There are different ways of implementing retries in activiti (e.g. expected failures due to network issues etc.). You can use the BPMNError approach, combined with error-catching events. This approach handles the error as part of the process and you can model in any number of retries. Another approach is to make the "calls for retry on exception" asynchronous. Activiti will use the job-executor to execute these parts of the process, as opposed to using the calling thead that doe the API-Call. Advantage of the job executor is that, after a failure, it can retry any number of times (by default, it's 3). If it's still failed after those X attempts, the job remains inactive. You can use our API to query for these failed jobs and check out the exception-stacktrace and message. if needed, you can ask Activiti to execute the job again any number of times. The process will be inactive until a successful execution of the job was done..