proj repo updated.docx

DONOR CATCHER USING VoIP

PROJECT REPORT

Submitted by

KADHIRESHAN.S Register No.: 11TD0455

SHANMOUGAPRIYAN.V Register No.: 11TD0523

HARIHARAN.R Register No.: 11TD0440

Under the guidance of

Mr. M. SHANMUGAM

in partial fulfillment of the requirements for the degree

of

BACHELOR OF TECHNOLOGY

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

MADAGADIPET, PUDUCHERRY-605107

APRIL 2013

SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

PONDICHERRY UNIVERSITY

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

BONAFIDE CERTIFICATE

This is to certify that the project work entitled “DONOR CATCHER USING VOIP” is a

bonafide work done by KADHIRESHAN.S [REGISTER NO.:11TD0455],

SHANMOUGAPRIYAN.V [REGISTER NO.:11TD0], HARIHARAN.R [REGISTER

NO.:11TD04] in partial fulfillment of the requirement, for the award of B.Tech Degree in

Computer Science and Engineering by Pondicherry University during the academic year 2012-

2013.

PROJECT GUIDE HEAD OF THE DEPARTMENT

Submitted for the University Examination held on ……………………………..

INTERNAL EXAMINER EXTERNAL EXAMINER

ACKNOWLEDGEMENT

We are very thankful and grateful to our beloved guide, Mr. M. SHANMUGAM whose great support in valuable advices, suggestions and tremendous help enabled us in completing our project. He has been a great source of inspiration to us.

We also sincerely thank our Head of the Department, Mr. K. PREMKUMAR whose

continuous encouragement and sufficient comments enabled us to complete our project report.

We thank all our Staff Members who have been by our side always and helped us with

our project. We also sincerely thank all the lab technicians for their help as in the course of our

project development.

We would also like to extend our sincere gratitude and grateful thanks to our Director

cum Principal, Dr. V. S. K. VENKATACHALAPATHY for having extended the Research and

Development facilities of the department.

We are grateful to our Founder Chairman Mr. N. KESAVAN. He has been a constant

source of inspiration right from the beginning.

We would like to express our faithful and grateful thanks to our Chairman & Managing

Director, Mr. M. DHANASEKARAN for his support.

We would also like to thank our Vice Chairman Mr. S. V. SUGUMARAN, for providing

us with pleasant learning environment.

We wish to thank our Family Members and Friends for their constant encouragement,

constructive criticisms and suggestions that has helped us in timely completion of this project.

Last but not the least; we would like to thank the ALMIGHTY for His grace and

blessings over us throughout the project.

ABSTRACT

Emergency situations, such as automobile or other accidents, create an immediate, critical need

for specific blood types. In mass-casualty emergencies, such as the 2006 Mumbai train blasts, the

spike in need can result in scarcities that force government authorities to ask all healthy

individuals capable of donating blood to do so. In addition to emergency requirements, advances

in medicine have increased the need for blood in many ongoing treatments and elective

surgeries.

To help meet demand, Indian citizens have created Web sites to match blood donors and

recipients. Donors register themselves on the sites, specifying their blood types and contact

information; requesters do the same, specifying when they need what blood type. Sometimes

requesters must specify months in advance of elective treatments because of donation shortages.

Two problems arise with this Web based approach to blood distribution. First, it doesn’t address

immediate emergency requirements. Second, in a country like India, many people lack access to

Internet facilities. Cell phones, however, are becoming ubiquitous in emerging. In India, smart

phones are more common than PDAs and computers, simply because they’re more affordable.

So, we are having a Smart phone application to search donor and also to register as a donor. And

we have a new system, when a users call to our server, It will respond a IVR message, asking the

language, blood group and the location via DTMF tones and redirects the call to the donor. So

any user at any situation using any mobile he can get the donor.

iv

LIST OF TABLES

TABLE NO. NAME OF THE TABLE PAGE NO.

1.1 DTMF keypad frequencies 4

V

LIST OF FIGURES

FIGURE NO. NAME OF THE FIGURE PAGE NO.

3.1 Functioning of Eligible donor finding Algorithm 6

4.1 Use case diagram of donor catcher system

4.2Activity diagram of donor catcher system

4.3Class diagram of donor catcher system

4.4Component diagram of donor catcher system

4.5Deployment diagram of donor catcher system

vi

LIST OF ABBREVIATIONS

DTMF – Dual Tone Multi Frequency

IVR - Interactive Voice Response

VoIP - Voice over Internet Protocol

vii

TABLE OF CONTENTS

CHAPTER NO. TITLE PAGE NO.

ABSTRACT iv

LIST OF TABLES v

LIST OF FIGURES vi

LIST OF ABBREVIATIONS vii

1. 1 INTRODUCTION 1

1.1 COMMUNICATION TECHNOLOGY 1

1.2 TECHNOLOGIES USED 2

1.2.1 Interactive voice response 2

1.2.2 Dual Tone Multi Frequency 3

1.2.3 Voice over Internet Protocol 4

1.2.4 Standalone mobile application 5

2. 2 LITERATURE SURVEY 6

2.1 AUTOMATED ONLINE BLOOD BANK

DATABASE 6

2.2 SMART PHONES TO THE RESCUE: THE VIRTUAL

BLOOD BANK PROJECT 7

2.3 SMART BLOOD QUERY: A NOVEL MOBILE

PHONE BASED PRIVACY- AWARE BLOOD

DONOR RECRUITMENT AND MANAGEMENT

FOR DEVELOPING REGIONS 7

2.4 MHEALTH: BLOOD DONATION SERVICE IN

BANGLADESH 8

2 3 SYSTEM STUDY 9

3.1 EXISTING SYSTEM 9

3.1.1 Issues in the system 9

3.1.2 Solutions 9

3.2 PROPOSED SYSTEM 9

4 4 SYSTEM REQUIREMENTS 14

4.1 HARDWARE REQUIREMENTS 14

4.2 SOFTWARE REQUIREMENTS 14

5 DESIGN AND IMPLEMENTATION 15

5.1 OBJECT ORIENTED ANALYSIS 15

5.2 SYSTEM ARCHITECTURE 19

5.3 IMPLEMENTATION DETAILS 19

5.3.1 Call receiving module 19

5.3.2 Call processing module 19

5.3.3 Call forwarding module 20

5 6 CONCLUSION & FUTURE ENHANCEMENT 21

6.1 CONCLUSION 21

6.2 FUTURE ENHANCEMENT 21

APPENDICES

APPENDIX 1 (SAMPLE SCREEN SHOTS)

APPENDIX 2 (PUBLICATIONS)

REFERENCES 22

CHAPTER 1

INTRODUCTION

1.1 COMMUNICATION TECHNOLOGY

