Создание системы управления взаимоотношениями с клиентами

РЕФЕРАТ

Целью данного курсового проекта является проектирование системы управления взаимоотношениями с клиентами для выполнения поставленных задач, с учётом бизнес-логики, бизнес-процессов и требований к данной системе.

Данная система предназначена для обеспечения общения с клиентами, а так же иных взаимоотношениях с потенциальными заказчиками и покупателями.

Разработанная система имеет четкое разделение на архитектурные слои, поэтому легко изменить отдельную часть, не прибегая к полному переписыванию программы.

Одной из особенностей системы является поддержка авторизации и аутентификации с использованием встроенного механизма сервлет-контейнера. В данной реализации используется LDAP-сервер, как хранилище данных о пользователях, зарегистрированных в системе.

Система является кроссплатформенной (работа возможна на любой операционной системе с присутствием виртуальной Java-машины, независимо от компьютерной архитектуры).

СОДЕРЖАНИЕ ВВЕДЕНИЕ

• 1. Анализ решаемой задачи
• 1.1 Стратегия системы управления
• 1.2 Требования к системе управления
• 2. Разработка
• 2.1 Разработка схемы базы данных
• 2.2 Разработка логической структуры базы данных
• 3. Разработка триггеров и настройка репликации
• 3.1 Хранимые процедуры и триггеры. Особенности использования
• 3.1.1 Разработанные триггеры
• 3.2 Репликация базы данных
• 3.2.1 Настройка репликации в СУБД Postgres
• 4. настройка сервера ldap
• 4.1 Настройка сервера LDAP
• ВЫВОДЫ
• ПЕРЕЧЕНЬ ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ

ВВЕДЕНИЕ

Система управления взаимоотношениями с клиентами - предназначена для организации, а так же автоматизации стратегий взаимодействия с заказчиками (клиентами), в частности, для повышения уровня продаж, оптимизации маркетинга и улучшения обслуживания клиентов путём сохранения информации о клиентах и истории взаимоотношений с ними, установления и улучшения бизнес-процедур и последующего анализа результатов.

Преимущества, которыми обладает система:

1.Доступ к информации о запланированных и проведенных встречах.

2.Постоянная связь с заказчиками и покупателями.

3.Система не имеет ограничений на виртуальную площадь. Можно разместить сколь угодно сделок и проектов.

4.Система обладает удобным интерфейсом для отображения различных данных.

5.Развитие мобильных устройств для доступа в Интернет (мобильный телефон, КПК и т. д.) позволяет получить доступ к порталу из любой точки мира, вне зависимости от местоположения потенциального клиента.

1. Анализ решаемой задачи Целью создания системы управления, является разработка программного решения для быстрого и удобного предоставления возможности общения и улучшения обслуживания клиентов.

Важной функцией CRM является возможность контроля работы менеджеров руководителем, который имеет доступ к информации о запланированных и проведенных встречах, переговорах, а также иных взаимоотношениях с потенциальными заказчиками и покупателями.

Современные корпоративные программные системы обладают такими характеристиками как сложность бизнес-логики, надежность, защищенность, масштабируемость, простота сопровождения.

Корпоративные программные приложения предполагают необходимость отображения, обработки и сохранения больших массивов (сложных) данных, а также реализации моделей бизнес-процессов, манипулирования этими данными. Примерами могут служить системы управления расходами, бронирования билетов, финансовые приложения, серверы опросов и новостей и т. д.

Создание корпоративных приложений имеет ряд особенностей, а именно:

«расслоение» приложения по уровням;

структурирование логики предметной области;

связывание модулей, размещаемых в памяти с реляционной базой данных.

Для создания корпоративных приложений применяются несколько технологий, которые включают: .NET, J2EE и др. Однако, учитывая бесплатность и открытость технологий, связанных с языком Java и J2EE библиотеками, использование именно этих технологий представляет особый интерес.

