Расширенная функциональность
28
Янв
2

CRM 2013 или найди 10 отличий… Платформа

Бизнес-правила

Бизнес-правила – это новый функционал, который позволяет настраивать бизнес-логику на стороне клиента без разработки (на JavaScript). К сожалению, полностью заменить JS они не смогут, поскольку, во-первых, на данный момент могут выполнять весьма ограниченным набор операций, а во-вторых JS-код бывает весьма нетривиален (например, может вызывать CRM’ные и сторонние сервисы и обрабатывать полученный результат).

Бизнес-правила на данный момент допускает 5 действий:

  • Установка значения для определенного поля;
  • Установка обязательности заполнения для поля;
  • Установка видимости поля;
  • Блокировка/разблокировка поля;
  • Вывод сообщения (сообщение появляется в правом нижнем углу, рядом с дискеткой).

Будем ждать большего набора действий (в том числе и кастомных) в следующих обновлениях MS CRM.

При задании действий Вы можете использовать математические вычисления для подходящих полей (например, для поля типа Валюта):

  • Сложение;
  • Вычитание;
  • Умножение;
  • Деление.

В качестве операндов могут выступать как статичные значения, так и другие (числовые) поля.

Бизнес-правила работают в веб-интерфейсе, Outlook-клиенте, мобильных приложениях и новых формах быстрого создания. Они могут быть применены к одной конкретной форме объекта или ко всем формам какого-либо объекта.

Как и многие другие компоненты Бизнес-правила могут быть включены в Решение CRM и перенесены вместе с ним.

Бизнес-правила выполняются для событий OnLoad, OnSave и OnChange.

Получить доступ к Бизнес-правилам можно следующими способами:

  1. Параметры – Настройка – нужный объект – Бизнес-правила;
  2. Параметры – Настройка – нужный объект – Поля – откройте определенное поле – вкладка Бизнес-правила;
  3. В редакторе форм щелкните на Ленте по кнопке Бизнес-правила;
  4. В свойствах поля в редакторе форм – вкладка Бизнес-правила.

Попробуем настроить простое Бизнес-правило: когда в Интересе поле Источник интереса менется на Партнера, то:

  • Сделать поля Рабочий телефон и Электронная почта обязательными для заполнения;
  • Скрыть поле Мобильный телефон.

Для этого:

  • Перейдите к настройкам Интереса – Бизнес-правила – Создать;
  • Создайте новое Бизнес-правило. Интерфейс его настройки довольно интуитивно понятен и похож на другие визарды CRM (например, на Расширенный поиск). Вам нужно указать следующие компоненты:
    • Название;
    • Условия: задайте условия, при котором должно срабатывать Бизнес-правило. При этом Вы можете проверить содержится ли в поле значение, сравнить значение с «захардкоденным» значением или рассчитанным значением, а также со значением другого поля и т.д.
      Все поля, указанные в условии фактически являются теми полями, на которые будет срабатывать Бизнес-правило. Если какое-либо поле будет отсутствовать на форме, то Бизнес-правило не будут выполняться;
    • Действия: задайте действия, которые будут выполнены при достижении условий. В основном все Действия связаны с полями.
      Примечания:

      • Также, как и при кодировании в JS, Вам нужно предусмотреть обратное действие. Т.е. если какое-либо событие скрывает поле, но наступление противоположного события должно его отображать. Само по себе это не произойдет – Вам нужно создать еще одно Бизнес-правило с соответствующим условием и действием;
      • Если Вы устанавливаете некоторое значение поля, используя Бизнес-правило, то событие onChange не будет срабатывать для этого поля.
    • Описание;
    • Если у Вас множество форм, то определите для каких из них должны быть применено Бизнес-правило.
  • Сохраните и активируйте Бизнес-правило.

На этом можно переходить к тестированию…



В бэкграунде, Бизнес-правила, которые Вы создаете, переводятся в JavaScript (на форме). Т.е. с точки зрения кастомизации системы у Вас только выбор в том, кто будет разрабатывать этот функционал – консультант (через интерфейс) или разработчик (через код). По этой же причине Бизнес-правила, как и остальной JavaScript, не будут выполняться при массовом редактирование записей, при импорте, в Mobile Express, при вызове серверных API и выполнении Бизнес-процессов. Другие интересные моменты:

  • Если есть JavaScript, работающий для того же поля что и Бизнес-правила, то он будет выполнятся перед Бизнес-правилами;
  • Бизнес-правила не поддерживают скрытие Вкладок и Секций;
  • Бизнес-правила работают во всех клиентах CRM: веб (в том числе и на формах Быстрого создания), Outlook, мобильных приложениях (для iPad и Windows 8). При этом настроить их можно только в вебе или клиенте Outlook;
  • Бизнес-правила могут быть добавлены в Решение CRM, а значит их можно импортировать и экспортироваться;
  • Бизнес-правила ограничены одним объектом, т.е., Вы не можете создать одно Бизнес-правило и использовать его на разных объектах (если есть такая потребность, то нужно создать несколько одинаковых Бизнес-правил в разных объектах);
  • Выводимое сообщение Бизнес-правилом уведомление можно локализовать с помощью трансляции.