A basic telecommunication system consists of three primary units that are always present in some

form:

A transmitter that takes information and converts it to a signal.

A transmission medium, also called the "physical channel" that carries the signal. An example of this

is the "free space channel".

A receiver that takes the signal from the channel and converts it back into usable information.

For example, in a radio broadcasting station the station's large power amplifier is the transmitter; and the

broadcasting antenna is the interface between the power amplifier and the "free space channel". The free space

channel is the transmission medium; and the receiver's antenna is the interface between the free space channel

and the receiver. Next, the radio receiver is the destination of the radio signal, and this is where it is converted

from electricity to sound for people to listen to.

Sometimes, telecommunication systems are "duplex" (two-way systems) with a single box

of electronics working as both a transmitter and a receiver, or a transceiver. For example, a cellular

telephone is a transceiver. The transmission electronics and the receiver electronics in a transceiver are actually

quite independent of each other. This can be readily explained by the fact that radio transmitters contain power

amplifiers that operate with electrical powers measured in the watts or kilowatts, but radio receiver’s deal with

radio powers that are measured in the microwatts or nanowatts. Hence, transceivers have to be carefully

designed and built to isolate their high-power circuitry and their low-power circuitry from each other.

Telecommunication over fixed lines is called point-to-point communication because it is between one

transmitter and one receiver. Telecommunication through radio broadcasts is called broadcast

communication because it is between one powerful transmitter and numerous low-power but sensitive radio

receivers.

Telecommunications in which multiple transmitters and multiple receivers have been designed to cooperate

and to share the same physical channel are called multiplex systems. The sharing of physical channels using

multiplexing often gives very large reductions in costs. Multiplexed systems are laid out in telecommunication

networks, and the multiplexed signals are switched at nodes through to the correct destination terminal

receiver.

1

1.2 TECHNOLOGIES USED

1.2.1 Interactive voice response

Interactive voice response (IVR) is a technology that allows a computer to interact with humans through

the use of voice and DTMF tones input via keypad.

In telecommunications, IVR allows customers to interact with a company’s host system via a telephone

keypad or by speech recognition, after which they can service their own inquiries by following the IVR

dialogue. IVR systems can respond with pre recorded or dynamically generated audio to further direct

users on how to proceed. IVR applications can be used to control almost any function where the interface

can be broken down into a series of simple interactions. IVR systems deployed in the network are sized to

handle large call volumes.

It is common in industries that have recently entered the telecommunications industry to refer to

an automated attendant as an IVR. The terms, however, are distinct and mean different things to

traditional telecommunications professionals, whereas emerging telephony and VoIP professionals often

use the term IVR as a catch-all to signify any kind of telephony menu, even a basic automated attendant.

The term voice response unit (VRU), is sometimes used as well.

IVR systems are typically intended to service high call volumes, reduce cost and improve the customer

experience. Examples of typical IVR applications are telephone banking, televoting, and credit

card services. Companies also use IVR services to extend their business hours to 24/7 operation. The use

of IVR and voice automation allows callers' queries to be resolved without the need for queuing and

incurring the cost of a live agent. If callers do not find the information they need or require further

assistance, their calls are often transferred to an agent. This makes for a more efficient system in which

agents have more time to deal with complex interactions. The agents do not deal with basic inquiries that

require yes/no responses or obtaining customer details.

Call centres use IVR systems to identify and segment callers. The ability to identify customers allows

services to be tailored according to the customer profile. The caller can be given the option to wait in the

queue, choose an automated service, or request a call back. The system may obtain caller line

identification (CLI) data from the network to help identify or authenticate the caller. Additional caller

authentication data could include account number, personal information, password and biometrics (such

as voice print).

When an IVR system answers multiple phone numbers the use of DNIS ensures that the correct

application and language is executed. A single large IVR system can handle calls for thousands of

applications, each with its own phone numbers and script.

IVR also enables customer prioritization. In a system wherein individual customers may have a different

status the service will automatically prioritize the individual's call and move customers to the front of a

specific queue. Prioritization could also be based on the DNIS and call reason.

2

http://en.wikipedia.org/wiki/Televoting

Smaller companies and start-ups can also use an IVR system to make their business appear larger than it

is. For example, a caller never needs to know that their sales and support calls are routed to the same

person.

In addition to interacting with customer information systems and databases, IVRs will also log call detail

information into its own database for auditing, performance report, and future IVR system enhancements.

1.2.2 Dual Tone Multi Frequency

Dual-tone multi-frequency signalling (DTMF) is an in-band telecommunication signalling system

using the voice-frequency band over telephone lines between telephone equipment and other

communications devices and switching centres

Multi-frequency signalling is a group of signalling methods that use a mixture of two pure

tone (pure sine wave) sounds. Various MF signalling protocols were devised by the Bell

System and CCITT. The earliest of these were for in-band signalling between switching centres,

where long-distance telephone operators used a 16-digit keypad to input the next portion of the

destination telephone number in order to contact the next downstream long-distance telephone operator.

This semi-automated signalling and switching proved successful in both speed and cost effectiveness.

Based on this prior success with using MF by specialists to establish long-distance telephone calls, dual-

tone multi-frequency signalling was developed for end-user signalling without the assistance of operators.

The DTMF system uses a set of eight audio frequencies transmitted in pairs to represent 16 signals,

represented by digits, letters, and symbols. As the signals are audible tones in the standard telephony

voice frequency range, they could be transmitted across long distances through electrical repeaters and

amplifiers, and over radio and microwave links, thus eliminating the need for intermediate operators.

The DTMF telephone keypad is laid out in a 4×4 matrix of push buttons in which each row represents

the low frequency component and each column represents the high frequency component of the DTMF

signal. Pressing a key sends a combination of the row and column frequencies. For example, the

key 1 produces a superimposition of tones of 697 and 1209 hertz (Hz). Initial pushbutton designs

employed levers, so that each button activated two contacts. The tones are decoded by the switching

centre to determine the keys pressed by the user.

3

DTMF keypad frequencies

1209 Hz 1336 Hz 1477 Hz 1633 Hz

697 H

z1 2 3 A

770 H

z4 5 6 B

852 H

z7 8 9 C

941 H

z* 0 # D

Table 1.1 DTMF keypad frequencies

1.2.3 Voice Over IP

Voice over IP (VoIP) is a methodology and group of technologies for the delivery of voice

communications and multimedia sessions over Internet Protocol (IP) networks, such as the Internet. Other

terms commonly associated with VoIP are IP telephony, Internet telephony, broadband telephony,

and broadband phone service.

The term Internet telephony specifically refers to the provisioning of communications services

(voice, fax, SMS, voice-messaging) over the public Internet, rather than via the public switched telephone