1.1 Стратегия системы управления Выделим основные сущности системы и их функции на самом высоком уровне абстракции.

Предполагается, что разрабатываемая система сможет уметь управлять бизнес-процессами. Для этого в своей деятельности она должна использовать процессный подход. В соответствии с ним вся деятельность любого предприятия представляется в виде множества бизнес-процессов, исполняемых в определённой среде. Среда выполнения — это первая сущность системы.

Вторая сущность — это бизнес-процессы. Бизнес-процесс — это упорядоченный по времени набор заданий, выполняемых как людьми, так и информационными системами предприятия, который направлен на достижение заранее известной бизнес-цели за известное время.

С каждым бизнес-процессом также связан определённый набор данных. В рамках любого бизнес-процесса «на входе» используется один или несколько видов ресурсов, и в результате этой деятельности на «выходе» создаётся продукт (бизнес-цель), представляющий ценность для конечного потребителя. Ресурсы и конечный продукт можно представить в виде данных процесса. Следовательно, с любым бизнес-процессом связан его набор данных — следующая сущность системы.

Каждый бизнес-процесс должен иметь единственного владельца. Владелец процесса единолично и полностью отвечает за качество продукта бизнес-процесса, исполнение всех его операций. Во время выполнения бизнес-процесса к участию в его операциях может привлекаться множество исполнителей, выполняющие различные роли. Исполнители и владелец бизнес-процесса — это различные работники предприятия. В плане рассматриваемой предметной области они могут быть пользователями системы, которые, благодаря информационным компонентам системы, получают возможность следить за выполнением бизнес-процесса и (или) брать в нем участие. Т. е., пользователи, берущие участие в бизнес-процессе — это внешняя сущность системы.

Также следует выделить периферийные информационные компоненты системы как сущность, благодаря которой производиться информационное взаимодействие внутренних сущностей системы (среды выполнения бизнес-процессов) с внешними (пользователями).

1.2 Требования к системе управления

клиент база триггер репликация

Система должна обеспечивать безопасность данных путем ограничения доступа зарегистрированных пользователей к возможности редактирования комментариев, личной информации других пользователей. Должен ограничиваться доступ незарегистрированных пользователей к любым операциям по редактированию данных.

Пользователи должны быть наделены правами доступа к ресурсам программной системы в зависимости от привилегий: администратор, модератор, пользователь и гость.

В соответствии с изложенными правилами для каждой роли системы необходимо реализовать следующую функциональность:

Администратор — это пользователь обладающими всеми правами в системе, может редактировать любую информацию. Он может создавать пользователей системы и назначать права на определенные действия.

Менеджер — это пользователь, который взаимодействует с клиентами, создает проекты, сделки и поддерживает актуальность данных клиента.

Бухгалтер — пользователь системы который принимает платежи по сделкам контролирует сроки оплаты и ведет отчет финансовой деятельности предприятия.

2. Разработка

2.1 Разработка схемы базы данных

Была разработана структура БД, описанная на формальном языке, поддерживаемом системой управления базами данных (СУБД).

2.2 Разработка логической структуры базы данных

Принцип или порядок организации записей в базе данных и связей между ними приводится в виде схемы логической структуры базы данных, которая отображает предметную область, показана на рисунке 3.4.

Рисунок 2.1? Схема базы данных

3. Разработка триггеров и настройка репликации

3.1 Хранимые процедуры и триггеры. Особенности использования

Определение хранимой процедуры следующее: хранимая процедура — объект базы данных, представляющий собой набор SQL-инструкций, который компилируется один раз и хранится на сервере. Определение четкое и вполне хорошее, все ясно и понятно. То есть в СУБД необходимо выполнить определенный SQL-код, который сохранится в базе как некоторый объект и очевидно, что мы сможем его эффективно/рационально использовать для решения задач работы с базой. При проектировании хранимых процедур и триггеров надо избегать следующих вещей:

