Best practices for handling tasks from elsewhere

[ritchieannand]

I'm looking at Activiti to control a hybrid of people-oriented processes and automated processes, and I'm trying to figure out some best practices.

Is the general tendency to try to put automated processes somewhere controllable by web service, so that a ServiceTask combined with a Java class of some sort can call out to it?

Is it frowned upon to have code controlling the automated process use the Activiti API directly? I mean, with the vacation example in the documentation, I could theoretically do this on a timer:

TaskService taskService = processEngine.getTaskService();
List<Task> tasks = taskService.createTaskQuery().taskCandidateGroup("management").list();
for (Task task : tasks)
{
    Map<String, Object> variables = new HashMap<String, Object>();
    variables.put("vacationApproved", "true");
    variables.put("managerMotivation", "The computer says so");
    taskService.complete(task.getId(), variables);
}
‍‍‍‍‍‍‍‍‍‍‍

Is that a no-no? Is there a nicer way to do the same sort of thing?

Someone here floated the idea of launching/destroying VMs. It would seem that multiple VMs would be better handled by making the process on the VM responsible for asking for work instead of trying to register them somewhere and get a ServiceTask to specifically ask about them, but maybe that would be better?

Excuse my newbishness in the area. It's entirely possible I saw the solution in front of my face as I was reading things but it didn't sink in

Kind regards,

– Ritchie Annand

[jbarrez]

"Is the general tendency to try to put automated processes somewhere controllable by web service, so that a ServiceTask combined with a Java class of some sort can call out to it?"

It depends on your company and its habits. Typically people will use Java Service tasks. But in companies with a lot of REST endpoints, that'll be different upon.

"Is it frowned upon to have code controlling the automated process use the Activiti API directly?"

Again, depends on your use case. Activiti is very open and flexible and does not judge. If the use case makes sense for you, why not.

"…  instead of trying to register them somewhere and get a ServiceTask to specifically ask about them, but maybe that would be better?"

Not 100% sure what you mean by this. I assume you mean polling from a service task?
That could be done (intermediate timer + service task). Or you could use queues that start process instances when something comes in.

[ritchieannand]

Okay - good to know that it doesn't matter too much.

We were discussing the other day about "pull" versus "push" semantics, and liked "pull" (which in this case could be a small program using the Activiti API to query tasks and do things to them) over "push" (which could be, for example, a ServiceTask calling out to one of our machines) simply because it's easier to talk to Activiti than to provide some sort of location service.

I gather from some other threads that people do Activiti clustering much the same way: just run it on numerous machines and have them go looking for work, as it were, instead of somehow registering them somewhere and getting something else to actively coordinate them.

One thing I haven't encountered too much and I don't know if it's appropriate is mixing workflow engines like Activiti with various messaging technologies like MSMQ or RabbitMQ to interact with other programs, but perhaps the state management in Activiti just makes those technologies redundant.

Thanks for the reply, Joram

– Ritchie

[jbarrez]

Probably because there are not that much problems with it, but to my knowledge, people use Activiti with queues like RabbitMq very often