network (PSTN). The steps and principles involved in originating VoIP telephone calls are similar to

traditional digital telephony and involve signalling, channel setup, digitization of the analog voice signals,

and encoding. Instead of being transmitted over a circuit-switched network, however, the digital

information is packetized, and transmission occurs as IP packets over a packet-switched network. Such

transmission entails careful considerations about resource management different from time-division

multiplexing (TDM) networks.

4

Early providers of voice-over-IP services offered business models and technical solutions that mirrored

the architecture of the legacy telephone network. Second-generation providers, such as Skype, have built

closed networks for private user bases, offering the benefit of free calls and convenience while potentially

charging for access to other communication networks, such as the PSTN. This has limited the freedom of

users to mix-and-match third-party hardware and software. Third-generation providers, such as Google

Talk, have adopted the concept of federated VoIP—which is a departure from the architecture of the

legacy networks. These solutions typically allow dynamic interconnection between users on any two

domains on the Internet when a user wishes to place a call.

VoIP systems employ session control and signalling protocols to control the signalling, set-up, and tear-

down of calls. They transport audio streams over IP networks using special media delivery protocols that

encode voice, audio, video with audio codec’s, and video codec’s as Digital audio by streaming media.

Various codec’s exist that optimize the media stream based on application requirements and network

bandwidth; some implementations rely on narrowband and compressed speech, while others support high

fidelity stereo codec’s. Some popular codec’s include μ-law and a-law versions of G.711, G.722, which is

a high-fidelity codec, marketed as HD Voice by Polycom, a popular open source voice codec known

as iLBC, a codec that only uses 8 Kbit/s each way called G.729, and many others.

VoIP is available on many smart phones, personal computers, and on Internet access devices. Calls and

SMS text messages may be sent over 3G or Wi-Fi.

1.2.4 Standalone Mobile Application

A mobile app is a computer program designed to run on smart phones, tablet computers and other mobile devices.

Apps are usually available through application distribution platforms, which began appearing in 2008 and are typically operated by the owner of the mobile operating system, such as the Apple App Store, Google Play, Windows Phone Store, and BlackBerry App World. Some apps are free, while others must be bought. Usually, they are downloaded from the platform to a target device, such as an iPhone, BlackBerry, Android phone or Windows Phone, but sometimes they can be downloaded to laptops or desktop computers. For apps with a price, generally a percentage, 20-30%, goes to the distribution provider (such as iTunes), and the rest goes to the producer of the app.[1]The same app can therefore cost the average Smartphone user a different price depending on whether they use iPhone, Android, or BlackBerry 10 devices.

Mobile apps were originally offered for general productivity and information retrieval, including email, calendar, contacts, stock market and weather information. However, public demand and the availability of developer tools drove rapid expansion into other categories, such as word processing, social media, picture sharing, mobile games, factory automation, GPS mapping and location-based services, banking, networking and file transfer, education, video streaming, order tracking, ticket purchases and recently mobile medical apps. The explosion in number and variety of apps made discovery a challenge, which in turn led to the creation of a wide range of review, recommendation, and

5

http://en.wikipedia.org/wiki/Mobile_app#cite_note-1

http://en.wikipedia.org/wiki/ILBC

http://en.wikipedia.org/wiki/Polycom

curation sources, including blogs, magazines, and dedicated online app-discovery services. Recently government regulatory agencies have launched initiatives to regulate and curate apps, particularly medical apps.

CHAPTER 2

LITERATURE SURVEY

In this chapter we see an overview of some related research works presented.

2.1 SMART PHONES TO THE RESCUE: THE VIRTUAL BLOOD BANK PROJECT

AUTHOR: Ramesh Singh, Preeti Bhargava, and Samta Kain

IDEA

Donors register with the service through their mobile devices, specifying their blood type and contact information in a donor application.

The General Packet Radio Service supports network communications between mobile devices and the server.

The server stores information about the available blood supply in a central data repository.

People who seek blood also communicate with the server through their mobile devices, specifying their blood type and current location in a subscriber application.

The server matches the blood type and location with the profiles of registered donors or blood banks, retrieves the information, and sends it to the seeker via GPRS.

The architecture thus embodies a pervasive network of information about availability of the requested blood type.

DISADVANTAGE

It needs GPRS service in mobile phone.

6

2.2 Smart Blood Query: A Novel Mobile Phone Based Privacy-aware Blood Donor Recruitment and Management System for Developing Regions

AUTHOR: Ren Muhammad Sajidur Rahman, Khondoker Asif Akter, Shakil Hossain, Anjon Basak, Syed Ishtiaque Ahmed

IDEA

Blood donors register for this service through SMS, specifying their blood groups and other necessary information in specific format. These are stored in the central database.

Donors are also given the option to edit their profile and update details such as change in location or availability.

When a query for blood come to SBQ server, it makes a quick query and sends a bulk SMS to top 5 search result donors, stating the situation.

The donors have the option to either accept the request by replying ‘YES’ or deny it by replying ‘NO’. If a donor agrees to the request, he/she is sent a brief questionnaire in order to check if he/she fulfils the requirements of blood donation.

If everything is all right, the donor then contacts with the recipient. When a donor updates the date of last donation by SMS, his name is disabled from the donor list for 89 days after donation.

Similarly, if the donor is unwell, he can edit his profile and mark as “unavailable.”

DISADVANTAGE

User needs messaging service in mobile phone.

Every people cannot use this service easily, literates only can do.

7

2.3 AUTOMATED ONLINE BLOOD BANK DATABASE

AUTHOR: Muhammad Arif, Sreevass, Nafseer K, Rahul R

IDEA

A blood bank database is created by collection of details from various sources like Blood banks, NSS, NGO‘s hospitals and through web interface.

The data collected will be maintained in a central server. This central server will be associated with a Toll free number that can be used to connect to it.

An algorithm will be defined based on the various parameters that need to be accounted for, before blood transfer is done.

The willingness of donor and the closeness of the donor to the place from where the call is coming are also accounted for in defining this algorithm.

Based on the algorithm the most eligible donor is found out.

From the server the call from the required person is routed to the eligible donor's number.

DISADVANTAGE

It has a more complex structure.

It costs very high.

8

2.4 mHealth: Blood Donation Service in Bangladesh

AUTHOR: A. H. M. Saiful Islam, Nova Ahmed, Kamrul Hasan and Md. Jubayer

IDEA

Clients as well as Blood donors need to be registered first for this project to collect donors’ record.

A client or donor is managed by a mobile phone.

The collected data is constantly wirelessly transmitted GPRS to a data centre, from where it is forwarded to responsible personnel who can assess required information of a donor.

The registration processes are done wirelessly using GPRS to a data centre acting as an intermediary between donors/clients.

