Basically "WorkFlow" management and "e-form" are two separated modules (or functions).
An "e-form" is an entity which allows user to "open/fill/save" content of a form. Each “e-form entity” is a single entity which may be stored as a physical file (or a XML record in database). Additional programming effort is required to store the content to separated fields of a relational database.
"WorkFlow” is build on top of "e-form" with other tasks. For example, for a workflow which related to OT cliam/approval. The work flow involves the following tasks:
- Open e-form of OT claim, fill-in information, save the form to repository and database.
- Submit (eg: through email) the e-form to Staff A for checking
- Checked by Staff A and submit (eg: through email) the e-form to Staff B for approval
- Approved by Staff B and return the e-form to the staff who claim for OT.
The above workflow involves 4 tasks which base on handling and status update related to ONE e-form.
To provide above functions in a flexible e-form system with prelim workflow function, one of the solution will be the following:
The "e-form" provides functions of "e-form filling" with 3 buttons (Submit, Check, Approval) When button of “Submit”, “Check”, “Approval” is clicked, it will call related “Web Services (or function)” of WorkFlow Engine to provide related operation.
- [Submit]: Save e-form as entity and record in database. Update workflow status and send email alert to Staff A
- [Check]: Update workflow status and send email alert to Staff B
- [Approval]: Update workflow status and send email alert to staff who submit the OT Claim.
The e-form interpreter should be capable to enable/disable the button(s) which depends on status of the work flow. Status should be an entity of the XML which represents the e-form.
For simplicity, may consider above is a web-service based solution in which "e-form" is an entity which provides "open/fill/save" operation. Other logic related to workflow operation is done through web service.
