This exercise shows a process interaction of something us developers and analysts know pretty well: managing requirements in a sprint. It's something that we do everyday, so we don't have to waste so much time explaining the domain, and we can get really fast to the process definitions and how to do each task.
It's also a very good example to run through all the things related to a process execution:
- Human tasks: Writing code, performing QA analysis, reporting bugs and fixing them.
- Automated tasks: Jenkins interactions in a continuous interaction environment, automatic deploys and tests, email notifications, all have a use in this small case
- Process interactions: Each requirement in a sprint is a process by itself, and the sprint runs as a process too.
- Rules execution tasks: We can use them to validate requirements, define initial priorities, and probably a lot more.
You can see that we have all the requirement life cycle defined in this process definition; when developers do it, when it has to be tested, what to do if bugs are found... and finally, the process instance is completed when no more bugs are found in the requirement implementation.
This one is for the sprint:
It's a bit more cryptic, but the objective is simple. It starts and distributes all requirements priorities using rules, then starts each requirement in a process using a script task. The process will then finish when a signal is sent to the instance that either all requirements are completed or the sprint was manually closed.
We will show you a small test case where you can simulate all the steps of these processes, learn how
to make them intercommunicate using different methods, how to run them using custom handlers, and also asynchronous executors, and we will have a lot of fun learning how to add new features to the processes and the runtime. You can download the example from here to play with it in the meantime!