It provides two services: data repository (collecting and storage of the received data), streaming service (forwarding data to a donor or client) using SMS.

DISADVANTAGE

It needs both GPRS and Messaging service.

The user who searches for blood should also be registered to search.

9

CHAPTER 3

SYSTEM STUDY

3

3.1 EXISTING SYSTEM

3.1.1 ISSUES IN THE SYSTEM

SMS service and GPRS service becomes essential in the existing system, which every one cannot have and one cannot have it in every time.

Needs some kind of English knowledge for using the existing system.

Registration may take time while one searches for donor and it is unnecessary.

3.1.2 SOLUTIONS

The system is made to be used by everyone, anyone who has a basic mobile phone or a telephone or by a pay phone, can access this service.

Those who wish to register can register using the web application provided.

3.2 PROPOSED SYSTEM

Working

1) Processing Steps:

i. Call is made to the server

ii. Required blood group is typed on the keypad

iii. DTMF decoder decodes this key

iv. Algorithm comes into play getting the list of eligible donors

v. Call gets routed to the most eligible donor

10

vi. In case the most eligible donor is not responding, automatically the call gets routed to the second most eligible donor

vii. IVRS system constantly updates the person who is making the call so that he knows what process is going on.

2) Functioning of Eligible donor finding Algorithm

A key component of the system is the algorithm used for determining a prospective donor in real time. The parameters which are taken into consideration are:

Blood group

Last time of donation

Health parameters

Closeness to location from where call is happening

Frequency of donation

We should ensure that the hit rate of finding a successful donor after a redirection is as high as possible, since both the time of caller and system resources are crucial.

Inputs: The DONOR table and a blood group

Outputs: The highest priority donor of that blood group

Steps:

I. Start.

II. LOC=closest location in donor table.

III. Get the list of donors in location=LOC. Let this be list Ll.

IV. OLD DONATION=oldest donation date from list Ll.

V. From list Ll get the list of donors who last donated on day=OLD_DONATION. Let this be list L2.

VI. OLD CONTACT=oldest contact date from list L2.

VII. From list L2 get the list of donors who were contacted on day=OLD CONTACT. Let this be list L3.

VIII. BMI=maximum Body Mass Index from list L3.

IX. From list L3, select a donor whose body mass index >= BMI. He/she is the most eligible donor.

11

X. Stop.

This algorithm considers four parameters for selection. The parameters with their priority are given below:

a. Health parameters.

b. Location (distance between the donor and recipient).

c. Last Donation Date.

d. Last Contact Date.

12

Fig 3.1 Functioning of Eligible donor finding Algorithm

KEY ISSUES

1) Tackling fake callers

In order to prevent the issue of fake callers demanding for blood, DTMF password facility is provided. These passwords are one time passwords that are provided through hospitals or blood banks.

13

2) Tackling fake donors

Since a dynamic algorithm for choosing the most eligible donor is followed, which takes into account the willingness factor of each donor, fake donors will automatically be relegated to the bottom of the donor list.

3) Follow up communication with the donor

Once the initial communication between the donor and recipient is completed, a SMS containing the recipient's number is given to the donor for follow up communication. An alternate IVRS facility is also provided keeping in mind the landline phone users for whom the phone number will be dictated out.

4) Handling large user traffic blood

To handle large user traffic parallel programming is employed. When a higher demand for blood is needed, by pressing a key on the phone, automatic redirection to the next most eligible donor is made possible. A limit of 5 donors is kept for each caller. For people with constant demand for blood, like people with blood cancer, a separate registry of their phone numbers is kept.

5) Avoiding intermediaries from creating artificial scarcity

A caller's database is maintained and monitored to ensure the too frequent calls from the same number are not made. A separate registry is made containing phone numbers of hospitals and blood banks. Thus tracking of intermediaries or agents can be made possible.

6) Updating database

For every blood transfusion made, it is essential that the database is updated about this transfer. It is essential factor that should be considered for selecting the most eligible donor the next time, as a minimum of 56 days should be passed between successive whole blood donations. This updating is done based on the confirmation from both the donor and the blood bank/hospital where the donation was done.

ADVANTAGES

ADVANTAGES OVER OTHER SIMILAR SYSTEMS

14

When there is urgent need for blood, it may not be possible for people to connect to the internet to look into the online blood database systems that are already in existence. If we adopt this model, the caller is immediately connected to the donor.

Consider a SMS based database system is in which whenever a SMS is send to prospective senders, based on the demand. Here there will be a significant delay in the recipient side in viewing the SMS and then responding to it. If the system that we propose is setup, only the most eligible donor is contacted and that too with no cost being borne by him.

Another significant advantage is the fact that location details of prospective donors is taken into account by the algorithm. This ensures that automatically the nearest donor is contacted and immediate fulfilment of blood requirement is done. In other similar systems, there is no such provision, which again adds on to the delay in getting a donor.

A toll free number is used to connect to the server. Any other additional cost that may occur will be minimal that can be borne by government or NGO's. So any common man at the time his utmost need can connect to this system for help.

Internet access is not a essential requirement for the effective working of this system. This enables the system to be used in rural areas as well, which are not well connected by internet service.

An apt scenario where the full use of this system can be described is some big vehicle accident. There will be a number of people who will be in urgent need of blood of different blood groups. Once they connect to this system, the IVRS system automatically directs to them the most eligible donor of that specific blood group. Also, will multiple number of parallel ports provided, considerable amount of traffic can be easily handled.

4 CHAPTER 4

5 SYSTEM REQUIREMENTS

4.1 HARDWARE REQUIREMENTS

15

For simulation

Processor Intel Pentium IV or higher

RAM 2 GB

Secondary Memory 500 MB

Display 14” colour monitor

Keyboard 101 key standard keyboard

Mouse Windows OS compatible

For working

Any Mobile phone or Telephone

For Android Application

OS Android 4.1 or Above

RAM 512 MB

Memory 100 MB

4.2 SOFTWARE REQUIREMENTS

Operating System Linux x86 32/64-bit Windows 7, 8 and XP

Mac OS X 10.7,10.8 and 10.9

Tool C Complier and System Libraries

CHAPTER 5

DESIGN AND IMPLEMENTATION

5.1 OBJECT ORIENTED ANALYSIS

16

5.1.1 USE- CASE DIAGRAM

Fig 5.1 Use case diagram of donor catcher system

Explanation:

The hospital will maintain the donor list and will update the benefactor and donor details. The user will call the toll free number and will ask for the required blood group. The donor will register his details and will update the personal and donor details it will be maintained by the hospital and the administrator. The administrator will collect the donor details from the NGO and will invest later.

5.1.2 ACTIVITY DIAGRAM

17

Fig 5.2 Activity diagram of donor catcher system

Explanation:

