Огляд MSCRM 2011 beta SDK - Частина 1
Отже, вміст SDK:
- CHM-файл - безпосередньо документація,
- директорія bin з основними типами даних, описані далі,
- samplecode - приклади використання C#,
- schemas - XSD-схеми конфігураційних файлів,
- tools - як завжди, утиліта реєстрації плагінів - pluginregistration і файл зіставлення "сутність - допустима операція" - 'message-entity support for plug-ins.xlsx'
- walkthroughs - приклади кастомізації в новому форматі solution (!) з проектами для ribbon та workflow.
Складання зі складу Microsoft Dynamics CRM SDK
Перелік збірок зі складу SDK:
Архітектура взаємодії Microsoft Dynamics CRM
Тут все, як у попередній версії:
- WCF Web Services - Web-сервіс реалізований через Windows Communication Foundation (WCF),
- Processes (formerly Workflows): workflows and dialogs,
- Plug-ins,
- Client Application Extensions,
- Reporting.
Про залежність прав доступу
Додано невеликий розділ із поясненнями залежностей прав доступу один від одного.
| Для того, щоб створити і записати власника | CREATE READ |
| To Share a record | SHARE. Цей правий потрібний для людини, щоб зробити share operation. READ. Цей правий потрібний для людини робить share operation і також за особу, з якою запис використовується. |
| To Assign a record | ASSIGN WRITE READ |
| To Append To a record | READ APPENDTO |
| To Append a record | READ APPEND |
Використання Field Security для обмеженнядоступу до полів у Microsoft Dynamics CRM
Поведінка Secured Fields під час вилучення даних: якщо користувач не має доступу на читання для захищеного поля, буде повернуто null. І не можна точно визначити чому null повернуто - чи це поле не містить значення або через обмеження доступу.
Звідси випливає така поведінка при фільтрації даних: якщо фільтром встановлено обмеження на якесь поле IsNull, то в результуючий набір потраплять як записи, у яких поле має значення null, так і записи із заповненим полем, але значення якого не може бути відображене користувачеві через накладання обмеження профілем Field Security. Це також треба мати на увазі при угрупованнях, агрегуванні та впорядкування по полю з накладеним обмеженням, якщо у користувача немає прав на читання, у всіх випадках буде використано значні null. Справедливо вищесказане і під час роботи з Filtered Views.
Сценарії програмної взаємодії з Microsoft Dynamics CRM 2011
У Microsoft Dynamics CRM 2011 доступні такі підходи до розробки:
- Early-bound – раннє зв'язування – дозволяє використовувати строго типізовані методи та властивості. Усі визначені в кастомізації поля будуть доступні в коді, причому перевірка їх типів виконується на етапі компіляції, що дозволяє уникнути некоректного використання (присвоєння значень, написання назв полів).
- Late-bound - пізнє зв'язування - програмна парадигма, що дозволяє писати код для сутностей, які можуть бути ще не визначені на момент початку розробки. Це дозволяє писати універсальні компоненти, які працюватимуть на будь-якому проекті Microsoft Dynamics CRM. Наочний приклад late-bound програмування – це використанняDynamicEntity у CRM 4.0, про долю класу DynamicEntity у CRM 2011 буде написано далі.
- REST - те, про що так довго говорили більшовики, нарешті, відбулося - кінцева точка формату REST для Ajax-і Silverlight-клієнтів представляє альтернативний інтерфейс для роботи з даними Microsoft Dynamics CRM. Тепер не доведеться формувати в клієнтському коді великі SOAP-запити, достатньо буде звернутися до REST-сервісу, сформувавши певний URI.
- WSDL – зворотна сумісність та сумісність з іншими платформами збережена за допомогою стандарту WSDL.
Основні класи CRM 2011
Головний підхід до розробки під Microsoft Dynamics CRM 2011 не використовує WSDL. Натомість, задіяні дві збірки з усіма необхідними для розробки типами. Такий сценарій може бути охарактеризований як пізнє зв'язування або слабка типізація: ви використовуєте клас Entity, атрибути якого зберігаються як тип property bag. Цей стиль програмування підходить для всіх типів розширення функціональності Microsoft Dynamics CRM 2011.
Ось як виглядало спадкування класів у Microsoft Dynamics CRM 4.0:
У CRM 2011 структура спадкування була спрощена:
Як бачимо, клас DynamicEntity був замінений на Entity ! У коді можливе змішання двох підходів:
Клас Entity надає всім успадкованим від нього класам сутностей доступ до атрибутів під час компіляції (поводиться як strong type), включаючи класи для кастомних сутностей та атрибутів. Водночас допускається використання підходу з пізнім зв'язуванням.
У той час як класDynamicEntity в 4.0 ми могли використовувати тільки з методом Execute web-сервісу CRM, клас Entity допускається використовувати і з методами Retrieve або RetrieveMultiple, так само як і з методом SaveChanges класу OrganizationServiceContext (про нього буде сказано пізніше).
Використання IOrganizationService для читання та запису даних та метаданих
У Microsoft Dynamics CRM 2011 основним сервісом для доступуяк до даних, так і метаданим вашої організації є служба IOrganizationService (у CRM 4.0 використовувалися два окремі сервіси).