As I mentioned, many webflows have a series of screens, each of which builds on the preceding screens. The example I gave showed that the first couple screens would select an employee id and department id. This might be a good save point in the webflow because a relationship was made (EMP -> DEPT). If your data model and pageflow are designed appropriately, you should be able to progress through the webflow without running into FK constraint violations. Think of the webflow as a series of screens in which you are collecting bits of data in a linear fasion as needed. Submission of the first screen might create a record in a webflow process table, setting it's status to in-progress or whatever. Each subsequent screen that creates a relationship might add a record to an XREF table...aw, what the hell, here is an abbreviated version of a possible DB implementation for the dept transfer app:
DISCLAIMER: This is off the top of my head and I'm no DBA! TABLE WEBFLOW_PROCESS_CFG webflow_process_cfg_id NUMBER (PK) webflow_process_code NUMBER (optional 'DEPTXRFER', 'TERM', etc.) webflow_description VARCHAR (long name of the process) initiator NUMBER (FK -> EMPLOYEE) completed INT (0 or 1 = incomplete or complete) TABLE WEBFLOW_PROCESS webflow_process_id NUMBER (PK) webflow_type_id NUMBER (FK -> WEBFLOW_PROCESS_CFG?) initiator NUMBER (FK -> EMPLOYEE) completed INT (0 or 1 = incomplete or complete) TABLE EMPLOYEE emp_id NUMBER (PK) TABLE DEPARTMENT dept_id NUMBER (PK) holds dept->employee relationship WF_EMPLOYEE_DEPT_XREF emp_id NUMBER (FK -> EMPLOYEE) Null dept_id NUMBER (FK -> DEPARTMENT) Null webflow_process_id NUMBER (FK -> WEBFLOW_PROCESS) final resting place for the completed webflow. sent off the the workflow or just persisted for the app. TABLE WF_DEPT_TRANSFER dept_transfer_id NUMBER (PK) webflow_process_id NUMBER (FK) Not Null emp_id NUMBER (FK -> EMPLOYEE) Not Null dept_id NUMBER (FK -> DEPARTMENT) Not Null pay_increase FLOAT (+, - or 0) Not Null The XREF tables would essentially be your temp tables, for storing the "save points." They would consist of the FK relationship fields and the related webflow_process_id. The data from all XREF tables relating to a specific webflow process will be "reassembled" next time the manager logs in to complete the webflow. They are then persisted to the WF_DEPT_TRANSFER (final) table, and status is updated in the WEBFLOW_PROCESS table. If, by chance, you have a workflow engine looking for processes to pick up, it would check the WEBFLOW_PROCESS table for processed with status complete. If not, your app may just check the WF_DEPT_TRANSFER table. Again, not a DBA, but that's my deranged perspective. Phew! I'm going home. On 8/31/06, Joel Espinosa <[EMAIL PROTECTED]> wrote:
Thanks for your quick responses. I agree with you Monkeyden, there are differences between two definitions webflow and workflow, I'm planing to code a webflow. Monkeyden your aproach is very close to what I need but... certainly I need to use save points, but if I use them between tables this could afect the database's referencial integrity, am I right? I mean, if I only save data in one table but this table references another one, what will I put in these reference field? I cannot set to null these table's field. Another question was what would I do if the user wants to do more than one webflow at the same time for the same process?, putting the objects in the session scope is not enough, one webflow could overwrite the objects of the other one. Again, thanks to you two. Best regards. -- Ing. Joel Alejandro Espinosa Carra Centro de Tecnología de Semiconductores CINVESTAV Unidad Guadalajara Tel. +52 (33) 3770-3700 ext. 1049 http://www.gdl.cinvestav.mx -- Este mensaje ha sido analizado por MailScanner en busca de virus y otros contenidos peligrosos, y se considera que está limpio. MailScanner agradece a transtec Computers por su apoyo. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