The donor will register his details and will update the personal and donation information.The user will call the toll free number and will enter the blood group and the call will be forwarded to the best eligible donor. The user will receive the SMS later.

5.1.3. CLASS DIAGRAM

18

Fig 5.3 Class diagram of donor catcher system

Explanation:

The donor will give his personal details and it will be stored in the server. The hospitals information is also stored in the server. The user will request the server and will get the required information.

5.1.4 COMPONENT DIAGRAM

19

Fig 5.4 Component diagram of donor catcher system

Explanation:

The user will search and filter the details and will forward the required details. The user will request for the information from the server.

20

5.1.5 DEPLOYMENT DIAGRAM

Fig 5.5 Use case diagram of donor catcher system

Explanation:

The communication takes place through the mobile phone and by the telephone exchange. They request information from the server and it is stored in the database for future use.

5.2 SYSTEM DESIGN

21

Fig 5.6 System design diagram of Donor catcher system

5.3 IMPLEMENTATION DETAILS

5.3.1 Call Receiving Module

The call made by the users will be handled by our server. IVR will respond to the user. It will ask the users to press numbers for questions like city, blood group, language etc. The user will press the number; the mobile will send the DTMF tones to the server and the server will process according to the DTMF.

5.3.2 Call Processing Module

The server will receive the DTMF values for city and blood group. The server will search the donors in that city in that blood group and will check the last donated date, when the user matches all the criteria’s the call will be forwarded to the respective donor.

5.3.3Call Forwarding ModuleThe calls will be forwarded to the respective donors. The user will now talk to the donor, when he is

satisfied, he will be asked to press one button, when not satisfied, he will be asked to press another button

and the server will forward the call to the next donor.

CHAPTER 6

22

CONCLUSION & FUTURE ENHANCEMENT

5.1 CONCLUSION

We all know blood is a primary necessity of life. There are lots of scenarios where immediate availability of blood can save human lives. Our project makes one step in this direction. Online database aided with automatic call routing facility can is an apt choice for immediate fulfilment of blood requirements.

5.2 FUTURE ENHANCEMENT

We have simulated the telecommunication concept to the mobile phones. It can be made into real time and so it will be helpful to the public.

Hospital logins in the websites are yet to be made. So the hospitals can update the details of the donor on the spot when need, and they can also search for the donors.

REFERENCES

23

1. T Santhanam, S Sundaram, “Application of CART Algorithm in Blood Donors Classification”, Journal of Computer Science, 2010 – scipub.org.

2. Kapicak, L. ,Nevlud, P. , Zdralek, J. , Dubec, P. , Plucar, J. "Remote control of Asterisk via Web Services", 34th International Conference on Telecommunications and Signal Processing (TSP), 2011

3. Sripanidkulchai, K., Shu Tao, Zon-Yin Shae "DA VINCI: A tool to improve VoIP call routing configurations", IEEE Network Operations and Management Symposiwn (NOMS), 2010

4. Dinusha Vatsalan1,Shiromi Arunatileka, Keith Chapman, Gihan Senaviratne, Saatviga etileka and Yvonne Wickramasinghe, Mobile Technologies for Enhancing eHealth Solutions in Developing Countries,2010 Second International Conference on eHealth, Telemedicine, and Social Medicine

5. BN Li, S Chao, MC Dong, “SIBAS: a blood bank information system and its 5-year implementation at Macau”, Computers in Biology and Medicine, 2007-Elsevier.

APPENDICES

24

APPENDIX 1

Coding of Mobile Application

Index.html

<!DOCTYPE HTML><html> <head> <meta charset="UTF-8">

<title>index</title> <meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-

scale=1.0, minimum-scale=1.0, user-scalable=0"> <link rel="shortcut icon" href="images/favicon.png"> <link rel="apple-touch-icon" href="images/apple-touch-icon.png"> <link href="jqueryMobile/jquery.mobile-1.4.0.css" rel="stylesheet"> <link href="jqueryMobile/jquery.mobile-1.4.0.min.css" rel="stylesheet"> <link rel="stylesheet" href="css/main.css"> <script>window.$ = window.jQuery = WLJQ;</script> <script src="jqueryMobile/jquery.mobile-1.4.0.js"></script> <link href="native/www/default/jqueryMobile/jquery.mobile-1.4.0.css" rel="stylesheet"> <link href="native/www/default/jqueryMobile/jquery.mobile-1.4.0.css" rel="stylesheet"> <link href="native/www/default/jqueryMobile/jquery.mobile-1.4.0.css" rel="stylesheet"> <link href="native/www/default/jqueryMobile/jquery.mobile-1.4.0.css" rel="stylesheet">

<link href="native/assets/www/default/jqueryMobile/jquery.mobile-1.4.0.min.css"rel="stylesheet">

</head> <body onload="startTime()"> <div data-role="page" id="page" data-theme="b" > <div data-role="content" style="padding: 15px">  <div data-role="header" data-position="fixed"> <h1>Choose</h1> </div> <div id="txt" align="right"></div> <br><br><br><br> <a href="#" data-role="button" id="reg" onClick="reg()">Register</a> <a href="#" data-role="button" id="need" onClick="need()">Need Blood?</a> <a href="#" data-role="button" id="dnd" onClick="dnd()">Update activities</a>

25

</div> <br><br><br> <div data-role="footer">

<marquee>Save blood, save life</marquee></div></div>

<div data-role="page" id="page1" data-theme="b" > <div data-role="content" style="padding: 15px">  <div data-role="header" data-position="fixed"> <h1>Register</h1> </div> <div data-role="navbar"> <ul> <li><a href="#" id="home2">Home</a></li> <li><a href="#" id="reg2">Register</a></li> <li><a href="#" id="sear2">Search</a></li> </ul>

</div><form name="myForm"><input type="text" id="name" name="name"

placeholder="Name"> <input type="text" id="mno" name="mno" placeholder="Mobile

number"> <select id="bg" name="bg">

<option value="A+"selected>A+</option><option value="A-">A-</option><option value="B+">B+</option><option value="B-">B-</option><option value="AB+">AB+</option><option value="AB-">AB-</option><option value="O+">O+</option><option value="O-">O-</option>

</select> <input type="password" id="addr" name="addr" placeholder="Enter

password"><input type="text" id="addr2" name="addr2" placeholder="Door no.,

street,"><input type="text" id="addr3" name="addr3" placeholder="Area, city,

state"><!--<table>

26

<tr><td>Post</td><td><select id="public1"> <option value="yes">Yes</option> <option value="no">No</option> </select>

</td></tr> </table>--><table>

<tbody>

<tr><td>Drinking?:</td><td><select id="drink">

<option value="yes" >Yes</option><option selected

value="no">No</option></select></td>

