Sie sind auf Seite 1von 116

e-Appointment Service Development Report

Elsa Estevez Vincent Douwe Tomasz Janowski

type date version location

Technical Report 14 April 2009 1.0 www.egov.iist.unu.edu/outputs

UNU-IIST Center for Electronic Governance

www.egov.iist.unu.edu

UNU-IIST Center for Electronic Governance

Identity: An International Center of Excellence on research and practice in Electronic Governance, part of United Nations University - International Institute for Software Technology, located in Macao, China.

Mission: To support governments in developing countries in strategic use of technology to transform the working of public organizations and their relationships with citizens, businesses, civil society, and with one another.

Activities: Applied and policy research, capacity building, and various forms of development strategy development, software development, institutional development and development of communities of practice.

Copyright 2009, UNU-IIST Center for Electronic Governanc

SUMMARY

SUMMARY
This document describes the development of the eAppointment Service, part of the software infrastructure for Electronic Government, enabling government customers to make appointments for public services. The system enables government agencies to define the locations and working hours for serving their customers. It also allows citizens to make appointments, as well modify or cancel previous appointments. In addition, the system notifies citizens about confirmed appointments. The document first presents the scope of the Macao Data Exchange Gateway Project and an introduction to

the e-Appointment Service. Next, it specifies in detail the software requirements, conceptual and use case models, followed by design, implementation and deployment diagrams. A glossary of terms and some implementation artifacts, such as XML Schemas, configuration files, Application Programming Interfaces and the main Java classes of the Appointment System are included in the appendices. This work was partly funded by Macao Foundation under the e-Macao Program (www.emacao.gov.mo).

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

TABLE OF CONTENTS

ii

TABLE OF CONTENTS
Summary .................................................................................................................................................................................... i Table of Contents ...................................................................................................................................................................... ii List of Tables............................................................................................................................................................................. iii List of Figures ........................................................................................................................................................................... iv List of Requirements ................................................................................................................................................................. v Abbreviations ........................................................................................................................................................................... vi Revisions .................................................................................................................................................................................. vi 1. Introduction .......................................................................................................................................................................... 1 2. Background ........................................................................................................................................................................... 2 2.1. Motivation ..................................................................................................................................................................... 2 2.2. Concepts ........................................................................................................................................................................ 3 2.3. Process........................................................................................................................................................................... 4 2.4. Implementation Approach ............................................................................................................................................ 5 2.5. Challenges...................................................................................................................................................................... 7 2.6. Case Studies ................................................................................................................................................................... 7 3. Requirements ...................................................................................................................................................................... 14 3.1. Functional Requirements............................................................................................................................................. 14 3.2. Non-Functional Requirements..................................................................................................................................... 21 4. Modeling ............................................................................................................................................................................. 24 4.1. Conceptual Model ....................................................................................................................................................... 24 4.2. Use Case Model ........................................................................................................................................................... 25 5. Design .................................................................................................................................................................................. 30 5.1. Architecture Static View ........................................................................................................................................... 30 5.2. Architecture Dynamic View ...................................................................................................................................... 31 5.3. Detailed Structural Design Diagrams ........................................................................................................................... 32 5.4. Detailed Behavioural Design Diagrams ........................................................................................................................ 38 6. Implementation ................................................................................................................................................................... 43 6.1. Overview...................................................................................................................................................................... 43 6.2. Technologies ................................................................................................................................................................ 45 6.3. Improvements ............................................................................................................................................................. 46 7. Deployment ......................................................................................................................................................................... 48 8. Conclusions ......................................................................................................................................................................... 49 References............................................................................................................................................................................... 50 Appendices .............................................................................................................................................................................. 51 A. Glossary .......................................................................................................................................................................... 51 B. XML Schemas.................................................................................................................................................................. 53 C. Configuration File ........................................................................................................................................................... 59 D. Application Programming Interfaces.............................................................................................................................. 64 E. Java Classes ..................................................................................................................................................................... 72

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

LIST OF TABLES

iii

LIST OF TABLES
Table 1: Examples of Public Services Requiring Appointment................................................................................................... 2 Table 2: Main Tasks of the e-Appointment Business Process ................................................................................................... 4 Table 3: Implementation Approach for Main Tasks of the e-Appointment Business Process ................................................... 5 Table 4: e-Appointment Functions ............................................................................................................................................ 6 Table 5: Greece DDYEP e-Appointment Service - Performance Indicators ............................................................................... 8 Table 6: Top-Level Use Cases .................................................................................................................................................. 25 Table 7: Use Cases Manage e-Appointment Service ............................................................................................................ 26 Table 8: Use Cases Manage Supported Services .................................................................................................................. 27 Table 9: Use Cases Request Appointments .......................................................................................................................... 28 Table 10: Use Cases Use Software Infrastructure................................................................................................................. 28 Table 11: Use Cases versus Functional Requirements............................................................................................................. 29 Table 12: Technologies Used by e-Appointment Service ........................................................................................................ 45

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

LIST OF FIGURES

iv

LIST OF FIGURES
Figure 1: Appointment Negotiation Process ............................................................................................................................. 7 Figure 2: Singapore ICA e-Appointment Service ..................................................................................................................... 9 Figure 3: Singapore ICA e-Appointment Service Authenticating Applicants...................................................................... 10 Figure 4: Singapore ICA e-Appointment Service Retrieving an Appointment.................................................................... 10 Figure 5: Singapore ICA e-Appointment Service Appointment Receipt ............................................................................. 11 Figure 6: Singapore LRWD e-Appointment Service Terms and Conditions........................................................................ 11 Figure 7: Singapore LRWD e-Appointment Service Negotiating Time ............................................................................... 12 Figure 8: Singapore LRWD e-Appointment Service Providing Personal Data .................................................................... 13 Figure 9: Singapore LRWD e-Appointment Service Retrieving an Appointment ............................................................... 13 Figure 10: Conceptual Model .................................................................................................................................................. 24 Figure 11: Top Level Use Case Diagram................................................................................................................................... 25 Figure 12: Use Case Diagram Manage e-Appointment Service ............................................................................................ 25 Figure 13: Use Case Diagram Manage Supported Services .................................................................................................. 26 Figure 14: Use Case Diagram Request Appointments .......................................................................................................... 27 Figure 15: Use Case Diagram Use Software Infrastructure .................................................................................................. 28 Figure 16: Architecture Static View ...................................................................................................................................... 30 Figure 17: Architecture Dynamic View for Making an Appointment .................................................................................... 31 Figure 18: Design Class Diagram e-Appointment Common Web Pages ............................................................................... 33 Figure 19: Design Class Diagram e-Appointment Portal Web Pages .................................................................................... 33 Figure 20: Design Class Diagram e-Appointment Agency Web Pages .................................................................................. 34 Figure 21: Design Class Diagram Service .............................................................................................................................. 36 Figure 22: Design Class Diagram Util .................................................................................................................................... 36 Figure 23: Design Class Diagram Communication ................................................................................................................ 36 Figure 24: Design Class Diagram Database ........................................................................................................................... 37 Figure 25: Sequence Diagram for Adding an Agency............................................................................................................... 38 Figure 26: Sequence Diagram for Deleting an Agency ............................................................................................................ 39 Figure 27: Sequence Diagram for Making an Appointment Steps 1 and 2 ........................................................................... 40 Figure 28: Sequence Diagram for Making an Appointment Steps 3 and 4 ........................................................................... 41 Figure 29: Implementation Diagram ....................................................................................................................................... 43 Figure 30: Deployment Diagram A Possible Scenario ........................................................................................................... 48

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

LIST OF REQUIREMENTS

LIST OF REQUIREMENTS
Requirement 1: Administering Agencies ................................................................................................................................. 14 Requirement 2: Administering Services List ............................................................................................................................ 15 Requirement 3: Managing Public Holidays.............................................................................................................................. 15 Requirement 4: Managing Services Data ................................................................................................................................ 16 Requirement 5: Managing Centers ......................................................................................................................................... 16 Requirement 6: Managing Non-Working Days ........................................................................................................................ 17 Requirement 7: Managing Working Hours .............................................................................................................................. 17 Requirement 8: Viewing Appointments .................................................................................................................................. 18 Requirement 9: Exporting Appointments................................................................................................................................ 18 Requirement 10: Making Appointment .................................................................................................................................. 19 Requirement 11: Cancelling Appointment .............................................................................................................................. 19 Requirement 12: Modifying Appointment .............................................................................................................................. 20 Requirement 13: Notifying Applicant ...................................................................................................................................... 20 Requirement 14: Reminding Applicant ................................................................................................................................... 21 Requirement 15: Exchanging Appointment-related Information............................................................................................ 21 Requirement 16: Authenticating users ................................................................................................................................... 22 Requirement 17: Ensuring Confidentiality .............................................................................................................................. 22 Requirement 18: Ensuring Generality ..................................................................................................................................... 23 Requirement 19: Ensuring Interoperability ............................................................................................................................. 23

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

ABBREVIATIONS AND REVISIONS

vi

ABBREVIATIONS
EPS IAS ID IPIM SAFP SI4EG SS UML UNU UNU-IIST UNU-IIST-EGOV XML XSL XSLT Electronic Public Services Social Welfare Institute Macao Sports Development Board Macao Trade and Investment Promotion Institute Public Administration and Civil Services Bureau Software Infrastructure for Electronic Government Health Bureau Unified Modeling Language United Nations University UNU International Institute for Software Technology Center for Electronic Governance at UNU-IIST eXtensible Markup Language eXtensible Stylesheet Language XSL Transformations

REVISIONS
DATE 24/01/2009 09/02/2009 20/02/2009 14/04/2009 RESPONSIBLE Elsa Estevez Vincent Douwe Elsa Estevez Tomasz Janowski SCOPE First version Second draft version Second draft version revised Final version VERSION 0.96 0.97 0.98 1.0

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

SECTION 1 INTRODUCTION

1. INTRODUCTION
The provision of Electronic Public Services (EPS) in terms of number, maturity and accessibility is central for measuring the progress of Electronic Government development. However, the rapid provision of mature EPS cannot be achieved following a case-by-case approach, as it requires the availability of pre-existing components, tools and artifacts that can be used for rapid development, deployment and reliable delivery. These components, tools and artifacts constitute the so-called Software Infrastructure for Electronic Government. Such infrastructure includes design-time artifacts like readyto-customize domain models, guidelines and implementation frameworks that can be used for accelerating EPS development; as well as run-time components and services supporting or realizing common software functionality required for the efficient and reliable delivery of services like submission of citizen data through electronic forms, notifications to applicants, and message exchange between software applications. The availability of such infrastructure is one of the major facilitators for scaling up, rapidly and efficiently, the provision of EPS. In addition to the motivation explained above, main benefits that can be gained by delivering such infrastructure for Electronic Government include: providing standardized services to all agencies based on common technical standards; reducing the costs of developing EPS by individual agencies; promoting the adoption of standards across government; establishing a platform for collaboration between agencies and between public and private sector on EPS and infrastructure development; facilitating the creation of cross-agency EPS; and enabling the integration of applications built with different technologies. Based on the motivation and prospective benefits of providing software infrastructure, the Software Infrastructure for Electronic Government Project was defined by the UNU-IIST Center for Electronic Governance to be executed as part of the e-Macao Program during 2007. The Message Exchange Gateway (Gateway), a major infrastructure service, was delivered by this project. The Gateway enables asynchronous exchange of messages among registered members (e.g. software applications or human users) through dynamically created and subscribed channels. It comprises a core framework supporting plain exchange of messages, and various extensions providing enhanced functionality - such as message logging, validation, transformation, encryption/decryption, mediation, and resource discovery, enabled on the platform. In 2008, the Macao Data Exchange Gateway Project was carried out by UNU-IIST Center for Electronic Gover-

nance. The project aim was to develop a unified message infrastructure based on the UNUs Extensible Message Gateway and DSCs e-DocX Service Unified Macao Government Message Gateway. This integration leverages the strengths of the two solutions to support integration of back-office applications, e-document exchange and multi-channel service delivery. A meeting was held between SAFP, DSC and UNU-IIST representatives to discuss the integration of the Extensible Message Gateway and e-DocX Service. Consequently, it was concluded that it would be simpler for government agencies to use both tools independently of the other, based on specific needs. Subsequently, the objectives of the Macao Data Exchange Gateway Project were revised producing the following: o1) In order to facilitate the use of the Messaging Gateway by Macao Government Agencies, UNU will provide APIs to invoke the Message Gateway services by software applications running on the IT platforms most commonly used by Macao Government. o2) The encryption-decryption extension of the Messaging Gateway will be re-implemented using the certificates provided by Macao Post Office. o3) In order to facilitate the testing of the Messaging Gateway by SAFP, UNU will submit the Message Gateway Quality Assurance report. o4) To develop a pilot e-service enabling the management of customer queues by government agencies. To achieve the former two objectives, a new release of the Gateway was delivered including new APIs and enhanced services. To fulfill the third objective, the Extensible Messaging Gateway Quality Assurance Report [29] was delivered to SAFP. To achieve the last objective, two services were developed Queuing and Appointment. This report constitutes the development report for the e-Appointment Service. The rest of this document is structured as follows. Section 2 introduces some concepts and motivation for providing an appointment service. Section 3 defines the functional and non-functional requirements for the service. Section 4 describes the domain concepts and the required functionality, depicted by the Conceptual and Use Case models, respectively. Section 5 presents the architecture and detailed design of the service. Section 6 and 7 introduce implementation details and possible deployment scenarios. Some conclusions are drawn in Section 8. Finally, a set of appendices include the XML schemas, configuration files, application programming interfaces, and the main Java classes of the eAppointment Service.

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

SECTION 2 BACKGROUND

2. BACKGROUND
The aim of this section is to provide background information related to the e-appointment service in order to get a better understanding of its scope. The section is structured as follows. Section 2.1 (Motivation) presents the need for providing an appointment service as part of the software infrastructure for Electronic Government, by presenting concrete public services delivered by the Government of Macao SAR requiring appointments as part of their business processes. Section 2.2 (Concepts) introduces definitions related to the service. Section 2.3 (Business Process) explains the different stages for delivering the service. Section 2.4 (Implementation Approach) discusses an approach for implementing each of the steps of the service business process. Section 2.5 (Challenges) outlines some of the challenges for implementing and delivering the service. Finally, Section 2.6 (Case Studies) illustrates some examples of eAppointment services.

In order to deliver such services more efficiently - making better use of scarce government resources and avoid applicants queuing; some kind of agreement is required to schedule such visits. These agreements are managed through appointments. Examples of public services delivered by the Government of Macao SAR requiring appointments were extracted from the survey carried out as part of the eMacao Project (Phase I), documented in The State of Electronic Government in Macao, Volume 2 Agencies report [4]. These examples are depicted in Table 1 and explained as follows:

1)

2.1. MOTIVATION
The delivery of some public services requires the applicant to visit a government agency or a centre providing specialized public services. For example, a business owner visits a government agency to sign the establishment of a new company; a patient visits a hospital to receive medical assistance. Likewise, it may also require a civil servant to visit the applicants facilities for example, an official inspecting the sanitary conditions of a new establishment. These visits involve skillful or professional civil servants, like government officials or medical doctors, usually part of the scarce human resources in government.

Health Bureau (SS) provides Out-patient Medical Assistance service. Once the patient is referred to a specialist, a consultation is booked with the specialist for the patient to receive adequate treatment. After paying the visit to the specialist, new appointments may be required for follow-up consultations, as well as appointments for follow-up clinical analysis. Social Welfare Institute (IAS) provides the Financial Assistance to Individuals service. Applicants need to book an appointment to visit the social welfare center to apply for the service. In addition, after the application is complete and the computer records are created for the applicant, a government official visits the applicant to inspect his/her life conditions in order to complete the assessment of the applicants financial status.

2)

Table 1: Examples of Public Services Requiring Appointment


AGENCY SERVICE APPOINTMENT REQUIREMENT SS Out-patient Medical Assistance An appointment with a specialist is booked IAS Financial Assistance to Individuals Applicant books an appointment to visit the social welfare center. Government official visits the applicant to inspect his/her life conditions IPIM One-stop Investor Service An appointment is done with IPIM notary for signing the company establishment ID Sport Medical Services Appointments with physiotherapy are booked for the patient

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

SECTION 2 BACKGROUND

3)

Macao Trade and Investment Promotion Institute (IPIM) provides One-Stop Investor service. Once the submission of all the necessary documentation by the applicant is completed, the applicant makes an appointment with IPIM notary to sign the company establishment. Macao Sports Development Board (ID) provides Sport Medical services. After the patient is received and registered at the center, consultation is carried out and a prescription is issued to the patient. The patientmakes payment and an appointment is booked for the applicant to visit the physiotherapy.

Definition 2: e-Appointment e-Appointment is a service providing an agreement between a service consumer and the service provider for interacting at a certain future time and place (physical or virtual) for a specific purpose. The agreement is achieved through a series of ICT-supported interactions.

4)

Main differences can be highlighted between the last definition and the one provided by Klischewski, such as: 1) e-Appointment is a service all service-related concepts can be applied, like service consumer and provider, business process supporting the delivery of the service, the interactions for providing the service, benefit delivered by the service, etc.; the concrete benefit delivered by the service is an agreement; the agreement involves two parties service consumer and service provider; the agreement is about interacting in the future (i.e. the interaction will take place on a future date and time; the future interaction may take place in a physical place like a hospital; or in a virtual place like an e-forum; the agreement pursues a specific purpose. Since parties know in advance the purpose of the meeting, they are able to fulfill the pre-defined requirements for the future interaction. For example, an agreement for clinical analysis, requiring the patient not to eat during a given time before the analysis takes place; the agreement is achieved through a series of interactions; and the agreement is not restricted to be done through the Internet; it is achieved through interactions supported by ICT.

As illustrated, appointments are included as part of the business processes of various public services. Therefore, instead of developing individual solutions for each of these services, providing an e-Appointment service as part of the software infrastructure for Electronic Government would facilitate the rapid development and efficient provision of such services.

2)

2.2. CONCEPTS
An appointment is an arrangement for a meeting, as defined by the Merrian-Webster Dictionary [2]. Our proposed definition is presented below. Definition 1: Appointment An appointment is an arrangement between parties for interacting at a certain time and place for a specific purpose.

3)

4)

5)

6)

For example, a citizen and the local government who agree to have a meeting in a given place for the citizen to be examined before issuing a driving license. Since we are focusing on appointments which are involved in the delivery of public services, the appointment itself can be treated as a service. Consequently, it can be transformed into an e-service. In order to transform the appointment service into an e-service, the interactions between parties - for making the arrangement, should be supported through ICT. In this way, the concept of e-Appointment emerges. Klischewski defines e-Appointment as an Internetmediated agreement between two or more parties as social subjects (person or institution) to interact at a certain time and place for a certain purpose, such as a business meeting or medical treatment [3]. The following definition of e-Appointment is proposed.

7)

8)

Finally, Klischewski [3] differentiates between the appointment and the booking services. He emphasizes that appointments involve agreements between social actors like persons or institutions; while bookings involve physical resources, like booking a venue, or booking a seat for a government press conference.

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

SECTION 2 BACKGROUND

2.3. PROCESS
In order to better understand the requirements for developing an e-Appointment service, Klischewski [3] identifies three main phases as part of the process for delivering the service Pre-appointment Activities, Appointment Negotiation, and Post-Appointment activities; and provides concrete examples for the interactions taking place during these phases. Aiming at defining the underlying business process for providing e-Appointment services, we follow the three main stages identified by Klischewski. However, we rename the activities as Pre-Application, Application and Post-Application phases, in order to avoid any confusion that could be raised by using the Post-Appointment name to refer to the actions that could take place after the agreement itself (appointment) and not after the date on which the appointment was agreed. In addition, we enrich the model by defining tasks that the two parties service provider and service consumer can ex-

ecute during these phases. The process is depicted in Table 2 and explained below. The Pre-Application phase comprises all the tasks that the parties can execute before negotiation of the agreement takes place. For instance, during this phase, the service provider shall announce the e-appointment service in support of a public service (S); define the locations (places) and working hours (times) where the interactions regarding S can take place; and register some performance measures related to S, like number of customers that can be served at a time; mean time for serving a customer; and how many minutes in advance the service provider would like to remind the applicant about the agreed interaction (reminder notification) time. At the same time, the service consumer can search for the required service (S); find the e-appointment service supporting the delivery of S; and find information about S, like the application form, eligibility criteria, required supporting documents, delivery channels, delivery centers, etc.

Table 2: Main Tasks of the e-Appointment Business Process ACTIVITY Preapplication SERVICE PROVIDER TASKS P1 Announce the e-Appointment service in support of a public service (called S) Define places for S-related interactions Define times for S-related interactions Register performance measures for S, like: - number of consumers served at a time; - mean time for serving each consumer; - notification period of time. Application P5 P6 P7 Negotiate place for S-related interaction Negotiate time for S-related interaction Provide pre-defined requirements for attending the agreed interaction S4 S5 S6 SERVICE CONSUMER TASKS S1 Search for the required service (S)

P2 P3 P4

S2 S3

Find e-Appointment for S Find S-related information, like: application form, supporting documents, delivery channels, delivery centers,

Negotiate place for S-related interaction Negotiate time for S-related interaction Receive pre-defined requirements for attending the agreed interaction Notify the service provider about special conditions Fulfill the requirements for attending the agreement Cancel existing agreement Modify existing agreement Be present at the place at the agreed time

S7

Postapplication

P8

Notify consumer about the agreement

S8

P9

Ensure resources are available for providing S on the agreed places and at the agreed time Remind consumer about the agreement

S9 S10 S11

P10

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

SECTION 2 BACKGROUND