Бизнес-процессы

Синхронные Бизнес-процессы

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

Характеристики синхронных Бизнес-процессов:

  • Все шаги синхронного Бизнес-процесса работают в рамках одной транзакции. И если что-то пойдет не так, то вся транзакция откатится;
  • Синхронные Бизнес-процессы поддерживают и Пре и Пост выполнение;
  • Работают во всех средах CRM: веб, Outlook, мобильная-среда;
  • Настраиваются тем же способом, как и асинхронные.

Рассмотрим простой пример: при связывании Контакта с существующей Организацией, Бизнес-процесс в режиме реального времени перенесет информацию с этой Организации в Контакт.

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

Создайте новый Бизнес-процесс (как и раньше) и при этом снимите галку «Запустить в фоновом режиме». В экране настройки Бизнес-процессов появились новые опции для синхронных БП:

  • Условия запуска: Пре или После. Означает то же самое что и для плагинов – когда будет выполнен БП, до основной операции или после;
  • У Бизнес-процессов есть изменение в плане безопасности – они могут теперь работать относительно либо полномочий владельца Бизнес-процесса, либо Пользователя иницировавшего запуск Бизнеес-процесса.

Примечание:

  • После создания синхронного Бизнес-процесса, его можно конвертировать в асинхронный и обратно;
  • Логирование синхронных БП происходит только при возникновении ошибки;
  • Синхронные Бизнес-процессы также позволяют отменять сохранение, если условия не выполняются. Для этого нужно задать шаг Останоить БП с состоянимем Отменено (и задать нужное сообщение в свойствах).


С поялением новых возможностей диапазон применения БП расширился:

  • Проверка введенных данных и предотвращение сохранения;
  • Синхронное обновление полей при выполнении действий;
  • Если дополнять такие БП кастомными сборками, то возможно практически полностью отказать от Плагинов.

А вот реализация следующего функционала возможно останется в плагинах:

  • Действия, которые требуют наличи снимков Пре/пост;
  • Стадия Пре для Создания записи (синхронные БП имеют только стадию Пост при Создании записей);
  • Стадия Пост для Удаления записи (синхронные БП имеют только стадию Пре при Удалении записей);
  • Изменение таргета в стадии Пре при Создании или Обновлении. Это дает возможность не вызывать лишний раз Обновление. В БП придется вызывать Обновление;
  • Другие, более сложные случаи в плагинах.

Действия процессов

Действия процессов это по сути отдельные «островки» бизнес-логики, которые не привзаны ни к чему конкретно и могут использоватся любыми частями системы по запросу.

Лирическое отступление: мечтали когда-нибудь вызывать плагины по запросу? 🙂 Вот это почти оно и есть 🙂

С технической точки зрения это те же самые Бизнес-процессы, за несколькими исключениями:

  • Нельзя заставить автоматически срабатывать Действия процессов (т.е. прикрепить их к какому-либо событию) – они запускаются только через прямые вызовы веб-сервиса (из JS-кода, плагинов, веб-запросов и т.д.);
  • Действия процессов могут быть созданы как для определенного объекта, так и быть глобальными;
  • Могут принимать входящие парвметры и возвращать исходящие (Бизнес-процессы принимают только GUID записи, для которой они будут выполнятся и ничего не возвращают);
  • Поддерживают откат транзакции;
  • Выполняются только синхронно.

Настройка

Настраиваются Действия процессов как и обычные Бизнес-процессы:

  • Создайте новый Бизнес-процесс с категорией Действие. При этом в качестве Сущности выберите какую-либо конкретную, либо Нет (глобальный), чтобы Действие процесса не было привязано ни какой сущности;
  • Задайте выходные и выходные параметры:
    • Входные параметры – передаются в Действия процессов при их вызове. Могут быть как обязательными, так и опциональными. Могут быть использованы в работе Действия процессов;
    • Выходные параметры – возвращаются в код вызвавший Action. Также могут быть обязательными или опциональными.
      Поддерживается большентво CRM’ных типов параметров.
  • Далее Вы пишете свою бизнес-логику, используя обычные шаги доступные в Бизнес-процессах – создание, обновление, отправка эолектропочты. При этом Вы можете настроить проверку входных параметров и назначить значения выходным параметрам (как в Диалогах);
  • Ну и напоследок укажите если требуется две галки:
    • Включить откат – если произойдет ошибка вся транзакция будет отменена;
    • Сохранять журнал если произошла ошибка.