</tr></tbody>

</table>  <input type="text" id="std" name="std" placeholder="STD Code"><input type="text" id="pin" name="pin" placeholder="PIN Number"> <a href="#" data-role="button" id="reg"

onclick="submit()">REGISTER</a></form></div>

</div> <div data-role="page" id="page2" data-theme="b"> <div data-role="content" style="padding: 15px">  <div data-role="header" data-position="fixed"> <h1>Search blood</h1> </div> <div data-role="navbar"> <ul> <li><a href="#" id="home1">Home</a></li> <li><a href="#" id="reg1">Register</a></li>

27

<li><a href="#" id="sear1">Search</a></li> </ul>

</div>

<select id="bloody" name="bloody"><option value="A+"selected>A+</option><option value="A-">A-</option><option value="B+">B+</option><option value="B-">B-</option><option value="AB+">AB+</option><option value="AB-">AB-</option><option value="O+">O+</option><option value="O-">O-</option>

</select>  <input type="text" id="stdcode" name="stdcode" placeholder="STD code"> <input type="button" id="search1" name="search1" value="Search" onclick="search()"> <br><br><br><br>

<a href="#" data-role="footer" id="back" onclick="back()">Back</a>

</div></div>

<div data-role="page" id="dndpage" data-theme="b" > <div data-role="content" style="padding: 15px">  <div data-role="header" data-position="fixed"> <h1>Update activities</h1> <div data-role="navbar"> <ul> <li><a href="#" id="home3">Home</a></li> <li><a href="#" id="reg3">Register</a></li> <li><a href="#" id="sear3">Search</a></li> </ul>


</div>

28

<input type="text" id="dndmno" name="mno" placeholder="Mobile number">

<input type="password" id="dndname" name="name" placeholder="Password">

<select id="dndbg" name="bg"><option value="A+"selected>A+</option><option value="A-">A-</option><option value="B+">B+</option><option value="B-">B-</option><option value="AB+">AB+</option><option value="AB-">AB-</option><option value="O+">O+</option><option value="O-">O-</option>

</select> <a href="#" data-role="button" id="login"

onClick="login()">ENTER</a></div></div>

<div data-role="page" id="dndpage1" data-theme="b" > <div data-role="content" style="padding: 15px">  <div data-role="header" data-position="fixed"> <h1>Do not disturb</h1>

</div> <div data-role="navbar">

<ul> <li><a href="#" id="home4">Home</a></li> <li><a href="#" id="reg4">Register</a></li> <li><a href="#" id="sear4">Search</a></li> </ul>


 <select id="reason" name="dnddetail">

29

<option value="6mon"selected>Blood donated, don't disturb for 6 months</option>

<option value="never">Not interested, never disturb</option><option value="act">Activate me again</option>

</select>

<a href="#" data-role="button" id="dndenter" onClick="dndenter()">DND</a>

</div></div>

<div data-role="page" id="page4" data-theme="b" data-dom-cache="false">

<input type="button" id="backgo" onclick="backgo()" value="Back"> <div data-role="content" style="padding: 15px"> 

<div data-role="listview" id="con"><form id="form" action="">

<ol id="listview"><li></li>

</ol></form>

</div></div></div>

<div data-role="page" id="page5" data-theme="b" > <div data-role="content" style="padding: 15px"> 

30

<div data-role="listview" id="con">

<label id="label">HI:</label><form id="form1" action="">

<ol id="listview1"><li></li>

</ol></form>

</div></div></div>

<div data-role="page" id="page7" data-theme="b" ><div data-role="content" style="padding: 15px">

<input type="button" id="mapback" onclick="backend()" value="Back">

</div> <div data-role="content" id="mapp" style="padding: 15px" style="height: 400px;" > 

</div></div>

<script src="js/initOptions.js"></script> <script src="js/main.js"></script> <script src="js/messages.js"></script> <script src="https://maps.googleapis.com/maps/api/js?v=3.exp&sensor=false"></script>

<script type="text/javascript" src="http://maps.google.com/maps/api/js?sensor=false"></script> </body></html>

Main.css/* Reset CSS */a, abbr, address, article, aside, audio, b, blockquote, body, canvas, caption, cite, code, dd, del, details, dfn, dialog, div, dl, dt, em, fieldset, figcaption, figure, footer, form, h1, h2, h3, h4, h5, h6, header, hgroup, html, i, iframe, img, ins, kbd, label, legend, li, mark, menu, nav, object, ol, p, pre, q, samp, section, small, span, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, time, tr, ul, var, video {

margin: 0;31

padding: 0;}

/* Worklight container div */body {

height: 460px;margin: 0 auto;width: 320px;

} ]

Main.js

function wlCommonInit(){

/* * Application is started in offline mode as defined by a connectOnStartup property in

initOptions.js file. * In order to begin communicating with Worklight Server you need to either: * * 1. Change connectOnStartup property in initOptions.js to true. * This will make Worklight framework automatically attempt to connect to Worklight Server

as a part of application start-up. * Keep in mind - this may increase application start-up time. * * 2. Use WL.Client.connect() API once connectivity to a Worklight Server is required. * This API needs to be called only once, before any other WL.Client methods that

communicate with the Worklight Server. * Don't forget to specify and implement onSuccess and onFailure callback functions for

WL.Client.connect(), e.g: * * WL.Client.connect({ * onSuccess: onConnectSuccess, * onFailure: onConnectFailure * }); * */

// Common initialization code goes here

}function startTime(){

32

});$("#sear3").click(function() { $.mobile.changePage('#page2');});$("#sear4").click(function() { $.mobile.changePage('#page2');});$("#home1").click(function() { $.mobile.changePage('#page');});$("#home2").click(function() { $.mobile.changePage('#page');});$("#home3").click(function() { $.mobile.changePage('#page');});$("#home4").click(function() { $.mobile.changePage('#page');});function backend(){

$.mobile.changePage('#page4',{transition:"slide"});

}function back(){

$.mobile.changePage('#page',{transition:"slide"});

}function backgo(){

$.mobile.changePage('#page2',{transition:"slide"}); //$('#page4').reload();

}function mapback()

34