разбалансирование бизнес-логики системы;

создание анти паттерна «велосипед» (свое плохое решение, при существовании лучшего).

Триггер — это хранимая процедура особого типа, которую пользователь не вызывает непосредственно, а исполнение которой обусловлено наступлением определенного события (действием) — по сути добавлением INSERT или удалением DELETE строки в заданной таблице, или модификации UPDATE данных в определенном столбце заданной таблицы реляционной базы данных.

3.1.1 Разработанные триггеры

Триггер, который не дает пользователю изменить идентификатор контакта в таблице контактов:

begin

if «old» ." contacts_name" ≠"new" ." contacts_name" then

update «contacts» set «id» = «old» ." id"

where «contacts.id» = «old» ." id" ;

end if;

return old;

end;

Триггер, который добавляет запись о каком либо изменении в таблице заданий, в таблицу событий:

DECLARE

mstr varchar (30);

msstr varchar (30);

mssstr varchar (30);

nstr varchar (100);

ostr varchar (100);

astr varchar (100);

retstr varchar (364);

BEGIN

IF TG_OP = 'INSERT' THEN

nstr = NEW. tasks_name;

ostr = NEW. responsible;

mstr := 'Add new tasks: ';

msstr := ' to contacts: ';

retstr := mstr || nstr || msstr || ostr;

INSERT INTO «events» (id, events_text, tasks_id) values ((select count (*) from «events»)+1,retstr, NEW. id);

RETURN NEW;

ELSIF TG_OP = 'UPDATE' THEN

nstr = NEW. tasks_name;

mstr := 'Update task: ';

retstr := mstr || nstr;

if (OLD.tasks_name ≠ NEW. tasks_name) then

nstr = NEW. tasks_name;

ostr = OLD. tasks_name;

mstr := 'Update task name: ';

msstr := ' to name: ';

retstr := mstr || ostr || msstr || nstr;

end if;

INSERT INTO «events» (id, events_text, tasks_id) values ((select count (*) from «events»)+1,retstr, NEW. id);

RETURN NEW;

ELSIF TG_OP = 'DELETE' THEN

ostr = OLD. tasks_name;

mstr := 'Remove task: ';

retstr := mstr || ostr;

INSERT INTO «events» (id, events_text) values ((select count (*) from «events»)+1,retstr);

RETURN OLD;

END IF;

END;

Триггер, который добавляет запись о каком либо изменении в таблице компаний, в таблицу событий:

DECLARE

mstr varchar (30);

msstr varchar (30);

nstr varchar (100);

ostr varchar (100);

retstr varchar (254);

BEGIN

IF TG_OP = 'INSERT' THEN

nstr = NEW. company_name;

mstr := 'Add new company: ';

retstr := mstr || nstr;

INSERT INTO «events» (id, events_text) values ((select count (*) from «events»)+1,retstr);

RETURN NEW;

ELSIF TG_OP = 'UPDATE' THEN

nstr = NEW. company_name;

ostr = OLD. company_name;

mstr := 'Update company: ';

msstr := ' To company: ';

if (OLD.company_name ≠ NEW. company_name) then

retstr := mstr || ostr || msstr || nstr;

else

retstr := mstr || nstr;

end if;

INSERT INTO «events» (id, events_text) values ((select count (*) from «events»)+1,retstr);

RETURN NEW;

ELSIF TG_OP = 'DELETE' THEN

ostr = OLD. company_name;

mstr := 'Remove company: ';

retstr := mstr || ostr;

INSERT INTO «events» (id, events_text) values ((select count (*) from «events»)+1,retstr);

RETURN OLD;

END IF;

end;

Триггер, который добавляет запись о каком либо изменении в таблице контактов, в таблицу событий:

DECLARE

mstr varchar (30);

msstr varchar (30);

nstr varchar (100);

ostr varchar (100);

retstr varchar (254);

BEGIN