The Application phase involves those interactions between the parties that enable them to set the agreement. For instance, both parties need to negotiate the place and time for the interaction. In addition, the service provider shall provide information about the requirements that the consumer needs to fulfill before the meeting; while the service consumer shall receive such information. In addition, the service consumer can notify the service provider about special conditions he/she would like before an interaction is agreed upon. The Post-application phase comprises all possible actions that the parties can execute after the agreement is established. For example, the service provider notifies the consumer about the confirmed agreement; assures all the required resources will be available for the interaction; and remind the service consumer some time in advance that the interaction will take place. The service consumer fulfills the requirements before at-tending the interaction and is available at the time and place agreed. In addition, the service consumer can modify or cancel an existing agreement. The following section discusses implementation approaches for each phase.

2.4. IMPLEMENTATION APPROACH


Based on the business process tasks defined in the previous section, an implementation approach for each of them is depicted in Table 3 and explained as follows. Some tasks could be provided by available services offered by the government portal since they involve publishing information on the portal and facilitating access to an e-service through the portal. For instance, P1 Announce the e-Appointment service in support of another public service (called S); P7 - Provide predefined requirements for attending the agreed interaction; S1 Search for the required service (S); S2 Find eAppointment for S; and S3 Find S-related information. Task P9 - Assure resources are available for providing S at the agreed places at the agreed time; should be executed according to organizational procedures. Some of the tasks executed by the service consumer are out of the scope of public administrations since they are consumers responsibility, like: S6 - Receive pre-defined requirements for attending the agreed interaction; S8 Fulfill the requirements for attending the agreement; and S11 - Be present at the place and time agreed.

Table 3: Implementation Approach for Main Tasks of the e-Appointment Business Process ACTIVITY Preapplication SERVICE PROVIDER TASKS P1 P2 P3 P4 Application P5 Service of the government portal e-Appointment function e-Appointment function e-Appointment function e-Appointment function S4 e-Appointment function and optionally Authentication service e-Appointment function and optionally Authentication service Out of scope e-Appointment function Out of scope SERVICE CONSUMER TASKS S1 S2 S3 Search service of the government portal Search service of the government portal Search service of the government portal

P6

e-Appointment function

S5

P7

e-Appointment function and/or search services of the government portal

S6 S7

Postapplication

P8

e-Appointment function and Notification service Organizational procedures

S8

P9

S9 S10

e-Appointment function e-Appointment function Out of scope

P10

e-Appointment function and Notification service

S11

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

SECTION 2 BACKGROUND

Table 4: e-Appointment Functions ACTIVITY Preapplication FUNCTIONS P2 P3 P4 Application P5 S4 P6 S5 P7 Post-application P8 P10 S9 S10 Define places for S-related interaction Define times for S-related interaction Define performance measures for S Negotiate place for S-related interaction Negotiate time for S-related interaction Notify the service provider about special conditions Notify consumer about agreement Remind consumer about agreement Cancel existing agreement Modify existing agreement

All other tasks should be provided by the e-appointment service, like P2 - Define places for S-related interactions; P3 - Define times for S-related interactions; P4 - Register performance measures for S; P5 and S4 Negotiate place for S-related interaction; P6 and S5 Negotiate time for S-related interaction; P7 - Provide pre-defined requirements for attending the agreed interaction; P8 Notify the consumer about the agreement; P10 Remind the consumer about the agreement; S7 Notify the provider about special conditions; S9 Cancel the agreement; and S10 Modify the agreement. In addition, P8 and P10 Notify and Remind the consumer about the agreement, may involve the notification service of the software infrastructure. In addition, if the service requires authenticating the applicant, tasks S4 and S5 Negotiate place and time for S-related interaction, can be supported by the Authentication service of the software infrastructure. In summary, Table 4 presents the list of tasks that shall be considered as functionality offered by the eAppointment service. The tasks include defining places, times and performance measures for S-related interaction; negotiate place and time for the interaction; notify the service producer about special conditions; notify and remind the service consumer about the agreement; and cancel and modify an existing agreement. Except for the appointment negotiation tasks (P5-S4 and P6-S5), all other functions involved in the eAppointment service are simple tasks to be automated, since they involve updating information in a database.

For the appointment negotiation tasks, Klischewski [3] differentiates two possible approaches for negotiating the agreement: 1) Consultation hour - the provider informs the available dates and times; the consumer selects and submits his/her choice, the provider and optionally, the consumer confirms the agreement. One-on-one appointment - the consumer submits his/her choices and/or restrictions, the provider presents the available choices matching the consumers preferences, the consumer selects and submits his/her choice, and the provider confirms the agreement.

2)

The first approach minimizes the number of interactions required to reach an agreement and is the most commonly used. Therefore, the one adopted in this work. However, we present a more refined version explained as follows. We introduce the idea that there might be several locations where the interaction can take place, and each of them may have different working hours. Consequently, the consumer, first selects the location, and second, selects the date and time. In summary, the agreement negotiation can be executed according to the following sequence: 1) service provider informs available places; 2) service consumer selects place; 3) service provider informs available times; 4) service consumer selects time; 5) service provider confirms place and time; and 6) service consumer confirms place and time. The sequence is illustrated in Figure 1.

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

SECTION 2 BACKGROUND

Figure 1: Appointment Negotiation Process

agreements made with different IT platforms on which these software applications are deployed. C4) Multi-Channel Delivery as any other service, a multi-channel delivery approach may be adopted for e-Appointment; meaning that service consumers should be able to make appointments through various channels, like portal, phone, SMS, counter, call centre, fax, etc. If a multi-channel delivery approach is implemented, the e-Appointment solution shall be able to fit within the existing approach. C5) Service Parameterization since each service using the e-Appointment may have its own performance measures; the e-Appointment solution shall provide a mechanism to easily configure parameters for each service. C6) Infrastructure Integration if a software infrastructure providing common functionality like authentication and notification services; is deployed, the e-Appointment solution shall be able to integrate and interact with the infrastructure components and services.

2.5. CHALLENGES
As Klischewski has pointed out [3], there are no scientific publications about e-Appointment mainly due to the rather simple implementation problem when considering the appointment for one single service. However, while attempting to generalize the appointment service and conceiving it as an infrastructure service, various challenges arise. Some of them are presented below. C1) Communication Infrastructure the e-Appointment service, part of the software infrastructure, should be accessible through the government portal. However, the service needs to provide information about the confirmed agreements to several government agencies responsible for delivering services using the e-Appointment solution. A secure communication infrastructure is needed to exchange appointment-related information between the government portal and agencies providing services. C2) Standardized Data each government agency providing services using the e-Appointment solution may have its own computerized records about the available places and times in which the interactions can take place. Standardized data shall be available for the e-Appointment solution to be able to retrieve them. C3) Back-Office Heterogeneity each government agency providing services using the e-Appointment solution may have its own software applications supporting the back-office processes. The eAppointment shall be able to communicate the

2.6. CASE STUDIES


Experiences of e-Appointment services from Greece and Singapore were analyzed. The findings are presented in Section 2.6.1. The next sections present in details each of the case studies analyzed. 2.6.1. FINDINGS 1) The experience from Greece, although is not an eAppointment infrastructure service since it only sup-ports services provided by one government agency, explains clearly the benefits achieved by implementing an e-Appointment solution. The case study presents concrete performance indicators and measurements demonstrating the improvements achieved in efficiency. Two experiences from Singapore were analyzed i) provided by the Ministry of Home Affairs and ii) provided by the Ministry of Manpower. Both solutions are different; showing the lack of a common e-Appointment service, part of software infrastructure for Electronic Government. The Singapore experience from the Ministry of Home Affairs shows an e-Appointment service supporting various services delivered to different recipients like citizens, permanent residents and tourists- all provided by the same government agency. The service does not provide a standardized mechanism for authenticating applicants; uses different data for each service.

2)

3)

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

SECTION 2 BACKGROUND

4)

A good design feature implemented in the solution provided by the Ministry of Home Affairs of Singapore is the user interface. For example, it made good use of colors to highlight different options like holidays, available and non-available dates for appointments. Two special features implemented in the solution provided by the Ministry of Home Affairs of Singapore include: 1) issuing of a receipt after confirming the appointment for some services; the applicant is required to bring the receipt to the appointment; 2) managing different validation rules for each service; for example, the time in advance for changing an appointment. The Singapore experience from the Ministry of Manpower shows a very simple and friendly service, although it seems very unreliable no exhaustive validations are executed and while submitting the results of a questionnaire about the service, an error was obtained informing that the database was not available.

EOF, for issuing all EOF licensing decisions concerning approval, renewal, modification and withdraw of marketing authorizations, and for storing and maintaining all EOF records. DDYEP has deployed an e-Appointment system [5] through which pharmaceutical companies can arrange scheduled appointments. Some of the driving forces creating the need for the e-Appointment solution include: i) to provide a solution to the increasing pressure on resource utilization; ii) to be more customer-focused; iii) to seek out and make use of available technologies; iv) to better utilize the time of personnel and stakeholders; and v) to secure transparency and equity. Strategic and operational objectives were defined for the e-Appointment service. The strategic objectives include: i) to increase process transparency by directly involving the consumers (pharmaceutical companies) in the formulation of the visit schedule; ii) to ensure fair treatment to all pharmaceutical companies; iii) to provide services based on the consumers needs rather than on the division capabilities; iv) to create an environment of common purpose and cooperation between DDYEP and the pharmaceutical companies; v) to develop a standardized process which can be monitored, measured, analyzed, and continuously improved; and vi) to build capacity among pharmaceutical companies and staff for future development comprising e-services. The operational objectives comprise: i) to increase effectiveness by controlling the amount of time for serving each company; ii) to eliminate idle time between companies visits; iii) to control the differences between the time spent with each company, for ensuring all receive the services they require; and iv) to ensure effective long term scheduling for staff activities.

5)

6)

2.6.2. GREECE E-APPOINTMENT SERVICE IN HEALTH AREA The National Organization for Medicines (EOF) [5] of Greece is a public entity under the Ministry of Health and Solidarity responsible for ensuring the public health and safety regarding specific products, like medicines for human and veterinary use, feeding stuffs and food additives, food supplements, medical devices, and cosmetics, among others. Within EOP, the Validation of Applications and Marketing Authorization Division (DDYEP) is responsible for validating all applications submitted to

Table 5: Greece DDYEP e-Appointment Service - Performance Indicators KEY PROCESS INDICATOR Number of appointments Number of appointments served per staff Number of calls for arranging appointment Number of visits for arranging appointment Variance between appointment desired and scheduled Employee time spent in arranging appointments Statistics available to pharmaceutical companies number of appointments scheduled, held, missed, per category, for a given time, etc Statistics available to DDYEP number of appointments scheduled, held, missed, repeated, per category, per assessor, per a given time, etc BEFORE 8063 1675 1-5 1-3 50% 20% not known AFTER 9024 2112 0 1-2 20% 0 recorded recorded analyzed IMPROVEMENT 12% 26% 100% 50% 60% 100% 100%

not known

100%

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

SECTION 2 BACKGROUND

Some of the lessons learnt after deploying the solution include: 1) the increased transparency for scheduling visits has proactively addressed pharmaceutical companies grievances, and has helped in cultivating spirit of common purpose; 2) a systematic analysis of statistics enables to improve efficiency in managing the workload and making better use of limited resources; and 3) analysis of the statistics of visit schedules enables better staffing decisions, and hence provides better services to companies. Results about the improvements gained with the deployed solution are presented in Table 5. The results show how the total number of appointments served increased by 12%; the number of appointments served by each staff increased by 26%; the number of calls for arranging appointments dropped to zero; while the number of visits for the same purpose also decreased by 50%. The latter two results help to reduce the time spent by employees in arranging appointments to zero. The differences between the appointments desired and scheduled improved by 60%. Finally, statistics are available for the pharmaceutical companies and for DDYEP.

2.6.3. SINGAPORE - E-APPOINTMENT SERVICE IN MINISTRY OF HOME AFFAIRS The Immigration and Checkpoints Authority (ICA) [7] of Singapore is a government agency under the Ministry of Home Affairs. ICA is responsible for the security of Singapores borders including the entry of undesirable persons and cargo through land, air and sea checkpoints. ICA is also responsible for issuing ID cards and passports to Singapore citizens, and various immigration permits and visas for tourists. ICA has deployed an e-Appointment system [5] through which citizens, permanent residents and visitors can arrange an appointment to receive various services. For example, i) citizens can arrange appointments for collecting Identity Card (IC) and passport, and for modifying an existing appointment (Citizenship Registration); ii) permanent residents can arrange appointments for applying for Permanent Residence (PR), for renewing or transferring the Re-Entry Permit (REP) or Certificate of Identity (CI), and for completing Permanent Residence formalities; iii) visitors can arrange appointments for completing visit pass and Secure Trade Partnership (STP) formalities, and for changing an existing appointment (e-XTEND). Figure 2 shows the different types of services which are supported by the e-Appointment service.

Figure 2: Singapore ICA e-Appointment Service

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

SECTION 2 BACKGROUND

10

Four main features of the solution include: 1) Different data is used to authenticate the service consumer depending on the service. For instance, if a citizen would like to change a previous appointment (Citizenship Registration), he/she needs to provide the application ID; for collecting the IC (Collection of IC), he/she needs to provide the number of the National Registration Identity Card (NRIC) and the NRIC date of issue; while for collecting the passport (Collection of Passport), he/she needs to provide the NRIC and the File reference numbers. Figure 3 shows these examples. Colors are used for indicating to the service consumer the status of the available times. For instance, when a citizen would like to change an appointment, a calendar is shown on the screen, as the one presented in Figure 4. The current applicants appointment is highlighted in orange (Thursday 31); the available dates are shown in green (like Friday 18), non-working days are indicated in pink (like Sunday 20), while days on which all appointments are booked are shown in grey (like Thursday 24). Validation rules are defined for each service. For instance, for collecting ICs, appointments can be changed at least two days before the appointment date and the appointment can be changed only twice; while for applying for permanent residence the appointment can be changed at least one day before the scheduled date. A receipt, like the one presented in Figure 5, is issued for some of the services. The applicant is re-

quired to carry this acknowledgment when attending the appointment, and scan it in the Self Service Ticketing Kiosk for the queue ticket. Figure 3: Singapore ICA e-Appointment Service Authenticating Applicants

2)

3)

4)

Figure 4: Singapore ICA e-Appointment Service Retrieving an Appointment

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

SECTION 2 BACKGROUND

11

Figure 5: Singapore ICA e-Appointment Service Appointment Receipt

1) 2.6.4. SINGAPORE - E-APPOINTMENT SERVICE IN MINISTRY OF MANPOWER The Labour Relations and Workplace Division (LRWD) [9] is a government unit under the Ministry of Manpower of the Government of Singapore. LRWD is responsible for promoting and maintaining industrial peace and stability in Singapore by providing a legal framework to balance the interests of employers and employees. LRWD provides an e-Appointment service [10]. The service allows a person to book an appointment through the Internet to consult the Division Advisory Officers on the Employment Act. Therefore, the e-Appointment solution only supports one service. Main features of the solution include:

The first mandatory page for accessing the eAppointment service is related to terms and conditions of the use of the service (Figure 6.) Consumers must accept the conditions to access the service. The service enables the applicant to make a new appointment, view, cancel or re-schedule an existing appointment. The applicant is not authenticated when accessing the service. A demo online provided as a pdf file; is available for explaining the process for obtaining the appointment to the applicant.

2)

3)

4)

Figure 6: Singapore LRWD e-Appointment Service Terms and Conditions

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

SECTION 2 BACKGROUND

12

Figure 7: Singapore LRWD e-Appointment Service Negotiating Time

5)

The process comprises three steps. The first step presents a calendar showing the available dates and time, and requests the applicant to select his choice See Figure 7. Non-working days are identified in grey (like 7-8 February), unavailable times are shown in orange (like all times on 9 February), and available times are indicated in blue (like all times on 11 February). The second step requests the applicant to fill a form indicating the type of appointment requested claim or enquiry about Employment Act, and his personal data like type of identifier (NRIC, FIM Foreigner Identification Number, Passport, or Work Permit) and number, name, mobile, and office/home phones, email address, home address, and an explanation of the purpose of the visit. The form is illustrated in Figure 8. Finally, the third step confirms the appointment and allows the applicant to print a receipt.

6)

Few validations are executed when making an appointment. Except controlling that all mandatory fields are completed and that the home/office phone is valid, no other validations are applied. It is possible to make an appointment with entirely fake data only a valid phone is required. To retrieve an existing appointment, the applicant needs to inform the identification he/she used to make the appointment and the appointment date. In this way, the applicant must remember these data in order to modify, cancel, or view an existing appointment. See Figure 9. A survey is available for providing feedback. After completing and submitting the form, an error message was presented indicating that the system/database was down.

7)

8)

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

SECTION 2 BACKGROUND

13

Figure 8: Singapore LRWD e-Appointment Service Providing Personal Data

Figure 9: Singapore LRWD e-Appointment Service Retrieving an Appointment

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

SECTION 3 REQUIREMENTS

14

3. REQUIREMENTS
This section describes the functional and non-functional software requirements for the e-Appointment service. Each requirement is assigned the following fields: 1) 2) 3) 4) 5) 6) 7) 8) a unique identifier, requirements category, textual description, list of glossary terms used, justification for the requirement, implementation priority, feasibility of the requirement and criteria for verifying the requirement.

user categories: i) portal administrator person responsible for the administration of the government portal; ii) service providers persons responsible for operating the e-Appointment Service in each of the agencies delivering services supported by e-Appointment; and iii) service consumers persons requesting appointments. The requirements are explained in the following sections as follows: 1) Section 3.1.1 Managing e-Appointment Service, describes the functionality for the portal administrator; Section 3.1.2 - Managing Supported Services, presents the functionality for service providers; and Section 3.1.3 Requesting Appointments, introduces the functionality for service consumers.

2)

3)

The category field has two possible values: functional or non-functional. The implementation priority has three possible values: high, medium or low. The following sections describe in details the functional and non-functional requirements.

3.1.1. MANAGING E-APPOINTMENT SERVICE As any other e-service, access to the e-Appointment service should be offered through the one-stop government portal. The functionality that shall be provided for the portal administrator involves managing data about those services for which appointments are required as part of their business process, and the agencies providing those services. In addition, to avoid applicants booking an appointment on a public holiday, data about public holidays shall be available. The following three requirements address these needs.

3.1. FUNCTIONAL REQUIREMENTS


The functionality that shall be provided by the eAppointment service is defined according to three main

Requirement 1: Administering Agencies ID CATEGORY DESCRIPTION F1 Functional Information about agencies providing services requiring appointments as part of their delivery process shall be available. Data about the communication structures used for exchanging information with these agencies shall be maintained. Agency, Communication Structures Allows keeping information about the agencies which are responsible for carrying out the appointments and all communication-related data enabling information exchange between the portal and the agencies. High It can be implemented through a simple function updating data in a database. Log in as portal administrator, view agencies, add two agencies, view the updated data, remove one agency, view the updated data, and log out.

TERMS JUSTIFICATION

PRIORITY FEASIBILITY VERIFICATION

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

SECTION 3 REQUIREMENTS

15

Requirement 2: Administering Services List ID CATEGORY DESCRIPTION F2 Functional Information about the services requiring appointments as part of their delivery processes shall be available. For each service, information about the providing agency shall also be maintained. Service To make an appointment, the applicant shall specify the service for which he/she is requesting the appointment. High It can be implemented through a simple function updating data in a database. Log in as portal administrator, select an agency, add two new services, view the updated data, remove the second added service, view the updated data, and log out.

TERMS JUSTIFICATION

PRIORITY FEASIBILITY VERIFICATION

Requirement 3: Managing Public Holidays ID CATEGORY DESCRIPTION F3 Functional Public holidays representing non-working days for all government agencies shall be maintained. If the government portal already maintains information about public holidays, this information should not be duplicated. In this case, this requirement shall be interpreted as providing a function to get this data. Public Holiday A list of all non-working days for all government agencies shall be maintained to avoid applicants booking appointments for those days. High It can be implemented through a simple function updating data in a database. Log in as portal administrator, view holidays, add two new holidays, view the updated data, delete one holiday, and log out.

TERMS JUSTIFICATION

PRIORITY FEASIBILITY VERIFICATION

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

SECTION 3 REQUIREMENTS

16

3.1.2. MANAGING SUPPORTED SERVICES Service providers (agencies) shall be able to define which of the services provided by them require applicants to make appointments (supported services), where the services are provided (centers), days in which appointments cannot be made (non-working days), and hours in which appointments can take place (working hours). In addition, service providers shall be able to

update service parameters like number of persons that can be served at a time (counters), mean time for serving a person (service time), minutes in advance to remind the applicant about the appointment (reminder notification time). Finally, service providers shall be able to view and export to a file the appointments done for a particular date. The following requirements specify these functions.

Requirement 4: Managing Services Data ID CATEGORY DESCRIPTION F4 Functional Information about services requiring appointments shall be available. For each service, data about performance measures like mean time for serving a person (service time), and minutes in advance to remind the applicant about the appointment (reminder notification time) shall be maintained. Service Time, Reminder Notification Time Information about the service time is required for being able to show applicants the available times for the appointments. Information about the reminder notification time is needed for sending an appointment reminder to applicants. High It can be implemented through a simple function updating data in a database. Log in as portal administrator, select an agency, add two new services, add its parameters, view the updated data, update the parameters of the first added service, remove the second added service, view the updated data, and log out.

TERMS JUSTIFICATION

PRIORITY FEASIBILITY VERIFICATION