Вызовы

Вызов с помощью C#:

// Вызываем Действие процесса - new_EnquiryCreateProject
OrganizationRequest req = new OrganizationRequest("new_EnquiryCreateProject");
req["ProjectName"] = "This is a test operation for using Actions in CRM 2013 ";
req["Target"] = new EntityReference("new_enquiry", enquiryObj.Id);

// Выполняем запрос
OrganizationResponse response = service.Execute(req);

Здесь вызывается Действие сервиса new_EnquiryCreateProject и передается два параметра: входной аргумент «ProjectName» и запись в отношении которой будет работать Действие сервиса.

Тот же самый вызов, но из JavaScript:

function CallActionFromJavaScript() {
    var projectName = "Project Created through Action from Javascript";
    var entityId = Xrm.Page.data.entity.getId();
    var entityName = "new_enquiry";
    var requestName = "new_EnquiryCreateProject";
    ExecuteActionCreateProject(projectName, entityId, entityName, requestName);}
function ExecuteActionCreateProject(projectName, entityId, entityName, requestName) {
    
    // Создаем XML-запрос для вызова Действия процесса
    var requestXML = ""
    requestXML += "<s:Envelope xmlns:s=\"http://schemas.xmlsoap.org/soap/envelope/\">";
    requestXML += "  <s:Body>";
    requestXML += "    <Execute xmlns=\"http://schemas.microsoft.com/xrm/2011/Contracts/Services\" xmlns:i=\"http://www.w3.org/2001/XMLSchema-instance\">";
    requestXML += "      <request xmlns:a=\"http://schemas.microsoft.com/xrm/2011/Contracts\">";
    requestXML += "        <a:Parameters xmlns:b=\"http://schemas.datacontract.org/2004/07/System.Collections.Generic\">";
    requestXML += "          <a:KeyValuePairOfstringanyType>";
    requestXML += "            <b:key>Target</b:key>";
    requestXML += "            <b:value i:type=\"a:EntityReference\">";
    requestXML += "              <a:Id>" + entityId + "</a:Id>";
    requestXML += "              <a:LogicalName>" + entityName + "</a:LogicalName>";
    requestXML += "              <a:Name i:nil=\"true\" />";
    requestXML += "            </b:value>";
    requestXML += "          </a:KeyValuePairOfstringanyType>";
    requestXML += "          <a:KeyValuePairOfstringanyType>";
    requestXML += "            <b:key>ProjectName</b:key>";
    requestXML += "            <b:value i:type=\"c:string\" xmlns:c=\"http://www.w3.org/2001/XMLSchema\">" + project
    Name + "</b:value>";
    requestXML += "          </a:KeyValuePairOfstringanyType>";
    requestXML += "        </a:Parameters>";
    requestXML += "        <a:RequestId i:nil=\"true\" />";
    requestXML += "        <a:RequestName>" + requestName + "</a:RequestName>";
    requestXML += "      </request>";
    requestXML += "    </Execute>";
    requestXML += "  </s:Body>";
    requestXML += "</s:Envelope>";
    var req = new XMLHttpRequest();
    req.open("POST", GetClientUrl(), false)
    req.setRequestHeader("Accept", "application/xml, text/xml, */*");
    req.setRequestHeader("Content-Type", "text/xml; charset=utf-8");
    req.setRequestHeader("SOAPAction", "http://schemas.microsoft.com/xrm/2011/Contracts/Services/IOrganizationServic
/Execute");
    req.send(requestXML); 
    // Получаем ответ
    // var response = req.responseXML.xml;
}

function GetClientUrl() {
    if (typeof Xrm.Page.context == "object") {
        clientUrl = Xrm.Page.context.getClientUrl();
    }
    var ServicePath = "/XRMServices/2011/Organization.svc/web";
    return clientUrl + ServicePath;
}

Сообщения

А теперь самая удивительная возможность Действий процессов – они могут выступать как «сообщения», на которые можно регистрировать плагины (точно также как на сообщения Create, Update и т.д.). Т.е. каждый раз когда будет вызываться Действие процесса плагин будет перехватывать этот вызов и выполнять какую-либо логику. Например, чтобы выполнить предварительную проверку (во время выполнения плагина Вы можете получить входящие параметры) или отменить операцию.


Примечания:

  • Действие процесса в выполняется в самой операции на стадии 30;
  • Действие процесса всегда запускается в контексте прав вызывающего Пользователя;
  • Не поддерживается офлайн клиентами.

Сервисы

Есть 2 новых службы как часть ролей Back End Server и Deployment Administration Server, а также одна измененная служба…

VSS Writer Service

Эта служба предоставляет интерфейс для баэкапа и восстановления данных CRM при помощи Windows Server Volume Shadow Copy Service (VSS). Volume Shadow Copy Service (VSS) это набор стандартизованных интерфейсов, который позволяет централизованно управлять резервными копиями и восстановлением данных для различных приложений.

Необходимые компоненты:

  • System Center 2012 Data Protection Manager (DPM);
  • SQL Server VSS Writer (доступен в SQL Server 2008 R2 и SQL Server 2012).

Microsoft Dynamics CRM VSS Writer поддерживает следующие возможности:

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

Microsoft Dynamics CRM VSS Writer не поддерживает:

  • Бэкап и восстановлени базы данных Microsoft SharePoint интегрированной с Microsoft Dynamics CRM. Для этих целей нужно использовать SharePoint VSS Writer;
  • Бэкап и восстановлени базы данных Microsoft SQL Server Reporting Services, которая используется для отчетов в Microsoft Dynamics CRM. Для этих целей нужно использовать SQL Server VSS Writer.

Использование

Следующая команда должна быть выполнена в DPM Management Shell на компьютере, установлен System Center 2012 Data Protection Manager, чтобы Data Protection Manager мог распознать Microsoft Dynamics CRM VSS Writer. Пользователь, выполняющий команду, должен быть локальным админом.

Set-DPMGlobalproperty -dpmservername DPM_SRVR_NAME -registeredwriters APPS_VSS_WRITER_ID

Где,

  • DPM_SRVR_NAME — имя компьютера, на котором установлен System Center 2012 Data Protection Manager;
  • APPS_VSS_WRITER_ID – уникальный идентификатор службы Microsoft Dynamics CRM VSS Writer. Всегда равен 74bf91e0-e0fa-4ba9-9258 48f4fd1d0445.

После этого базы данных CRM будут доступны для управления через System Center 2012 Data Protection Manager.


Monitoring Service

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

Monitoring Service не выполняет никаких других задач и не передает информацию вне компьютера, на котором работает. Все происходящие события Monitoring Service записывает в Event Log под источником MSCRMMonitoringServerRole.

Синхронизация на стороне сервера

E-mail Router’а больше нет (с нескрываемой ухмылкой потирал руки уставший администратор CRM) :). Теперь отправкой и получением электропочты управляет непосредственно CRM сервер. И все это гламурно называется Синхронизация на стороне сервера.

