1)      Построение отчетов. Использование Report Builder.

Добрый день!

 Для отчетности в Microsoft Dynamics CRM существует ряд инструментов - Microsoft Excel или SQL Server Reporting Services. Зачем понадобился еще один? Дело в том, что возможности конечных бизнес-пользователей ограничены, если они хотят построить какой-либо отчет по нескольким объектам, например, отобразить всех клиентов и связанных с ними потенциальные продажи и т.д. В этом случае, надо использовать либо отчет SSRS, либо использовать Excel, но тогда от пользователя требуется знание того, как данные хранятся в системе и умение написать SQL запрос. К сожалению, не все бизнес-пользователи умеют писать запросы. И здесь может помочь Report Builder, который является компонентом SQL Server 2005 Reporting Services.

В чем состоит идея использования Report Builder? Администратор системы или разработчик создает промежуточный уровень между самими данными и пользователями - модель. Пользователи подключаются к Report Builder, выбирают требуемую модель данных и сами строят тот отчет, который им необходим. Важно отметить, что в этом случае пользователи оперируют знакомыми им понятиями, например, КЛИЕНТ, ЗАКАЗ, ПОТЕНЦИАЛЬНАЯ ПРОДАЖА и т.д., а не FilteredAccount, FilteredOpportunity. Кроме того, им не требуется знание основ написания SQL запросов.

 Давайте попробуем создать простую модель и, используя ее, создать простейший отчет в Report Builder:

1. Запускаем Visual Studio 2005, создаем новый проект и указываем, что мы хотим создать Report Model Project. Вводим имя проекта и нажимаем кнопку Ок.
2. В Solution Explorer нажимаем правой кнопкой мыши на пункте Data Sources и выбираем пункт Add New Data Source.
3. В появившемся окне нажимаем кнопку New, вводим необходимую информацию (название сервера, тип аутентификации, базу данных CRM) и нажимаем кнопку Ок.
4. Нажимаем кнопку Next и, затем, Finish.
5. Мы создали источник данных. Теперь, нам необходимо создать представление данных. Для этого, нажимаем правую кнопку мыши на пункте Data Source Views (в окне Solution Explorer) и выбираем пункт Add New Data Source View.
6. В появившемся окне выбираем соответствующий источник данных (созданный на предыдущем этапе) и нажимаем кнопку Next.
7. Теперь выбираем объекты, которые мы хотим включить в нашу модель. В моем случае все просто - я хочу включить в модель только организации и соответствующие потенциальные продажи. Соответственно, я выбираю FilteredAccount и FilteredOpportunity (всегда помните про безопасность данных). Переносим их в правую часть и нажимаем кнопки Next и Finish.
8. Теперь мы должны установить логические связи между нашими двумя объектами. Те, кто смотрел структуру данных, знают, что представления, которые мы выбрали не связаны в самой БД, но мы можем установить логическую связь между ними. Для этого, надо кликнуть мышкой на соответствующем Data Source View. В результате, отобразится структура наших данных, состоящая из двух объектов - FilteredAccount и FilteredOpportunity.
9. Сначала, нам надо переназвать наши объекты, чтобы их названия были более дружественны для пользователей. Выбираем объект FilteredAccount, и в окне Properties меняем атрибут FriendlyName на Организация.
10. Аналогично поступаем с FilteredOpportunity, меняя название на Потенциальная продажа.
11. Теперь надо установить связь. Для этого нажимаем правую кнопку мыши на любом объекте и выбираем пункт New Relationship.
12. В качестве primary key используем accountid из FilteredAccount.
13. В качестве foreign key используем accountid из FilteredOpportunity.
14. Нажимаем кнопку Ок. Система сообщает нам, что у нас не объявлен первичный ключ и предлагает создать логический первичный ключ. Соглашаемся, нажимая кнопку Yes.
15. Создаем логический первичный ключ для Потенциальная продажа (opportunityid).
16. И теперь осталось создать саму модель данных. Нажимаем правую кнопку мыши на пункте Report Models и выбираем пункт Add New Report Model.
17. Выбираем соответствующее представление источника данных (data source view) и нажимаем кнопку Next.
18. В окне выбора правил генерации ничего не меняем и нажимаем кнопку Next 2 раза.
19. Нажимаем кнопку Run. Процедура генерации займет некоторое время.
20. По окончании процесса, нажимаем кнопку Finish и, затем, Yes to All.
21. Теперь, нам надо разместить эту модель на нашем сервере. Выбираем пункт меню Build -> Deploy [Название модели]