Requirement 5: Managing Centers ID CATEGORY DESCRIPTION F5 Functional For each service requiring appointments, information - like name and address, about the centers in which the appointments can take place shall be maintained. Appointments for a service can be provided in more than one center, and one center can serve appointments for several services. For each center and service, the number of applicants that can be served at a time shall be maintained (Counters) Center, Counter Appointments related to one service can take place in more than one place, not necessarily the government agency. Information about these places shall be stored. High It can be implemented through a simple function updating data in a database. Log in as agency administrator, select an agency, add one service, add two centers, view centers, delete one center, view the updated data, and log out.

TERMS JUSTIFICATION

PRIORITY FEASIBILITY VERIFICATION

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

SECTION 3 REQUIREMENTS

17

Requirement 6: Managing Non-Working Days ID CATEGORY DESCRIPTION F6 Functional Each agency shall be able to define its own non-working days in addition to the public holidays. Non-working days are applicable to all centers serving appointments for the services provided by the agency. Non-working Day An agency should be able to define a non-working days in addition to public holidays. High It can be implemented through a simple function updating data in a database. Log in as agency administrator, add two non-working days, view non-working days, delete one nonworking day, view the updated data, and log out. Log-in as user, try to make an appointment for the non-working day, and log out.

TERMS JUSTIFICATION PRIORITY FEASIBILITY VERIFICATION

Requirement 7: Managing Working Hours ID CATEGORY DESCRIPTION F7 Functional Each agency shall be able to define the working hours. Working hours are related to the service and the center - different services may have different working hours, and the same service can be delivered during different working hours in the centers. Working Hour In order to make appointments, working hours are needed for defining the available times. High It can be implemented through a simple function updating data in a database. Log in as agency administrator, select an agency, add one service, add one center, add two working hours, view working hours, delete one working hour, view the updated data, and log out. Log in as user, try to make an appointment during non-working hours, make an appointment during working-hours, and log out.

TERMS JUSTIFICATION PRIORITY FEASIBILITY VERIFICATION

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

SECTION 3 REQUIREMENTS

18

Requirement 8: Viewing Appointments ID CATEGORY DESCRIPTION TERMS JUSTIFICATION F8 Functional Each agency shall be able to retrieve the appointments done for a particular date. Appointment It is necessary to know in advance the appointments confirmed for a specific date in order to plan the required resources for serving government customers. High It can be implemented through a simple function retrieving data from the database. Make appointments for one date. Log in as agency administrator, input the date for which the appointments have been made, view the appointments, and log out.

PRIORITY FEASIBILITY VERIFICATION

Requirement 9: Exporting Appointments ID CATEGORY DESCRIPTION TERMS JUSTIFICATION F9 Functional Each agency shall be able to export the appointments done for a particular date. Appointment, Export It is necessary to know in advance the appointments confirmed for a specific date in order to plan the required resources for serving government customers, and to be able to export these data for being able to process it by another software application. High It can be implemented through a simple function retrieving data from the database. Make appointments for one date. Log in as agency administrator, input the date for which the appointments have been made, export the appointments and log out.

PRIORITY FEASIBILITY VERIFICATION

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

SECTION 3 REQUIREMENTS

19

2.1.3. REQUESTING APPOINTMENTS Government customers shall be able to make appointments, cancel or modify an existing appointment, re-

ceive notifications about the appointments they confirmed or cancelled, and receive a reminder before the appointment will take place. The following requirements define these functions.

Requirement 10: Making Appointment ID CATEGORY DESCRIPTION F10 Functional The system shall implement a function enabling a user to make an appointment for a particular service. The negotiation process shall be divided in steps, and in each step the user shall be allowed to continue or return back to the previous step. The process shall be clearly explained to the user before it starts. An estimation of the amount of time required for completing the process shall be informed to the applicant when the process starts. The negotiation process executed by the consumer includes: selecting the service for which the appointment is required; selecting the center; selecting a suitable date and time, and confirming the choice. Appointment This is the main function provided by the service. High It requires exchanging information between the government portal and the agency. Once the agency receives the data about the appointment, the data shall be stored in the agency database. Log in as user, make an appointment, and log out. Log in as agency administrator, view appointments, and log out.

TERMS JUSTIFICATION PRIORITY FEASIBILITY

VERIFICATION

Requirement 11: Cancelling Appointment ID CATEGORY DESCRIPTION F11 Functional The system shall implement a function enabling a user to cancel an existing appointment. The applicant shall receive a notification about the cancelled appointment. The applicant needs to be authenticated for cancelling an appointment. Appointment Enabling the user to cancel an existing appointment allows reducing the number of applicants no showing up and making better use of government resources since another user can booked an appointment for the center/date/time of the one who was cancelled. High It requires exchanging information between the government portal and the agency. Once the agency receives the data about the appointment, these data shall be updated in the database (the existing appointment shall be deleted). Log in as user, make an appointment, and log out. Log in as agency administrator, view appointments, and log out. Cancel the appointment. Log in as agency administrator, view appointments, and log out.

TERMS JUSTIFICATION

PRIORITY FEASIBILITY

VERIFICATION

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

SECTION 3 REQUIREMENTS

20

Requirement 12: Modifying Appointment ID CATEGORY DESCRIPTION F12 Functional The system shall implement a function enabling a user to modify an appointment that was previously done. The service shall delete the previous appointment and add the new one. The applicant shall receive a notification about the new appointment. Appointment Enabling the user to modify an existing appointment allows reducing the number of applicants no showing up and making better use of government resources since another user can booked an appointment for the center/date/time of the one who was changed. High It requires exchanging information between the government portal and the agency. Once the agency receives the data about the appointment, these data shall be updated in the database (the existing appointment shall be deleted and a new appointment shall be added). Make an appointment. Log in as agency administrator, view appointments, and log out. Modify the appointment. Log in as agency administrator, view appointments, and log out.

TERMS JUSTIFICATION

PRIORITY FEASIBILITY

VERIFICATION

Requirement 13: Notifying Applicant ID CATEGORY DESCRIPTION F13 Functional The system shall implement a function notifying the applicant every time an appointment is done, cancelled or modified. Notifications shall be sent through e-mail and SMS. Appointment, Notification It is important for the user to receive a notification that the system registered precisely the action he/she requested (make, cancel or modify an appointment) High It requires notifying the applicant according to his/her preferred channel (e-mail or SMS). Make an appointment and receive notification. Modify the existing appointment and receive notification. Cancel the existing appointment and receive notification.

TERMS JUSTIFICATION

PRIORITY FEASIBILITY VERIFICATION

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

SECTION 3 REQUIREMENTS

21

Requirement 14: Reminding Applicant ID CATEGORY DESCRIPTION F14 Functional The system shall implement a function reminding the applicant that the appointment will take place. The notification shall be sent some minutes in advance, those indicated by the reminder notification time. The service provider defines the reminder notification time as part of the service parameters. Appointment, Reminder Notification Time It is important for the user to receive a notification reminding him/her about the appointment. High It requires notifying the applicant according to his/her preferred channel (e-mail or SMS). Make an appointment and receive a notification before the appointment will take place.

TERMS JUSTIFICATION PRIORITY FEASIBILITY VERIFICATION

3.2. NON-FUNCTIONAL REQUIREMENTS


The non-functional requirements for the e-Appointment service address four major aspects of system quality: reliability, security, generality and interoperability. Each of them is described as follows.

3.2.1. RELIABILITY The e-Appointment must essure that information about appointments confirmed and cancelled through the government portal is received by the agencies providing the services.

Requirement 15: Exchanging Appointment-related Information ID CATEGORY DESCRIPTION NF15 Non-Functional The e-Appointment service shall be able to ensure that all appointments confirmed and cancelled through the government portal are sent to the proper agencies. An agency shall receive only appointment-related information for the services delivered by it. Reliability Users (service providers and consumers) shall trust the service is reliable. High The property can be fulfilled if communications between the government portal and government agencies are supported by reliable communication infrastructure. Log in as user; make two appointments for two different services delivered by different agencies, and log out. Log in as one of the service providers, view the appointments done and log out. Log in as the other service provider, view the appointments done and log out.

TERMS JUSTIFICATION PRIORITY FEASIBILITY

VERIFICATION

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

SECTION 3 REQUIREMENTS

22

3.2.2. SECURITY Authentication and confidentiality are the security requirements defined for the e-Appointment service. Authentication ensures that access to the e-Appointment service and its data is restricted to those who can provide the appropriate proof of identity. For instance, in

order to cancel an appointment, the applicant needs to be authenticated. Confidentiality ensures that minimum data are requested from applicants for making appointments, and that these data are stored and exchanged without risks of being tampered. The following requirements address these issues.

Requirement 16: Authenticating users ID CATEGORY DESCRIPTION NF16 Non-Functional Users like service consumers, service providers and portal administrator shall be authenticated for accessing functionality and data about appointments. Authentication Only authorized users can have access to information managed by the e-Appointment service. High Authentication is a common feature in software applications. Log in as user; make an appointment, and log out. Log in as portal administrator, control the available functions and log out. Log in as service provider, control the available functions, view and export appointments for a specific date, check the information is only related to services delivered by the agency, and log out.

TERMS JUSTIFICATION PRIORITY FEASIBILITY VERIFICATION

Requirement 17: Ensuring Confidentiality ID CATEGORY DESCRIPTION NF17 Non-Functional Information used for authenticating applicants shall be minimal. Information stored and exchanged shall be protected. Confidentiality The amount of personal information used by the e-Appointment service shall be minimized and disclosure of these data must be avoided. High The property can be fulfilled if an authentication mechanism is used, access to databases is restricted only to those authorized, and communications rely on a secure network. Check that the authentication mechanism is in place. Check that only the authorized functions are available for each user type. Check policies for accessing databases.

TERMS JUSTIFICATION

PRIORITY FEASIBILITY

VERIFICATION

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

SECTION 3 REQUIREMENTS

23

3.2.3. GENERALITY Generality tries to minimize the need for changing the software due to restrictions introduced during the de-

sign phase. Parameterization techniques can be used for providing a general solution enabling service consumers to make appointments for various services delivered by different agencies. The following requirement describes this feature.

Requirement 18: Ensuring Generality ID CATEGORY DESCRIPTION NF18 Non-Functional The system shall rely as much as possible on service parameters which shall enable functions to show different behavior according to the value of the parameters. Possible parameterization include: service mean time; service reminder notification time; whether the applicant needs to be authenticated or not for making appointments; among others. Configuration file The e-Appointment service shall be able to support various services, not only one. Specific requirements for each service shall be considered. High Parameterization techniques are a common feature of software applications Log in as service provider, check the service mean time for a service, and log out. Log in as service consumer, make an appointment, and log out. Log in as service provider, modify the service mean time for the service, and log out. Log in as service consumer, check the times for making appointments, and log out.

TERMS JUSTIFICATION

PRIORITY FEASIBILITY VERIFICATION

3.2.4. INTEROPERABILITY The e-Appointment service shall be able to interoperate

with other software infrastructure components and services like authentication, notification, and the Messaging Gateway.

Requirement 19: Ensuring Interoperability ID CATEGORY DESCRIPTION TERMS JUSTIFICATION NF19 Non-Functional The system shall be able to interact with other software infrastructure components. Configuration file The e-Appointment service shall be able to interact with other software infrastructure components, like the government portal, authentication and notification services, and be able to exchange information through the messaging gateway. High Interoperability can be assured if open standards and open source technologies and tools are used for software development. Check whether messages are exchanged using the messaging gateway.

PRIORITY FEASIBILITY

VERIFICATION

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

SECTION 4 MODELING

24

4. MODELING
The following two sections describe the conceptual (Section 4.1) and use case (Section 4.2) models for the eAppointment service.

except Non-working Days, which include Public Holidays. Non-working Days are defined for each Center. Services are delivered at Centers through Counters. A Counter serves one consumer at a time. Each Counter may define its own Working Hours. Appointments are requested by Service Consumers for a given Service. An Appointment involves a Notification. There exist different types of Notifications (Notification Type), like those sent through SMS or e-Mail. Three types of Users are identified: i) Service Consumer applicants making appointments; ii) Service Provider persons responsible for managing appointments at the agencies providing supported services; and iii) Portal Administrator person responsible for maintaining the Government portal.

4.1. CONCEPTUAL MODEL


The conceptual model depicted in Figure 10 describes the e-Appointment-related concepts and their relationships. For each concept, a definition is provided in the Glossary and an explanation follows. An Agency delivers Services (supported services) through Centers. One Service can be delivered at various Centers, and several Services can be delivered in one Center. Services are delivered at Centers every day,

Figure 10: Conceptual Model

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

SECTION 4 MODELING

25

4.2. USE CASE MODEL


The top-level use case diagram is depicted in Figure 11. Four main groups of services are provided: 1) Manage e-Appointment Service

2) 3) 4)

Manage Supported Services Request Appointments Use Software Infrastructure

The top-level use cases are listed in Table 6 and are described in the following sections. Figure 11: Top Level Use Case Diagram

Table 6: Top-Level Use Cases ID UC-1 UC-2 UC-3 UC-4 DESCRIPTION Manage e-Appointment Service Manage Supported Services Request Appointments Use Software Infrastructure

4.2.1. MANAGE E-APPOINTMENT SERVICE The functionality provided to the portal administrator is defined by the high-level use case Manage eAppointment Service. This use case comprises three uses cases: Manage Agencies, Manage Services, and Manage Public Holidays. These uses cases are depicted in Figure 12 and are identified in Table 7. The Manage Agencies use case enables management of information about the agencies delivering services which require appointments as part of their delivery processes. For each agency, its identifier, name and the channel identifier used for exchanging messages through the Messaging Gateway shall be maintained. New agencies can be added. Information about an existing agency can be modified, or deleted if the agency no longer deliver services requiring appointments.

Figure 12: Use Case Diagram Manage e-Appointment Service

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

SECTION 4 MODELING

26

The Manage Service List use case allows keeping information about the services for which the service consumers can request appointments. For each service, its identifier and name are maintained, together with information about the agency that is responsible for its delivery. New services can be added to the list, and existing services can be removed if they do not require appointments. Finally, the Manage Public Holidays use case enables storing information about official holidays for all government agencies and centers. Each holiday has an identifier and a date. To avoid information duplication, if information about public holidays is already available at the government portal, the functionality provided by this use case shall be replaced by a function able to get the list of public holidays. Table 7: Use Cases Manage e-Appointment Service ID UC-1-1 UC-1-2 UC-1-3 DESCRIPTION Manage Agencies Manage Services Manage Public Holidays

cases are depicted in Figure 13 and are identified in Table 8. The Manage Services Data use case enables management of information about those services requiring appointment which are delivered by a particular agency. For each service, its identifier, name and its performance measures like service time and reminder notification time, are stored. In addition, information about centers used for delivering the service is also maintained. Information about services can be modified. An existing service can be deleted, if the service no longer requires appointments. The Manage Centers use case enables management of the identification and addresses of those places where appointments take place. New centers can be added, and the data of existing centers can be modified and deleted. Each agency stores information about the centers used for delivering its services. The Manage Non-working Days use case allows registeration of dates in which appointments cannot be requested. Each center can define its own Non-working Days. New Non-working Days can be added and existing Nonworking Days can be deleted. The Manage Counters use case enables defining how many applicants can be served at a time for a particular service in a given center. This data can be updated. The Manage Working Hours use case allows defining the time frame in which appointments can be requested. For each day of the week, the starting and ending times for arranging appointments is stored. Working Hours can be added, modified and deleted.

4.2.2. MANAGE SUPPORTED SERVICES The functionality offered to service providers is defined by the high-level use case Manage Supported Services. This use case comprises seven use cases: Manage Services Data, Manage Centers, Manage Non-Working Days, Manage Counters, Manage Working Hours, View Appointments, and Export Appointments. These uses

Figure 13: Use Case Diagram Manage Supported Services

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

SECTION 4 MODELING

27

The View Appointments use case enables the service provider to retrieve all the appointments arranged for a given date. Finally, the Export Appointments use case enables the service provider to generate a file with data about all the appointments arranged for a given date. Table 8: Use Cases Manage Supported Services ID UC-2-1 UC-2-2 UC-2-3 UC-2-4 UC-2-5 UC-2-6 UC-2-7 DESCRIPTION Manage Services Data Manage Centers Manage Non-Working Days Manage Counters Manage Working Hours View Appointments Export Appointments

pointment, Cancel Appointment, and Change Appointment. These uses cases are depicted in Figure 14 and are identified in Table 9. The Make Appointment use case enables the applicant to arrange an appointment related to a specific service. After selecting the service, the process follows the set of interactions depicted in Figure 1. Once the appointment is confirmed, a notification is sent to the applicant. Some validation rules can be defined for avoiding applicants booking many appointments. In the pilot implementation, the rule specifies that an applicant is not allowed to book more than three appointments with a given agency. The Cancel Appointment use case enables the applicant to cancel an existing appointment. After cancelling the appointment, a notification is sent to the applicant. The Change Appointment use case enables the applicant to change the date and time for an existing appointment. After changing an appointment, a notification is sent to the applicant. The Send Reminder use case enables to send a notification to the applicant before the appointment will take place. For sending the reminder, the service attribute reminderNotificationTime is used. The notification is sent as many minutes in advance to the appointment as the value of this attribute indicates. The Send Notification use case allows sending a notification to the applicant. The software infrastructure notification service could be used for this purpose.

4.2.3. REQUEST APPOINTMENTS The functionality offered to service consumers is defined by the high-level use case Request Appointment. This use case comprises three uses cases: Make Ap-

Figure 14: Use Case Diagram Request Appointments

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

SECTION 4 MODELING

28

The Notify Applicant use case sends notifications to service consumers. This function shall invoke the notification service provided by the software infrastructure. In the current release, it sends notifications by e-mail and by SMS using Clickatell [26] service. Table 9: Use Cases Request Appointments ID UC-3-1 UC-3-2 UC-3-3 UC-3-4 UC-3-5 UC-3-6 DESCRIPTION Make Appointment Cancel Appointment Change Appointment Send Notification Send Reminder Notify Applicant

thenticating the applicant. The implementation of this use case could be done based on an attribute defined for the service. The Use Notification use case aims to integrate the eAppointment service and the notification service of the software infrastructure. The implementation of this use case is merely the invocation of the software infrastructure service. The Use Messaging Gateway use case enables to invoke the services of the Gateway for exchanging information between the government portal and the agencies delivering the supported services. For creating the communication structures like registering members and creating and subscribing to channels, the user interface of the Gateway is used. For sending and receiving messages, the e-Appointment service relies on the Gateway APIs. Since the implementation of the first two use cases (UC4-1 and UC-4-2) highly depends on the software infrastructure services, they are not implemented in the current release. Table 10: Use Cases Use Software Infrastructure ID UC-4-1 UC-4-2 UC-4-3 DESCRIPTION Use Authentication Use Notification Use Messaging Gateway

4.2.4. USE SOFTWARE INFRASTRUCTURE The e-Appointment service can rely on three software infrastructure components and services: Authentication, Notification, and Messaging Gateway. These uses cases are depicted in Figure 15 and are identified in Table 10. The Use Authentication use case aims to integrate the eAppointment service and the authentication service of the software infrastructure. However, not all services supported by the e-Appointment service require au-

Figure 15: Use Case Diagram Use Software Infrastructure

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

SECTION 4 MODELING

29

4.3. USE CASES VERSUS INFORMAL REQUIREMENTS This section relates the informal requirements presented in Section 3 to the use cases described in Section 4.2. The relation is depicted in Table 11.

Table 11: Use Cases versus Functional Requirements USE CASE UC-1-1 UC-1-2 UC-1-3 UC-2-1 UC-2-2 UC-2-3 UC-2-4 UC-2-5 UC-2-6 UC-2-7 UC-3-1 UC-3-2 UC-3-3 UC-3-4 UC-3-5 UC-4-1 UC-4-2 UC-4-3 DESCRIPTION Manage Agencies Manage Services List Manage Public Holidays Manage Services Data Manage Centers Manage Non-Working Days Manage Counters Manage Working Hours View Appointments Export Appointments Do Appointment Cancel Appointment Change Appointment Send Notification Send Reminder Use Authentication Use Notification Use Messaging Gateway FUNCTIONAL REQUIREMENTS F1 F2 F3 F4 F5 F6 F5 F7 F8 F9 F10 F11 F12 F13 F14 F10, F11, F12 F10, F11, F12 F10, F11, F12

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

SECTION 5 DESIGN

30

5. DESIGN
This section presents the design details of the eAppointment System. First, the static and dynamic views of the architecture models are presented in Sections 5.1 and 5.2 respectively. Next, detailed structural design diagrams for the major components are provided in Section 5.3, while detailed behavioral diagrams are presented in Section 5.4.

5.1. ARCHITECTURE STATIC VIEW


The static view of the system is depicted in Figure 16. The system design follows a layered architecture comprising the following five main packages - User Interface Portal, User Interface Agency, Core Business, Entities, and Database. The User Interface Portal and the User Interface Agency provide classes implementing all the web pages offering the functionality that is available through a browser. The web pages are

grouped in three components: a common set of pages required at the government portal and the agencies (Common), a set of pages with the functions offered to the portal administrator and users (Portal), and a set of pages offering functions to the service providers (Agency). The Core Business package implements the e-Appointment business logic; for instance, it comprises classes implementing methods for making, cancelling and modifying an appointment (Service), for sending and receiving messages between the government portal and the agencies providing services (Communication) and for storing some parameters of the delivery channels used for sending notifications (Util) . The Entities package implements the system entities, like Agency for representing government units; Centers for defining the places where the appointments will take place, and Service for defining services requiring appointments, among others. Finally, the Database package is responsible for managing the database. It implements operations required for storing, reading, updating, and deleting an entity from the database.

Figure 16: Architecture Static View

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

SECTION 5 DESIGN

31

5.2. ARCHITECTURE DYNAMIC VIEW


