Difference between revisions of "Workflow"
(→See also) |
|||
| Line 29: | Line 29: | ||
* [[Debugger|Code- and Workflow Debugger]] | * [[Debugger|Code- and Workflow Debugger]] | ||
| − | [[Category: | + | [[Category:Workflow]] |
Revision as of 12:50, 3 February 2015
Contents
Overview
Workflows are a powerful way for adapting UBIK® to any needs. They can be used as a replacement for the traditional way of customizing using code, or simply as an additional option to achieve a desired behavior.
What is it?
A workflow is a series of distinct programming steps or phases, where each step is modeled as an Activity. Such activities can be assembled visually into workflows using the Workflow Designer, a design surface that runs within various components of UBIK® Studio.
When to use?
This question isn't easily answered. In fact it is completely up to the user to draw the border between coding and workflows, or to draw a border at all, and one would most likely achieve the same results using either technique. However, here are some recommendations that might be helpful in picking the right turn:
Use coding for...
- resulting behavior that is quite static and doesn't change a lot over time
- very complex tasks
- tasks where performance and resource consumption is an issue
Use workflows for...
- business logic
- dynamic tasks
- tasks where traceability is an issue
- potentially long running tasks that will require persistence
Implementation in UBIK®
UBIK® uses a dedicated class type for managing workflows, the System MetaClass Workflow. Each Instance of this MetaClass represents a distinct workflow and holds the actual definition of the workflow as serialized XAML code. Unlike coded customizing, workflows are not compiled when deploying a new UBIK® customizing version, but are always interpreted at runtime.