В предыдущих версиях CRM отправка и получение электропочты могло происходить как через отдельный компонент (E-mail Router), так и через Outlook-клиент CRM. Что вносило немало путаницы и проблем в администрирование CRM системы. Теперь все будет происходить централизовано – через сервер CRM. И, соответственно, будет только одна точка администрирования.

При этом синхронизация при помощи E-mail Router’а и клиента Outlook по-прежнему поддерживается. Вы можете выбрать способ обработку элкутропочты в нстройках системы. Помимо этого в этих же настройках появился замечательный раздел, который позволяет применять настроенный профиль электропочты по умолчанию к вновь создаваемым ящикам.

Если Вы используете Exchange Server, помимо электронной почты можгут синхронизироваться:

  • Встречи;
  • Календари;
  • Задачи;
  • Контакты.

Технически за это отвечает отдельная серверная роль Email Integration Service, которая не входит в стек сервисов Windows и которая разворачивается при установке CRM.

Синхронизация на стороне сервера поддерживает следующие настройки:

Система/протокол Online On-primise
Exchange online *
Exchange 2013 *
Exchange 2010 *
POP3/SMTP * *

На этом плюшки не заканчиваются…

Т.к. роутер больше не обязательно использовать, то вся настройка перетекала в интерфейс CRM. Найти ее Вы сможете в Параметры – Настройка электронной почты. С технической точки зрения ничего не изменилось: Вам, как и прежде, необходио настройить профили входящей и исходящей правила и почтовые ящики пользователей.


Best Practice Analyzer