Все, теперь осталось только проверить работу. Открываем SSRS, например, по ссылке http://servername/Reports и запускаем Report Builder. Открывается окно Microsoft Report Builder. В правой панели выбираем нашу модель, указываем тип отчета (например, Table) и нажимаем кнопку Ок. В левом верхнем окне отображаются доступные объекты - Организации и Потенциальные сделки, а слева внизу - атрибуты соответствующих объектов. Перетаскиваем в окно (где написано Drag and Drop column fields) атрибут Name объекта Организация и атрибут Name объекта Потенциальная продажа. Добавляем название отчета (в область Click to add title) - "Сделки по организациям". Все, теперь нажимаем кнопку Run Report и получаем требуемую нам информацию. Все просто!!!

a.        Оптимизация производительности Microsoft Dynamics CRM 3.0

Добрый день! Очень часто меня спрашивали как партнеры, так и наши клиенты о том, как можно повысить производительность системы, каким образом можно ускорить работу подсистемы отчетов и т.д. Теперь эту информацию вы можете получить, скачав обновленную Read More...

a.        Workflow против Callouts

Microsoft Dynamics CRM 3.0 предоставляет ряд возможностей, которые позволяют расширить функционал системы в области автоматизации бизнес-процессов. К таким возможностям можно отнести использование .NET сборок для расширения функционала Workflow и создание специальных процедур - Callout. .NET сборка - библиотека, которая с помощью конфигурационного файла один раз подключается к системе, а, затем, функционал данной библиотеки можно использовать сколь угодно много раз не будучи разработчиком. Callout-ы - по сути, триггеры, которые позволяют "повесить" дополнительные обработчики на различные события, такие как: создание, обновление, слияние и т.д. (кстати, кто сдавал локализованный вариант экзамена Customization знает, что в переводе Callout - выноска :) ). Callout-ы также подключаются с помощью конфигурационного файла, но, для того, чтобы использовать их функционал, необходимо знать, как устроена данная библиотека/процедура и ее использование невозможно через редактор бизнес-процессов Workflow Manager. Соответственно, очень часто встает вопрос: "Какое средство необходимо использовать для решения данной конкретной задачи?". И иногда принимается неверное решение, что ведет к дальнейшему переделыванию системы, увеличения срока внедрения, росту расходов на проект и т.д. Чтобы снизить данные риски, давайте посмотрим, когда лучше использовать Workflow, а когда - Callout-ы.

Надо понимать, что любое бизнес-правило, которое задается с помощью Workflow, может быть также задано и с помощью Callout-ов. Разница только в способе подключения библиотеки и возможность использования данного правила в дальнейшем бизнес-аналитиком (т.е. человеком, который не является разработчиком и не знает как писать на .NET) с помощью Workflow Manager.

Если нам надо, чтобы наше правило мы могли использовать в дальнейшем, и люди, которые будут использовать это правило, не являются разработчиками и не знают систему очень глубоко, то предпочтительней использовать Workflow. Действительно, подключение .NET сборки к системе занимает чуть больше 10 строчек в конфигурационном файле. А после этого данное правило будет доступно для всех бизнес-аналитиков, которые используют Workflow Manager. При этом, конечно, надо учитывать, что есть ряд ограничений, присущих именно .NET сборкам:

• Одно из самых главных - асинхронный режим работы. Т.е. мы не можем заранее предсказать, когда закончится выполнение того или иного правила. По сути, все правила Workflow попадают в очередь и постепенно исполняются. Соответственно, НЕЛЬЗЯ (или точнее, не рекомендуется) использовать .NET сборки для синхронизации данных между Microsoft Dynamics CRM и сторонними системами.
• Другое ограничение (не менее важное) - количество событий, по которым может срабатывать правило. Это Создание объекта (Create), Назначение другому пользователю (Assign To), Изменение статуса (Change). Кроме того, существует возможность ручного запуска (Manual) правила.
• Можно создавать workflow правила для собственных объектов, но только для тех, за которые отвечают пользователи (т.н. User-owned). Примерами user-owned объектов являются: Организации, Контакты, Возможные сделки и т.д.

Таким образом, если нам можно использовать асинхронный режим работы в нашей бизнес-логике, мы хотим запускать обработчик при наступлении одного из трех условий (Create, Assign To, Change) или вручную, работаем с сосбтвенными объектами, за которые отвечают пользователи, и хотим в дальнейшем использовать это правило через Workflow Manager, то можно воспользоваться .NET сборками. 

2)       Workflow против Callouts

