How many times have you had a way of implementing something buried under layers of classes/source code that’s fairly impossible to explain, understand and much less remember months down the road?
Usually it starts with a question that goes something like, “Hey Bob, how does that rule for TPS reports get applied?” Or worse yet, “There’s a problem in production. We’ve got a meeting in 10 minutes and you need to explain to the ‘Big Boss‘ how the TPS logic works.” And you think to yourself (being Bob after all), “Hmm… what the heck? Why ARE we using TPS reports… but more importantly, what WAS that rule for TPS reports?”
So, you start digging into source code, checking your version control commit logs/comments, fire up the app and start poking around. ANYTHING to jog that memory or stumble across that rare snippet of code that will reveal exactly HOW that TPS report rule gets applied on the 3rd Thursday of the month for left-handed new hires on their second week of orientation.
Implementing your process in a workflow engine like Activiti can lend some sanity to this process. Activiti (and many BPM engines) gives a graphical representation of various workflow states which are very easy (if designed properly) to show to non-technical users, and are also easily modifiable when necessary. With a few well placed comments, the diagram can almost explain itself with no intervention:
enterprise application development
This is a possible workflow for setting up a new employee in TPS training. There’s some branching involved within the training sub-process, and error handling as well (for example, if the employee quits sometime within the training process).
Say your boss wants an additional step added between training and testing. In this case, a new task could be added to the workflow; reset the connections and you’re done.
You might ask, “How are the actual service nodes implemented?” It’s as simple as creating a Java class that implements org.activiti.engine.delegate.JavaDelegate and uses its execute method to begin the unit of work (Note the Spring annotation @Configurable, to allow Spring to manage the bean).

@Configurable
public class SetupTPSCredentialsAndSettingsDelegate implements JavaDelegate {
@Autowired
private TrainingService trainingService;
public void execute(DelegateExecution execution) throws MessagingException, IOException {
// get the employee
Employee trainee = execution.getVariable("trainee");
// Give them permissions
trainingService.givePermissions(trainee);
// So on & so forth
...
}
}

From here you can link up the implementations with the Activiti diagram under “Properties”:
enterprise application development
Of course there’s a lot more depth, but this article is mostly meant to explain why you would want to adopt Activiti in the first place rather than provide a technical deep dive.
More information can be found on the official http://activiti.org website, newly published “Activiti In Action”, and future Isos articles that will delve more into the inner workings of Activiti and how to make it dance the way you’d like to dance.