IF TG_OP = 'INSERT' THEN

nstr = NEW. contacts_name;

mstr := 'Add new contact: ';

retstr := mstr || nstr;

INSERT INTO «events» (id, events_text, contakts_id) values ((select count (*) from «events»)+1,retstr, NEW. id);

RETURN NEW;

ELSIF TG_OP = 'UPDATE' THEN

nstr = NEW. contacts_name;

ostr = OLD. contacts_name;

msstr := ' To contact name: ';

if (OLD.contacts_name ≠ NEW. contacts_name) then

mstr := 'Update contact name: ';

retstr := mstr || ostr || msstr || nstr;

else

mstr := 'Update contact: ';

retstr := mstr || nstr;

end if;

INSERT INTO «events» (id, events_text, contakts_id) values ((select count (*) from «events»)+1,retstr, NEW. id);

RETURN NEW;

ELSIF TG_OP = 'DELETE' THEN

ostr = OLD. contacts_name;

mstr := 'Remove contact: ';

retstr := mstr || ostr;

INSERT INTO «events» (id, events_text) values ((select count (*) from «events»)+1,retstr);

RETURN OLD;

END IF;

end;

Триггер, который добавляет запись о каком либо изменении в таблице сделок, в таблицу событий:

DECLARE

mstr varchar (30);

msstr varchar (30);

nstr varchar (100);

ostr varchar (100);

retstr varchar (254);

BEGIN

IF TG_OP = 'INSERT' THEN

nstr = NEW. deals_name;

mstr := 'Add new deal: ';

retstr := mstr || nstr;

INSERT INTO «events» (id, events_text, deals_id) values ((select count (*) from «events»)+1,retstr, NEW. id);

RETURN NEW;

ELSIF TG_OP = 'UPDATE' THEN

nstr = NEW. deals_name;

ostr = OLD. deals_name;

msstr := ' To deal name: ';

if (OLD.deals_name ≠ NEW. deals_name) then

mstr := 'Update deal name: ';

retstr := mstr || ostr || msstr || nstr;

else

mstr := 'Update deal: ';

retstr := mstr || nstr;

end if;

INSERT INTO «events» (id, events_text, deals_id) values ((select count (*) from «events»)+1,retstr, NEW. id);

RETURN NEW;

ELSIF TG_OP = 'DELETE' THEN

ostr = OLD. deals_name;

mstr := 'Remove deal: ';

retstr := mstr || ostr;

INSERT INTO «events» (id, events_text) values ((select count (*) from «events»)+1,retstr);

RETURN OLD;

END IF;

end;

Триггер, который не позволяет пользователю ввести бюджет сделки ниже единицы, в таком случае значение автоматически устанавливается в единицу:

begin

if «new» ." money" <1 then

update «deals» set «money» = 1;

end if;

return new;

end;

Триггер, который не позволяет пользователю ввести бюджет сделки больше ста тысяч, в таком случае значение автоматически устанавливается в единицу:

begin

if «new» ." money" >100 000 then

update «deals» set «money» = 1;

end if;

return new;

end;

Триггер, который заносит данные в таблицу событий при изменении адреса контакта:

DECLARE

mstr varchar (30);

nstr varchar (100);

astr varchar (30);

ostr varchar (100);

retstr varchar (254);

begin

if OLD. contacts_address ≠ NEW. contacts_address then

nstr = NEW. contacts_name;

ostr = NEW. contacts_address;

mstr := 'Update address to contacts: ';

astr := ' to address: ';

retstr := mstr || nstr || astr || ostr;

insert into «events» («id» ," contakts_id" ," events_text")

values ((select count (*) from «events»)+1,

NEW.id, retstr);

end if;

return new;

end;

Триггер, который заносит данные в таблицу событий при изменении e-mail контакта:

DECLARE

mstr varchar (30);

nstr varchar (100);

astr varchar (30);

ostr varchar (100);

