University of Houston - Clear Lake
University of Houston - Clear Lake [pic]
RoboComm v.2.5 :
Rule Based Scheduling for Communication Systems
Capstone Instructor
Dr. Kwok-Bun Yue
Mentor
Mr. Dilhar De Silva
Team Members
Waleed Alsaglab
Manoj Kumar
Srikanth Tasupalli
Rohit Rangera
Fall 2007
November 30, 2007
Acknowledgement
We would like to thank both our instructor, Dr. Kwok Bun Yue, and our Mentor, Mr. Dilhar De Silva for their proper support and guidance throughout the academic semester. We also like to thank to Lab administrator Mr. David Webb who supported us by providing lab and system privileges. We would like to thank all the people who helped us in completion of this project and we might have not mentioned here.
1. Definitions, Acronyms and Abbreviations ………………………………………… 7
1.1 Users ………………………………………………………………… 7
1.2 Technologies ………………………………………………………………… 7
1.3 Business Case for the Product ……………………………………………… 7
2. Analysis ……………………………………………………………… 8
2.1 Use Case Diagrams ………………………………………………………. 8
2.1.1 Convener View …………………………………………………… 8
2.1.2 Invitee View ………………………………………………………… 9
2.1.3 Robocomm Overview ………………………………….……………. 9
2.2 Sequence Diagrams ...…………………………………………………… 10
2.2.1 Create Meeting ……………………………………………………… 10
2.2.2 Invitees Response ………………………………………………………. 11
2.2.3 Convener confirms a meeting ……………………………………….… 12
2.2.4 Convener cancels a meeting ………………………………………….… 13
2.3 UI component and client/server architecture ………………………………… 14
3. Design ………………………………………………………………… 15
3.1 User interface ………………………………………………………….….. 15
3.2 Business Logic…….………………………………………………………… 16
3.3 Database ……………………………………………..…………………. 16
4 Implementation …………………………………………………………… 16
4.1 User Interface …………………………………………………………. 17
4.1.1 New Multi-Time Meeting Proposal …………………………………… 17
4.1.2 Invitee Reply Form ………………………………….. ……………… 19
4.1.3 Convener Meeting Tool ……………………………………………….. 21
4.2 Implementation of JBoss Rules Component ………………………………… 22
4.2.1 Rules implemented by Capstone team Spring-2006: ........………………… 22
4.2.2 Rules implemented by Capstone team Fall-2007: .……………………… 22
4.2.3 Conversion of JBoss 3.0 to 4.0 …………………………………………. 23
4.2.4 Implementation details of JBoss ………………………………………….. 23
4.3 Database Component ...……………………………………………. 24
5 Technologies Used …………………………………………..……………….. 25
6 Progress of Solution …………………………………………………………… 25
6.1 Solution to the problem ………………………………………………… 25
6.2 Design of solution and future enhancement ………………………………… 25
6.3 Implementation issues ………………………………………………….. 25
6.4 Lessons learned ……………………………………………………… …. 26
6.4.1 Research ……………………………………………………… 26
6. 4.2 Time Management ……………………………………………………… 26
6.4.3 Team Work ……………………………………………….. 26
6.4.4 Gained Valuable Experience ………………………………………. 26
8 Conclusions …………………………………………………………………….. 27
9 References ………………………………………………………………………. 28
10 Appendices …………………………………………………………..…………… 29
10.1 Appendix A – Major tasks and Team members contributions ………………… 29
10.2 Appendix B – Classes used in implementation …………………….................. 30
10.3 Appendix C – UML Diagrams in Robocomm …………………...…………… 31
10.4 Appendix D - Database Schema ……………………….…………………. 32
Abstract
Atlink, a software company focused on communication process automation, is in the process of developing and testing of RoboComm. RoboComm is a project to build an effective communication system to schedule meetings among mobile participants, using different communication devices through rule-based technologies. RoboComm aims to help in scheduling meetings among participants around the world with the minimal human interaction. It provides the convener (meeting initiator) an intelligent feedback on choosing the best time for a meeting of certain participants. Also, it should enable the invitee to suggest his best available time; this provides the flexibility to both the convener and the invitees. Robocomm uses a rules-based engine, an inference engine which matches details such as meeting times against rules to infer actions whether to organize or cancel a particular meeting. . The output of the project is a tool that can help companies to save a lot of time in scheduling meeting between participants across the world with different time zones and different working hours using a user-friendly interface running on the web
The project uses Zimbra, built on AJAX Toolkit as a user-interface for a convener and an invitee. Our team used Firebug and JPDA as debuggers for Zimbra. It also includes an installation of PerlScript which acts as a SMTP for Zimbra Server so that the implementation is restricted to a single machine. The current functionalities of the project were developed by Fall 2006 and Spring 2007 capstone teams, and the work of team5 Fall 2007 will be a continuation of the project by adding more rules and web user interface enhancements.
The goal’s of this project is to refine the prototype and to enhance both its functionality and usability. Our team developed a new meeting proposal option which supports multiple meetings with different times in a view .Also, we developed a reply functionality which allows an invitee to suggest a new meeting time apart from accepting and declining a meeting proposal. In this project to effectively schedule meetings, we implemented business driven rules where a Convener checks whether the number of invitees attending are greater than or equal to a threshold and schedules the meeting to a different date if it fails. We also implemented some time-based rules which check if a meeting time falls in office hours and does not organize a meeting if the condition fails
Introduction
Scope
The scope of this project is to develop a prototype for rule based scheduling communication systems. This project is a continuation of version 1 & 2 developed by Capstone groups of Fall 2006 and Spring 2007. This is being developed by Capstone Group #5 – Fall 2007 of the University of Houston, Clear Lake. Robocomm aims to schedule meetings between communication devices which are in different international time zones. It uses a rule based technology in which rules get triggered depending on meeting requirements and schedule meetings as a result of its action. The major requirements of the project include adding more rules to the existing set. These rules are time-based and business driven providing an intelligent feedback to a meeting organizer in case a meeting cannot be scheduled. Also, it provides real time manipulating capabilities for an organizer to pick a different meeting time so as to organize the meeting.
We have created a new meeting proposal view where a user can create multiple meetings with different times, and a reply view which allows an invitee to accept or decline a meeting. It also gives flexibility an invitee to suggest the convener a new meeting time in case an invitee cannot accept a particular meeting time. In RoboComm, if a meeting fails as the number of invitees available does not reach a threshold; the Convener has the ability to decide when to schedule a meeting depending on the number of invitees available. The Convener also schedules a meeting to make sure that a mandatory user attends a meeting.
Our team used Zimbra UI. We modified Zimbra according to our requirements. The user interface is modified by changing the MVC architecture to form new menu buttons, views and event handlers for various views .The Capstone group Fall 2006 used an AJAX based web application as a user-interface. Using Zimbra UI makes the application better as it uses AJAX Toolkit which reduces the programming work to a great extent and increases portability across browsers. The Capstone group Spring 2007 implemented only one requirement. The rest of the requirements are being implemented by this project. The functionality of the system is to add more rules to the existing set of rules that are time based and business driven
1 Definitions, Acronyms and Abbreviations
1.1 Users
Convener: A convener is an individual who initiates the meeting or conference
call and is responsible for providing the specifics.
Invitee: An invitee is an individual invited to attend a particular meeting or conference. He may specify his own preferences, in terms of date or time, in attending the meeting.
1.2 Technologies
Zimbra: Zimbra Collaboration Suite is a groupware product created by Zimbra Inc. This project uses an open-source version of Zimbra as a user interface. Zimbra provides facilities like shared calendars, e-mail and search functionalities to schedule a meeting. It also supports functionalities such as tooltips, draggable items and right clicks on a calendar view. It uses AJAX Toolkit as a library.
AJAX Toolkit: This is a 100% JavaScript Toolkit designed for developing browser based applications. It uses various functionalities provided by a browser like CSS, JavaScript programming language to build a rich user-interface and provides elements to develop client-server applications.
JBoss Rules: This is an open-source rule based software system that derives an action by automating rules on input data. This Rule Base inference engine evaluates input elements like meeting times against a set of business rules and triggers an action if the rules evaluate it to be true.
1.3 Business Case for the Product:
Robocomm is being developed for Atlink to enhance functionality of its existing rule based scheduling system. Upon successful completion, Atlink will integrate this prototype with an EVI system at its local office.
2 Analysis
2.1 Use case diagrams
We used use case diagrams for convener view, invitees reply and robocomm overview to explain the functionality.
2.1.1 Convener
[pic]
Diagram: 1
The above use case diagram shows the functionality required of a Convener. The Convener who organizes a meeting sends an invitation to a list of invitees. The Convener specifies the percentage of invitees attendance required for the meeting to be successful. It also assigns preference to different invitees specified as ‘Mandatory’ or ‘Optional’. In order to organize a meeting, a ‘Mandatory’ invitee needs to be present where as an ‘Optional’ user does not. The
Convener after receiving replies from invitees confirms a meeting time depending on whether the mandatory users are present and if the percentage of invitees attending the meeting exceeds a threshold. If the conditions fail to satisfy, the convener can cancel the meeting or change the required attendees’ percentage.
2.1.2 Use case diagram – Invitee
[pic]
Diagram: 2
This use case diagram defines an invitee. An invitee receives a meeting proposal from the Convener. The proposal consists of different meeting times. The invitee can accept or decline these meetings. Also, he can suggest a new time to the Convener as per his convenience.
3. Use Case Diagram – Robocomm Overview
[pic]
Diagram: 3
This specifies an overview of required functionality of RoboComm. A Convener interacts with an Invitee through Zimbra. The Convener proposes a meeting consisting of different meeting times. He interacts with JBoss to check whether the meeting satisfies a set of business constraints and gets a reply back to cancel the meeting if constraints fail. The invitee can accept, decline or suggest a new meeting time. The Convener in turn interacts with JBoss to check if a mandatory user fails to attend the meeting and cancels the meeting if the condition applies. He also assures that the number of attendees is equal to or exceeds the attendees percentage specified before a meeting. Finally, the Convener confirms a meeting if all the conditions apply.
2.2 Sequence Diagrams
We used sequence diagrams to explain the flow of control in meeting creation, invitees response to a proposal, confirmation and cancellation of a meeting by a convener
2.2.1 Create Meeting:
[pic]
Diagram: 4
This sequence diagram specifies the flow of control between a Convener and Invitees for a meeting proposal. The Convener adds invitees and assigns the preferences as mandatory or optional. On saving the appointments to the server, the server sends an invitation to the invitees through e-mails.
2.2.2 Invitee’s response:
[pic]
Diagram: 5
This diagram explains the flow of control between an invitee and a convener when the invitees reply to a proposal. The invitee views the meeting proposal through Zimbra UI and responds to it. He can accept the proposal, in which case, control directly transfers to the server. In case of a denial, the invitee can suggest a new meeting time. This new meeting time is sent back to the convener
2.2.3 Convener confirms a meeting.
[pic]
Diagram 6
The Convener views the responses of all the invitees and selects a time which satisfies all the business constraints. Then it confirms the final meeting time and sends it to Zimbra Server which in turn e-mails to all the invitees.
2.2.4 Convener cancels a meeting:
[pic]
Diagram: 7
This diagram shows how control transfers between a Convener and an Invitee when a meeting is cancelled. The Convener after viewing feedbacks from the JBoss and invitees cancels a meeting if required. This is sent as an e-mailto all the invitees.
2.3 UI component and client/server architecture
[pic]
Diagram: 2
RoboComm Architecture
[pic]
Diagram: 3
3 Design
3.1 User interface
3.1.1 New Meeting Proposal:
We designed this view for a Convener to create a new meeting. We designed multiple meeting proposals using shared calendars in Zimbra. We considered each calendar as a separate meeting. A meeting consists of different appointments where all the appointments have same properties in every aspect except the meeting time. We disabled the option of creating an appointment in multiple calendars at same time. This is done to separate the calendars logically. After finalizing the meeting proposal, the convener should be able to send an invitation to all the invitees of that meeting.
3.1.2 Invitees Reply Option :
This view is designed for an invitee to reply a meeting proposal. We designed a reply option as a webpage having all the details of a particular meeting such as the start and end times of each appointment in a meeting. The user has options to accept or decline these meeting times. This ‘reply’ page communicates to a convener so that he can receive the meeting time details and reply back his availability.
3.1.3 Convener – Know when to meet tool
The Convener sends meeting requests along with start and end times to all the invitees in a meeting. It confirms meeting time depending on replies of invitees such as the percentage of invitees attending and whether all the mandatory invitees will attend the meeting. It communicates with JBoss to implement these business rules.
3.2 Business Logic
We applied some business constraints to the meeting such as a meeting should be held only within office hours; it should not be held on weekends. The percentage of invitees who the meeting proposal should equal or exceed a threshold. We also checked whether all the mandatory invitees will attend the meeting. JBoss communicates with the Convener of a meeting to get the meeting details like the list of invitees who accepted
the proposal so that it can verify whether a mandatory user attends a meeting. Also, the times at which an invitee accepts to check if the constraints imposed on the invitees are being violated at that particular meeting time.
3.3 Database:
ER diagram of database:
[pic]
Diagram 8
The database design is as follows:
1. We designed a database such that there is an entry for a meeting. Associated with a meeting, there are entries for a unique id of the meeting, number of invitees, number of accepted members and number of declined members for that particular meeting.
2. Every meeting has some invitees; we have an entry for invitees related to a set of entries which represent its properties such as name, email and role of an employee. This entity for invitees is related to the meeting.
3. A meeting has multiple proposals having different meeting times. We designed a meeting time associated with a set of entries for that particular meeting-time such as deadline time for a meeting, meeting-id to identify the meeting, percentage of invitees attending at that meeting-time.
4. For every proposed meeting time, an invitee replies. We have an entry in database for invitee’s reply associated with a set of attributes like email-id of the invitee who replies, appointment id for that particular meeting and reply of an invitee whether he accepts or declines.
4 Implementation
4.1 User Interface
4.1.1 New Multi-time Meeting Proposal:
We implemented the meeting proposal as a menu button on the toolbar. When clicked on the menu-button, it invokes a new calendar view. A dialog box pops-up, which prompts the user to enter new meeting details. This is shown in Diagram 9.We removed a check box Synchronize the calendars on the dialog box as it is not related to Robocomm. We changed the title of dialog box so that the invitee considers the calendar view as a new meeting view.
[pic]
Diagram 9
When the view opens, the new meeting is checked and all the other meetings are unchecked as shown in Diagram 10. This is to display only the current view. As all the appointments in a meeting have same properties except the meeting time, details such as appointment name and other properties are assigned from meeting name. The convener sends an e-mail to all the invitees by right-click on any appointment and selecting the option ‘send invitees’.
[pic] Diagram 10
Implementation details:
1. Uncheck all calendars except the current view
2. Add new appointments in a meeting
Follow comment lines in the code below:
3. Send invitations on right-click on an appointment
An appointment on right-click shows an option to send a meeting request for the present view. The details are included in comment lines of the code
4.1.2 Invitee Reply Form
We implemented the Reply Option as a view which is invoked by clicking a menu-button on a toolbar as shown in Diagram 11. This option is implemented as a jsp page which is integrated with Zimbra. We implemented this by duplicating any file in calendar view of Zimbra e.g. month view, week view and changing any function or a constructor which displays the view so that it opens a jsp page.
[pic]
Diagram 11
Implementation details:
Change the constructor of the view as shown below:
Implementation details of reply form:
This form displays all the meeting time slots mentioned by the convener along with accept and decline options for a meeting time. The invitee chooses the meeting times possible for him and these details are stored in the database.
4.1.3 Convener Meeting Tool:
The Convener View is invoked in the same way as Reply View.
[pic]
Diagram 12
Implementation details:
1. This form retrieves and displays the details of a meeting from a database, such as the meeting times, invitees with their roles and attendees’ percentage required for a meeting. These can be changed to make the meeting possible.
2. This form displays all the possible meeting times with green color, and in case a meeting is not possible, it is indicated with a red color.
3. Whenever the Convener changes the assigned preferences for invitees or the percentage of attendees, the rules get fired and the possible meeting times get changed. The exceptions caught due to firing rules are the causes for a meeting denial. These are displayed along with the declined meeting times so that the convener makes the necessary changes.
4.2 Implementation of JBoss Rules Component
JBoss rules engine matches input facts such as meeting times against a set of rules and results in actions if a match occurs.
. JBoss Rules:
The convener invokes JBoss rules before creating a meeting and after receiving invitees’ replies. We implemented two new rules apart from the rules implemented by Capstone team Spring 2006. The rules implemented by team in Spring 2006 in JBoss 3.0 are transformed to those implemental in JBoss 4.0 by our team.
1. Rules implemented by Capstone team Spring-2006:
1. Office hours check rule: This rule gets fired when a convener sends a meeting request to
invitees. JBoss rules check if meeting time falls outside office hours, taken as 8:00 AM to
5:00 PM in RoboComm.
2. Threshold check: This rule gets fired after invitees reply to a meeting proposal. This rule
checks whether the number of accepted members for a particular meeting time are more than a threshold value. If the convener does not get the required percentage, the meeting can’t be held on that particular time. The convener can cancel the meeting.
4.2.2 Rules implemented by Fall-2007
1. Mandatory, optional member check: This is an attendee’s based rule which gets fired after an invitee replies to a meeting request. This rule checks if a replied member is mandatory or optional. It gets fired if a mandatory member does cancel a request.
2. Weekend check rule: When a Convener sends a meeting request, JBoss rules makes sure that the day is not a weekend. The Convener cancels the meeting if the rule gets fired.
4.2.3 Conversion of JBoss 3.0 to 4.0
1. Working Memory Creation:
JBoss 4.0:
JBoss 4.0 has two working memories, ‘stateful’ and ‘stateless’, unlike JBoss 3.0, which has only ‘stateful’memory. In Robocomm, we changed the creation of working memory given by:
StatefulSession wm = rulebase.newStatefulSession ( );
2. Working Memory Actions:
We replaced some of Working Memory actions in JBoss 3.0.by methods in JBoss 4.0 as shown below:
|Drools 3.0 |Drools 4.0 |
|WorkingMemory.assertObject() |WorkingMemory.insert() |
|WorkingMemory.assertLogicalObject() |WorkingMemory.inserLogical() |
|WorkingMemory.modifyObject() |WorkingMemory.update() |
a)
4.2.4 Implementation details of JBoss:
The data to be validated by JBoss are passed by a convener in form of objects. There are different implementations of classes to reflect the meeting details like meeting times, invitees and so on.
1. 1. Creation of framework to run JBoss rules:
This is created by instantiating PackageBuilder
PackageBuilder builder = new PackageBuilder
PackageBuilder is configurable with the help of new object “builder”.
2. 2. Load rules from a ‘drl’ file:
This loads rules from meetingpossibility.drl which contains all the rules implemented in Robocomm
Reader source = new InputStreamReader (Main.class.getResourceAsStream (“/meetingpossibility.drl)
3. Add rules to a package:
This returns a package of compiled rules
RuleBase ruleBase = RuleBaseFactory.newRuleBase ()
Add newly created rules to the package
ruleBase.addPackage (pkg)
4. Working Memory creation:
This creates a session or working memory to execute rules and load application data which is sent by the convener.
StatefulSession session = rulebase.newStatefulSession ()
5. Insert data into session so as to check against rules
session.insert (meeting)
6. Fire all rules and dispose session :
Session.fireAllRules ()
Session.dispose ()
19 Database Component:
The implementation by Group Spring 2006 has data about the percentage of invitees required, deadlines in a meeting. We implemented the database so as to support the java classes implemented in the server. The database is changed to support operations performed by the objects such as create an application, edit an application, delete an application. Also the new database implementation has data regarding invitees such as invitees who replied to the meeting, invitees who did not reply to the meeting, mandatory and optional invitees.
5 Technologies Used
In this project, we used Java to develop three tier web applications. We used Zimbra AJAX Toolkit to create the UI; MySQL and OpenLDAP as a database server; JBoss Rules 4.0 as a rules engine; and PerlScript acts as a SMTP server for Zimbra Server without this SMTP server the e-mail functionality does not work in Zimbra. We used debugging tools like Firebug for Zimbra Web-Client. This is a plug-in for Firefox and shows sequence of execution of statements in Web-Client. This helps in finding values of variables during execution in a line of code. We also used JPDA (Java Platform Debugger Architecture) to debug ‘servlets’ and ‘.jsp pages’ on Zimbra Server which allows a user to set break points and sequentially execute each line of code.
6 Progress of the Solution
6.1 Solution to the problem
ZimbraUI: We made many changes to the user interface to make it easier for a user to create multiple meetings and respond to a meeting proposal.
JBoss Rules: In implementation, business policies were separated as rules. We implemented rules to provide feedback to a convener while responding to a meeting proposal. We have rules to confirm a meeting depending on whether a mandatory user is available or not and rules to check if a meeting falls on weekend or a holiday.
6.2 Design of solution and future enhancement
The Zimbra UI is modified a lot deal in this project and now it is very easy for a user to create and accept meetings. We think these changes are adequate. Though we implemented JBoss rules, we might need some more to meet the changing business requirements. The databases require modification to agree with the changes in JBoss.
6.3 Implementation Issues
Initially everything is new to us in this project. We have taken time to research about different components like Zimbra, JBoss Rules and OpenLDAP before using them. It was difficult to install Zimbra in the beginning as it used to fail during installation. We removed and installed individually the failed components. As there is no proper documentation for AJAX Toolkit and Zimbra being programmed in 100% JavaScript, we had difficulties in building applications. There was no proper debugger to fix errors in the Web-Client. We used Firebug and JPDA to keep track of the program flow and the values of variables.
6.4 Lessons learned
6.4.1 Research
It is a good experience in learning about Zimbra, JBoss and the usage of databases for a particular project. In this project we spent much time in research and understanding of these components than any other project and met the requirements needed.
6.4.2 Time Management
We learned how to manage time efficiently for a given project. The SCRUM list assigned by our mentor every week helped us. This is a project management approach for software development projects. We had weekly meetings to discuss the team’s progress, upcoming work and difficulties. It helped us to know where the other team members were and improved our communication. The deadlines set for the finalization of project depending on the current progress helped in making the application much better.
6.4.3 Team Work
We learned a lot about team work. We coordinated with each other. Working as a team made this project easy.
6.4.4 Gained Valuable Experience
This project has given us hands-on experience. We learned about JBoss, Zimbra and AJAX Toolkit. We learned how to manage time efficiently and how to work in a team.
7 Conclusions
Scheduling a conference call or a meeting can be time consuming and error-porn process for both the convener and the invitees. Hence , our solution using a rule based approach and having a calendar based user interface such as Zimbra for meetings is very efficient solution. We have successfully modified the Zimbra user interface using AJAX Toolkit and implemented the business constraints for a meeting in JBoss rules successfully.
8 References
The following references have been used in order to understand the underlying technologies used in developing this prototype. These have not been used for our documentation purposes.
1. Dr. Yue, Guidelines for Final Reports,
2. Zimbra open-source system,
3. JBoss Rules 4.0,
4. Java,
5. Software Requirement Specifications for Robocomm
9 Appendices
9.1 Appendix A – Major tasks and Team members contributions
Task Assignments
Following are the major tasks of the project
• Understanding the Zimbra system (Done)
• Modifying the user interface using AJAX Toolkit (Done)
• Implementing JBoss rules. (Done)
• Creating Database in MySQL (Done)
• Integrating all the above three (Done)
• Report and other Documentation which include UML Diagrams (Done)
Also, conversion of previous team Rules from JBoss (version 3.0) to JBoss (version 4.0)
Team member’s contribution
|Team Member |Task |
|Waleed Alsaglab – Team Leader |Assigning tasks to team members, Worked on Zimbra UI, |
| |JBoss , Zimbra Server and on database, technical report |
|Manoj Kumar |Designing all forms and implementation of convener view, worked on executing rules, |
|Srikanth Tasupalli |Modification of Zimbra UI, Technical Report, worked on initial design of meeting |
| |proposal form |
|Rohit Rangera |JBoss and implementation of rules, worked on initial design of reply form, technical |
| |report |
| | |
9.2 Appendix B – Classes used in implementation
9.2.1 Invitee. java:
This class stands for an invitee in a meeting. It has variables and functions that can be used to assign or retrieve details of an invitee in a meeting such as name, address and if the invitee is mandatory.
9.2.2. Meeting. java:
This stands for a meeting in Robocomm. It has values such as subject, meeting-id and required percentage of employees in a meeting. Also, it has functions that return all the invitees and meeting times of a particular meeting in an array.
9.2.3 MeetingTime.java:
This stands for a particular meeting time or an appointment in a meeting. It has
properties such as meetingid start and end times of a meeting time and a value
indicating whether the meeting is possible and an error message of why the meeting is
not possible
9.2.4 Reply. java:
This stands for the ‘reply’ of an invitee at a particular meetingtime in a meeting. It has different functions for retrieving and assigning these values.
92.5 DbReader.java: This retrieves details such as ‘meetingtime’, ‘invitee’ and other details of a meeting from the database
ConvenerFormSvl: This is a servlet for the jsp of a Convener view. It communicates with JBoss rules to check if a meeting is possible. It returns problems associated with failure of a meeting to the Convener through sessions. Also, it stores in a session, the values of meeting times if a meeting is successful.
10.3 Appendix – C : UML Diagrams for the classes implemented in Robocomm
[pic]
Diagram: 11
10.4 Appendix – D: Database Schema:
10.4.1 invitee (Field, Type, Null, Key, Default, Extra)
|Field |Type |Null |Key |Default |Extra |
|meeting_id |int(11) |NO |PRI | | |
|email |varchar(50) |NO |PRI | | |
|name |varchar(100) |YES | |NULL | |
|role |varchar(5) |YES | |NULL | |
This table stores invitee’s details.
10.4.2 inviteereply (email, appt_id, reply)
|Field |Type |Null |Key |Default |Extra |
|email |varchar(50) |NO |PRI | | |
|appt_id |varchar(50) |NO |PRI | | |
|reply |varchar(10) |YES | |NULL | |
10.4.3 meeting
| Field |Type |Null |Key |Default |Extra |
|meeting_id |varchar(50) |NO |PRI | | |
|mailbox_no |int(11) |NO | | | |
|deadline |datetime |YES | |NULL | |
|pct |double |YES | |NULL | |
|confirmed |varchar(14) |YES | |NULL | |
10.4.4 meetingtime
|Field |Type |Null |Key |Default |Extra |
|appt_id |varchar(50) |NO |PRI | | |
|Item_id |int(11) |NO | | | |
|Meeting_id |int(11) |YES | |NULL | |
|invited |int(11) |YES | |NULL | |
|accepted |int(11) |YES | |NULL | |
|declined |int(11) |YES | |NULL | |
-----------------------
AJAX Tool kit
Web Browser
Tomcat
Zimbra Client
Zimbra Server
Tom cat
My SQL
Open LDAP
JBoss Rules
Perl Script simulating SMTP
ZmCalViewController.prototype.show =
if (viewId == ZmController.NEWMEETINGPROPOSAL_VIEW)
{
var cc= this._calTreeController.getCheckedCalendars (ZmZimbraMail._OVERVIEW_ID);
for (var i=0; i < cc.length; i++) {
var cal = cc[i];
cal.setChecked (false); }
var newCalDialog = this._appCtxt.getNewMultiTimeMeetingDialog();
this._showDialog (newCalDialog, this._newMultiTimeMeetingCallback); }
ZmCalViewController.prototype._showQuickAddDialog =
function (appt, shiftKey) {
if (this._currentView == ZmController.NEWMEETINGPROPOSAL_VIEW) // if new meeting proposal view
{
var cc = this.getCheckedCalendars ();
if (cc.length != 1) //need to have only 1 calendar checked
{
window.alert ("Error: you have to check ONLY 1 calendar (MultiTimeMeeting)");
}
else
{
appt.setName (cc[0]. getName()); // get details such as appointment name from meeting
appt.setFolderId (cc[0].id); // get folderid details
var size = this.getList().size();
if (size == 0) // if no appointments created,
{
this.newAppointment (appt); // this is first appointment
this.FirstAPPT = appt;
}else {
appt._attendees [1] = this.FirstAPPT._attendees [1]; // load details from other appointments
appt.save ();
}
ZmCalViewController.prototype._handleSendInvitationAction =
Function (ev) {
var share = null;
var actionMenu = this.getActionMenu();
var appt = actionMenu.__appt;
var cc = this.getCheckedCalendars();
if (cc.length != 1)
window.alert ("Can not invitee for more than ONE meeting at a time");
else {
var calendar = cc[0];
var sharePropsDialog = this._appCtxt.getSharePropsDialog();
var atts = appt.getAttendees(); // get invitees of an appointment
sharePropsDialog._granteeInput.setValue(""); // Pops a dialog box with which sends invitations
// to the invitees of an appointment
sharePropsDialog.popup(ZmSharePropsDialog.NEW, calendar, share);
}
function ZmCalMonthViewDup(parent, posStyle, controller, dropTgt)
var cc = controller.getCheckedCalendars ();
if(cc.length != 1)
window.alert("Choose ONLY one calendar");
else if (cc[0].id == 10)
window.alert ("This is not a Multi-Time meeting");
else
{
if (cc [0].isRemote ())
var id = cc [0].rid;
else
var id = cc [0].id;
var email = controller._appCtxt.get (ZmSetting.USERNAME);
window.open ("/MeetingTools/ReplyForm.jsp?meeting_id="+id+"&email="+email, "Invitee Reply Form", "height=800, width=600, toolbar=no,directories=no,status=no,menubar=no,scrollbars=yes");
}
};
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related download
- life cycle plan lcp
- ufe tf meeting minutes 10 19 04
- ch ncar earth observing laboratory
- travel determining compensable time for non
- case study title
- report of the informal advisory committee to the biosafety
- i tech lmi module communication everyday leadership
- university of houston clear lake
- about corporatetime
Related searches
- university of houston student center
- university of houston downtown online degrees
- university of houston education program
- university of houston student services
- university of houston testing center
- university of houston testing services
- university of houston degree programs
- university of houston education major
- university of houston education degree
- university of houston downtown programs
- university of houston masters programs
- university of houston rfp