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.

Google Online Preview   Download