SharePoint 2013. Служба ServiceDesk за 8 часов либо правильный проект

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

Для примера создадим простую службу обработки заявок, поступающих от пользователей в ServiceDesk.

Постановка задачи

Требуется реализовать службу обработки заявок в ServiceDesk, которая:

  • Принимает заявки, отправляемые пользователями посредством корпоративной электронной почты;
  • Автоматизирует процесс обработки заявки, состоящий из двух этапов: назначения исполнителя заявки и обработка заявки, назначенным исполнителем;
  • Позволяет получать статистические данные по работе системы;

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

Реализация на SharePoint

Задача, описанная выше потребует создания следующих артефактов в SharePoint:

  • Список заявок;
  • Ресивер к списку для обработки электронных писем;
  • Рабочие процесс. Будет использован стандартный процесс с тремя состояниями (Three-state workflow);

Получение статистики возложим на Excel и стандартный функционал SharePoint экспорта данных списка.

Успеть за рабочий день

Дополнительным эффектным требованием будем считать ограничение по времени: все работы необходимо сделать за один рабочий день силами одного программиста. Также необходимо развернуть решение на тестовом сервере и только затем на боевом.

Предположим, что на постановку задачи и её обдумывания ушел один час. На реализацию остается 7 часов. Here we go!

Шаг 1. Настройка среды

Чтобы использовать электронную почту в качестве инструмента информирования пользователей, а также внесения данных в систему (заявок), необходимо настроить получение входящей почты и отправку исходящей почты.

На выполнение этих работ будет достаточно одного часа. Остается 6 часов.

Шаг 2. Список

Теперь переходим к списку, в котором будет хранится информация о заявках в Service Desk. Список будет содержать минимально необходимое кол-во полей для хранения информации:

  • Название. Содержит тему сообщения, поступившего в Service Desk;
  • Дата поступления заявки. Дата, когда заявка была зарегистрирована;
  • Текст заявки. Текст из письма, отправленного в Service Desk;
  • Приоритет. Приоритет заявки, соответствующий приоритету отправленного письма (Low, Normal, High);
  • Статус заявки. Может быть одним из: Новая, В работе, Завершена;
  • Исполнитель. Исполнитель заявки;
  • Дата завершения. Дата закрытия заявки;
  • Отправитель. Пользователь, получаемый, исходя из адреса отправителя;
  • Email отправителя. Нужен в случае, когда пользователя не удалось идентифицировать;
  • Адрес для ответа. В случае, когда адрес для ответа на письмо не соответствует адресу заявителя

Работы для описания типа содержимого "Заявка в Service Desk", шаблона соответствующего списка и его экземпляра в Visual Studio 2012 (даже с учетом локализации на два языка) потребует от программиста не более часа.

Ещё один час потрачен, остается 5 часов.

Шаг 3. Ресивер для обработки входящих писем

Заявки в Service Desk будут поступать посредством корпоративной почты, поэтому нам понадобиться ресивер, который эту почту будет обрабатывать. В проекте Visual Studio 2012 для реализации оного добавляем новый элемент в проект типа EventReceiver:

Остается только указать тип ресивера: List Email Events и список, к которому он будет привязан:

Сначала в ресивере получаем информацию из входящего письма:

  1. /// <summary>
  2. /// The list received an e-mail message.
  3. /// </summary>
  4. public override void EmailReceived(SPList list, SPEmailMessage emailMessage, String receiverData)
  5. {
  6.     base.EmailReceived(list, emailMessage, receiverData);
  7.  
  8.     // Текст сообщения
  9.     var mailBody = emailMessage.PlainTextBody;
  10.     // Тема сообщения
  11.     var mailSubject = emailMessage.Headers["Subject"];
  12.     // Отправитель
  13.     var mailSender = emailMessage.Headers["x-sender"];
  14.     // Приоритет письма
  15.     var mailPriority = emailMessage.Headers["Importance"];
  16.     // Адрес для ответа
  17.     var mailReturnPath = emailMessage.Headers["Return-Path"];
  18.     // Вложения
  19.     var mailAttachments = emailMessage.Attachments;
  20.     // Пользователь, отправивший заявку
  21.     SPUser sender = null;
  22.     try
  23.     {
  24.         // Пробуем получить пользователя по его адресу электронной почты
  25.         sender = list.ParentWeb.SiteUsers.GetByEmail(mailSender);
  26.     }
  27.     catch
  28.     {
  29.                 
  30.     }
  31.     //TODO
  32. }

