05/01/2007
UHCL
THE TIEFLOW WORKFLOW TOOLKIT
Process Definition XML
FINAL REPORT
Version 2.0
INSTRUCTOR:
Dr.Kwok Bun Yue
MENTORS:
Mr. Scott Hetherington
Mr. Abbasi Dhilawa
SUBMITTED BY:
Jigyasa Dubey
Plabita Baruah
Preetha Boisen Paul
Sarjana Singh
Acknowledgement
We thank our instructor Dr. Kwok Bun Yue and mentors Mr. Scott Hetherington and Mr. Abbasi Dhilawa for their support, suggestions and guidance throughout the semester. A special thanks to all the people who helped us in this project.
Abstract
Tieflow Workflow Toolkit is a Web-based electronic workflow system used to automate manual, form-based processes. Tietronix specifies the definitions or templates for these processes in XML according to a proprietary DTD created.
The elements and structure of the Tieflow XML process definition and its DTD were developed prior to the introduction of many of the XML process specification standards currently available. As a result, the Workflow Toolkit process definition does not conform to and is not compatible with any of today’s standards.
Many industrial workflow standards, such as XML Process Definition Language (XPDL 2.0) and Business Process Execution Language (BPEL4WS 1.1), have become available after the creation of the Tieflow process definition DTD. The objective of the project is to create a standalone or integratable component in order to provide the transformation between the Tieflow process definition XML and the industrial standards. XML Process Definition Language (XPDL) is used for exchanging business process definitions between different workflow products whereasBPEL4WS 1.1 is an execution language designed to provide a definition of web service orchestration.
Mapping the elements and attributes of Tieflow with XPDL was the first task in the project. For mapping, Tieflow DTD as well as the Tieflow Architecture was researched in order to understand the Tieflow elements and attributes. After a thorough research it was possible to map the elements and attributes of Tieflow, which were similar to elements, and attributes of XPDL.
Table of Contents
Acknowledgement......
Abstract
Table of Contents......
List Of Figures......
1.0 Introductions And Background......
2.0 Design of the Solution......
2.1 System Architecture
2.2 Class Diagram
3.0 Implementation of the solution......
3.1 Mapping
3.2 Need for Configuration file
3.3 Format of configuration file
3.4 Assumptions in coding
4.0 System Evaluation......
5.0 Conclusion......
6.0 References......
Appendix A(Project Management And Team Information)
Appendix B (Major Tasks And Contributions)......
Appendix C (Sequence diagrams)......
Appendix D (Brief Explanation of the classes)......
Appendix E (Brief Explanation of the methods)......
Appendix F (Installation)......
Appendix G (User Instructions)......
Appendix H ( Source code)......
Appendix I (Acceptance Tests)......
Appendix J (Screen shots)......
Appendix K (The Extended Schema File)
List of Figures
Figure 2.1.1 System Architecture. ………………………………………………………7
Figure 2.2.1 Class Diagram. ………………………………………………………….…8
Figure 2.3.1 Activity Diagram. ……………………………………………………….... 9
Figure 2.3.1 Process and WorkFlowProcess…………………………………………....10
Figure 3.1.1 Comparision of Tieflow and XPDL……………………………………... .12
Figure C.1 Sequence Diagram for AttributeToElementTranslator…………………. …..20
Figure C.2 Sequence Diagram for ElementToElementTranslator…………………...... 21
Figure C.3 Sequence Diagram AttributeToAttributeTranslator……………………….22
Figure C.4 Sequence Diagram ElementToAttributeTranslator…………….…………..23
Figure J.1 Screen shots. …………………………………………………………………61
Figure J.2 Screen shots. ………………………………………………………………....62
Figure J.3 Graphical User Output. ……………………………………………………....63
Figure J.4 Command line Interface Output. ……………………………………………..64
Figure J.5 output_file.xml. ……………………………………………………………....65
List of Tables
Figure A.1 Project Management And Team Information…………………………..18
Figure B.1 MajorTasks And Contributions………………………………………..19
Figure D.1 Brief Explanation of the classes………………………………………..30
Figure E.1 Brief Explanation of the methods………………………………………31
Figure F.1 Contents of the batch file XMLTranslator.bat………………………….32
1.0 Introductions and Background
In any organization, there are a series of activities to be performed by different people to accomplish a piece of work. These activities when automated in full or part are called Workflow. Workflow can be formally defined as “The automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules.” Automation of the actual work increases the efficiency by many times and helps the managers in creating a Virtual Organization.
Tietronix uses a created web enabled GUI based product for its workflow called the Tieflow Workflow Toolkit which is a Web-based electronic workflow system used to automate manual, form-based processes. It takes the Tieflow XML as input and produces the process definition in the flow chart fashion. Since the Tieflow XML was created long ago, it is incompatible with today’s standards. The goal of this project is to develop a translator, which translates the two process definitions and is compatible with today’s standards like XPDL and BPEL4WS.
2.0 Design of the Solution
2.1 System Architecture
Figure 2.1.1 Overall Architecture
In the above figure 5.4, the overall architecture can be seen. The Tieflow elements and the XPDL elements are mapped with the help of the mapping file, which has been developed in XML, which is called the configuration file. This Configuration file and the Tieflow input file would act as the input to the translator, which has been developed in Java, and give the XPDL file as its output.
2.2 Class Diagram
Figure 2.2.1 Class Diagram
In the above figure 2.2.1, it can be seen that there are a total of 8 classes. The XMLTranslator class and the NodeTranslator Class are the main classes. The XMLTranslatorUtility is the helper class and the other five classes i.e., ElementToElementTranslator,AttributeToElementTranslator,ElementToAttributeTranslat-or, AttributeToAttributeTranslator and ExtendedAttributeTranslator are the subclasses of the NodeTranslator class. For details, please refer the Appendix D.
2.3 Activity Diagram
Figure 2.3.1 Activity Diagram
In the above figure 2.3.1, the user selects the input XML file that has to be translated to XPDL file. In XMLTranslator, translate ( ) parses and validates the input XML file. Then, it calls the getTranslatorUtil ( ), which returns instance of XMLTranslatorUtility. It creates two HashMaps, which stores the mapping from the Configuration file. Then translateNodes ( ) creates the instance of NodeTranslator, which implements the recursive algorithm to populate the output XML file.
3.0 Implementation of the solution
3.1 Mapping
The team first performed a high-level mapping analysis between concepts of the Tieflow and XPDL process definition. Then, we did low-level mapping between attributes/elements of both process definition. The categories of matches found are:
Few Elements/Attributes of two standards have the same underlying concepts. Though they have different hierarchy
Figure 3.1.1 Process and Workflow Process
In figure 3.1.1, Process and WorkFlowProcess are the group of activities and subprocess. In Tieflow, ‘version’ under process matches with XPDL’s ‘version’ under ‘process header’, which is the sub element of WorkFlowProcess. So during mapping we identified the elements of XPDL, which do not have any corresponding match in Tieflow, like process header. Likewise, in Tieflow LastModifiedDate has no match in XPDL. TimeUnit and DurationUnit denote the time in both process definitions, though they have different name.
Complexity: The problem in implementing these matches arises due to the insertion of process header in the output XPDL file. To handle this insertion in output file, we added one more attribute ‘only One=true’ in our configuration file(see appendix C).Later on, we are handling this problem in our code using this attribute.
Few elements/attribute have different name but they represents the same concepts
In fig 5.2, Tieflow process and package contains the Role, which provides a layer of indirection between the Activities in the Process definition and the individual users. It also allows the actual users to be selected as the assignees for an Activity at the time the Activity is started. In XPDL same logic is implemented by Lane, which contains the performer. Performer is the one who will assign for that activity. In Tieflow, Role also contains the Assignee Role equivalent to Performer in XPDL.
Figure 3.1.2 Comparision of Tieflow and XPDL
Few elements in Tieflow share their implementation in two different elements in XPDL
In Tieflow Role has attribute roleType, which matched with Type under ParticipantType in XPDL. The hierarchy of these two elements is Proceess::Role::RoleType and WorkFlowProcess::Participants::Participant::ParticipantType:Type. Here in mapping RoleType to Type, we need to skip two elements in hierarchy. To handle such situation , we did coding to take care of these exceptions. Moreover, Role in Tieflow has two matches first is Lane and second is Participants in XPDL. So we are also taking care , when to map it with Role or Participants.
Handling unmatched elements/attributes of Tieflow
We extended XPDL schema to validate the unmatched elements/attributes of Tieflow. Extended Schema include all unmatched elements/attributes their description, default values, types and all other valuable information our mentors want us to preserve. First we developed a code, which directly put all the unmatched elements/attributes from input xml file to the output xml file. At that time our configuration file contains only the mapping of matched elements. We were assuming that if there is no mapping described in a configuration file for any elements/attributes that elements/attributes don't have any matches. We have to just write them out in output file. During implementation and testing of this logic we found the lost hierarchy of elements. We were unable to keep track of elements/attributes respective parent elements. Later on, we decided to include unmatched elements also in our configuration file, for the maintenance of hierarchy. Our second configuration file is combination of matched and unmatched elements.
3.2 Need for Configuration file
We need a configuration file so that we can perform the mapping or translation between the Tieflow and the XPDL 2.0. It is one of the requirements that the translation should be performed in such a way that XML Translator shall provide the capability to add a new language definition without recompiling the component source code. Also the XML Translator shall provide the capability to modify, add, or delete elements or attributes of an already implemented language without recompiling the component source code. This is achieved with the help of the Configuration file. We used configuration file to store the mapping definition. For each elements/attributes of the input Tieflow XML that has direct mapping, the configuration file stores the nature of the mapping (whether the result is an element or attribute), the name of the element or attribute and it also stores the hierarchy of that element or attribute in both process definition. Comparing to the hard coding the mapping logic in the program, this approach is more flexible and portable. Different programs written in different languages for different purposes can process the configuration file.
3.3 Format of configuration file
The configuration file is in the XML format with “Translations” as the root Element.There are many “Translation” tags, which consist of two “NodeName” Children.The former Node Name corresponds to the Tieflow and the latter one corresponds to the XPDL 2.0. The hierarchy of the nodes is also maintained in these tags and is separated by “::”.
In configuration file, the nature of the mapping is mentioned in attribute name ‘translatorClassName’ that refers to the class, which handles the mapping between the respective elements/attributes. Appendix C shows the configuration file ‘Tieflow_XPDLTransformation.xml’
3.4 Assumptions in coding
1) The root node of the output document is treated as a special case. The method createRoot() of the XMLTranslator class handles this situation. It reads the input file root, i.e., the Package element and checks the configuration file content to find the appropriate matching element. Then it creates the root node in the output DOM.
2) The parent node in the input document will always be an element node except for root node. All nodes in the input and output DOM other than the root node have a parent node. The attribute nodes need to be traversed and handled distinctly from the element nodes.
3) Recursive algorithm is used to populate the output document. The protected method createNodeRecursive( ) of the NodeTranslator class in conjunction with the createRoot()::XMLTranslator method and the createLastNode() are responsible for populating the output DOM.
4) The information from the configuration file needs to be fully loaded into the hash maps before translation. A separate utility class – the XMLTranslatorUtility has been created for this purpose. The preloading of the configuration file into two hash maps improves the performance of the XML Translator program.
3.5 Choice of Technologies
We chose JAVA, Jdk1.5 since it was required and the parser used is the Xerces DOM parser that comes bundled with the JDK. In order to view the Tieflow Workflow Process definitions we used the Tieflow Workflow editor. The Enhydra JaWE open source editor was used for the purpose of viewing sample XPDL files. The XML files are viewed with the help of IE 6.0.
4.0 System Evaluation
The developed XML Translator is compatible and integratable with the Tieflow Workflow Toolkit Workflow Editor. It uses the XML parser currently used by the Workflow Editor for any required XML processing. In order to view the XPDL XML file, we used JaWE Enhydra Editor. The translator is a generic translation component. We have used a configuration file i.e. a XML file, which takes care of the translation between the two languages i.e. the Tieflow XML and the XPDL. Any changes if any made in the Tieflow DTD, should be updated in this configuration file rather than the code. Thus maintaining the code would be extremely simple. Future Enhancements are also very easy since changes would be made to this file and not to the code. It can be implemented as a standalone component with command line interface and GUI.
5.0 Conclusion
During the development of the application, we found that it was a very difficult task to perform the mapping between two process definition languages. The Mapping analysis between both the XML process definitions, we found about 20% matching and about 80% non-matching concepts. Having a very few matches, it was a challenging job to perform mapping because we could have ended up throwing some important information from the input XML file. We also found that placing the entire mapping in the configuration file is the best approach to develop the translator so that modification and enhancements in future can be easily incorporated. We succeeded in avoiding the complexity in coding due to the configuration file. The only drawback on the code is that it sticks to the format of the configuration file.
6.0 References
The following references have been used in order to understand the underlying technologies used in developing this application and for the documentation.
[1] XPDL Description PDF:
10-03.pdf
[2] XPDL Specification XSD:
1025_bpmnxpdl_24.xsd
[3] XPDL Resources, Papers, Documents:
[4] API:
[5]An Introduction to Workflow Link:
An_Introduction.pdf
[6] Documentation:
APPENDICES
Appendix A
Project Management And Team Information
Team Lead / Plabita BaruahWebmaster / Jigyasa Dubey, Preetha Paul, Sarjana Singh
System Analysts / All
Testing and Debugging / All
Developers / All
Design and Implementation / All
Technical writing / All
Figure A.1 Team Information
The above table has all the roles of the team members.
Appendix B
Major Tasks And Contributions
System Analysis and Research / AllTask Management / All
Presentation / All
Meeting Participation / All
Web Site Maintenance / Jigyasa Dubey, Sarjana Singh, Preetha Paul
Source Code Developers / All
Testing and Debugging / All
Configuration XML / Preetha Paul, Plabita Baruah
Extended XML / Jigyasa Dubey, Sarjana Singh
Architecture Diagrams / Preetha Paul
Class Diagrams / Sarjana Singh
Sequence/Activity Diagrams / Jigyasa Dubey
Documentation / All
Figure B.1 Detailed Team Information
The above table shows the detailed contribution of the team members.
Appendix C
Sequence diagrams
Figure C.1 Sequence Diagram for AttributeToElementTranslator
Figure C.2 Sequence Diagram for ElementToElementTranslator
Figure C.3 Sequence Diagram for AttributeToAttributeTranslator
Figure C.3 Sequence Diagram for ElementToAttributeTranslator
The above figures i.e. figure C.1,figure C.2,figure C.3 and figure C.1 shows the sequence diagrams. There are four cases as seen. The user selects the input file, which is to be translated. Then the translate( ) of XMLTranslator class is called which calls the NodeTranslator class where the output file is recursively created.
Appendix D
Brief Explanation of the classes
JAVA CLASSESXMLTranslator.java / Core class
Functionality: Parse/validate input XML file. Provide Java API’s. Create instance of the appropriate NodeTranslator class.
XMLTranslatorUtility.java / Helper class
Functionality: Loads the configuration information into two hash maps.
XMLTranslatorFrame.java / Graphical user interface
Functionality: Displays the GUI. Takes user inputs.
NodeTranslator.java / Abstract class
Functionality: Implements the recursive algorithm to populate the output XML file.
ElementToElementTranslator.java / Subclass of NodeTranslator
Functionality: Takes care of element-to-element translation. Implements the abstract method to populate the last node in the output XML file.
AttributeToAttributeTranslator.java / Subclass of NodeTranslator
Functionality: Takes care of attribute-to-attribute translation. Implements the abstract method to populate the last node in the output XML file.
\
ElementToAttributeTranslator.java / Subclass of NodeTranslator
Functionality: Takes care of element to attribute translation. Implements the abstract method to populate the last node in the output XML file
AttributeToElementTranslator.java / Subclass of NodeTranslator
Functionality: Takes care of attribute to element translation. Implements the abstract method to populate the last node in the output XML file.
ExtendedAttributeTranslator.java / Subclass of NodeTranslator
Functionality: Takes care of extended attribute translation. Implements the abstract method to populate the last node in the output XML file.
Figure D.1 Brief Description of classes