SCSM изначально был рассчитан на работу в мульти язычных средах, когда сотрудники используют одну и ту же систему с интерфейсом на разных языках. Но кроме собственно отображения информации, необходимо помнить, что SCSM также выполняет различные внутренние процессы, которые, так или иначе, должны возвращать какую-либо текстовую информацию “в мир”. Примером таких процессов является рассылка оповещений, в частности почтовых. Судя по форумам TechNet, этот процесс вызывает массу вопросов, в том числе и у русскоязычных пользователей. В данной статье я постараюсь полностью описать этот процесс и его нюансы.

Начнем с того, что рассмотрим процесс отправки почты “изнутри”. Из интерфейса SCSM мы можем создать рассылку двумя способами: из представления Администрирование –> Уведомления –> Подписки и из настроек рабочих процессов рабочих элементов (инцидентов, действий, запросов). Каждый из способов создает разные правила, но в части рассылки они отличаются только в одном – подписка напрямую вызывает активность (термин из программирования, см. описание) SendNotificationsActivity, а в рабочих процессах она вызывается через дополнительную прослойку.

Коренным отличием между созданием оповещения из Подписок, и из настроек рабочих процессов является то, что из подписок мы можем задать только конкретных пользователей или группы из CMDB в качестве получателей, тогда как в настройках рабочих процессов мы можем указать только значение поля элемента типа “Пользователь или группа” (та самая дополнительная прослойка как раз и занимается преобразованием значения поля в конкретного пользователя в CMDB).

Активность SendNotificationsActivity принимает на вход 3 параметра (на самом деле параметров больше, но многие почему-то не используются):

• TemplateIds – список шаблонов, которые будут применяться для создание тела письма
• PrimaryUserList – список пользователей, для которых будет выполнена рассылка
• InstanceIds – список элементов. Используется для подстановки значений в шаблон. Во всех трех случаях передается не сам объект, а лишь его внутренний ID в виде строки Guid.

Алгоритм работы активности таков:

1. Строится список получателей, который группируется по локали этих получателей.
2. Для каждой из локали, найденной в списке пользователей, получаем значение шаблона и формируем список сообщение, также группированный по локали. Если для локали нет шаблона – сообщение не формируется.
3. Затем для каждого элемента в списке InstanceIds и для каждого сообщения выполняем отправку писем.

Как видно из последовательности, в процессе отправки используется две локали: локаль пользователя и локаль шаблона. Локаль пользователя хранится в свойствах пользователя, поле “Языковой стандарт”:

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

Таким образом мы можем для каждого пользователя в системе отправить сообщение на его родном языке.

Отлично, но что если локаль не указана? Как я уже писал выше, если в шаблоне нет сообщения для локали пользователя, оно просто не будет отправлено. А вот если не указано локаль пользователя, то берется пользовательская локаль из настроек текущей учетной записи. Чтобы понять, какая учетная запись в данном случае является “текущей”, необходимо помнить, как работает механизм рабочих процессов. Все РП запускаются от имени специальной учетной записи рабочих процессов (Workflow Account), если иное не указано в настройках самого РП. В данном случае никаких дополнительных настроек у процесса отправки почты нет, поэтому все действия будут выполнятся от имени Workflow Account, и именно настройки этой учетной записи будут использоваться для локали пользователей SCSM, у которых не заполнено поле “Языковый стандарт”.

В Windows существует два вида локали – системная и пользовательская. Обе локали указываются в Региональных настройках. Системная локаль задается на вкладке Дополнительно (Administrative) – опция Язык программ, не поддерживающих Юникод (Language for non-Unicode programs). Пользовательская локаль указывается на вкладке Форматы (Formats) – опция Формат (Format).

А теперь пример из жизни. Допустим, у нас компания, в которой в основном русскоязычные пользователи. Но админы в нашей компании, по рекомендации лучших сабаководов, используют английские версии серверных операционных систем. А после установки такой системы настройки пользовательской локали равны “Английская (США)”. И если для админских записей, которые работают непосредственно с сервером, локаль меняют, то вот для всех остальных учетных записей, в том числе и для сервисных, это часто забывают сделать.

На этот самый сервер админы установили SCSM, настроили исходящую почту, настроили шаблоны для русского языка. Локаль для пользователей в SCSM не меняли, т.к. всё равно у нас всё будет на русском. Всё вроде отлично, одно НО… Письма не ходят… Что по логике работы SCSM естественно – Workflow Account имеет английские настройки, а т.к. у пользователей не настроена локаль, то будет использоваться настройки Workflow Account, которое никто не менял, и оно равно “Английская (США)”. Но в шаблоне нет значения темы и тела письма для английской локали, поэтому письмо отправлено не будет.

Еще один частый вопрос – а где в SCSM хранится адрес пользователя, на который ему будут отправлены оповещения? Все адреса пользователя (а их может быть несколько) можно найти и изменить на вкладке Оповещения (Notifications) в форме пользователя:

В конце несколько полезных команд.
Получить текущую пользовательскую локаль из Powershell:
[System.Globalization.CultureInfo]::CurrentCulture
Вызвать окно региональных настроек:
RunDll32.exe shell32.dll,Control_RunDLL intl.cpl,,0

Обе команды полезно использовать с Shift+клик правой кнопкой мыши –> Запустить от имени другого пользователя