For illustrating a dynamic view of the architecture, Figure 17 presents high-level collaborations for making an appointment. The collaborations are divided in four steps following the process for negotiating the appoint-

ment. The three objects on the left depicted in green, reside at the government portal side, while the two objects on the right depicted in orange, reside at the agency providing the service for which the appointment is requested. The collaborations for each step are explained as follows.

Figure 17: Architecture Dynamic View for Making an Appointment

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

SECTION 5 DESIGN

32

In Step 1, the User requests a new appointment 1:makeAppointment. Then, the user is requested to select the service for which the appointment is required - 2:requestService, and the user selects the service - 3:selectedService. A request for getting the centers - 4:getCenters, is forwarded to the portal business layer, who prepares the message to be sent to the provider agency - 5:msgToSend, and sends the message - 6:sendMessage(getCenters). After receiving the message at the provider agency (AgencyA), a request is sent to the database to retrieve this information 7:retrieve(centers). The information is sent back through all the involved components until it reaches the user 8:centers, 9:receiveMessage(centers), and 1011:centers. Finally, the user selects the center 12:selectedCenter. In Step 2, the user is requested to provide appointmentrelated data, like preferred delivery channels for receiving notifications, and text message to be sent to the provider agency 13:requestApplicantData. The applicant provides his/her data 14:applicantData, he/she is requested to select the appointment date 15:requestDate; and informs his/her choice 16:selectedDate. In Step 3, a request for getting the working hours is sent to the portal business layer 17:getWorkingHours, which prepares the message to be sent to the provider agency 18:msgToSend, and sends the message 19:sendMessage(getWorkingHours). After receiving the request, the core business component at the agency forwards the request to the database 20:retrieveWorkingHours. The information obtained is sent back to the user, through all the objects requesting it 21:workingHours, 22:receiveMessage(workingHours), 23:workingHours, 24:workingHours. Finally, based on the working hours indicated, the user selects the preferred time for the appointment 25:selectedTime. In Step 4, a web page is shown for confirming the appointment 26:requestConfirmation, and the user confirms 27:confirmation. A request is sent to the portal business layer for sending the information about the new appointment to the provider agency 28: NewAppointment. A message is formatted 29:msgToSend, and is sent to the agency 30:sendMessage(new Appointment). Upon reception to the message at the agency, the new appointment is stored in the database 31:store(Appointment). For simplicity of the diagram, the Entities component was not shown. However, every time an entity is handled like centers, working hours, and appointment; either at the portal or at the agency side, by any of the tiers user interface, core business or database, the

data is processed through the Entities component. In addition, the information exchange between the government portal and the provider agency is done through the Messaging Gateway, although this component was not shown for the same reason.

5.3. DETAILED STRUCTURAL DESIGN DIAGRAMS


The following sections present detailed design for the main layers of the architecture: User Interface, Core Business and Database. 5.3.1. USER INTERFACE LAYER The e-Appointment user interface is implemented as part of a web application, which is built using Apache Wicket (Wicket) framework [11]. Wicket is a framework enabling the rapid development of Java-based web applications. As mentioned before, three main components implement the user interface: i) UI-Common, ii) UIPortal, and iii) UI-Agency. The detailed design class diagram of UI-Common is shown in Figure 18. Four main packages are shown: i) Wicket Component; ii) web.template; iii) web; and iv) web.session. The Wicket Component represents the development framework used. The component web.template comprises the following classes: o Template is an abstract class defining a general template for all web pages. For instance, the template includes the page header and footer. SecureTemplate is a base class for all web pages requiring authentication. Result a general template to display some information. It provides a simple box. Its content can be filled and displayed. PendingAppointment a general template displaying a fixed message explaining that there are pending appointments. It is used when a deletion request cannot be satisfied due to this reason. ConfirmLink a general template requesting a confirmation. Every time a deletion request is submittted, this class is used for getting the users confirmation. DateSection a template for displaying the schedule of working hours for a particular date. It shows which are the available and the unavailable times.

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

SECTION 5 DESIGN

33

TimeField a template for managing the starting and ending time of working hours, showing the hour and minutes.

stantiating SecureTemplate for implementing the home page of the application. The web.session contains one class My.session, for handling the sessions. In this release, information about the current user is maintained. The detailed design class diagram of UI-Portal is shown in Figure 19. Four main packages are shown: i) web.agency; ii) web.holidays; iii) web.service; and iv) web.appointment

The web component includes three classes: i) Application this class is required by the Wicket framework for managing all requests; ii) Login is a concrete page instantiating the Template class provided by the web.template component; it enables the user to log in; and iii) Home Page is a concrete page in-

Figure 18: Design Class Diagram e-Appointment Common Web Pages

Figure 19: Design Class Diagram e-Appointment Portal Web Pages

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

SECTION 5 DESIGN

34

The web.agency package comprises two classes for creating or editing agencies providing services requiring appointments (Create) and for listing and deleting these agencies (List). The web.holidays package contains two classes for creating public holidays (Create) and for listing and deleting existing public holidays (List). Similarly, the web.service package comprises two classes: CreateFromPortal enables to include one service requiring appointments; and ListFromPortal allows viewing and deleting services supported by the e-Appointment service. The web.appointment package contains the following classes: o NewAppointment implements the functions for showing information related to the appointment process when a new appointment is requested; Cancel implements the functions for deleting an appointment; Update implements the functions for modifying an appointment, which comprises deleting the existing appointment and creating a new appointment; AppointmentWizard implements the negotiation process for getting an appointment. It keeps information about the current step and allows moving to the previous and next steps; AppointmentPage is used to initiate the appointment process.

One more package is depicted in Figure 19 web.template. The package is shown in green colour, since it belongs to the e-Appointment Common Web Pages package. All classes in the eAppointment Portal Web Pages package are subclasses of the SecureTemplate class provided by the web-template package. The detailed design class diagram of the UI-Agency is shown in Figure 20. Five main packages are shown: i) web.center; ii) web.service; iii) web.holidays; iv) web.workingHours; and v) web.appointment. web.center package includes classes for managing the creation of a new center (Create) and for listing information about existing centers (List). In addition, it contains one class for managing the interactions when there is a request for deleting a center and there are appointments that will take place at this center (CenterPendingAppointment). web.service package includes classes for managing the creation of a new service (Create), for listing information about existing services (List), for keeping the relation between the service and the centers where appointments related to the service can take place (Center), and for listing information about these centers (ListCenters). web.holidays package includes classes for managing the creation of a new holiday or non-working day for the agency (CreateFromAgency) and for listing this information (ListFromAgency). In addition, it contains one class for managing the interactions when there is a request for creating a non-working day for an agency and there are appointments that will take place at this date (HolidayPendingAppointment).

Figure 20: Design Class Diagram e-Appointment Agency Web Pages

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

SECTION 5 DESIGN

35

web.workingHours package includes classes for managing the creation of new working hours (Create) and for listing this information (List). In addition, it contains one class for managing the interactions when there is a request for updating working hours and there are appointments that will take place at the time that will be changed (WorlkingHourPendingAppointment). web.appointment package includes classes for listing existing appointments (List) and exporting information about existing appointments to a file (Export). One more package is depicted in Figure 20 web.template. The package is shown in green colour, since it belongs to the e-Appointment Common Web Pages package. All classes in the eAppointment Agency Web Pages package are subclasses of one of the classes contained in the web.template package, although for simplicity, these relationships are only shown for the web.workingHours package. As illustrated in the figure, Create and List are subclasses of SecureTemplate; while WorkingHourPendingAppointment is a subclass of PendingAppointment. The relationships between the rest of the classes are as follows: Create and List from the web.center package, Create, List, Center and ListCenters from the web.service package, CreateFromAgency and ListFromAgency from web.holidays package; and List and Export from the web.appointment package; are all subclasses of SecureTemplate. CenterPendingAppointment, ServicePendingAppointment, HolidayPendingAppointment, and WorkingHourPendingAppointment are subclasses of PendingAppointment. 5.3.2. CORE BUSINESS LAYER The core business layer comprises three main components: Service, Util and Communication. The design class diagram for the Service component is depicted in Figure 21. The component includes the following classes: 1) ServiceFactory acts as a factory for instantiating different types of objects like concrete implementation of: IAppointmentService, IAgencyService, IWorkingHourService, IHolidayService, ICitizenService, IServiceService, and INotificationService;

2)

AppointmentService manages data and functions related to appointments; AgencyService manages data and functions related to agencies; WorkingHourService manages data and functions related to working hours; HolidayService manages data and functions related to holidays; CitizenService manages data and functions related to citizens requesting appointments; ServiceService manages data and functions related to the services requiring appointments; NotificationService manages data and function related to notifications to applicants; Host manages the reminder notifications that are sent to applicants before the appointment takes place.

3)

4)

5)

6)

7)

8)

9)

10) Sender is an abstract class for sending notifications to applicants; 11) SMSSender is a subclass of Sender responsible for sending notifications through SMS; 12) EmailSender is a subclass of Sender responsible for sending notifications through e-mails. 13) AppointmentServiceException manages the exceptions raised by processing errors. Functions of classes 2) to 8) implement the operations defined in their interfaces. The name of the interface defining the operations of the class starts with capital I and is followed by the class name; for instance, AppointmentService provides implementation for the operations defined in IAppointmentService. The design class diagram for the Util component is depicted in Figure 22. The component includes the ConfigurationParameter class for storing parameters to send notifications and other data used by the application like the id of the member to be used or the name of the current agency, among others. It is a composite class involving SMSParameter and EmailParameter classes each of these classes defines the parameters used to send notifications through SMS and e-Mail, respectively.

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

SECTION 5 DESIGN

36

Figure 21: Design Class Diagram Service

Figure 22: Design Class Diagram Util

5.3.3. DATABASE LAYER The design class diagram for the Database component is shown in Figure 24. The component includes a Generic Access Object (GenericDAO) implementing an interface (IDAO) which provides general functions for accessing the database, like add, remove, update, listAll, and findById (CRUD operations). In addition to IDAO, there are other specific interfaces, subclasses of DAO, like INotificationDao, IAppointmentDao, IServiceDao, IHolidayDao, IWorkingHoursDao, IAgencyDao, ICenterDao, ICounterDao, and ICitizenDao for defining specific operations for accessing notifications, appointments, services, holidays, working hours, agencies, centers, counters, and citizens, respectively. Similarly, in addition to GenericDAO, there are other classes, all subclasses of GenericDAO, like: NotificationManager, AppointmentManager, ServiceManager, HolidayManager, WorkingHoursManager, AgencyManager, CenterManager, CounterManager, CitizenManager for managing notifications to applicants, appointments, services, holidays, working hours, agencies, centers, counters and citizens, respectively. These classes provide implementation for the corresponding interfaces. For instance, NotificationManager implements INotificationDao. Figure 24 depicts the general design for the database. However, different data is stored in the portal database and in agency databases. For instance, the portal database stores information about agencies, services and holidays; while the agency database stores information about services, centers, counters, working hours, nonworking days, citizens, appointments, and notifications.

Finally, the Communication component involves two classes for receiving messages through the Messaging Gateway: i) AgencyApplicationListener implements a listener enabling the providing agency to receive messages; ii) PortalApplicationListener implements a listener enabling the government portal to receive messages. In addition, the XG2GSynchron class allows synchronizing the reply messages with the request messages for simulating synchronous communications based on the asynchronous communications provided by the Messaging Gateway. The XG2GSynchron implements the operations defined by the IXG2GSynchron interface for getting the reply messages. The design class diagram for the Communication component is depicted in Figure 23. Figure 23: Design Class Diagram Communication

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

SECTION 5 DESIGN

37

Figure 24: Design Class Diagram Database

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

SECTION 5 DESIGN

38

5.4. DETAILED BEHAVIOURAL DESIGN DIAGRAMS


Three detailed sequence diagrams are shown for explaining the behavior of the system. The diagrams present the collaboration between objects for: i) adding an agency; ii) deleting an agency, and iii) making an appointment. Each of these diagrams is presented in the following sections. 5.4.1. ADDING AN AGENCY The sequence diagram for adding an agency is presented in Figure 25 and is explained below. Adding an agency is part of the use case for managing agencies. The function is requested by the portal administrator (1:manageAgencies). The request is processed by the Application object, who asks the ServiceFactory to get the interface object responsible for managing agencies (2:getAgencyService). As a reply, the IAgencyService object is received

(3:IAgencyService). Application requests this object to get the list of all existing agencies (4:getAllAgencies). The IAgencyService object forwards the request to the interface of the agency entity for retrieving the list of agencies from the database (5:getAll). The replies 6:reply(listOfAgencies) and 7:reply(listOfAgencies), are sent back and presented to the user (8:listOfAgencies). After viewing the list of agencies, the user decides to add a new agency (9:addAgency). The Application object creates a new object (10:newAgency), and asks the ServiceFactory to get the interface object responsible for managing agencies (11:getAgencyService). Similarly, as a reply, the IAgencyService object is received (12:IAgencyService). Application requests this object to create the new agency (13:create). The IAgencyService object forwards the request to the interface of the agency entity to store the data in the database (14:add).

Figure 25: Sequence Diagram for Adding an Agency

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

SECTION 5 DESIGN

39

5.4.2. DELETING AN AGENCY The sequence diagram for deleting an agency is presented in Figure 25 and is explained below. Deleting an agency is part of the use case for managing agencies. Therefore, steps 1) to 9) are the same as those explained for adding an agency. After viewing the list of agencies, the user may decide to

delete an existing agency (9:deleteAgency). The Application object asks the ServiceFactory to get the interface object responsible for managing agencies (10:getAgencyService). As a reply, the IAgencyService object is received (11:IAgencyService). Application requests this object to delete the selected agency (12:delete). The IAgencyService object forwards the request to the interface of the agency entity to delete the record from the database (14:destroy).

Figure 26: Sequence Diagram for Deleting an Agency

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

SECTION 5 DESIGN

40

5.4.3. MAKING AN APPOINTMENT Making an appointment involves various collaborations among several objects. A detailed sequence diagram of the collaborations involved in the first two steps of the negotiation process is presented in Figure 27. The six objects on the left of the diagram depicted in green, reside at the portal side, while the four objects on the right depicted in orange reside at the agency side. The process starts when the user requests to make an appointment - 1:makeAppointment. The request is processed by Application, who gets the list of services and requests the user to select one 2:requestService. For simplicity, this action is shown as a simple action in the diagram; however, it involves requesting ServiceFactory to get the interface of the object managing services (IServiceService), ServiceFactory to provide this object, Application requesting IServiceService to get the list of services, and ServiceDao object getting all services from the database. Once the list of services are shown to the user, he/she selects one 3:selectedService. Application requests ServiceFactory to get the interface for the object managing Agencies (IAgencyService) 4:getAgencyService, and the object is returned 5:reply(IAgencyService). Application requests the IAgencyService to get the list of centers where appointments for the selected service can take place - 6:getCenters. IAgencyService

prepares the message to be sent to the agency 7:msgToSend, and asks the member acting on behalf of the government portal in the Messaging Gateway (p:Member) to send the message - 8:sendMessage. The member acting on behalf of the agency providing the service (ag:Member) receives the message and delivers it to the AgencyApplicationListener 9:receiveMessage. Upon interpreting the message, the AgencyApplicationListener requests the IAgencyService to get all centers. The request is forwarded to IAgencyDao 11:getAll(Centers). The reply (listOfCenters) is received by IAgencyService 12:reply(listOfServices), who forwards it to AgencyApplicationListener. When the list of centers is received by this later object, it prepares the message to be sent as reply 14:msgtoSend, and requests ag:Member to send the message 15:sendMessage. The message received by p:Member is forwarded to PortalApplicationListener - 16:receiveMessage, who sends the list of centers received to the IAgencyService 17:reply(listOfCenters). For simplicity, action 16 is shown as a single interaction but it involves collaboration from IXG2GSynchron for synchronizing the request and the reply messages. IAgencyService sends the reply to Application 18:reply(listOfCenters), who shows the list of centers to the user 19:listOfCenters. Finally, the user selects the center 20:selectedCenter.

Figure 27: Sequence Diagram for Making an Appointment Steps 1 and 2

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

SECTION 5 DESIGN

41

Step 2 of the process involves Application requesting the user to provide appointment-related information, like the preferred channel for notifications and a text message to the provider agency 21:requestApplicantInformation, and the user provides these data 22:applicantData. In addition, Application requests the appointment date 23:requestDate, and the user selects his/her preferred date 24:selectedDate. The collaborations involved for executing the third and fourth step of the appointment negotiation process are shown in Figure 28. As in the previous figure, the seven objects on the left depicted in green, reside at the portal side, while the four on the right depicted in orange, reside at the agency side. In Step 3, after receiving the date selected by the user, Application requests IAgencyService to get the working hours 1:getWorkingHours. IAgencyService prepares the message to be sent to the agency 2:msgToSend, and requests the p:Member

to send the message 3:sendMessage. ag:Member receives the message, and forwards it to AgencyApplicationListener 4:receiveMessage, who asks IAgencyService to get the working hours 5:getWorkingHours. For simplicity, collaborations between IAgencyService, IServiceService, IWorkingHoursService, and IWorkingHoursDAO for getting this information from the database are not shown. Once IAgencyService has the information about working hours, it replies to AgencyApplicationListener 6:reply(workingHours), who prepares the message to be sent to the portal 7:msgToSend, and sends the message 8:sendMessage. The member at the portal, after receiveing the message, forwards it to PortalApplicationListener 9:receiveMessage. Reply messages are sent back to the objects requesting the information 10:reply(workingHours), 11:reply(working Hours), and 12: workingHours. Finally, based on the available hours, the user selects their choice 13:selectedTime.

Figure 28: Sequence Diagram for Making an Appointment Steps 3 and 4

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

SECTION 5 DESIGN

42

In Step 4, after receiving the time selected by the user, Application request a confirmation of the appointment 14:requestConfirmation, and the user confirms 15:confirmation. Application requests ServiceFactory to get the interface object for managing appointments (p:IAppointmentService) 16:getAppointmentService, and receives the object as reply 17:reply(IAppointmentService). Application requests IAppointmentService to create a new appointment 18:newAppointment. Therefore, p:IAppointmentService prepares the message to be sent to the agency 19:msgToSend, and requests p:Member to send the message 20:sendMessage. ag:Member, after receiving the message, forwards it to AgencyApplicationLis-

tener 21:receiveMessage. AgencyApplicationListener requests the IAppointmentService at the agency side (ag:IAppointmentService) to create the new appointment 22:createAppointment. Further collaborations, not shown in the diagram, take place among ag:IAppointmentService and IAppointmentDao to store the record in the database. After updating the database, AgencyApplicationListener creates a message to confirm the registration of the appointment at the agency 23:msgToSend, and requests ag:Member to send the message 24:sendMessage. After receiving the message, p:Member forwards it to PortalApplicationListener. All replies are sent back through all the objects involved, until the user is informed 2627-28:reply(appointmentConfirmed).

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

SECTION 6 IMPLEMENTATION

43

6. IMPLEMENTATION
The following three sections provide a general overview of the implementation phase of the e-Appointment service (Section 5.1), technologies used (Section 5.2), and further customization details that could improve the current functionality (Section 5.3).

6.1. OVERVIEW
Figure 29 presents the implemented components, the relationships among them, and the relationships with other software infrastructure components depicted in orange.

Figure 29: Implementation Diagram

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

SECTION 6 IMPLEMENTATION

44

Five packages were implemented: i) User Interface - Portal implementing the user interface for users and the portal administrator; ii) User Interface Agency implementing the user interface for service providers; iii) e-Appointment Core Business implementing the business logic, iv) Entities a set of classes for manipulating the data structure of each entity; and vi) Database implementing data persistence through the database. The Messaging Gateway xG2G, a software infrastructure component used by the e-Appointment service is also depicted. In addition, a configuration file for the eAppointment service is provided eAppointConfigurationFile. As explained in Section 5.3, the user interface packages include three components: UI-Common, UI-Portal and UI-Agency. UI-Common, through the Application class, uses the IVisitor interface provided by the Messaging Gateway to restart a member either a member acting on behalf of the portal, or a member acting on behalf of a providing agency. It also uses the Util component to access the configuration file. UIPortal uses IXG2GSynchron, an interface provided by the Communication component to synchronize requests and replies between the portal and the agencies. All three UI-Common, UI-Portal, and UIAgency; use the interfaces of the core business layer provided by the Service component. These inferfaces include: IAgencyService, IAppointmentService, IHolidayService, INotificationService, and IServiceService. The CoreBusiness package includes three components: i) Service, ii) Communication, and iii) Util. As explained above, the Service component provides the interfaces required by the user interface layer. In addition, it uses the interfaces provided by the Database component IDAO and all its sub-classes, and the IMember interface provided by the Messaging Gateway, as well as the component for sending notification Utils. The Communication component implements the IXG2GSynchron interface used by UIPortal and the ApplicationListener used by the Messaging Gateway. In addition, it uses the Service component for processing the received messages. The Util component uses the eAppointmentConfigurationFile. All three components Service, Communication and Util, use the Entities component for processing the entity data structures. The Database package implements a general interface IDAO used by the core business layer. IDAO is refined by several interfaces one for each table of the database, like, IAgencyDao, IServiceDao, ICenterDao, IHolidayDao, IWorkingHourDao, ICitizenDao, INotificationDao, and IAppointmentDao. The classes contained in this package use the classes of the Entities package.