Заносим эту информацию в список (TODO в листинге выше):

  1. //Новый элемент
  2. var item = list.AddItem();
  3. // Заполняем поля списка
  4. item[SPBuiltInFieldId.Title] = mailSubject;
  5. item["DateReceive"] = DateTime.Now;
  6. item["Message"] = mailBody;
  7. item["Priority"] = mailPriority;
  8. item["Status"] = "New";
  9. item["SenderMail"] = mailSender;
  10. item["ReturnMail"] = mailReturnPath;
  11. if (sender != null)
  12. {
  13.     item["Sender"] = sender;
  14. }
  15. // Сохраняем элемент
  16. item.Update();
  17. // Добавляем вложения из письма к созданному элементу
  18. foreach (SPEmailAttachment attachment in mailAttachments)
  19. {
  20.     //ToByteArray - extension-метод для преобразования потока в массив байтов
  21.     item.Attachments.AddNow(attachment.FileName, attachment.ContentStream.ToByteArray());
  22. }

В конце можно добавить вызов метода, отправляющего письмо заявителю, о том, что письмо в системе Service Desk зарегистрировано и указать его номер (ID элемента заявки) и ссылку на форму просмотра. Вызываем метод SPUtility.SendMail() с параметрами угодными исполнителю.

На реализацию такого ресивера уйдет еще один час. Остается 4 часа. Идем дальше.

Шаг 4. Рабочий процесс

Для обработки настраиваем рабочий процесс трех состояний. Переходим к параметрам рабочих процессов списка и добавляем новый. Задаем необходимые параметры.

Настраиваем переход состояний заявки:

Параметры первого этапа (указание исполнителя):

Параметры второго этапа:

Также можно настроить отправку уведомлений:

Ничего больше от рабочего процесса не требуется. Настройка его займет не более 30 минут.

Шаг 5. Статистика

Для предоставления статистики можно использовать обычный Office Excel, построить несколько простых отчетов в Report Builder'е. И на эти работы понадобится еще один час (3-4 простых отчета, с различными группировками, графиками и диаграммами).

Шаг 6. Тестирование и развертывание

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

Шаг 7. Демонстрация

Оставшееся время можно потратить на демонстрацию решения, сочинение письма сотрудникам, о том, что все заявки слать на адрес такой-то и прочие мелочи.

Итоги

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

Почему так не бывает?

Предположим, что начальник ИТ-отдела решил отказаться от использования существующей дорогой и отдельно-живущей системы ServiceDesk, с целью получить аналог, построенный на платформе SharePoint, развитие которого не будет зависеть от издателя ПО, поддержка которого не будет выливаться в требования иметь в штате человека, обладающего специфической компетенцией.

С этими требованиями он идет к разработчикам с вопросом: "Сколько стоит простая система ServiceDesk?". И получает примерно следующее: ответ на такой вопрос можно получить только после сбора и детализации требований.

И начинается процесс анализа. Аналитик проводит интервьюирование пользователей, задает им уточняющие вопросы, которые не приводят к разъяснению существующих требований. Они приводят к порождению новых. После нескольких итераций сбора требований у заказчика, согласования их с архитектором проекта появляется пакет документов. Без документов никуда: что будет если один программист с проекта уйдет? Нужен волшебный документ, прочитав который, новый программист продолжит работу ровно с того места, где закончил предыдущий.

Заказчик простой системы ServiceDesk получает ответ, что реализация данной системы обойдется ему в 2000 человеко-часов и четыре месяца. Аргумент простой: заказная разработка стоит дорого:

  • Надо собрать требования, этим занимается Аналитик;
  • Надо описать архитектуру будущего решения, этим занимается Архитектор;
  • Надо реализовать решение, этим занимается Программист;
  • Решение необходимо проверить, этим занимается Тестировщик;
  • Всем этим надо управлять, этим занимается Руководитель проекта;

Задача на один день для одного программиста превращается в огромный проект, по одной простой причине: так положено.


Поделиться

Коментарии