Microsoft Dynamics CRM 3.0 предоставляет ряд возможностей, которые позволяют расширить функционал системы в области автоматизации бизнес-процессов. К таким возможностям можно отнести использование .NET сборок для расширения функционала Workflow и создание специальных процедур - Callout. .NET сборка - библиотека, которая с помощью конфигурационного файла один раз подключается к системе, а, затем, функционал данной библиотеки можно использовать сколь угодно много раз не будучи разработчиком. Callout-ы - по сути, триггеры, которые позволяют "повесить" дополнительные обработчики на различные события, такие как: создание, обновление, слияние и т.д. (кстати, кто сдавал локализованный вариант экзамена Customization знает, что в переводе Callout - выноска :) ). Callout-ы также подключаются с помощью конфигурационного файла, но, для того, чтобы использовать их функционал, необходимо знать, как устроена данная библиотека/процедура и ее использование невозможно через редактор бизнес-процессов Workflow Manager. Соответственно, очень часто встает вопрос: "Какое средство необходимо использовать для решения данной конкретной задачи?". И иногда принимается неверное решение, что ведет к дальнейшему переделыванию системы, увеличения срока внедрения, росту расходов на проект и т.д. Чтобы снизить данные риски, давайте посмотрим, когда лучше использовать Workflow, а когда - Callout-ы.

Надо понимать, что любое бизнес-правило, которое задается с помощью Workflow, может быть также задано и с помощью Callout-ов. Разница только в способе подключения библиотеки и возможность использования данного правила в дальнейшем бизнес-аналитиком (т.е. человеком, который не является разработчиком и не знает как писать на .NET) с помощью Workflow Manager.

Если нам надо, чтобы наше правило мы могли использовать в дальнейшем, и люди, которые будут использовать это правило, не являются разработчиками и не знают систему очень глубоко, то предпочтительней использовать Workflow. Действительно, подключение .NET сборки к системе занимает чуть больше 10 строчек в конфигурационном файле. А после этого данное правило будет доступно для всех бизнес-аналитиков, которые используют Workflow Manager. При этом, конечно, надо учитывать, что есть ряд ограничений, присущих именно .NET сборкам:

• Одно из самых главных - асинхронный режим работы. Т.е. мы не можем заранее предсказать, когда закончится выполнение того или иного правила. По сути, все правила Workflow попадают в очередь и постепенно исполняются. Соответственно, НЕЛЬЗЯ (или точнее, не рекомендуется) использовать .NET сборки для синхронизации данных между Microsoft Dynamics CRM и сторонними системами.
• Другое ограничение (не менее важное) - количество событий, по которым может срабатывать правило. Это Создание объекта (Create), Назначение другому пользователю (Assign To), Изменение статуса (Change). Кроме того, существует возможность ручного запуска (Manual) правила.
• Можно создавать workflow правила для собственных объектов, но только для тех, за которые отвечают пользователи (т.н. User-owned). Примерами user-owned объектов являются: Организации, Контакты, Возможные сделки и т.д.

Таким образом, если нам можно использовать асинхронный режим работы в нашей бизнес-логике, мы хотим запускать обработчик при наступлении одного из трех условий (Create, Assign To, Change) или вручную, работаем с сосбтвенными объектами, за которые отвечают пользователи, и хотим в дальнейшем использовать это правило через Workflow Manager, то можно воспользоваться .NET сборками. 

3)       Поговорим об External Connector...

Одним из новшеств в версии 3.0 по сравнению с предыдущей версией (1.2) стало появление специального типа лицензии - External Connector. И, хотя, с момента выхода Microsoft Dynamics CRM 3.0 прошло более полутора лет, до сих пор я получаю много вопросов от партнеров, клиентов и коллег по поводу использования данного типа лицензии. Давайте разберемся, что это такое.

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

Конечно, лицензия External Connector имеет ряд ограничений:

• Лицензия External Connector доступна только для редакции Professional.
• External Connector - это не какой-то механизм организации доступа к системе, а только ЛИЦЕНЗИЯ.
• Лицензия разрешает доступ к систему неограниченному количеству ВНЕШНИХ пользователей, к которым, естественно, не относятся наши сотрудники и сотрудники афилированных с нашей организацией структур.
• Если пользователи будут использовать стандартный Web или Outlook интерфейс, то для таких пользователей необходимо приобретать обычную ИМЕННУЮ лицензию. Использование в данном случае External Connector является нарушением лицензионного соглашения. Соответственно, для того, чтобы использовать данный тип лицензии, необходимо написать свое web приложение, к которому будут обращаться внешние пользователи (и организовать аутентификацию этих пользователей).
Лицензия External Connector не решает вопросы с лицензирование других программных продуктов (к примеру, в случае использования External Connector требуется процессорное лицензирование SQL сервера).

4)     O лицензировании SQL Servera

Мы получилаем часто запросы от клиентов о том, надо ли лицензировать SQL Server если он используется только для работы с Microsoft Dynamics CRM. Ответ достаточно прост:

1. Лицензия на Microsoft CRM не дает право использовать другие программные продукты

2. Описанная выше ситуация (когда мы используем SQL Server только как хранилище данных для других приложений и не используем его базы данных напрямую) называется мультиплексирование. Документ, который находится по ссылке, сообщает нам, что "Применение мультиплексирования или пулирования не уменьшает количества клиентских лицензий (CAL), необходимых для доступа к SQL-серверу...".