The Entities package provides one class for managing every entity. The package is used by all other packages: User Interface Portal, User Interface Agency, Core Business, and Database. The specification of eAppointmentConfigurationFile is included in Appendix C. The following parameters are defined in the file: o memberId - identification of the member acting on behalf of the software applications deployed on the node agencyName - identification of the hosting agency agencyDescription full name of the hosting agency channelId - identification of the channel used by the hosting agency to communicate with the government portal type - role of the application deployed at the node. The possible values include: portal and agency; numbermonth number of months in advance when appointment can be booked . For instance, if the current date is 6 February 2009, it will allow to book appointments till 6 May 2009. Parameters for sending notifications through emails, like: o o o emailserver - smtp server , emailport - smtp port number, isemailauthenticationrequired - flag for indicating if authentication is required for sending e-mails. The possible values are true and false, sendermail - e-mail address of the sender, emailsenderpassword - password for authenticating the sender, istlsenabled - flag for indicating if transport layer security (tls) is enabled; emailtemplate text of the e-mail to be sent to the applicant as a reminder of the appointment

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

SECTION 6 IMPLEMENTATION

45

newnotificationtemplate text of the e-mail to be sent to the applicant as a confirmation of the appointment. updatenotificationtemplate text of the e-mail to be sent to the applicant as a confirmation of the updated appointment. cancelnotificationtemplate text of the e-mail template to be sent to the applicant as a confirmation of the cancelled appointment.

1)

number of appointments per citizen in order to avoid misusing the service., For instance, a citizen booking most of the appointments. A bound is defined to set the maximum number of appointments a citizen can request; and number of months a bound is defined for showing future days in the calendar when the user is requesting or updating an appointment.

2)

6.2. TECHNOLOGIES
The guiding principle for implementing the eAppointment Service was to adopt open-source technologies and open-standards. Therefore, all software components were implemented in Java [12][13]. The database used is MySQL [14][15], and Hibernate [16][17] is applied for the object-relational mapping. Messages are written using eXtensible Markup Language (XML) [18][19], and composed and decomposed using XMLBeans [20]. The exchange of messages is supported by the e-Macao Messaging Gateway [21]. Log4J [22] API is used for logging messages, and JavaMail [23] for sending e-mails. The development framework used for implementing the web application is Apache Wicket 1.3.4 [11]. The web server used for deploying the web application is Apache Tomcat 6 [24], and the Spring 2.5 [25] container is used to instantiate different objects. The set of technologies used by the e-Appointment service is depicted in Table 12.

Parameters for sending notifications through SMS, like: o username name of the user holding the account used for sending SMS smsuserpassword password of the user holding the account used for sending SMS smsapiid key enabling the user to send SMS smstemplate text of the SMS to be sent to the applicant as a reminder of the appointment.

Two bounds are defined in the configuration file:

Table 12: Technologies Used by e-Appointment Service Appointment Application Technologies LANGUAGE DATABASE OBJ.-REL. MAPPING MESSAGING OBJECT-XML MAPPING LOGGING FRAMEWORK MAIL FRAMEWORK WEB FRAMEWORK WEB SERVER CONTAINER Java 1.6 MySQL 5 Hibernate 3.2 xG2G 1.0 (e-Macao infrastructure) XMLBeans 2.3.0 Log4j 1.2 JavaMail Apache Wicket 1.3.4 Apache Tomcat 6 Spring 2.5

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

SECTION 6 IMPLEMENTATION

46

6.3. IMPROVEMENTS
The current release presents a prototype implementation of the e-Appointment service that could be improved in different ways. Three areas of improvements are identified and discussed in the following sections; integration with other software infrastructure components (Section 6.3.1), service parameterization (Section 6.3.2) and service reliability (Section 6.3.3). 6.3.1. SERVICE INTEGRATION The proposed e-Appointment service aims to deliver a general solution for managing appointments supporting the delivery of public services, as part of the software infrastructure for Electronic Government. Therefore, like other e-services, it should be integrated with software infrastructure components and services. In particular, we discuss the integration with authentication and notification services, a multi-channel delivery strategy, and the government portal database. An authentication service is usually provided as part of the software infrastructure for Electronic Government, which enables users to prove their identity before accessing some public services. In order to deliver these services following a customer-focus approach through a one-stop contact, the user should be requested to authenticate only once and gain access to different services single sign on. Therefore, the e-Appointment service should be integrated with the authentication service already in place. In the current release, a web page is used for simulating the need for authentication. The integration of the e-Appointment service with an authentication service shall discard the use of the eAppointment authentication page, and replace it by an invocation to the authentication service. The SecureTemplate class of the web.Template component should be modified. A notification service which enables notification of applicants through various channels can also be part of the software infrastructure for Electronic Government. If so, notifications should be sent by this infrastructure service and not by the e-Appointment service. The integration of the e-Appointment service with a notification service will require introducing changes to the following classes in the Service component: i) Sender for invoking the infrastructure notification service instead of sending the notifications itself; and ii) Host likewise, for sending the reminder notifications. In addition, the current release uses the services of Clickatell for sending SMS notifications. In the future, the interface with Clickatell [26] should be replaced by the interface to the telecommunication company chosen by the government. A multi-channel delivery approach for delivering public services requires providing access to a centralized database containing information about citizens, like the citizens contact details for each channel. Therefore, this

data should not be handled by the e-Appointment service, but by some other infrastructure component. However, the e-Appointment service can request from the applicant which is his preferred channel for receiving appointment-related notifications and manage this information. The integration of the e-Appointment service with a multi-channel delivery strategy will require changes to the data manipulated in the second step of the appointment negotiation process. In such case, the AppointmentWizard class of the web.Appointment component shall be modified, as well as the class managing persistence in the database CitizenDao. The current implementation of the e-Appointment service manages information that should be part of the government portal database. For instance, public holidays. The integration of e-Appointment and government portal databases will require replacing the function for updating public holidays in the e-Appointment database by a function retrieving this information from the portal database. In addition, it will require keeping in the eAppointment database at the portal side, only the list of agencies and services using e-Appointment service, and validating that these agencies and services exist in the corresponding tables of the portal database. One more improvement is to automatically update the table of services requiring appointments at the portal by exchanging messages through the Extensible Messaging Gateway every time a service is updated in the providing agency. In addition, the e-Appointment service could be integrated with other software applications supporting the delivery of services for which appointments are requested. One possible scenario for such integration is already supported by the current release through the function exporting an XML file with information about the appointments for a given date. Further improvements could consider importing appointment-related information from these applications for udating the database managed by the e-Appointment service. 6.3.2. SERVICE PARAMETERIZATION The e-Appointment service aims to provide a general solution for making appointments for delivering various public services. Each of these services may have its own requirements related to applicants authentication, notification texts, and number of appointments required for the service delivery, among others. A general solution for addressing these specific service needs can be provided through parameterization. Therefore, possible improvements related to service parameters could be introduced in further releases. For instance, the following service-related parameters are proposed to be introduced:

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

SECTION 6 IMPLEMENTATION

47

isAuthenticationRequired a flag for indicating if the appointment requires or not applicants authentication; o appointmentPre-requisites each service may have its own prerequisites for applicants attending appointments. For instance, the applicant should present some supporting documents during the appointment; the applicant should not eat within certain amount of hours prior to the appointment, in case of medical analysis; and others. Managing these appointment pre-requisites in the eAppointment service will enable reminding the applicant about such prerequisites when sending the notifications confirming and reminding the appointment. numberOfAppointments a general parameter is defined in the configuration file of the eAppointment service for controlling that an applicant is not allowed to book more than a given number of appointments. Since the number of appointments required for delivering a service depends on the service, it would be advisable to define the number of admissible appointments for a citizen as a service related parameter. monthsAheadForBookingAppointments likewise the previous case, a general parameter is defined for setting the number of months ahead for arranging appointments. However, the completion time of the business process for delivering services depends on the service. Therefore, a proposed im-

provement is to define the months ahead for booking appointments as a service related parameter. notificationTexts each service may need to define different texts for notifying applicants about appointments. Moreover, different texts may be required for each delivery channel. In the current release, the configuration file manages different parameters for notification texts for reminding applicants through e-mail and through SMS, and for confirming, changing and cancelling an appointment (same text regardless the channel used for sending notifications). A proposed improvement is to define notifications texts for each delivery channel, as service-related parameters.

Finally, an improvement is proposed for providing a function enabling service providers to update servicerelated parameters. 6.3.3. SERVICE RELIABILITY In the current release, it may happen that the member acting on behalf of the e-Appointment service at the agency side is not available when the application at the government portal is trying to exchange information with it. Therefore, an alternative mechanism shall be provided for such cases in order to improve reliability. Possible solutions include providing a secondary database at the government portal with information updated daily through batch processes, and enssuring members are deployed on servers, among others.

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

SECTION 7 DEPLOYMENT

48

7. DEPLOYMENT
There is only one deployment component eAppointmentService providing the functionality for all users. Depending on the value defined for the parameter type in the configuration file, the component plays two roles: i) Portal provides the functionality for the portal administrator and users requesting appointments - e-Appointment Service (P); and ii) Agency provides the functionality for service providers e-Appointment Service (A). Figure 30 presents a possible deployment scenario for the software components. The node Government Portal represents the Portal role, while all other nodes correspond to the Agency

role. In any deployment scenario, there must be only one node playing the Portal role, and as many nodes as required hosting the e-Appointment Service with the Agency role at least as many as government units using the e-Appointment service. The Portal Component corresponds to the government portal application, which may or may not be deployed on the same node as e-Appointment Service (P). While deploying the e-Appointment Service, the e-AppointmentDatabase is created on the hosting node. The libraries of the Messaging Gateway xG2G, are required on all nodes hosting an eAppointment Service component. As depicted in Figure 30, Portal uses e-Appointment Service (P), and the e-Appointment Service, regardless of its role, uses the e-AppointmentDatabase and xG2G.

Figure 30: Deployment Diagram A Possible Scenario

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

SECTION 8 CONCLUSIONS

49

8. CONCLUSIONS
This report presents technical details of the eAppointment service development. The development was carried out by UNU-IIST Center for Electronic Government during 2008 for the Government of Macao SAR, under the Macao Data Exchange Gateway Project, part of the e-Macao Program. The e-Appointment service enables booking of appointments between service consumers and service providers related to public service delivery. The proposed solution presents a general approach for managing appointments supporting the delivery of services provided by different agencies. The appointmentrelated information exchanged between the government portal and the agencies is supported by the Extensible Messaging Gateway [1]. The service can be considered part of the software infrastructure for Electronic Government. The e-Appointment service is built upon the following concepts: i) appointment an arrangement between parties for interacting at a certain time and place for a specific purpose; ii) appointment negotiation process required steps for making an appointment; iii) service a public service requiring appointments as part of its delivery process; iv) center a physical or virtual place where appointments are held; v) public holiday a day on which government agencies are officially closed; vi) non-working day a day on which an agency is not serving customers; and vii) working hours a period of time in which appointments can be arranged. The service distinguishes three types of users: i) portal administrator a person responsible for administering the government portal; ii) service providers administrators of the government units delivering services; and iii) service consumers persons who request appointments. Portal administrator is responsible for maintaining information about the government agencies delivering services requiring appointments, services for which appointments can be requested, and public holidays. Service providers are responsible for managing information about services delivered by them, centers in which these services are delivered, non working days and working hours. In addition, they can view and export the arranged appointments for a given day. Service consumers can make, change or cancel an appointment. They are notified about appointments made and re-

minded about coming appointments. In the current release, these notifications are delivered through e-mail and SMS. This report presented the development stages followed for implementing the software component. It also introduced some of the development artifacts produced. An introduction to the project scope, its aim and objective were presented in Section 1. Section 2 introduced some background for developing an e-Appointment service. The motivation for an e-Appointment service was presented, as well as e-Appointment-related concepts, business process, implementation approach, challenges for implementing and delivering the service, and case studies. Section 3 presented functional and nonfunctional requirements for the e-Appointment service. A set of functional requirements was introduced for specifying the functionality to be provided to the portal administrator, service providers and consumers. Four non-functional requirements were specified, related to: i) reliability, ii) security, iii) generality and iv) interoperability. A domain conceptual model and a use case model were presented in Section 4. In addition, the section introduced cross-references between the functional requirements identified in Section 3 and the use cases defined. The service top level and detailed design were explained in Section 5. Static and dynamic views of the architecture were presented, as well as design class diagrams and sequence diagrams explaining the structure and behavior of the service, respectively. Section 6 presented implementation details including some technologies used, and possible improvements to the current release. Section 7 illustrated a possible deployment scenario. Finally, appendices describing glossary of terms, configuration file, XML schemas, Application Programming Interfaces (APIs), and main Java classes were included. The main contributions of the e-Appointment development process include: i) providing a prototype solution for managing appointments in delivering public services, ii) presenting a general solution that can be used for delivering any service requiring appointments, iii) illustrating the exploitation of the Extensible Messaging Gateway, and iv) proposing enhancements based on the experience gained. This development report is complemented by the eAppointment User Manual [27]. Information about the project is also available at the project website [28].

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

REFERENCES

50

REFERENCES
[1] Elsa Estevez, Vincent Douwe and Tomasz Janowski, Extensible Messaging Gateway - Enhanced Services and New APIs, Macao Data Exchange Gateway Project, UNU-IIST-EGOV, February 2009. [2] Merrrian-Webster Online, available at http://www.merriam-webster.com/, visited on 25 January 2009. [3] Ralf Klischewski, The Challenges of e-Appointment: Process Modeling, Infrastructure, and Organizational Context, available at http://swtwww.informatik.unihamburg.de/publications/./files/ibim_klischewski.pdf visited on 25 January 2009. [4] Tomasz Janowski, Adegboyega Ojo and Elsa Estevez (Eds), The State of Electronic Government in Macao, Volume 2 Agencies, e-Macao Project, available at www.emacao.gov.mo, Deliverables - Survey, report 2, visited on 25 January 2009. [5] National Organization for Medicines (EOF), Ministry of Health, Government of Greece, http://eof1.eof.gr/eof_en/enhome.html. [6] S. Giannakou, Providing e-Appointment System to Pharmaceutical Companies for Licensing Applications and Guidance, Validation of Applications and Marketing Authorization Division (DDYEP), National Organization for Medicines (EOF), Government of th Greece, 5 Quality Conference for Public Administration in the EU, Paris, 20-22 October 2008, available at www.5qualiconference.eu/bib_res/364.pdf, 27 January 2009. [7] Ministry of Home Affairs, Government of Singapore, Inmigration and Checkpoints Authority (ICA), http://ica.gov.sg. [8] Ministry of Home Affairs, Government of Singapore, E-Appointment at ICA, https://eappointment.ica.gov.sg/ibook/index.do, visited 26 January 2009. [9] Ministry of Manpower, Government of Singapore, Labour Relations and Worplace Division, http://www.mom.gov.sg/publish/momportal/en/a bout_us/divisions_and_statutory/labour_relations_ department.html, visited 27 January 2009. [10] Ministry of Mapower, Government of Singapore, EAppointment at LRWD,

http://app.etools.mom.gov.sg/eindex.aspx, visited 27 January 2009. [11] Apache Wicket, http://www.wicket.apache.org, visited 3 February 2009. [12] Herbert Schildt, Java 2 The Complete Reference, th Osborne, 5 Edition, 2002. [13] Sun Microsystems, The Java Tutorial, 2004, http://java.sun.com/docs/books/tutorial. [14] Sun Microsystems, MySQL, http://www.mysql.com. [15] Paul DuBois, MySQL Cookbook, OReilly, November 2006. [16] Hibernate, Relational Persistence for Java and .Net, http://www.hibernate.org. [17] Christian Bauer and Gavin King, Hibernate in Action (In Action series), Hanning, August 2004. [18] W3C, Extensible Markup http://www.w3.org/XML/. Language (XML),

[19] Erik T. Ray, Learning XML, OReilly, 2001. [20] The Apache XML Project, Apache XMLBeans, http://xmlbeans.apache.org. [21] Vincent Douwe, Elsa Estevez, Tomasz Janowski, Extensible Message Gatewa - Development Report, Software Infrastructure for e-Government Project, UNU-IIST-EGOV, April 2008. [22] Logging Apache Org, Logging Services (LOG4J), http://logging.apache.org/log4j/1.2/index.html. [23] Sun Developer Network (SDN), J2EE Java Mail, http://java.sun.com/products/javamail/. [24] The Apache Software Foundation, Apache Tomcat, http://tomcat.apache.org. [25] The Spring Source http://www.springsource.org/. Community,

[26] Clickatell, Any message, Anywhere, Messaging Solutions, http://www.clickatell.com/solutions.php. [27] Elsa Estevez, Vincent Douwe, and Tomasz Janowski, e-Appointment Service User Manual, Macao Data Exchange Gateway Project, UNU-IIST-EGOV, February 2009. [28] Macao Data Exchange Gateway Project, http://www.egov.iist.unu.edu/index.php?/cegov/p rojects/infras-tructure. [29] Elsa Estevez, Vincent Douwe and Tomasz Janowski, Extensible Messaging Gateway Quality Assurance Report, Macao Data Exchange Gateway Project, UNU-IIST-EGOV, September 2008.

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

51

APPENDICES
A. GLOSSARY
ID T1 TERM Agency DESCRIPTION An administrative division of the government providing and receiving services. An arrangement between parties for interacting at a certain time and place for a specific purpose. The process of determining whether a member is authentic and eligible to access the e-Appointment service and its data. The process involves using the authentication service provided by the software infrastructure. A place where appointments can take place. Members, Channels, and Extensions of the Messaging Gateway used for information exchange. File storing parameters used by some functions of the service. A place, usually physical, where customers can be served. To generate information and store it in a file to be used by another software application. A delivery channel for sending notifications. A day in which appointments cannot be arranged. Acknowledgement of a fact. The e-Appointment service shall send notifications every time an appointment is confirmed or cancelled. A criteria for classifying notifications based on the delivery channel used for sending notifications. Person responsible for maintaining the Government Portal. A day in which government agencies are officially closed. The ability of a system or component to perform its required function under stated conditions for a specified period of time (IEEE). Time in advance from the appointment, in which a notification to the applicant will be sent for reminding him/her about the appointment. The outcome produced and delivered in interaction between a service provider and a service consumer in order to benefit the consumer or fulfill the consumers needs. A person or entity receiving a public service. A government unit providing services.

T2

Appointment

T3

Authentication

T4 T5

Center Communication Structures

T6 T7 T8

Configuration File Counter Export

T9 T10 T11

e-Mail Non-working Day Notification

T12

Notification Type

T13 T14 T15

Portal Administrator Public Holiday Reliability

T16

Reminder Notification Time

T17

Service

T18 T19

Service Consumer Service Provider

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

52

T20

Service Time

Service-related time that is required for serving one customer. The appointment between service provider and consumer will last at most the service mean time. A delivery channel for sending notifications SMS is the acronym of Short Message Service. Any person accessing the e-Appointment service. Time frame for arranging appointments.

T21

SMS

T22 T23

User Working Hour

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

53

B. XML SCHEMAS
B.1. SCHEMA FOR EXCHANGED MESSAGES XML Schema 1: Exchanged messages Schema <schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="http://egov.iist.unu.edu/emacao/queue/messages" elementFormDefault="qualified" xmlns:Q1="http://egov.iist.unu.edu/emacao/queue/messages"> <complexType name="NewAppointment"> <sequence> <element name="CustomerId" type="string" maxOccurs="1" minOccurs="1"> </element> <element name="CustomerName" type="string" maxOccurs="1" minOccurs="1"> </element> <element name="Date" type="date" maxOccurs="1" minOccurs="1"> </element> <element name="ServiceCode" type="string" maxOccurs="1" minOccurs="1"> </element> <choice maxOccurs="1" minOccurs="1"> <element name="EmailAddress" type="string"></element> <element name="MobilePhone" type="string"></element> </choice> <element name="Time" type="time" maxOccurs="1" minOccurs="0"> </element> <element name="Error" type="Q1:ErrorType" maxOccurs="1" minOccurs="0"> </element> <element name="ErrorDescription" type="string" maxOccurs="1" minOccurs="0"> </element> <element name="Details" type="string"></element> <element name="center" type="string" maxOccurs="1" minOccurs="1"> </element> </sequence> </complexType> <complexType name="UpdateAppointment">

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

54

<sequence> <element name="Service" type="string" maxOccurs="1" minOccurs="1"> </element> <element name="CustomerId" type="string" maxOccurs="1" minOccurs="1"> </element> <element name="Date" type="date" maxOccurs="1" minOccurs="1"> </element> <element name="NewDate" type="date" maxOccurs="1" minOccurs="1"> </element> <element name="Error" type="Q1:ErrorType" maxOccurs="1" minOccurs="0"> </element> <element name="ErrorDescription" type="string" maxOccurs="1" minOccurs="0"> </element> <element name="Center" type="string" maxOccurs="1" minOccurs="1"> </element> <element name="Time" type="time" maxOccurs="1" minOccurs="1"></element> </sequence> </complexType> <complexType name="TrackAppointment"> <sequence> <element name="Service" type="string" maxOccurs="1" minOccurs="1"> </element> <element name="Date" type="date" maxOccurs="1" minOccurs="1"> </element> <element name="Error" type="Q1:ErrorType" maxOccurs="1" minOccurs="0"> </element> <element name="ErrorDescription" type="string" maxOccurs="1" minOccurs="0"> </element> <element name="center" type="string" maxOccurs="1" minOccurs="1"> </element> <element name="number" type="int" maxOccurs="1" minOccurs="0"></element> </sequence>

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

55