retstr varchar (254);

begin

if OLD. contacts_email ≠ NEW. contacts_email then

nstr = NEW. contacts_name;

ostr = NEW. contacts_email;

mstr := 'Update mail to contacts: ';

astr := ' to mail: ';

retstr := mstr || nstr || astr || ostr;

insert into «events» («id» ," contakts_id" ," events_text")

values ((select count (*) from «events»)+1,

NEW.id, retstr);

end if;

return new;

end;

Триггер, который заносит данные в таблицу событий при изменении телефона контакта:

DECLARE

mstr varchar (30);

nstr varchar (100);

astr varchar (30);

ostr varchar (100);

retstr varchar (254);

begin

if OLD. contacts_telephon ≠ NEW. contacts_telephon then

nstr = NEW. contacts_name;

ostr = NEW. contacts_telephon;

mstr := 'Update phone to contacts: ';

astr := ' to phone: ';

retstr := mstr || nstr || astr || ostr;

insert into «events» («id» ," contakts_id" ," events_text")

values ((select count (*) from «events»)+1,

NEW.id, retstr);

end if;

return new;

end;

Триггер, который заносит данные в таблицу событий при изменении статуса сделки:

DECLARE

mstr varchar (30);

nstr varchar (100);

astr varchar (30);

ostr varchar (100);

retstr varchar (254);

begin

if OLD. deals_type ≠ NEW. deals_type then

nstr = NEW. deals_name;

ostr = NEW. deals_type;

mstr := 'Update deals type in dial: ';

astr := ' to type: ';

retstr := mstr || nstr || astr || ostr;

insert into «events» («id» ," deals_id" ," events_text")

values ((select count (*) from «events»)+1,

NEW.id, retstr);

end if;

return new;

end;

Триггер, который заносит данные в таблицу событий при изменении ответственного за задачу:

DECLARE

mstr varchar (350);

nstr varchar (100);

astr varchar (50);

ostr varchar (100);

retstr varchar (254);

begin

if OLD. responsible ≠ NEW. responsible then

nstr = NEW. tasks_name;

ostr = NEW. responsible;

mstr := 'Update tasks responsible in task: ';

astr := ' to contacts: ';

retstr := mstr || nstr || astr || ostr;

insert into «events» («id» ," tasks_id" ," events_text")

values ((select count (*) from «events»)+1,

NEW.id, retstr);

end if;

return new;

end;

Триггер, который заносит данные в таблицу событий при изменении статуса задачи:

DECLARE

mstr varchar (30);

nstr varchar (100);

astr varchar (30);

ostr varchar (100);

retstr varchar (254);

begin

if OLD. status ≠ NEW. status then

nstr = NEW. tasks_name;

ostr = NEW. status;

mstr := 'Update task status in task: ';

astr := ' to status: ';

retstr := mstr || nstr || astr || ostr;

insert into «events» («id» ," tasks_id" ," events_text")

values ((select count (*) from «events»)+1,

NEW.id, retstr);

end if;

return new;

end;

Триггер, который заносит данные в таблицу событий при изменении ответственного за сделку:

DECLARE

mstr varchar (350);

nstr varchar (100);

astr varchar (50);

ostr varchar (100);

retstr varchar (254);

begin

if OLD. responsible ≠ NEW. responsible then

nstr = NEW. deals_name;

ostr = NEW. responsible;

mstr := 'Update deals responsible in dial: ';

astr := ' to contacts: ';

retstr := mstr || nstr || astr || ostr;

insert into «events» («id» ," deals_id" ," events_text")

values ((select count (*) from «events»)+1,

NEW.id, retstr);

end if;

return new;

end;

Триггер, который заполняет автоматически поля, в которых хранится дата и время, при добавлении новой сделки:

begin

update «tasks» set «tasks_date» = ('now':text):date where «tasks» ." id" = NEW. id;