В CRM 2013 появилось много новых функций и улучшений для пользователей и разработчиков CRM. Не забыли также и администраторов. Для них выпустили новый инструмент – Best Practices Analyzer.

CRM 2013 Best Practices Analyzer выполняет следующие функции:

  • Собирает информацию об установленных ролях сервера CRM 2013;
  • Определяет, соответствует ли конфигурация наиболее успешным практикам;
  • Выводит отчеты обо всех конфигурация, указывая параметры, которые отличаются от рекомендаций;
  • Указывает потенциальные проблемы в установленных функциях CRM 2013;
  • Рекомендует способы решения потенциальных проблем.

Для этого инструмент диагностики требуется другой инструмент – Microsoft Baseline Configuration Analyzer 2.0, который используется для централизованной проверки систем на наличие типичных ошибок конфигурации различных систем.

Для использования Best Practices Analyzer выполните следующие шаги на CRM сервере:

  • Скачайте и установите Microsoft Baseline Configuration Analyzer 2.0;
  • Скачайте и установите Best Practices Analyzer;
  • Запустите Baseline Configuration Analyzer 2.0 под полномочиями локального администратора;
  • Выберите Ваш сервер и нажмите Start Scan – запустится сканирвоание;
  • После сканирования отобразится отчет о Вашей конфигурации и настьройках сгруппированный по разделам Error, Warning и Compliant.

Далее рассмотрите решения найденных ошибок.



SQL

Таблицы

В CRM 3.0 была такая проблема: пользователи могли создать ограниченной количество полей для одного объекта. Это было связано с тем, что на один объект приходилась одна таблица в SQL Server’е, а их возможности по объему данных были ограничены. Решением проблемы стало введение в CRM 4.0 второй SQL-таблицы для объекта: <имя_объекта>Base и <имя_объекта>ExtensionBase. В Base располагались стандартные поля, в ExtensionBase – кастомные.

Но времена идут и продукты совершенствуются. Не избежал этой участи и SQL Server, что в конечном итоге благоприятно сказалось и на CRM. В CRM 2013 на один объект снова приходится ровно одна таблица SQL Server’а (<имя_объекта>Base). Как ожидается это должно повысить производительность, т.к. теперь уменьшится количество объединяемых таблиц в SQL-запросах, а также уменьшится количество SQL-блокировок.


Шифрование данных

После установки или обновления будет активно шифрование данных. Настоятельно рекомендуется создать копию ключа шифрования организации и хранить ее в надежном месте. Дополнительные сведения см. на странице http://go.microsoft.com/fwlink/?LinkId=316366.

В CRM 2013 для некоторых полей, которые конфиденциальные данные, ряда объектов можно использовать шифрование на уровне SQL Server’а. Вот эти объекты:

  • Queue;
  • Mailbox;
  • User Settings;
  • EmailServerProfile;
  • Yammer token.

Ограничения:

  • Даже администратор БД не сможет получить доступ к зашифрованным данным;
  • В настоящий момент нет возможности повесить шифрование на какие-либо дополнительные поля;
  • Шифрование данных, один раз активированное, не может быть деактивировано;
  • За 15 минут Вы можете поменять ключ шифрования не более 3 раз.

Введено шифрование было в основном по двум причинам:

  • Чтобы поддерживать Синхронизацию на стороне сервера (хранит почтовые пароли);
  • Чтобы поддерживать интеграцию с Yammer (хранит Yammer authentication tokens).

Чтобы изменить ключ шифрования данных:

  • Перейдите Параметры – Управление данными – Шифрование данных;
  • Измените Ключ шифрования данных и нажмите Изменить.


Индексы

В CRM 2013 улучшена производительность Быстрого поиска. Делается это за счет автоматического создания SQL индексов (index maintenance job’ом) при добавлении новых полей в быстрый поиск. Им присваиваются имена следующего вида: ndx_QF_.

Ограничения:

  • В такие индексы может быть добавлено максимум 20 полей. Это число может быть изменено через параметр развертывания QuickFindEntityIndexLimit. Установка этого параметра в 0 отключит данный функционал для всего развертывания;
  • Индексы не будут созданы при двух условиях:
    • Число столбцов для поиска столбцов превышает QuickFindEntityIndexLimit;
    • Размер одного из строковых полей, добавленных для поиска, более чем 900 символов.
Комментарии (2)
  • Наталья 28.01.2014

    Диалоговые окна все еще невозможно вызывать изнутри процесса как дочерние?

  • slivka_83 28.01.2014

    Я о таком функционале не слышал.

*

code