</complexType> <complexType name="CancelAppointment"> <sequence> <element name="Service" type="string" maxOccurs="1" minOccurs="1"></element> <element name="Date" type="date" maxOccurs="1" minOccurs="1"></element> <element name="CustomerId" type="string" maxOccurs="1" minOccurs="1"></element> <element name="Error" type="Q1:ErrorType" maxOccurs="1" minOccurs="0"></element> <element name="ErrorDescription" type="string" maxOccurs="1" minOccurs="0"></element> </sequence> </complexType> <simpleType name="ErrorType"> <restriction base="string"> <enumeration value="SUCESS"></enumeration> <enumeration value="FAILURE"></enumeration> <enumeration value="UNKNOWN"></enumeration> <enumeration value="NO_APPOINTMENT"></enumeration> </restriction> </simpleType> <simpleType name="MessageType"> <restriction base="string"> <enumeration value="REQUEST"></enumeration> <enumeration value="REPLY"></enumeration> </restriction> </simpleType> <complexType name="QueueMessages"> <sequence> <element name="Type" type="Q1:MessageType" maxOccurs="1" minOccurs="1"> </element> <choice maxOccurs="1" minOccurs="1"> <element name="newAppointment" type="Q1:NewAppointment"> </element> <element name="tractAppointment" type="Q1:TrackAppointment"> </element> <element name="cancelAppointment" type="Q1:CancelAppointment"> </element> <element name="updateAppointment" type="Q1:UpdateAppointment">

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

56

</element> <element name="listDates" type="Q1:ListDates"></element> <element name="listCenters" type="Q1:ListCenters"></element> </choice> <element name="messageId" type="long" maxOccurs="1" minOccurs="1"></element> </sequence> </complexType> <element name="QueueMessage" type="Q1:QueueMessages"></element> <complexType name="DateInterval"> <sequence> <element name="MinDate" type="time"></element> <element name="MaxDate" type="time"></element> </sequence> </complexType> <complexType name="ListDates"> <sequence> <element name="Service" type="string" maxOccurs="1" minOccurs="1"> </element> <element name="MeanTime" type="int" maxOccurs="1" minOccurs="0"> </element> <element name="OldDate" type="date" maxOccurs="1" minOccurs="0"> </element> <element name="Occupied" type="Q1:DateInterval" maxOccurs="unbounded" minOccurs="0"> </element> <element name="Error" type="Q1:ErrorType" maxOccurs="1" minOccurs="0"> </element> <element name="ErrorDescription" type="string" maxOccurs="1" minOccurs="0"> </element> <element name="WorkHours" type="Q1:DateInterval" maxOccurs="unbounded" minOccurs="0"> </element> <element name="center" type="string" maxOccurs="1" minOccurs="1"> </element> <element name="customerId" type="string" maxOccurs="1" minOccurs="1">

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

57

</element> <element name="NewDate" type="date" maxOccurs="1" minOccurs="1"></element> </sequence> </complexType> <complexType name="ListCenters"> <sequence> <element name="service" type="string" maxOccurs="1" minOccurs="1"> </element> <element name="center" type="string" maxOccurs="unbounded" minOccurs="0"> </element> <element name="errorType" type="Q1:ErrorType" maxOccurs="1" minOccurs="0"> </element> <element name="errorDescription" type="string" maxOccurs="1" minOccurs="0"> </element> <element name="customerId" type="string" maxOccurs="1" minOccurs="0"></element> </sequence> </complexType> </schema>

B.2. SCHEMA FOR EXPORTING APPOINTMENTS XML Schema 2: Schema for Exporting Appointments <schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="http://egov.iist.unu.edu/emacao/queue/export" xmlns:tns="http://www.example.org/export" elementFormDefault="qualified" xmlns:Q1="http://egov.iist.unu.edu/emacao/queue/export"> <complexType name="Appointment"> <sequence> <element name="ServiceCode" type="string" maxOccurs="1" minOccurs="1"></element> <element name="Time" type="time" maxOccurs="1" minOccurs="1"></element> <element name="CitizenId" type="string" maxOccurs="1" minOccurs="1"></element> <element name="CitizenName" type="string" maxOccurs="1" minOccurs="1"></element> <element name="CitizenContact" type="string" maxOccurs="1" minOccurs="1"></element> <element name="ServiceCenter" type="string" maxOccurs="1" minOccurs="1"></element> </sequence> </complexType>

<complexType name="ListAppointment"> <sequence>

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

58

<element name="Date" type="date" maxOccurs="1" minOccurs="1"></element> <element name="Appointments" type="Q1:Appointment" maxOccurs="unbounded" minOccurs="0"></element> </sequence> </complexType> <element name="Appointments" type="Q1:ListAppointment"></element> </schema>

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

59

C. CONFIGURATION FILE
C.1. E-APPOINTMENT CONFIGURATION FILE Configuration File 1: e-Appointment Configuration File # Define the member id used by this agency memberId=100001 # The name of the hosting agency agencyName=SAFP # The description of the agency agencyDescription=Public Administration and Civil Service Bureau # Specifies the channel used for communication with the portal. It is only used by the agencies. channelId=500001 # Defines the type of deploiment. Possible values are agency and portal type=agency # Define the parameters required for sending email # Defines the smtp server emailserver=mailhost.iist.unu.edu # Defines the smtp port number. Default is 25 emailport=25 # Defines the sender password. Can be blank in case no password is required emailsenderpassword= # Defines if authentification is required. Possible values true or false isemailauthenticationrequired=false # Defines the address used to send emails senderemail=vincent@iist.unu.edu # Specifies if the tls need to enabled to send emails. Possible values are true or false istlsenabled=false # Define the parameters required for sending sms using the clickatell sms gateway # The user account at clickatell smsuser=douwevincent # The user password

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

60

smsuserpassword= # Defines the api key to be used smsapiid= # Define the number of months in advance that we can make an appointment. The default value is 3 numbermonth=3 # Define the number of appointment a citizen can make. The default value is 2 numberappointment=2 # Define the email template to send to the appointment maker to remind him about his appointment emailtemplate=Mr./Mrs <<name>>. This message is to inform you that \ you have an appointment with <<agency>> today at <<time>>. \ We look forward to meeting you. # Define the sms template to send to the appointment maker to remind him about his appointment smstemplate=Mr./Mrs <<name>>. This message is to inform you that you \ have an appointment with <<agency>> today at <<time>>. \ We look forward to meeting you. # Define the email template to send to the appointment maker to confirm the appointment newnotificationtemplate=Mr./Mrs <<name>>, this message is to inform you \ that your appointment with <<agency>> at the center <<center>> is confirmed for <<date>> at <<time>>. \ We look forward at meeting you. # Define the email template to send to the appointment maker when an appointment is updated updatenotificationtemplate=Mr./Mrs <<name>>, this message is to inform you that the date your appointment with \ <<agency>> at the center <<center>> was successfully updated. The new date is <<date>> and the time is <<time>> \ We look forward at meeting you. # Define the email template to send to the appointment maker when an appointment is canceled cancelnotificationtemplate=Mr./Mrs <<name>>, this message is to inform you that your appointment with \ <<agency>> at the center <<center>> on <<date>> at <<time>> is successfully cancelled. \ We look forward at meeting you in the future.

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

61

C.2. SPRING CONFIGURATION FILE Configuration File 2: Spring Configuration File <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:tx="http://www.springframework.org/schema/tx" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-2.0.xsd"> <!-- Configuring the DAO layer --> <bean id="agencyManager" class="edu.unu.iist.emacao.queuing.database.impl.AgencyManager" /> <bean id="agencyCenterManager" class="edu.unu.iist.emacao.queuing.database.impl.AgencyCenterManager" /> <bean id="centerDetailsManager" class="edu.unu.iist.emacao.queuing.database.impl.CenterDetailsManager" /> <bean id="notificationManager" class="edu.unu.iist.emacao.queuing.database.impl.NotificationManager" /> <bean id="appointmentManager" class="edu.unu.iist.emacao.queuing.database.impl.AppointmentManager" /> <bean id="customerManager" class="edu.unu.iist.emacao.queuing.database.impl.CustomerManager" /> <bean id="holidayManager" class="edu.unu.iist.emacao.queuing.database.impl.HolidayManager" /> <bean id="serviceManager" class="edu.unu.iist.emacao.queuing.database.impl.ServiceManager" /> <bean id="servingDetailsManager" class="edu.unu.iist.emacao.queuing.database.impl.ServingDetailsManager" /> <bean id="workingHoursManager" class="edu.unu.iist.emacao.queuing.database.impl.WorkingHoursManager" /> <!-- Configuring the Service layer --> <bean id="agencyService" class="edu.unu.iist.emacao.queuing.service.impl.AgencyService"> <property name="agencyDao" ref="agencyManager" /> <property name="agencyCenterDao" ref="agencyCenterManager" /> <property name="centerDetailsDao" ref="centerDetailsManager" /> <property name="serviceService" ref="serviceService" /> <property name="serviceDao" </bean> <bean id="customerService" class="edu.unu.iist.emacao.queuing.service.impl.CustomerService"> <property name="customerDao" ref="customerManager" /> </bean> <bean id="notificationService"
UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

ref="serviceManager" />

APPENDICES

62

class="edu.unu.iist.emacao.queuing.service.impl.NotificationService"> <property name="notificationDao" ref="notificationManager" /> </bean> <bean id="appointmentService" class="edu.unu.iist.emacao.queuing.service.impl.AppointmentService"> <property name="appointmentDao" ref="appointmentManager" /> <property name="customerDao" ref="customerManager" /> <property name="serviceDao" ref="serviceManager" /> <property name="notificationDao" ref="notificationManager" /> <property name="agencyCenterDao" ref="agencyCenterManager" /> <!-- <property name="xg2gSynchron" ref="xg2gSynchron" /> --> </bean> <bean id="holidayService" class="edu.unu.iist.emacao.queuing.service.impl.HolidayService"> <property name="holidayDao" ref="holidayManager" /> <property name="agencyDao" ref="agencyManager" /> <property name="agencyCenterDao" ref="agencyCenterManager" /> </bean> <bean id="workingHourService" class="edu.unu.iist.emacao.queuing.service.impl.WorkingHourService"> <property name="workingHourDao" ref="workingHoursManager" /> </bean> <!-- <bean id="xg2gSynchron" class="edu.unu.iist.emacao.queuing.xg2g.XG2GSynchron"/> --> <bean id="serviceService" class="edu.unu.iist.emacao.queuing.service.impl.ServiceService"> <property name="serviceDao" ref="serviceManager" /> <property name="centerDetailsDao" ref="centerDetailsManager" /> <property name="agencyCenterDao" ref="agencyCenterManager" /> <property name="servingDetailsDao" ref="servingDetailsManager" /> </bean> <bean id="serviceFactory" class="edu.unu.iist.emacao.queuing.service.ServiceFactory"> <property name="serviceService" ref="serviceService" /> <property name="workingHourService" ref="workingHourService" /> <property name="holidayService" ref="holidayService" /> <property name="appointmentService" ref="appointmentService" /> <property name="agencyService" ref="agencyService" /> <property name="customerService" ref="customerService" /> <property name="notificationService" ref="notificationService" /> </bean> <!-- Configuring JPA layer --> <bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean"> <property name="dataSource" ref="dataSource" /> <property name="jpaVendorAdapter"> <bean class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter"> <property name="showSql" value="false" /> <property name="databasePlatform" valUNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

63

ue="org.hibernate.dialect.MySQL5InnoDBDialect" /> <property name="generateDdl" value="true" /> </bean> </property> <property name="loadTimeWeaver"> <bean class="org.springframework.instrument.classloading.InstrumentationLoadTimeWeaver" /> </property> </bean> <!-- DBCP datasource --> <bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close"> <property name="driverClassName" value="com.mysql.jdbc.Driver" /> <property name="url" value="jdbc:mysql://localhost:3306/appointment" /> <property name="username" value="root" /> <property name="password" value="" /> </bean> <!-- transaction manager --> <tx:annotation-driven transaction-manager="txManager" /> <bean id="txManager" class="org.springframework.orm.jpa.JpaTransactionManager"> <property name="entityManagerFactory" ref="entityManagerFactory" /> </bean> <!-- exceptions traduction --> <bean class="org.springframework.dao.annotation.PersistenceExceptionTranslationPostProcessor" /> <!-- persistence annotations --> <bean class="org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor" />

</beans>

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

64

D. APPLICATION PROGRAMMING INTERFACES


D.1. IDAO INTERFACE Interface 1: IDao package edu.unu.iist.emacao.queuing.database; import java.io.Serializable; import java.util.Collection; import javax.persistence.EntityManager;

public interface IDao<T,ID extends Serializable> { public T findById(ID id) throws DataAccessException; public Collection<T> findAll() throws DataAccessException; public T create(T object) throws DataAccessException; public void delete(T object) throws DataAccessException; public T update(T object) throws DataAccessException; public void setManager(EntityManager manager) throws DataAccessException;

}
D.2. IAGENCYDAO INTERFACE Interface 2: IAgencyDao package edu.unu.iist.emacao.queuing.database; import edu.unu.iist.emacao.queuing.entities.Agency; public interface IAgencyDao extends IDao<Agency, Long> { public Agency findByName(String name) throws DataAccessException;

}
D.3. IAPPOINTMENTDAO INTERFACE Interface 3: IAppointmentDao package edu.unu.iist.emacao.queuing.database; import java.util.Collection; import java.util.Date; import edu.unu.iist.emacao.queuing.entities.AgencyCenter; import edu.unu.iist.emacao.queuing.entities.Appointment; import edu.unu.iist.emacao.queuing.entities.Customer; import edu.unu.iist.emacao.queuing.entities.Service;
UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

65

