Difference between revisions of "TaskFlow/Best practices"
< TaskFlow
(→Why) |
(→Top 10) |
||
| Line 17: | Line 17: | ||
* Link tasks that do '''one''' thing well together with the supplied patterns to create flows that do '''many''' things well together. | * Link tasks that do '''one''' thing well together with the supplied patterns to create flows that do '''many''' things well together. | ||
* Be '''very''' careful about RPC boundaries (especially when the workflow spans this boundary) and choose how you deal with this in a careful manner. | * Be '''very''' careful about RPC boundaries (especially when the workflow spans this boundary) and choose how you deal with this in a careful manner. | ||
| − | * '''Always''' associate a version with your tasks so that on software upgrades the previously partially completed tasks can be migrated & resumed. | + | * '''Always''' associate a (major, minor) version with your tasks so that on software upgrades the previously partially completed tasks can be migrated & resumed. |
* Return '''serializable''' objects from tasks not '''resources''' (or other non-serializable objects); expect that all returned objects may be persisted indefinitely. | * Return '''serializable''' objects from tasks not '''resources''' (or other non-serializable objects); expect that all returned objects may be persisted indefinitely. | ||
* Clearly name your tasks with '''relevant''' names; names are how restarted flows are re-associated with there previously (potentially partially) completed tasks for resumption or reversion so choose carefully. | * Clearly name your tasks with '''relevant''' names; names are how restarted flows are re-associated with there previously (potentially partially) completed tasks for resumption or reversion so choose carefully. | ||
* Raise '''meaningful''' exceptions to trigger task and flow reversion; the exception which triggered the flow reversion will be persistently stored (and can be referred to later), make sure it is as useful & meaningful as possible for later analysis. | * Raise '''meaningful''' exceptions to trigger task and flow reversion; the exception which triggered the flow reversion will be persistently stored (and can be referred to later), make sure it is as useful & meaningful as possible for later analysis. | ||
* Associate '''accessible''' (not instance/module private) <code>creation</code> functions with a flow so that the surrounding application does not need to be as involved in the flow & task resumption process. | * Associate '''accessible''' (not instance/module private) <code>creation</code> functions with a flow so that the surrounding application does not need to be as involved in the flow & task resumption process. | ||
Revision as of 03:21, 12 October 2013
Summary
Why
Since taskflow creates a path toward stable, resumable, and trackable workflows it is helpful to have a small set of recommended best practices to make sure you as a user of taskflow (the library) maximize the benefit you receive from using taskflow. Certain common patterns and best practices will be listed below to show the what, why and how so that you can maximize your taskflow experience and minimize the pain associated with understanding some of the taskflow key primitives.
Note: this list will likely continue growing as new usages of taskflow emerge (and new features are introduced into taskflow), please feel free to add any of your own below.
Top 10
- Create reuseable tasks that do one thing well; if that task has side-effects undo those side-effects in the
revertmethod. - Clearly define what a task
providesso that future (potentially not yet created) tasks can depend on those outputs. - Clearly define what a task
requiresso thatengine/scan deduce the correct order to run your tasks in. - Link tasks that do one thing well together with the supplied patterns to create flows that do many things well together.
- Be very careful about RPC boundaries (especially when the workflow spans this boundary) and choose how you deal with this in a careful manner.
- Always associate a (major, minor) version with your tasks so that on software upgrades the previously partially completed tasks can be migrated & resumed.
- Return serializable objects from tasks not resources (or other non-serializable objects); expect that all returned objects may be persisted indefinitely.
- Clearly name your tasks with relevant names; names are how restarted flows are re-associated with there previously (potentially partially) completed tasks for resumption or reversion so choose carefully.
- Raise meaningful exceptions to trigger task and flow reversion; the exception which triggered the flow reversion will be persistently stored (and can be referred to later), make sure it is as useful & meaningful as possible for later analysis.
- Associate accessible (not instance/module private)
creationfunctions with a flow so that the surrounding application does not need to be as involved in the flow & task resumption process.
