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:

Создание нового Event Receiver

Создание нового Event Receiver

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

Настройка Event Receiver

Настройка нового Event Receiver

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

/// <summary>
/// The list received an e-mail message.
/// </summary>
public override void EmailReceived(SPList list, SPEmailMessage emailMessage, String receiverData)
{
    base.EmailReceived(list, emailMessage, receiverData);
 
    // Текст сообщения
    var mailBody = emailMessage.PlainTextBody;
    // Тема сообщения
    var mailSubject = emailMessage.Headers["Subject"];
    // Отправитель
    var mailSender = emailMessage.Headers["x-sender"];
    // Приоритет письма
    var mailPriority = emailMessage.Headers["Importance"];
    // Адрес для ответа
    var mailReturnPath = emailMessage.Headers["Return-Path"];
    // Вложения
    var mailAttachments = emailMessage.Attachments;
    // Пользователь, отправивший заявку
    SPUser sender = null;
    try
    {
        // Пробуем получить пользователя по его адресу электронной почты
        sender = list.ParentWeb.SiteUsers.GetByEmail(mailSender);
    }
    catch
    {
                
    }
    //TODO
}

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

//Новый элемент
var item = list.AddItem();
// Заполняем поля списка
item[SPBuiltInFieldId.Title] = mailSubject;
item["DateReceive"] = DateTime.Now;
item["Message"] = mailBody;
item["Priority"] = mailPriority;
item["Status"] = "New";
item["SenderMail"] = mailSender;
item["ReturnMail"] = mailReturnPath;
if (sender != null)
{
    item["Sender"] = sender;
}
// Сохраняем элемент
item.Update();
// Добавляем вложения из письма к созданному элементу
foreach (SPEmailAttachment attachment in mailAttachments)
{
    //ToByteArray - extension-метод для преобразования потока в массив байтов
    item.Attachments.AddNow(attachment.FileName, attachment.ContentStream.ToByteArray());
}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Параметры уведомлений

Параметры уведомлений

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

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

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

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

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

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

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

Итоги

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

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

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

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

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

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

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

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

Виталий Жуков

Виталий Жуков

SharePoint архитектор, разработчик, тренер, Microsoft MVP (Office Development). Более 15 лет опыта работы с SharePoint, Dynamics CRM, Office 365, и другими продуктами и сервисами Microsoft.

Смотрите также

SharePoint 2007. Проверка на наличие элемента в списке

SharePoint 2007. Проверка на наличие элемента в списке

SharePoint 2007. База данных содержимого

SharePoint 2007. База данных содержимого

SharePoint 2007. Свой контрол на панели свойств веб-парта

SharePoint 2007. Свой контрол на панели свойств веб-парта

SharePoint 2007. Максимальное/минимальное значение поля в списке

SharePoint 2007. Максимальное/минимальное значение поля в списке

SharePoint 2007. Получение данных из нескольких списков и узлов

SharePoint 2007. Получение данных из нескольких списков и узлов