update «tasks» set «tasks_time» = ('now':text):time with time zone where «tasks» ." id" = NEW. id;

return new;

end;

3.2 Репликация базы данных

Репликация БД — это синхронизация нескольких копий содержимого базы данных. В простейшем случае репликация — это просто копирование информации из одной БД в другую.

Выделяют следующие виды репликации.

I. По направлению передачи данных между базами данных. Репликация бывает однонаправленной (односторонней) и многонаправленной (многосторонней). Однонаправленная репликация обычно используется при синхронизации резервной копии БД славной БД, многонаправленная — при синхронизации двух или более самостоятельных копий одной БД.

II. Синхронная и асинхронная.

При синхронной репликации может существовать только одна версия данных — это накладывает ограничения на работу с данными во время репликации. Асинхронная репликация позволяет избежать этой проблемы, но при ней база данных может иметь несовместимые, с точки зрения пользователя, данные. Обычно именно асинхронную репликацию имеют в виду, когда говорят о репликации базы данных вообще.

III. По времени проведения.

Если репликация проводится немедленно после внесения изменений в БД, то это репликация реального времени, в противном случае мы имеем дело с отложенной репликацией.

IV. По способу связи между базами данных. Выделяют прямую и недетерминированную репликацию. Прямая — это когда канал связи между базами достаточно устойчив. Если же базы данных связываются по неустойчивому каналу, то приёмник информации не может в любой нужный ему момент связаться с источником информации, из-за чего решения, принимаемые им при конфликте данных, носят вероятностный (недетерминированный) характер.

К числу преимуществ, которые обеспечивает репликация БД, относится повышение скорости обработки запросов и надежности. Надежность заключается в том, что при возникновении проблем с головным сервером, существует возможность переключения на резервную копию. Для увеличения скорости можно перенаправлять те запросы, которые не обновляют данные, на сервер с копиями.

3.2.1 Настройка репликации в СУБД Postgres

Для начала на обеих серверах в /etc/hosts были добавлены две строчки:

1.1.1.1 db₀

1.1.1.2 db₁

Далее был настроен файл pg_hba.conf:

# nano /usr/home/pgsql/data/pg_hba.conf

Для мастера:

#IP мастера

