100 lines
3.2 KiB
TeX
100 lines
3.2 KiB
TeX
|
|
JETServer Programmer's Guide
|
|
|
|
JETServer offers a unique set of tools for rapid application
|
|
deployment of complex workflows.
|
|
|
|
Provides libraries of already created functionality that you can snap
|
|
into your website.
|
|
|
|
Themes and theme management provide huge flexibility in style, feel and
|
|
functionality.
|
|
|
|
Complete work flow pattern design system provides graphical tools to
|
|
create complex data flow logic around described data base entities.
|
|
|
|
\chapter{Work Flow Concepts}
|
|
|
|
Work Flow within a data system can primarily be described as the
|
|
activities required in accessing, maintanining and interacting with
|
|
the data base entities and managing complex activities based upon
|
|
these interactions.
|
|
|
|
JETServer Work Flow allows you to combine various Qs (queues) to
|
|
perform various activities required in supporting workflow operations.
|
|
These Qs are:
|
|
|
|
1. Action Queue
|
|
2. External Queue
|
|
3. Decision Queue
|
|
4. Wait Queue
|
|
5. Process Queue
|
|
6. Event Queue
|
|
|
|
Each Q can have a list of associated reasons for exiting the queue and
|
|
these reasons are linked to the next queue in the flow.
|
|
Interconnecting these Qs is how work flow operations on data patterns are designed.
|
|
|
|
Action Queue (AQ)
|
|
|
|
This Q is the wrapper for the embedded work patterns and is the entry
|
|
point to initiate the work flow pattern.
|
|
|
|
External Queue (XQ)
|
|
|
|
This Q is used to interface a view on the workflows viewpoint. First
|
|
the view is rendered to XHTML and then inserted as the innerHTML on
|
|
viewpoint.
|
|
|
|
Within the placed data is the form for generating a POST request back
|
|
to the viewpoint's associated URL to provide the user response back to
|
|
the XQ and provide the link to the next queue based upon the resulting
|
|
user response from the XQ.
|
|
|
|
Decision Queue (DQ)
|
|
|
|
Decision queues are basically process queues but are designed to leave
|
|
no residual actions to the data and are considered faster. The
|
|
resulting decision is returned as a path to the the next queue.
|
|
|
|
Wait Queue (WQ)
|
|
|
|
Wait queues provide a place to `hang' a work flow unit until another
|
|
event happens or a timeout occurs.
|
|
|
|
If an event occurs and a work flow unit is in the wait queue and the
|
|
wait queue contains a response handler for the event then the workflow
|
|
unit will be forwarded to the linked queue for further work flow
|
|
processing.
|
|
|
|
Process Queue (PQ)
|
|
|
|
Process queues perform a function that produces a persistent result.
|
|
The resulting path can also be determined.
|
|
|
|
Event Queue (EQ)
|
|
|
|
Send a unit to an event queue to tell all waiting work flow units in
|
|
wait queues that the event has occured and to continue processing to
|
|
the the next queue. Only wait queues that have a handler for the event
|
|
type will respond.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
XQ
|
|
Within the XQ you can request action objects that are used to link
|
|
work flow exits. Using buttons and anchors you can progress a work
|
|
flow instance through a work flow patterns.
|
|
|
|
These links are calls to the server using a uniquely assigned id that
|
|
is only active for the duration of the XQ duration on the browser. As
|
|
soon as a link is selected all links associated with the XQ are
|
|
cancelled.
|
|
|
|
The associated work flow unit is moved through the work flow pattern
|
|
based upon the link selected in addition to the browser's form data
|
|
being passed to the work flow unit for processing.
|