public interface IAppointmentDao extends IDao<Appointment, Long> { public Collection<Appointment> findByDate(Date date) throws DataAccessException; public Collection<Appointment> findByServiceDate(Customer customer, Service service, Date date) throws DataAccessException; public Collection<Appointment> findByServiceDate(Service service, Date date) throws DataAccessException; public Appointment getLastAppointment(Service s, Date d)throws DataAccessException; public Collection<Appointment> getRunningAppointment(Date d) throws DataAccessException; public Collection<Appointment> findByServiceCenterDate(Service s,Date date, AgencyCenter center) throws DataAccessException; // relative to pending appointment public Collection<Appointment> getPendingAppointmentService(Service service, Date date) throws DataAccessException; public Collection<Appointment> getPendingAppointmentCenter(AgencyCenter center, Date date) throws DataAccessException; public Collection<Appointment> getPendingAppointmentDate(Date date) throws DataAccessException; public Collection<Appointment> getPendingWorkingHour(Date date, Date timeS, Date timeE) throws DataAccessException; } D.4. ICOUNTERDAO INTERFACE Interface 4: ICounterDao package edu.unu.iist.emacao.queuing.database;

import java.util.Collection;

import edu.unu.iist.emacao.queuing.entities.AgencyCenter; import edu.unu.iist.emacao.queuing.entities.CenterDetails; import edu.unu.iist.emacao.queuing.entities.Service;

public interface ICounterDao extends IDao<CenterDetails, Long> { public Collection<CenterDetails> findByService(Service service) throws DataAccessException; public Collection<CenterDetails> findByCenter(AgencyCenter center) throws DataAccessException; public CenterDetails findByServiceAndCenter(Service service, AgencyCenter center) throws DataAccessException;

}
D.5. ICITIZENDAO INTERFACE Interface 5: ICitizenDao package edu.unu.iist.emacao.queuing.database; import edu.unu.iist.emacao.queuing.entities.Customer; public interface ICitizenDao extends IDao<Customer, Long> {
UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

66

public Customer getById(String customerId) throws DataAccessException;

}
D.6. INOTIFICATIONDAO INTERFACE Interface 6: INotificationDao package edu.unu.iist.emacao.queuing.database; import java.util.Collection; import java.util.Date; import edu.unu.iist.emacao.queuing.entities.Notification; public interface INotificationDao extends IDao<Notification, Long> { public Collection<Notification> findByTime(Date timeInf, Date timeSup,boolean used) throws DataAccessException; public Collection<Notification> getNotSentNotification(Date date) throws DataAccessException;

}
D.7. ISERVICEDAO INTERFACE Interface 7: IServiceDao package edu.unu.iist.emacao.queuing.database; import edu.unu.iist.emacao.queuing.entities.Service; public interface IServiceDao extends IDao<Service, Long> { public Service findByCode(String code) throws DataAccessException; } D.8. IHOLIDAYDAO INTERFACE Interface 8: IHolidayDao package edu.unu.iist.emacao.queuing.database; import edu.unu.iist.emacao.queuing.entities.Holiday; public interface IHolidayDao extends IDao<Holiday, Long> { } D.9. IWORKINGHOURSDAO INTERFACE Interface 9: IWorkingHoursDao package edu.unu.iist.emacao.queuing.database;

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

67

import edu.unu.iist.emacao.queuing.entities.WorkingHours; public interface IWorkingHoursDao extends IDao<WorkingHours, Long> { } D.10. IAGENCYCENTERDAO INTERFACE Interface 10: IAgencyCenterDao package edu.unu.iist.emacao.queuing.database; import edu.unu.iist.emacao.queuing.entities.AgencyCenter; public interface IAgencyCenterDao extends IDao<AgencyCenter, Long> { } D.11. ISYNCHRON INTERFACE Interface 11: ISynchron package edu.unu.iist.emacao.queuing.xg2g; import edu.unu.iist.egov.emacao.queue.messages.QueueMessages; public interface IXG2GSynchron { public void addMessage(QueueMessages msg); public QueueMessages getMessage(long id); } D.12. IAGENCYSERVICE INTERFACE Interface 12: IAgencyService package edu.unu.iist.emacao.queuing.service; import java.util.Collection; import edu.unu.iist.emacao.queuing.entities.Agency; import edu.unu.iist.emacao.queuing.entities.AgencyCenter; import edu.unu.iist.emacao.queuing.entities.DayOfWeek; import edu.unu.iist.emacao.queuing.entities.Holiday; import edu.unu.iist.emacao.queuing.entities.Service; import edu.unu.iist.emacao.queuing.entities.WorkingHours; public interface IAgencyService {
UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

68

public Agency create(Agency agency)throws QueueServiceException; public Agency update(Agency agency) throws QueueServiceException; public Agency findByName(String name) throws QueueServiceException; public void delete(Agency agency) throws QueueServiceException; public Collection<Agency> list()throws QueueServiceException; public Collection<Service> getServices(Agency agency)throws QueueServiceException; public Collection<WorkingHours> getWorkingHours(AgencyCenter center, Service service)throws QueueServiceException; public Collection<WorkingHours> getWorkingHours(AgencyCenter center, Service service,DayOfWeek day) throws QueueServiceException; public Collection<Holiday> getHolidays(Agency agency)throws QueueServiceException; public Collection<Holiday> getHolidays(AgencyCenter center)throws QueueServiceException; public Collection<AgencyCenter> getCenters(Agency agency)throws QueueServiceException; public AgencyCenter getCenter(Agency agency, String address) throws QueueServiceException; public void addHoliday(Agency agency,Holiday holiday) throws QueueServiceException; public void addHoliday(AgencyCenter center,Holiday holiday) throws QueueServiceException; public void deleteHoliday(Agency agency,Holiday holiday) throws QueueServiceException; public void deleteHoliday(AgencyCenter center,Holiday holiday) throws QueueServiceException; public void addWorkingHour(AgencyCenter center, Service service, WorkingHours workingHour) throws QueueServiceException; public void deleteWorkingHour(AgencyCenter center, Service service,WorkingHours workingHour) throws QueueServiceException; public void deleteCenter(Agency agency,AgencyCenter center) throws QueueServiceException; public AgencyCenter addCenter(Agency agency,AgencyCenter center) throws QueueServiceException; public Collection<AgencyCenter> getCenterServingService(Agency agency, Service service) throws QueueServiceException; } D.13. IAPPOINTMENTSERVICE INTERFACE Interface 13: IAppointmentService package edu.unu.iist.emacao.queuing.service; import java.util.Collection; import java.util.Date; import edu.unu.iist.emacao.queuing.entities.AgencyCenter; import edu.unu.iist.emacao.queuing.entities.Appointment; import edu.unu.iist.emacao.queuing.entities.Service; import edu.unu.iist.emacao.queuing.entities.WorkingHours; import edu.unu.iist.emacao.queuing.util.WorkingHourDetails; import edu.unu.iist.emacao.queuing.xg2g.IXG2GSynchron; import edu.unu.iist.emacao.xg2g.core.Member; public interface IAppointmentService {

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

69

public int newAppointment(Appointment appointment, String center) throws QueueServiceException; public void cancelAppointment(String customerId,Date date,Service service)throws QueueServiceException; public int updateAppointment(String customerId,Date date,Service service, Date newDate, Date newTime)throws QueueServiceException; public int trackAppointment(Service service) throws QueueServiceException; public Collection<Appointment> list() throws QueueServiceException; public Collection<Appointment> findByServiceDate(String customerId, String serviceCode,Date date) throws QueueServiceException; public Collection<Appointment> findByServiceDate(String serviceCode,Date date) throws QueueServiceException; public Collection<Appointment> findByServiceCenterDate(String serviceCode,Date date, AgencyCenter center) throws QueueServiceException; // CRUD method public Appointment update(Appointment appointment) throws QueueServiceException; public Appointment create(Appointment appointment) throws QueueServiceException; public void delete(Appointment appointment) throws QueueServiceException; public Appointment getLastAppointment(Service s, Date d) throws QueueServiceException; public void setMember(Member member); public void setXg2gSynchron(IXG2GSynchron synchron); public Collection<Appointment> getStillRunningAppointment()throws QueueServiceException; public Collection<WorkingHourDetails> getAvailableHours(Service service,String customer,Date newDate,Date oldDate, String center) throws QueueServiceException; public String[] getCenter(String serviceCode) throws QueueServiceException; // Services related to pending appointment especially when we need to delete some data structures public Collection<Appointment> getPendingAppointmentForWorkingHour(WorkingHours working) throws QueueServiceException; public Collection<Appointment> getPendingAppointmentForService(Service serv) throws QueueServiceException; public Collection<Appointment> getPendingAppointmentForCenter(AgencyCenter center) throws QueueServiceException; public Collection<Appointment> getPendingAppointmentForDate(Date date) throws QueueServiceException; // Method to notify citizen public void notifyCitizen(Collection<Appointment> appointments, String message) throws QueueServiceException; } D.14 ICITIZENSERVICE INTERFACE Interface 14: ICitizenService package edu.unu.iist.emacao.queuing.service; import edu.unu.iist.emacao.queuing.entities.Customer; public interface ICustomerService { public Customer getById(String customerId) throws QueueServiceException; }

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

70

D.15. IHOLIDAYSERVICE INTERFACE Interface 15: IHolidayService package edu.unu.iist.emacao.queuing.service; import java.util.Date; import edu.unu.iist.emacao.queuing.entities.Agency; import edu.unu.iist.emacao.queuing.entities.AgencyCenter; import edu.unu.iist.emacao.queuing.entities.Holiday; public interface IHolidayService { public Holiday getById(Long id) throws QueueServiceException; public void delete(Holiday holiday) throws QueueServiceException; public boolean isHoliday(Agency agency, Date date) throws QueueServiceException; public boolean isCenterHoliday(AgencyCenter center, Date date) throws QueueServiceException; } D.16. INOTIFICATIONSERVICE INTERFACE Interface 16: INotificationService package edu.unu.iist.emacao.queuing.service; import java.util.Collection; import edu.unu.iist.emacao.queuing.entities.Notification; public interface INotificationService { public void createNotification(Notification notification) throws QueueServiceException; public void markAsSent(Notification notifcation) throws QueueServiceException; public Collection<Notification> listReadyToBeSent() throws QueueServiceException; public void delete(Notification notification) throws QueueServiceException; public void update(Notification notification) throws QueueServiceException; } D.17. ISERVICESERVICE INTERFACE Interface 17: IServiceService package edu.unu.iist.emacao.queuing.service; import java.util.Collection; import java.util.Date; import edu.unu.iist.emacao.queuing.entities.AgencyCenter;
UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

71

import edu.unu.iist.emacao.queuing.entities.CenterDetails; import edu.unu.iist.emacao.queuing.entities.Service; public interface IServiceService { public Service create(Service service)throws QueueServiceException; public Service update(Service service) throws QueueServiceException; public Service findByCode(String code) throws QueueServiceException; public Collection<Service> list() throws QueueServiceException; public void delete(Service service) throws QueueServiceException; public void updateCurrentServing(Service service, int numServing) throws QueueServiceException; public int getCurrentServing(Service service) throws QueueServiceException; public int getCurrentServing(Service service, Date date) throws QueueServiceException; public void modifyNumCounters(Service serv,AgencyCenter center, int counters) throws QueueServiceException; public int getNumberCounters(Service serv,AgencyCenter center)throws QueueServiceException; public Collection<CenterDetails> getCenterDetails(Service service) throws QueueServiceException; }

D.18. ISERVICEDAO INTERFACE Interface 18: IServiceDao package edu.unu.iist.emacao.queuing.database; import edu.unu.iist.emacao.queuing.entities.Service; public interface IServiceDao extends IDao<Service, Long> { public Service findByCode(String code) throws DataAccessException; } D.19. IWORKINGHOURSERVICE INTERFACE Interface 19: IWorkingHourService package edu.unu.iist.emacao.queuing.service; import edu.unu.iist.emacao.queuing.entities.WorkingHours; public interface IWorkingHourService { public WorkingHours getById(Long id) throws QueueServiceException; public void delete(WorkingHours workingHours) throws QueueServiceException; }

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

72

E. JAVA CLASSES
E.1. SERVICE CREATE CLASS Class 1 : Create package edu.unu.iist.emacao.queuing.web.service; import org.apache.wicket.markup.html.basic.Label; import org.apache.wicket.markup.html.form.Button; import org.apache.wicket.markup.html.form.Form; import org.apache.wicket.markup.html.form.TextField; import org.apache.wicket.markup.html.panel.FeedbackPanel; import org.apache.wicket.model.PropertyModel; import org.apache.wicket.model.ResourceModel; import edu.unu.iist.emacao.queuing.entities.Service; import edu.unu.iist.emacao.queuing.service.QueueServiceException; import edu.unu.iist.emacao.queuing.web.template.SecureTemplate; public class Create extends SecureTemplate { private Service service; public Create() { this(new Service()); } protected Service getService() { return service; } protected void setService(Service service) { this.service = service; } public Create(Service service) { this.service = service; MyForm form = new MyForm("form"); TextField codeText = new TextField("code", new PropertyModel(service, "code")); codeText.setRequired(true); TextField nameText = new TextField("name", new PropertyModel(service, "name")); TextField ackDelayText = new TextField("ackDelay", new PropertyModel( service, "ackDelay")); ackDelayText.setRequired(true);

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

73

nameText.setRequired(true); TextField meanSerText = new TextField("meanServiceTime", new PropertyModel(service, "meanServiceTime")); meanSerText.setRequired(true); Button button=new Button("button"); if(service.getId()==null){ add(new Label("header", new ResourceModel("service.header_create"))); button.setModel(new ResourceModel("service.create")); }else{ add(new Label("header", new ResourceModel("service.header_edit"))); button.setModel(new ResourceModel("service.edit")); } form.add(codeText); form.add(nameText); form.add(ackDelayText); form.add(meanSerText); form.add(new Label("agency", new PropertyModel(getAgency(),"name"))); form.add(button); add(form); add(new FeedbackPanel("feedback")); } @SuppressWarnings("serial") class MyForm extends Form { public MyForm(String id) { super(id); } @Override protected void onSubmit() { Service service = getService(); service.setAgency(getAgency()); try { if(service.getId()==null) getServiceFactory().getServiceService().create(service); else getServiceFactory().getServiceService().update(service);

setResponsePage(edu.unu.iist.emacao.queuing.web.service.List.class); } catch (QueueServiceException e) { error(e.getMessage()); } }

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

74

} @Override public String getPageTitle() { return "Appointment System - Create a service"; } } E.2. AGENCY LIST CLASS Class 2: List package edu.unu.iist.emacao.queuing.web.agencies; import org.apache.wicket.markup.html.basic.Label; import org.apache.wicket.markup.html.link.Link; import org.apache.wicket.markup.html.panel.FeedbackPanel; import org.apache.wicket.markup.repeater.Item; import org.apache.wicket.markup.repeater.data.DataView; import org.apache.wicket.markup.repeater.data.IDataProvider; import org.apache.wicket.markup.repeater.data.ListDataProvider; import edu.unu.iist.emacao.queuing.entities.Agency; import edu.unu.iist.emacao.queuing.service.QueueServiceException; import edu.unu.iist.emacao.queuing.web.template.ConfirmLink; import edu.unu.iist.emacao.queuing.web.template.SecureTemplate; public class List extends SecureTemplate { java.util.List<Agency> listAgencies; public List() { add(new NewAgency("newAgency")); listAgencies = getData(); refreshList(false); add(new FeedbackPanel("feedback")); } private void refreshList(boolean test) { IDataProvider provider = new ListDataProvider(listAgencies); DataView agenciesData = new AgencyDataView("loops", provider); if (test) remove("loops"); add(agenciesData);

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

75

} private java.util.List<Agency> getData() { java.util.List<Agency> result = null; try { result = (java.util.List<Agency>) getServiceFactory() .getAgencyService().list(); } catch (Exception e) { e.printStackTrace(); error(e.getMessage()); } return result; } private void edit(Agency agency) { Create create = new Create(agency); setResponsePage(create); } private void delete(Agency agency) { try { getServiceFactory().getAgencyService().delete(agency); setResponsePage(List.class); } catch (QueueServiceException e) { error(e.getMessage()); } } private void services(Agency agency) { edu.unu.iist.emacao.queuing.web.service.List servList = new edu.unu.iist.emacao.queuing.web.service.List( agency); setResponsePage(servList); } @Override public String getPageTitle() { return "Appointment System - List of agencies"; } private final class AgencyDataView extends DataView { private static final long serialVersionUID = 2202514093282421239L; private AgencyDataView(String id, IDataProvider dataProvider) {

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

76

super(id, dataProvider); } @Override protected void populateItem(Item item) { final Agency ag = (Agency) item.getModelObject(); item.add(new Label("name", ag.getName())); item.add(new Label("description", ag.getDescription())); item.add(new Label("channelId", ag.getChannelId())); item.add(new ServicesAction("services", ag)); item.add(new EditAction("edit", ag)); item.add(new DeleteAction("delete", ag)); } } private final class NewAgency extends Link { private static final long serialVersionUID = 67705242749863887L; private NewAgency(String id) { super(id); } @Override public void onClick() { setResponsePage(edu.unu.iist.emacao.queuing.web.agencies.Create.class); } } private final class ServicesAction extends Link { private static final long serialVersionUID = -3877244923013587852L; private final Agency ag; private ServicesAction(String id, Agency ag) { super(id); this.ag = ag; } @Override public void onClick() { services(ag); } }

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

77

private final class EditAction extends Link { private static final long serialVersionUID = 7009843932421244396L; private final Agency ag; private EditAction(String id, Agency ag) { super(id); this.ag = ag; } @Override public void onClick() { edit(ag); } } private final class DeleteAction extends ConfirmLink { private static final long serialVersionUID = -8992796734551382870L; private final Agency ag; private DeleteAction(String id, Agency ag) { super(id); this.ag = ag; } @Override public void onClick() { delete(ag); } }

}
E.3. AGENCY CREATE CLASS Class 3: Create package edu.unu.iist.emacao.queuing.web.agencies; import org.apache.wicket.markup.html.basic.Label; import org.apache.wicket.markup.html.form.Button; import org.apache.wicket.markup.html.form.Form; import org.apache.wicket.markup.html.form.TextField; import org.apache.wicket.markup.html.panel.FeedbackPanel; import org.apache.wicket.model.PropertyModel; import org.apache.wicket.model.ResourceModel; import org.apache.wicket.validation.validator.PatternValidator;

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

78

import edu.unu.iist.emacao.queuing.entities.Agency; import edu.unu.iist.emacao.queuing.service.QueueServiceException; import edu.unu.iist.emacao.queuing.web.template.SecureTemplate; public class Create extends SecureTemplate { public Create() { this(new Agency()); } public Create(Agency agenc) { agency = agenc; MyForm form = new MyForm("form1"); TextField nameText = new TextField("name", new PropertyModel(this, "agency.name")); nameText.setRequired(true); TextField descriptionText = new TextField("description", new PropertyModel(this, "agency.description")); descriptionText.setRequired(true); TextField channelIdText = new TextField("channelId", new PropertyModel( this, "agency.channelId")); channelIdText.setRequired(true); channelIdText.add(new PatternValidator("[0-9]+")); Button button = new Button("button"); if (getAgency().getId() == null) { add(new Label("header", new ResourceModel("agency.header_create"))); button.setModel(new ResourceModel("agency.create")); } else { add(new Label("header", new ResourceModel("agency.header_edit"))); button.setModel(new ResourceModel("agency.edit")); } form.add(nameText); form.add(descriptionText); form.add(button); form.add(channelIdText); add(form); add(new FeedbackPanel("feedback")); } private Agency agency; protected Agency getAgency() { return agency; }

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

79

protected void setAgency(Agency agency) { this.agency = agency; } @SuppressWarnings("serial") class MyForm extends Form { public MyForm(String id) { super(id); } @Override public void onSubmit() { try { if (getAgency().getId() == null) getServiceFactory().getAgencyService().create(getAgency()); else getServiceFactory().getAgencyService().update(getAgency()); setResponsePage(List.class); } catch (QueueServiceException e) { error(e.getMessage()); e.printStackTrace(); } } } @Override public String getPageTitle() { return "Appointment System - Create new agency"; } } E.4. CONFIGURATIONPARAMETERS CLASS Class 4: ConfigurationParameter package edu.unu.iist.emacao.queuing.util; import java.io.FileInputStream; import java.net.URL; import java.util.Properties; public class ConfigurationParameter { private static final String memberId;

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

80

private static final String type; private static final SMSParameter smsParameter; private static final EmailParameter emailParameter; private static final String CONFIG_FILE="/config/config.properties"; private static final String emailTemplate; private static final String smsTemplate; private static final String agencyName; private static final String agencyDescription; private static final String channelId; private static final String createNotificationTemplate; private static final String updateNotificationTemplate; private static final String cancelNotificationTemplate; private static final int numMonth; private static final int numAppointment; static { try { URL url=ConfigurationParameter.class.getResource(CONFIG_FILE); FileInputStream f=new FileInputStream(url.getPath()); Properties prop=new Properties(); prop.load(f); memberId = prop.getProperty("memberId"); type=prop.getProperty("type"); smsParameter = new SMSParameter(); smsParameter.setUser(prop.getProperty("smsuser")); smsParameter.setPassword(prop.getProperty("smsuserpassword")); smsParameter.setApiId(prop.getProperty("smsapiid")); emailParameter = new EmailParameter(); emailParameter.setAuthentificationRequired(prop.getProperty("isemailauthenticationrequired")); emailParameter.setEmailPort(prop.getProperty("emailport")); emailParameter.setEmailServer(prop.getProperty("emailserver")); emailParameter.setSenderEmail(prop.getProperty("senderemail")); emailParameter.setSenderPassword(prop.getProperty("emailsenderpassword")); emailParameter.setTLSEnabled(prop.getProperty("istlsenabled")); emailTemplate=prop.getProperty("emailtemplate"); smsTemplate=prop.getProperty("smstemplate"); agencyName=prop.getProperty("agencyName"); agencyDescription=prop.getProperty("agencyDescription"); channelId=prop.getProperty("channelId"); createNotificationTemplate=prop.getProperty("newnotificationtemplate"); updateNotificationTemplate=prop.getProperty("updatenotificationtemplate"); cancelNotificationTemplate=prop.getProperty("cancelnotificationtemplate"); numMonth=Integer.parseInt(prop.getProperty("numbermonth")); numAppointment=Integer.parseInt(prop.getProperty("numberappointment")); } catch (Throwable e) {

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

81

e.printStackTrace(); throw new ExceptionInInitializerError("Unable to initialize the configuration parameters"); } } public static String getMemberId() { return memberId; } public static SMSParameter getSmsParameter() { return smsParameter; } public static EmailParameter getEmailParameter() { return emailParameter; } public static String getType() { return type; } public static String getEmailTemplate(){ return emailTemplate; } public static String getSMSTemplate(){ return smsTemplate; } public static String getAgencyName() { return agencyName; } public static String getAgencyDescription() { return agencyDescription; } public static String getChannelId() { return channelId; } public static String getSmsTemplate() { return smsTemplate; }

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

82

public static int getNumMonth() { return numMonth; } public static String getCreateNotificationTemplate() { return createNotificationTemplate; } public static String getUpdateNotificationTemplate() { return updateNotificationTemplate; } public static String getCancelNotificationTemplate() { return cancelNotificationTemplate; } public static int getNumAppointment() { return numAppointment; } } E.5. SERVICEFACTORY CLASS Class 5: ServiceFactory package edu.unu.iist.emacao.queuing.service; public class ServiceFactory { private IAgencyService agencyService; private IAppointmentService appointmentService; private IHolidayService holidayService; private IServiceService serviceService; private IWorkingHourService workingHourService; private ICustomerService customerService; private INotificationService notificationService; public IAgencyService getAgencyService() { return agencyService; } public void setAgencyService(IAgencyService agencyService) { this.agencyService = agencyService; } public IAppointmentService getAppointmentService() { return appointmentService; }

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

83

public void setAppointmentService(IAppointmentService appointmentService) { this.appointmentService = appointmentService; } public IHolidayService getHolidayService() { return holidayService; } public void setHolidayService(IHolidayService holidayService) { this.holidayService = holidayService; } public IServiceService getServiceService() { return serviceService; } public void setServiceService(IServiceService serviceService) { this.serviceService = serviceService; } public IWorkingHourService getWorkingHourService() { return workingHourService; } public void setWorkingHourService(IWorkingHourService workingHourService) { this.workingHourService = workingHourService; } public ICustomerService getCustomerService() { return customerService; } public void setCustomerService(ICustomerService customerService) { this.customerService = customerService; } public INotificationService getNotificationService() { return notificationService; } public void setNotificationService(INotificationService notificationService) { this.notificationService = notificationService; }

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

84

E.6. GENERICDAO CLASS Class 6: GenericDao package edu.unu.iist.emacao.queuing.database.impl;

import java.io.Serializable; import java.lang.reflect.ParameterizedType; import java.util.Collection;

import javax.persistence.EntityManager; import javax.persistence.PersistenceContext;

import edu.unu.iist.emacao.queuing.database.DataAccessException; import edu.unu.iist.emacao.queuing.database.IDao;

public class GenericDao<T, ID extends Serializable> implements IDao<T, ID> {

private Class<T> entityClass;

@PersistenceContext
private EntityManager manager;

@SuppressWarnings("unchecked")
public GenericDao() {

entityClass = (Class<T>) ((ParameterizedType) getClass() .getGenericSuperclass()).getActualTypeArguments()[0]; }


public Class<T> getEntityClass() {

return entityClass; }

protected EntityManager getManager() throws DataAccessException{ if(manager==null) throw new DataAccessException("The entity manager has not yet been set"); return manager;

}
public void setManager(EntityManager manager) { this.manager = manager;

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

85

@Override
public T create(T object) throws DataAccessException {

getManager().persist(object);
return object;

} @Override
public void delete(T object) throws DataAccessException {

//object=findById(id) getManager().remove(object); } @SuppressWarnings("unchecked") @Override


public Collection<T> findAll() throws DataAccessException {

Collection<T> result=getManager().createQuery(" select u from "+entityClass.getName()+" u").getResultList();


return result;

} @Override
public T findById(ID id) throws DataAccessException {

T result=(T)getManager().find(entityClass, id);
return result;

} @Override
public T update(T object) throws DataAccessException {

object=getManager().merge(object);
return object;

} }
E.7. APPLICATION CLASS Class 7: Application package edu.unu.iist.emacao.queuing.web;

import java.util.HashMap; import java.util.Map;

import javax.servlet.ServletContext;

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

86

import org.apache.wicket.Page; import org.apache.wicket.Request; import org.apache.wicket.Response; import org.apache.wicket.Session; import org.apache.wicket.protocol.http.WebApplication; import org.apache.wicket.util.lang.PackageName; import org.springframework.context.ApplicationContext; import org.springframework.web.context.support.WebApplicationContextUtils;

import edu.unu.iist.emacao.queuing.entities.Agency; import edu.unu.iist.emacao.queuing.entities.User; import edu.unu.iist.emacao.queuing.service.QueueServiceException; import edu.unu.iist.emacao.queuing.service.ServiceFactory; import edu.unu.iist.emacao.queuing.util.ConfigurationParameter; import edu.unu.iist.emacao.queuing.util.Host; import edu.unu.iist.emacao.queuing.web.agencies.Create; import edu.unu.iist.emacao.queuing.web.session.MySession; import edu.unu.iist.emacao.queuing.xg2g.AgencyApplicationListener; import edu.unu.iist.emacao.queuing.xg2g.IXG2GSynchron; import edu.unu.iist.emacao.queuing.xg2g.PortalApplicationListener; import edu.unu.iist.emacao.queuing.xg2g.XG2GSynchron; import edu.unu.iist.emacao.xg2g.core.Anon; import edu.unu.iist.emacao.xg2g.core.Member;

public class Application extends WebApplication {

private ServiceFactory serviceFactory; private Member member; private Map<String, User> users;

public Application() {

} @Override
public Class<? extends Page> getHomePage() { return Login.class;

} @Override
public Session newSession(Request request, Response response) {

MySession session = new MySession(request);


return session;

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

87

}
public ServiceFactory getServiceFactory() { return serviceFactory;

} @Override
protected void init() { super.init();

ServletContext servletContext = getServletContext(); ApplicationContext applicationContext = WebApplicationContextUtils .getRequiredWebApplicationContext(servletContext);


serviceFactory = (ServiceFactory) applicationContext

.getBean("serviceFactory"); mount("/pages", PackageName.forPackage(Login.class.getPackage())); mount("/agency", PackageName.forPackage(Create.class.getPackage())); mount( "/app", PackageName .forPackage(edu.unu.iist.emacao.queuing.web.appointment.NewAppointment.class .getPackage())); mount( "/holi", PackageName .forPackage(edu.unu.iist.emacao.queuing.web.holidays.Create.class .getPackage())); mount( "/service", PackageName .forPackage(edu.unu.iist.emacao.queuing.web.service.Create.class .getPackage())); mount( "/work", PackageName .forPackage(edu.unu.iist.emacao.queuing.web.workinghours.Create.class .getPackage())); mountBookmarkablePage("/pages/Home", HomePage.class);
users=new HashMap<String, User>(); if ("portal".equalsIgnoreCase(ConfigurationParameter.getType())) {

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

88

PortalApplicationListener pListener = new PortalApplicationListener(); Anon anon = new Anon(); IXG2GSynchron synchron = new XG2GSynchron();

pListener.setXg2gSynchron(synchron); serviceFactory.getAppointmentService().setXg2gSynchron(synchron); member = anon.getMember(ConfigurationParameter.getMemberId(), pListener);


users.put("portal", new User("portal", "portal", "portal",0)); users.put("user", new User("user","user","user",2));

} else { AgencyApplicationListener aListener = new AgencyApplicationListener(); Anon anon = new Anon();

member = anon.getMember(ConfigurationParameter.getMemberId(), aListener); aListener.setMember(member); aListener.setServiceFactory(serviceFactory); users.put("agency", new User("agency","agency","agency",1)); } if (member != null) { serviceFactory.getAppointmentService().setMember(member);
long time = 30000L;

Host h = new Host(time); h.setServiceFactory(serviceFactory); h.start(); } // Create the hosting if it does not already exists in the database // Now we need to decide what to do if the member and the agency are not specificy String name = ConfigurationParameter.getAgencyName();
if (name != null) { try {

Agency ag = getServiceFactory().getAgencyService().findByName(name);
if(ag==null){ ag=new Agency();

ag.setName(name); ag.setDescription(ConfigurationParameter.getAgencyDescription()); ag.setChannelId(ConfigurationParameter.getChannelId()); getServiceFactory().getAgencyService().create(ag); }


} catch (QueueServiceException e) {

e.printStackTrace();

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

89

} } }
public Map<String, User> getUsers() { return users;

} }
E.8. AGENCYAPPLICATIONLISTENER CLASS Class 8: AgencyApplicationListener package edu.unu.iist.emacao.queuing.xg2g; import java.text.SimpleDateFormat; import java.util.ArrayList; import java.util.Calendar; import java.util.Collection; import java.util.Date; import java.util.HashMap; import java.util.Map; import javax.persistence.NoResultException; import org.apache.xmlbeans.XmlException; import edu.unu.iist.egov.emacao.queue.messages.CancelAppointment; import edu.unu.iist.egov.emacao.queue.messages.DateInterval; import edu.unu.iist.egov.emacao.queue.messages.ErrorType; import edu.unu.iist.egov.emacao.queue.messages.ListCenters; import edu.unu.iist.egov.emacao.queue.messages.ListDates; import edu.unu.iist.egov.emacao.queue.messages.MessageType; import edu.unu.iist.egov.emacao.queue.messages.NewAppointment; import edu.unu.iist.egov.emacao.queue.messages.QueueMessages; import edu.unu.iist.egov.emacao.queue.messages.UpdateAppointment; import edu.unu.iist.emacao.gateway.xmlUtil.UserMessage; import edu.unu.iist.emacao.queuing.entities.AgencyCenter; import edu.unu.iist.emacao.queuing.entities.Appointment; import edu.unu.iist.emacao.queuing.entities.Customer; import edu.unu.iist.emacao.queuing.entities.DayOfWeek; import edu.unu.iist.emacao.queuing.entities.Notification; import edu.unu.iist.emacao.queuing.entities.NotificationType; import edu.unu.iist.emacao.queuing.entities.Service;

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

90

import edu.unu.iist.emacao.queuing.entities.WorkingHours; import edu.unu.iist.emacao.queuing.service.QueueServiceException; import edu.unu.iist.emacao.queuing.service.ServiceFactory; import edu.unu.iist.emacao.queuing.util.ConfigurationParameter; import edu.unu.iist.emacao.queuing.util.Util; import edu.unu.iist.emacao.xg2g.core.ApplicationListener; import edu.unu.iist.emacao.xg2g.core.Member; import edu.unu.iist.emacao.xg2g.core.Message; public class AgencyApplicationListener implements ApplicationListener { private ServiceFactory serviceFactory; private Member member; final static int CREATE = 0; final static int UPDATE = 1; final static int CANCEL = 2; @Override public void recChExtensionReply(String message) { } @Override public void recConfigureChExtensionReply(String message) { } @Override public void recCreateChannelReply(String message) { } @Override public void recDestroyChannelReply(String message) { } @Override public void recForwardReply(String message) { } @Override public void recGetMemberReply(String message) {

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

91

} @Override public void recManageReply(String message) { } @Override public void recMemberUnsubscribe(String message) { } @Override public void recReceiveMessageReply(String message) { } @Override public void recRegisterReply(String message) { } @Override public void recSendMessageReply(String message) { } @Override public void recSubscribeChannelReply(String message) { } @Override public void recUnRegisterReply(String message) { } @Override public void recUnsubscribeChannelReply(String message) { } @Override public void receiveMessage(String message) { // This is the only method we need to implement

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

92

// We get the message content // we get the type of message // do the required processing // send back the message to the sender try { Message msg = new Message(message); UserMessage uMsg = UserMessage.Factory.parse(msg .getUserDefinedMessage()); QueueMessages qMsg = QueueMessages.Factory.parse(uMsg.getContent() .toString()); String reply = null; if (qMsg.isSetCancelAppointment()) { // Get the parameter CancelAppointment cMsg = qMsg.getCancelAppointment(); String serviceId = cMsg.getService(); String customerId = cMsg.getCustomerId(); Date appointmentDate = cMsg.getDate().getTime(); reply = cancelAppointment(serviceId, customerId, appointmentDate, qMsg); } else if (qMsg.isSetNewAppointment()) { NewAppointment nMsg = qMsg.getNewAppointment(); String serviceCode = nMsg.getServiceCode(); String customerId = nMsg.getCustomerId(); String customerName = nMsg.getCustomerName(); Date aDate = nMsg.getDate().getTime(); Date startTime = nMsg.getTime().getTime(); String emailAddress = nMsg.getEmailAddress(); String phoneNumber = nMsg.getMobilePhone(); String center = nMsg.getCenter(); String details = nMsg.getDetails(); reply = newAppointment(serviceCode, customerId, customerName, aDate, emailAddress, phoneNumber, startTime, center, details, qMsg); } else if (qMsg.isSetUpdateAppointment()) { UpdateAppointment upMsg = qMsg.getUpdateAppointment(); String serviceId = upMsg.getService(); String customerId = upMsg.getCustomerId(); Date oldDate = upMsg.getDate().getTime(); Date newDate = upMsg.getNewDate().getTime(); Date newTime = upMsg.getTime().getTime(); reply = updateAppointment(serviceId, customerId, oldDate, newDate, newTime, qMsg); } else if (qMsg.isSetListDates()) { ListDates lMsg = qMsg.getListDates(); String serviceCode = lMsg.getService();

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

93

String center = lMsg.getCenter(); Date oldDate = (lMsg.getOldDate() == null) ? null : lMsg .getOldDate().getTime(); Date newDate = lMsg.getNewDate().getTime(); String customerId = lMsg.getCustomerId(); reply = listDates(serviceCode, oldDate, newDate, center, customerId, qMsg); } else if (qMsg.isSetListCenters()) { ListCenters centers = qMsg.getListCenters(); String service = centers.getService(); reply = listCenters(service, qMsg); } else { // TODO Give a value to reply here // reply=?? } uMsg = UserMessage.Factory.newInstance(); QueueMessages m = QueueMessages.Factory.parse(reply); uMsg.setContent(m); msg.setUserDefinedMessage(uMsg.toString()); String chId = msg.getChannelId(); msg.setMessageDate(new Date()); String ids = msg.getSenderId(); msg.setSenderId(msg.getReceiverId()); msg.setReceiverId(ids); msg.setMessageStep(msg.getMessageStep() + 1); sendMessage(chId, m.toString()); } catch (XmlException e) { e.printStackTrace(); } } private String listCenters(String service, QueueMessages msg) { msg.setType(MessageType.REPLY); ListCenters c = msg.getListCenters(); try { Service s = null; try { s = serviceFactory.getServiceService().findByCode(service); } catch (NoResultException e) { c.setErrorType(ErrorType.FAILURE); c.setErrorDescription("Unknown service " + service); } if (s != null) {

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

94

Collection<AgencyCenter> listc = serviceFactory .getAgencyService().getCenters(s.getAgency()); if ((listc != null) && (listc.size() != 0)) { Collection<String> val = new ArrayList<String>(); for (AgencyCenter ce : listc) { if (serviceFactory.getServiceService() .getNumberCounters(s, ce) > 0) val.add(ce.getAddress()); } String[] values = null; if (val.size() != 0) { values = new String[val.size()]; val.toArray(values); } c.setCenterArray(values); } } } catch (QueueServiceException e) { c.setErrorType(ErrorType.FAILURE); c.setErrorDescription(e.getMessage()); } return msg.toString(); } private String listDates(String serviceCode, Date oldDate, Date newDate, String center, String customerid, QueueMessages msg) { ListDates ld = msg.getListDates(); msg.setType(MessageType.REPLY); try { Service s = serviceFactory.getServiceService().findByCode( serviceCode); ld.setMeanTime(s.getMeanServiceTime()); Calendar cal = Calendar.getInstance(); cal.setTime(newDate); int day = cal.get(Calendar.DAY_OF_WEEK); DayOfWeek d = Util.getDayFromInt(day); Collection<WorkingHours> listW = null; AgencyCenter cent = null; if (center == null) { Collection<Appointment> aps = serviceFactory .getAppointmentService().findByServiceDate(customerid, serviceCode, oldDate); if ((aps != null) && (aps.size() != 0)) {

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

95

center = aps.iterator().next().getCenter().getAddress(); cent = serviceFactory.getAgencyService().getCenter( s.getAgency(), center); } } else { cent = serviceFactory.getAgencyService().getCenter( s.getAgency(), center); } if (cent == null) { ld.setError(ErrorType.FAILURE); ld.setErrorDescription("No appointment defined for customer " + customerid + " for " + (new SimpleDateFormat("dd/MM/yyyy").format(oldDate))); return msg.toString(); } else { if (serviceFactory.getHolidayService().isCenterHoliday(cent, newDate)) { ld.setError(ErrorType.FAILURE); ld.setErrorDescription((new SimpleDateFormat("dd/MM/yyyy")) .format(newDate) + " is not a working date for " + center); return msg.toString(); } listW = serviceFactory.getAgencyService().getWorkingHours(cent, s, d); } int numCounters = serviceFactory.getServiceService() .getNumberCounters(s, cent); if ((listW != null) && (listW.size() != 0)) { DateInterval[] listD = null; if (Util.today(newDate)) { listW = getWHours(listW, s.getMeanServiceTime()); } listD = new DateInterval[listW.size()]; int i = 0; for (WorkingHours dt : listW) { listD[i] = getDateInterval(dt.getStartTime(), dt .getEndTime()); i++; }

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

96

ld.setWorkHoursArray(listD); } // check only the services for the specified center Collection<Appointment> listBusy = serviceFactory .getAppointmentService().findByServiceCenterDate( serviceCode, newDate, cent); if ((listBusy != null) && (listBusy.size() != 0)) { Collection<DateInterval> listD = new ArrayList<DateInterval>(); for (Appointment ap : listBusy) { if (isFull(ap, listBusy, numCounters)) { if (!alreadyConsidered(ap, listD)) listD.add(getDateInterval(ap.getStartTime(), ap .getEndTime())); } } DateInterval[] val = new DateInterval[listD.size()]; listD.toArray(val); ld.setOccupiedArray(val); } ld.setError(ErrorType.SUCESS); } catch (QueueServiceException e) { ld.setError(ErrorType.UNKNOWN); ld.setErrorDescription(e.getMessage()); e.printStackTrace(); } return msg.toString(); } private Collection<WorkingHours> getWHours(Collection<WorkingHours> listW, int meanTime) { Collection<WorkingHours> list = new ArrayList<WorkingHours>(); for (WorkingHours h : listW) if (!Util.isBetween(h, meanTime)) list.add(h); return list; } private boolean alreadyConsidered(Appointment ap, Collection<DateInterval> listD) { for (DateInterval inter : listD) { if (ap.getStartTime().equals(inter.getMinDate().getTime())

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

97

&& ap.getEndTime().equals(inter.getMaxDate().getTime())) return true; } return false; } private boolean isFull(Appointment ap, Collection<Appointment> listBusy, int numCounters) { int val = 0; for (Appointment p : listBusy) if (ap.getStartTime().equals(p.getStartTime()) && (ap.getEndTime().equals(p.getEndTime()))) val++; return val >= numCounters; } private DateInterval getDateInterval(Date dateMin, Date dateMax) { DateInterval result = DateInterval.Factory.newInstance(); result.setMinDate(calendarFromDate(dateMin)); result.setMaxDate(calendarFromDate(dateMax)); return result; } private Calendar calendarFromDate(Date d) { Calendar c1 = Calendar.getInstance(); c1.setTime(d); return c1; } protected String updateAppointment(String serviceCode, String customerId, Date oldDate, Date newDate, Date newTime, QueueMessages msg) { UpdateAppointment u = msg.getUpdateAppointment(); msg.setType(MessageType.REPLY); try { Service s = serviceFactory.getServiceService().findByCode( serviceCode); Collection<Appointment> ap = serviceFactory.getAppointmentService() .findByServiceDate(customerId, serviceCode, oldDate); if (ap != null && ap.size() != 0) { for (Appointment aps : ap) { if (aps != null) { aps.setDate(newDate); aps.setStartTime(newTime); Calendar c = Calendar.getInstance(); c.setTime(newTime);

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

98

c.add(Calendar.MINUTE, s.getMeanServiceTime()); aps.setEndTime(c.getTime()); serviceFactory.getAppointmentService().update(aps); Notification f = aps.getNotification(); if (f != null) { Notification ns = createNotification(aps, null, -1); f.setMessage(ns.getMessage()); f.setTime(ns.getTime()); f.setDate(ns.getDate()); serviceFactory.getNotificationService().update(f); } Notification ns = createNotification(aps, new Date(), UPDATE); serviceFactory.getNotificationService() .createNotification(ns); u.setError(ErrorType.SUCESS); } } } else { u.setError(ErrorType.FAILURE); u .setErrorDescription(String .format( "No appointment defined for the citizen %s at the date of %s", customerId, (new SimpleDateFormat( "dd/MM/yyyy").format(oldDate)))); } // Generate the reply here } catch (QueueServiceException e) { u.setError(ErrorType.UNKNOWN); u.setErrorDescription(e.getMessage()); e.printStackTrace(); } return msg.toString(); } protected String newAppointment(String serviceCode, String customerId, String customerName, Date date, String emailAddress, String phoneNumber, Date startTime, String center, String details, QueueMessages msg) { msg.setType(MessageType.REPLY); NewAppointment n = msg.getNewAppointment();

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

99

try { Service s = serviceFactory.getServiceService().findByCode( serviceCode); AgencyCenter ac = serviceFactory.getAgencyService().getCenter( s.getAgency(), center); if (serviceFactory.getHolidayService().isCenterHoliday(ac, date)) { n.setError(ErrorType.FAILURE); n .setErrorDescription("You can not have an appointment on holiday"); } else { Appointment ap = new Appointment();// getAppointment(s, date); Customer c = serviceFactory.getCustomerService().getById( customerId); if (c == null) { c = new Customer(); c.setName(customerName); c.setCustomerId(customerId); c.setEmail(emailAddress); c.setMobile(phoneNumber); } ap.setCustomer(c); ap.setDate(date); ap.setDetails(details); ap.setService(s); Calendar t = Calendar.getInstance(); t.setTime(startTime); t.add(Calendar.MINUTE, s.getMeanServiceTime()); ap.setStartTime(startTime); ap.setEndTime(t.getTime()); ap.setCenter(ac); ap = serviceFactory.getAppointmentService().create(ap); // Create the notification here Notification ns = createNotification(ap, null, -1); // ap.setNotification(ns); ns.setAppointement(ap); serviceFactory.getNotificationService().createNotification(ns); ap.setNotification(ns); getServiceFactory().getAppointmentService().update(ap); n.setError(ErrorType.SUCESS); // Add another notification

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

100

Notification nss = createNotification(ap, new Date(), CREATE); serviceFactory.getNotificationService().createNotification(nss); } } catch (QueueServiceException e) { n.setError(ErrorType.UNKNOWN); n.setErrorDescription(e.getMessage()); e.printStackTrace(); } return msg.toString(); } private Notification createNotification(Appointment ap, Date date, int type) { Notification notification = new Notification(); notification.setEmail(ap.getCustomer().getEmail()); notification.setNumber(ap.getCustomer().getMobile()); notification.setDate(ap.getDate()); notification .setType((ap.getCustomer().getEmail() == null) ? NotificationType.SMS : NotificationType.EMAIL); String template; Map<String, String> props = new HashMap<String, String>(); Calendar cal = Calendar.getInstance(); switch (type) { case CREATE: template = ConfigurationParameter.getCreateNotificationTemplate(); props.put("<<date>>", new SimpleDateFormat("MM/dd/yyyy") .format(date)); break; case UPDATE: template = ConfigurationParameter.getUpdateNotificationTemplate(); notification.setDate(ap.getDate()); break; case CANCEL: template = ConfigurationParameter.getCancelNotificationTemplate(); notification.setDate(ap.getDate()); break; default: template = (ap.getCustomer().getEmail() == null) ? ConfigurationParameter .getSMSTemplate() : ConfigurationParameter.getEmailTemplate(); notification.setDate(ap.getDate()); } if (date != null) { cal.add(Calendar.MINUTE, 5); notification.setDate(date);

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

101

notification.setTime(cal.getTime()); // template = ConfigurationParameter.getNotificationTemplate(); } else { cal.setTime(ap.getStartTime()); cal.add(Calendar.MINUTE, -ap.getService().getAckDelay()); notification.setTime(cal.getTime()); } props.put("<<name>>", ap.getCustomer().getName()); props.put("<<time>>", new SimpleDateFormat("H:mm").format(ap .getStartTime())); props.put("<<delay>>", "" + ap.getService().getAckDelay()); props.put("<<agency>>", ap.getService().getAgency().getName()); props.put("<<center>>", ap.getCenter().getAddress()); notification.setMessage(Util.format(template, props)); return notification; } protected String cancelAppointment(String serviceCode, String customerId, Date appointmentDate, QueueMessages msg) { CancelAppointment c = msg.getCancelAppointment(); msg.setType(MessageType.REPLY); try { Collection<Appointment> ap = serviceFactory .getAppointmentService() .findByServiceDate(customerId, serviceCode, appointmentDate); if ((ap != null) && (ap.size() != 0)) { for (Appointment aps : ap) { serviceFactory.getAppointmentService().delete(aps); Notification ns = createNotification(aps, new Date(), CANCEL); serviceFactory.getNotificationService().createNotification( ns); } c.setError(ErrorType.SUCESS); } else { c.setError(ErrorType.FAILURE); c .setErrorDescription(String .format( "No appointment

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

102

defined for citizen %s at the date of %s", customerId, (new SimpleDateFormat( "dd/MM/yyyy")) .format(appointmentDate))); } } catch (QueueServiceException e) { c.setError(ErrorType.UNKNOWN); c.setErrorDescription(e.getMessage()); e.printStackTrace(); } return msg.toString(); } private void sendMessage(String chId, String msg) { if (member != null) { String msgs = member.formatMessage(chId, msg, null); member.sendMessage(chId, msgs); } } public ServiceFactory getServiceFactory() { return serviceFactory; } public void setServiceFactory(ServiceFactory serviceFactory) { this.serviceFactory = serviceFactory; } public Member getMember() { return member; } public void setMember(Member member) { this.member = member; } }

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

103

E.9. XG2GSYNCHRON CLASS Class 9: XG2GSynchron package edu.unu.iist.emacao.queuing.xg2g; import java.util.HashMap; import java.util.Map; import edu.unu.iist.egov.emacao.queue.messages.QueueMessages; public class XG2GSynchron implements IXG2GSynchron { private Map<Long, QueueMessages> listMessage; public XG2GSynchron(){ listMessage=new HashMap<Long, QueueMessages>(); } @Override public void addMessage(QueueMessages msg) { if(msg!=null){ listMessage.put(msg.getMessageId(), msg); } } @Override public QueueMessages getMessage(long id) { QueueMessages msg=null; while(msg==null){ msg=listMessage.get(id); try { Thread.sleep(1000); } catch (InterruptedException e) { // TODO log this message e.printStackTrace(); } } return msg; } }

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

104

E.10. PORTALAPPLICATIONLISTENER CLASS Class 10: PortalApplicationListener package edu.unu.iist.emacao.queuing.xg2g; import org.apache.xmlbeans.XmlException; import edu.unu.iist.egov.emacao.queue.messages.QueueMessages; import edu.unu.iist.emacao.gateway.xmlUtil.UserMessage; import edu.unu.iist.emacao.xg2g.core.ApplicationListener; import edu.unu.iist.emacao.xg2g.core.Message; public class PortalApplicationListener implements ApplicationListener{ private IXG2GSynchron xg2gSynchron; public PortalApplicationListener(){ } @Override public void recChExtensionReply(String message) { } @Override public void recConfigureChExtensionReply(String message) { } @Override public void recCreateChannelReply(String message) { } @Override public void recDestroyChannelReply(String message) { } @Override public void recForwardReply(String message) { } @Override

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

105

public void recGetMemberReply(String message) { } @Override public void recManageReply(String message) { } @Override public void recMemberUnsubscribe(String message) { } @Override public void recReceiveMessageReply(String message) { } @Override public void recRegisterReply(String message) { } @Override public void recSendMessageReply(String message) { } @Override public void recSubscribeChannelReply(String message) { } @Override public void recUnRegisterReply(String message) { } @Override public void recUnsubscribeChannelReply(String message) { } @Override

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

APPENDICES

106

public void receiveMessage(String message) { // We need to implement this method in order to enable the portal to // receive messages. The simple idea is to extract the content and put it in a queue try { QueueMessages msg=null; Message m=new Message(message); UserMessage uMsg = UserMessage.Factory.parse(m.getUserDefinedMessage()); msg = QueueMessages.Factory.parse(uMsg.getContent() .toString()); xg2gSynchron.addMessage(msg); } catch (XmlException e) { e.printStackTrace(); } } public IXG2GSynchron getXg2gSynchron() { return xg2gSynchron; } public void setXg2gSynchron(IXG2GSynchron xg2gSynchron) { this.xg2gSynchron = xg2gSynchron; } }

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

UNU-IIST Center for Electronic Governance

Das könnte Ihnen auch gefallen