listen_addresses = `1.1.1.1'

#На слейв

host replication postgres 1.1.1.2/32 trust

host all postgres 1.1.1.2/32 trust

#Тут мы говорим, что доступ имеют все и со всех адресов, с использованием пароля Далее производится настройка файла postgresql. conf:

# nano /usr/local/pgsql/data/postgresql.conf

В этом файле:

#Ведение журнала с правами чтения для слейва

wal_level = hot_standby

#Максимальное количество слейвов

max_wal_senders = 2

#Устанавливаем общее хранимое количество кусков лога

wal_keep_segments = 32

#Дублируем журнал в отдельное место

archive_mode = on

archive_command = 'cp %p /usr/lib/postgresql/9.1/main/archive/%f'

#Максимальное количество подключений

max_connections = 150

#Размер буфера

shared_buffers = 2400MB

Теперь нужно перезапустить мастер. Необходимо передать базу на слейв. Для этого используем rsync:

# psqlc «SELECT pg_start_backup ('label', true)»

# rsynca /usr/lib/postgresql/9.1/main/ [email protected]:/usr/lib/postgresql/9.1/main/ —exclude postmaster. pid

# psqlc «SELECT pg_stop_backup ()»

Теперь нужно настроить слейв. В postgresql. conf:

hot_standby = on

archive_mode = off

Необходимо создать recovery. conf:

standby_mode = 'on'

primary_conninfo = 'host=1.1.1.1 port=5432 user=postgres'

#триггер нужен для бэкапа, чтобы в случае бэкапа могли остановить процесс репликации и сделать слейв доступным на запись

Trigger_file = '/usr/lib/postgresql/9.1/main/trigger'

restore_command = 'cp /usr/lib/postgresql/9.1/main/archive/%f «%p» '

Теперь можно запустить процесс репликации.

Проверка на слейве:

# ps

postgres 6878 6872 1 10:31? 00:00:01 postgres: wal receiver process streaming 0/2 000 000

Это значит, что репликация настроена правильно.

3.3 Мониторинг системы с помощью утилиты Nagios

Nagios — система с открытым кодом, предназначенная для мониторинга компьютерных систем и сетей. Она следит за указанными в настройках узлами и службами, и оповещает администратора в случае, если какие-то из служб прекращают (или возобновляют) свою работу. Nagios, первоначально созданная под именем Netsaint, разработана Этаном Галстадом (Ethan Galstad). Он же поддерживает и развивает систему сегодня, совместно с командой разработчиков, которые занимаются как официальными, так и неофициальными плагинами.

Первоначально Nagios была разработана для работы под GNU/Linux, но она также хорошо работает и под другими Unixподобными ОС.

3.3.1 Настройка мониторинга Листинг файла localhost. cfg:

# A simple configuration file for monitoring the local host

# This can serve as an example for configuring other servers;

# Custom services specific to this host are added here, but services

# defined in nagios2-common_services.cfg may also apply.

#

define host

{

use generic-host; Name of host template to use

host_name slave

alias 1.1.1.2

address 1.1.1.2

}

#Apache

define command

{

command_name check_apache

command_line /home/sereban/apache2.sh

}

define service

{

use generic-service

host_name localhost

service_description Apache

check_command check_apache

notifications_enabled 1

}

#Postgres

define command

{

command_name check_postgres

command_line /home/sereban/pg.sh

}

define service

{

use generic-service

host_name localhost

service_description Postgres

check_command check_postgres

notifications_enabled 1

}

define service

{

use generic-service

host_name localhost

service_description Postgres

check_command check_postgres

notifications_enabled 1

}

define service

{

use generic-service

host_name slave

service_description Postgres

check_command check_postgres

notifications_enabled 1

}

Рисунок 3.1 — Мониторинг сервисов систем

4. настройка сервера ldap

4.1 Настройка сервера LDAP

В качестве сервера желательно выбрать открытое решение, поддерживающее общий стандарт протокола LDAP. Пожалуй, самым интересным и доступным в таком случае есть сервер sldap.

Для начала необходимо установить несколько пакетов:

# apt-get install slapd ldap-utils migrationtools

Теперь нужно переконфигурировать sldap, чтобы расширить количество изменяемых настроек:

#dpkg-reconfigure slapd

#пропустить настройку сервера LDAP? … Нет

#Доменное имя DNS: … debuntu. local

#Название организации: … Всечтоугодно debuntu. local

#Пароль для admin: 1

#Подтвердите пароль: 1

#Настраивается пакет slapd (информация о формате базы ldap)

OK

#Выбор формата базы ldap

BDB

#Удалять базу данных при вычистке slapd? … Нет

#Переместить старую базу данных? … Да

#Включить протокол LDAPv2? … Нет Теперь в системе установлен демон и административная учетная запись. Можно проверить есть ли доступ к ldap-серверу:

$ ldapsearchx -b dc=debuntu, dc=local

# extended LDIF

#

# LDAPv3

# base with scope subtree

# filter: (objectclass=*)

# requesting: ALL

#

# debuntu. local

dn: dc=debuntu, dc=local

objectClass: top

objectClass: dcObject

objectClass: organization

o: nodomain

dc: debuntu

# admin, debuntu. local

dn: cn=admin, dc=debuntu, dc=local

objectClass: simpleSecurityObject

objectClass: organizationalRole

cn: admin

description: LDAP administrator

# People, debuntu. local

dn: ou=People, dc=debuntu, dc=local

ou: People

objectClass: organizationalUnit

# search result

search: 2

result: 0 Success

# numResponses: 4

# numEntries: 3

Теперь нужно добавить пользователей. Используя migrationtools можно быстро импортировать всех существующих пользователей и групп с локальной системы в LDAP. Нужно отредактировать конфигурационный файл migrate_common.ph и заменить следующие параметры:

$DEFAULT_MAIL_DOMAIN = «debuntu.local» ;

$DEFAULT_BASE = «dc=debuntu, dc=local» ;

Теперь необходимо экспортировать данные:

# ./migrate_group.pl /etc/group ~/group.ldif

# ./migrate_passwd.pl /etc/passwd ~/passwd.ldif

В домашнем каталоге нужно создать файл people_group.ldif и заполнить его строками:

dn: ou=People, dc=debuntu, dc=local

ou: People

objectclass: organizationalUnit

dn: ou=Group, dc=debuntu, dc=local

ou: Group

objectclass: organizationalUnit

Теперь списки пользователей и групп, сконвертированные в LDAP формат ldif, нужно импортировать в LDAP базу:

# ldapaddx -WD «cn=admin, dc=debuntu, dc=local» -f ~/people_group.ldif

# ldapaddx -WD «cn=admin, dc=debuntu, dc=local» -f ~/group.ldif

# ldapaddx -WD «cn=admin, dc=debuntu, dc=local» -f ~/passwd.ldif

где:

— x означает, что не используется sasl;

— W что будет запрошен пароль администратора LDAP;

— D что используется для идентификации администратора;

— f что указывает файл, где ldapadd будет брать данные для добавления.

ВЫВОДЫ В рамках данного курсового проекта была создана система управления взаимоотношения с клиентами. Данная система предоставляет возможность контроля работы менеджеров руководителем, который имеет доступ к информации о запланированных и проведенных встречах, переговорах, а также иных взаимоотношениях с потенциальными заказчиками и покупателями.

Авторизация пользователей в системе осуществляется посредством LDAP сервера. Роль бухгалтера заключается в приеме платежей по сделкам и ведении отчета о финансовой деятельности предприятия. Роль менеджера назначает администратор, главная задача которого лежит в создании проектов, а так же в поддержке актуальности данных клиента.

Разрабатываемая система работает со следующими категориями пользователей: администратор, менеджер, бухгалтер.

ПЕРЕЧЕНЬ ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ

Documentation information [Електроний ресурс]: The JavaEE 6 Tuturial. — Електрон дан. — [USA], 2010. ;

LDAP and JNDI [Електроний ресурс]: Toglther forever. — Електрон. дан. — [USA] 2008;2010. — Режим доступу: http://www.javaworld.com /javaworld/jw-03−2000/jw-0324-ldap.html .

Spring Web Service [Електроний ресурс]: Spring Source. — Електрон. дан. [EU], 2005;2010. — Режим доступу: http://static.springsource. org/spring-ws/sites/1.5/

Chapter 8. Testing [Електроний ресурс]: Spring Source. — Електрон. дан. [EU], 2005;2010. — Режим доступу: http://static.springsource.org/ spring/docs/2.5.x/reference/testing.html.

Chapter 3. Beans, BeanFactory and the ApplicationContext [Електроний ресурс]: Spring Source. — Електрон. дан. [EU], 2005;2010. — Режим доступу: http://static.springsource.org/spring/docs/1.2.9/reference/beans .html.

Часть 19 — Spring. Бизнес-уровень в действие [Електроний ресурс]: Студенчиский отдел кадров. Пособие по JAVA-технологиям/Anton Saburov — Електрон. дан. [Россия], 2009. — Режим доступу: http://www.java-course.ru/students/part19.html.

Часть 10 — Spring. БизнесТестирование с точки зрения разработчика [Електроний ресурс]: Студенчиский отдел кадров. Пособие по JAVA-технологиям/Anton Saburov — Електрон. дан. [Россия], 2009. — Режим доступу: http://www.java-course.ru/ students/ part10.html.