{

$.mobile.changePage('#page5',{transition:"slide"});

}function mappage(k){

$.mobile.changePage('#page7',{transition:"slide"});//alert(window.myValue[k]);//alert(window.myValue1[k]);

var map;

var geocoder = new google.maps.Geocoder();var address = window.myValue1[k];var latitude;var longitude;//$('#page7').refresh();//$('#page7').append("<br><br>");//$('#page7').append("Name:<b>"+window.myValue2name[k].toUpperCase()+"</b><br>");//$('#page7').append("Blood group:<b>"+window.myValue4bg[k]+"</b><br>"); //$('#page7').append("Mobile number:<b>"+window.myValue3mobile[k]+"</b><br>");//$('#page7').append("Address:<b>"+window.myValue[k]+","+window.myValue1[k]+"</b><br>");//$('#page7').append("Pincode:<b>"+window.myValue5pin[k]+"</b><br>");

//$('#page7').append("<br><br>");

geocoder.geocode( { 'address': address}, function(results, status) {

if (status == google.maps.GeocoderStatus.OK) { window.latitude = results[0].geometry.location.lat(); window.longitude = results[0].geometry.location.lng();

} else { alert('Geocode was not successful for the following reason: ' + status); }

//var address = document.getElementById('address').value;35

geocoder.geocode( { 'address': address}, function(results, status) { if (status == google.maps.GeocoderStatus.OK) { map.setCenter(results[0].geometry.location); var marker = new google.maps.Marker({ map: map, position: results[0].geometry.location }); } else { alert('Geocode was not successful for the following reason: ' + status); } });

var mapOptions = { zoom: 15, center: new google.maps.LatLng(window.latitude, window.longitude) };

map = new google.maps.Map(document.getElementById('mapp'), mapOptions);

});

google.maps.event.addDomListener(window, 'load', initialize);

}function dnd(){

$.mobile.changePage('#dndpage',{transition:"slide"});}

function reg(){

$.mobile.changePage('#page1',{transition:"turn"});

}

36

onFailure:function(result){$.mobile.loading('hide');alert("Retry again...");}

});

}catch(err1){alert(err1);}

}

function submit(){

var name=$("#name").val();if(name==""){

alert("Enter valid name");document.myForm.name.focus() ;return false;

}var mobileno=$("#mno").val();{

if (mobileno.length!=10) { alert("Enter 10 digit mobile number"); document.myForm.mno.focus() ; return false; }

}var bg=$("#bg").val();var street=$("#addr").val();if(street<5)

{alert("Enter password greater than 5 digits");document.myForm.addr.focus() ;

return false;}

var city=$("#addr2").val();if(city==""){

alert("Enter address");document.myForm.addr2.focus() ;

39

return false;}

var country=$("#addr3").val();if(country==""){

alert("Enter address");document.myForm.addr3.focus() ;

return false;}

//var public1=$("#public1").val();var drink=$("#drink").val();var std=$("#std").val();if(std==""){

alert("Enter valid STD code");document.myForm.std.focus() ;

return false;}

var pin=$("#pin").val();{

if( document.myForm.pin.value == "" || isNaN( document.myForm.pin.value ) || document.myForm.pin.value.length != 6) { alert( "Please provide a zip in the format ######" ); document.myForm.Zip.focus() ; return false; }

}try{WL.Client.invokeProcedure({

adapter : "sample",procedure : "insertreg",parameters : [name, mobileno, bg, street, city, country, drink, std, pin]

}, {

onSuccess : function(result) {alert("Successfully registered");

$.mobile.changePage('#page');},

40

onFailure : function(result) {alert("Number already registered or connection not available");}

});}catch(err){alert(err);}

}

/*function search(){

document.write('<body bgcolor="blue">');document.write('Hi</body>');

}*/

function reg1(k){

$.mobile.changePage('#page5',{transition:"turn"});alert(window.myValue[k]);alert(window.myValue1[k]);//$('#page5').append("Welcome " + k + ", the "); //$('#page5').append("Pincode:<b>"+window.myValue[k]+"</b><br>"+window.myValue1[k]

+"</b><br>");

}

function search(){

//$("#page4").load("index.html");//("#page4").refresh();$.mobile.changePage("#page4");//$.mobile.reload("#page4"); //$('[data-role="content"]').empty();

$.mobile.loading('show', {text:'Retrieving...', textVisible:true, theme:'b'});//window.location.reload(true);

var stdcode=$("#stdcode").val();var bg=$("#bloody").val();//var pincode=$("#pincode").val();

41

//var ProductCollection = {};var responseData = {};

WL.Client.invokeProcedure({adapter:"sample",procedure:"getdonor",parameters:[stdcode,bg]

}, {

onSuccess:function(result){console.log("Inside function" +result);//var html='';//WL.Logger.debug("Return data" + result.invocationResult.resultSet);responseData = result.invocationResult.resultSet;if(result.invocationResult.isSuccessful)

{if(responseData.length>0){

// $("#productslist").empty();

//document.write("<html><body><b>Name</b> <b>Phone</b> <b>City</b></body></html>");

//var pass6 = new Array();myValue= [];myValue1= [];myValue2name= [];myValue3mobile= [];myValue4bg= [];myValue5pin= [];

for(var i=0;i<responseData.length;i++) { var obj=responseData[i]; var pass1=obj.name;// window.value1=pass1; var pass2=obj.mobileno;// window.value2=pass2;

42

var pass3=obj.city; var pass4=obj.bg; var pass5=obj.country; var pass6=obj.pin; // pass6[i]=pass6; window.myValue[i] = pass3; window.myValue1[i] = pass5; window.myValue2name[i] = pass1; window.myValue3mobile[i] = pass2; window.myValue4bg[i] = pass4; window.myValue5pin[i] = pass6;;// window.ivalue= i ; //$

('#page4').append(pass1+" "+pass2+" "+pass3+"<br>"); //document.write('<html><body> Name:'); $

('#page4').append("Name:<b>"+pass1.toUpperCase()+"</b><br>"); $('#page4').append("Blood

group:<b>"+pass4+"</b><br>"); $('#page4').append("Mobile

number:<b>"+pass2+"</b><br>"); $

('#page4').append("Address:<b>"+pass3+","+pass5+"</b><br>");

$('#page4').append("Pincode:<b>"+pass6+"</b><br>");

$('#page4').append('<a href="#" data-role="button" id="reg" onClick="mappage('+i+')">Map</a><b>');

$('#page4').append("<br><br>"); // window.value3=pass3; //$('#contentlist').append$('<li>', {}).append($

('<a>',{'href':'#details','data-transition' : 'slide','text':'obj.name','onclick':'getdetails('+pass1+')'})); //$.mobile.changePage("#show"); // $("#show").append(pass1);//document.write("<html><body><table

align:center background-color:grey cellspacing=5% cellpading=5%><tr>");//document.write('<td width="33%"><a

href="#contentlist" onClick="getdetails()">'+pass1+'</a></td>');//document.write("<td

width=33%>"+pass2+"</td>");//document.write("<td

width=33%>"+pass3+"</td>");43

//document.write("</tr></table></body></html>");// document.write("<!DOCTYPE

HTML><html><head><meta charset='UTF-8'><title>index</title><meta name='viewport' content='width=device-width, initial-scale=1.0, maximum-scale=1.0, minimum-scale=1.0, user-scalable=0'><link rel='shortcut icon' href='images/favicon.png'><link rel='apple-touch-icon' href='images/apple-touch-icon.png'><link href='jqueryMobile/jquery.mobile-1.4.0.css' rel='stylesheet'><link href='jqueryMobile/jquery.mobile-1.4.0.min.css' rel='stylesheet'><link rel='stylesheet' href='css/main.css'><script>window.$ = window.jQuery = WLJQ;</script><script src='jqueryMobile/jquery.mobile-1.4.0.js'></script><link href='native/www/default/jqueryMobile/jquery.mobile-1.4.0.css'rel='stylesheet'><link href='native/www/default/jqueryMobile/jquery.mobile-1.4.0.css'rel='stylesheet'><link href='native/www/default/jqueryMobile/jquery.mobile-1.4.0.css'rel='stylesheet'><link href='native/www/default/jqueryMobile/jquery.mobile-1.4.0.css'rel='stylesheet'></head><body><div data-role='page' id='page' data-theme='b' ><div data-role='content' style='padding: 15px'>");

//document.write(pass1); //document.write("</div></div><script

src='js/initOptions.js'></script<script src='js/main.js'</script><script src='js/messages.js'></script</body></html>");

//document.getElementById["print"].innerHTML=pass1;

//document.writeln(pass1+"---"+pass2+"---"+pass3);//document.writeln("<br>");//document.writeln("<br>");//document.writeln("<br>");//document.writeln(pass2);//document.writeln(pass3);//alert(pass1+"---"+pass2+"---"+pass3);//alert(pass2);//alert(pass3); //document.write("<br>");/*var detaillist=responseData[i]; html=html + '<li><a

href"#">'+detaillist.name+''+detaillist.mobileno+''+detaillist.city+'</a></li>'; //ProductCollection[obj.name]=obj;*/

} // jq("#list").html(html);

$.mobile.loading('hide');

44

}else{alert("Sorry, " +bg+" not available in this std code

"+stdcode);$.mobile.loading('hide');$.mobile.changePage('#page2');}}

},onFailure:function(result){alert("Error in Retrieving");}

});//document.writeln('</div><script src="js/initOptions.js"></script<script

src="js/main.js"></script><script src="js/messages.js"></script</body></html>');

}

Sample.xml

<?xml version="1.0" encoding="UTF-8"?><wl:adapter name="sample"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:wl="http://www.worklight.com/integration"xmlns:sql="http://www.worklight.com/integration/sql">

<displayName>sample</displayName><description>sample</description><connectivity>

<connectionPolicy xsi:type="sql:SQLConnectionPolicy">



<dataSourceDefinition><driverClass>com.mysql.jdbc.Driver</driverClass>

45

<url>jdbc:mysql://localhost:3306/sample</url> <user>root</user>

<password>root</password> </dataSourceDefinition>

</connectionPolicy><loadConstraints maxConcurrentConnectionsPerNode="5" />

</connectivity>

<procedure name="procedure1"/><procedure name="procedure2"/><procedure name="getSamples"> </procedure><procedure name="addSample"> </procedure><procedure name="updateSample"> </procedure><procedure name="deleteSample"> </procedure><procedure name="insertreg"/><procedure name="getdonor" /><procedure name="dndlogin" /><procedure name="dndupdate" />

</wl:adapter>

Sample-impl.js:

/*

sample-impl.js

/* * Licensed Materials - Property of IBM * 5725-I43 (C) Copyright IBM Corp. 2011, 2013. All Rights Reserved. * US Government Users Restricted Rights - Use, duplication or * disclosure restricted by GSA ADP Schedule Contract with IBM Corp. */

/******************************************************************************* * Implementation code for procedure - 'procedure1' *

46

* * @return - invocationResult */ var procedure1Statement = WL.Server.createSQLStatement("select COLUMN1, COLUMN2 from TABLE1 where COLUMN3 = ?");function procedure1(param) {

return WL.Server.invokeSQLStatement({preparedStatement : procedure1Statement,parameters : [param]

});}

/******************************************************************************* * Implementation code for procedure - 'procedure2' * * * @return - invocationResult */ function procedure2(param) {

return WL.Server.invokeSQLStoredProcedure({procedure : "storedProcedure2",parameters : [param]

});}

/******************************************************************************* * Functions that correspond to JSONStore client operations * */

var selectStatement = WL.Server.createSQLStatement("select COLUMN1, COLUMN2 from TABLE1");

function getSamples() {

47

return WL.Server.invokeSQLStatement({preparedStatement : selectStatement,parameters : []

});}

var addStatement = WL.Server.createSQLStatement("insert into TABLE1 (COLUMN1, COLUMN2) values (?, ?)");

function addSample(param1) {

return WL.Server.invokeSQLStatement({preparedStatement : addStatement,parameters : [param1]

});}

var updateStatement = WL.Server.createSQLStatement("update TABLE1 set COLUMN1=?, COLUMN2=?");

function updateSample(param1) {

return WL.Server.invokeSQLStatement({preparedStatement : updateStatement,parameters : [param1]

});}

var deleteStatement = WL.Server.createSQLStatement("delete from TABLE1 where COLUMN1=?");

function deleteSample(param1) {

return WL.Server.invokeSQLStatement({preparedStatement : deleteStatement,parameters : [param1]

});}

var insertst = WL.Server.createSQLStatement("insert into sample2 (name, mobileno, bg, street, city, country, drink, std, pin) values (?,?,?, ?, ?, ?, ?, ?, ?)");

function insertreg(name, mobileno, bg, street, city,country, drink, std, pin) {48

return WL.Server.invokeSQLStatement({preparedStatement : insertst,parameters : [name, mobileno, bg, street, city, country, drink, std,

pin]});

}

var searchreg= WL.Server.createSQLStatement("select name, mobileno, bg, street, city,country,pin from sample2 where std=? and bg=? and dnd='act'");function getdonor(stdcode,bg){

return WL.Server.invokeSQLStatement({preparedStatement : searchreg,parameters:[stdcode,bg]

});}

var dndlogin1= WL.Server.createSQLStatement("select street, bg from sample2 where mobileno=?");function dndlogin(dndmno){

return WL.Server.invokeSQLStatement({preparedStatement : dndlogin1,parameters:[dndmno]

});}

var dndupdate1 = WL.Server.createSQLStatement("update sample2 set dnd=? where mobileno=?");

function dndupdate(dndvalue, mobile) {

return WL.Server.invokeSQLStatement({preparedStatement : dndupdate1,parameters : [dndvalue, mobile]

});}

49

proj repo updated.docx

Documents

project work

project development

project guide head

blood donors

grateful thanks

s register

v register

r register