Імпорт даних у Microsoft Dynamics CRM
 |
| Мал. 1. Опис класу Bik. |
Деякі рішення, знайдені при розробці інструменту для імпорту та оновлення даних із довідника БІК Україна до системи Microsoft Dynamics CRM.
У результаті впровадження рішень з урахуванням Microsoft Dynamics CRM перед фахівцями часто постає завдання імпорту різних даних у CRM-систему. У більшості випадків для міграції даних використовують інструмент Microsoft CRM Data Migration Framework, що дозволяє імпортувати інформацію в CRM з різних джерел. Однак є й інше завдання: користувачам потрібно оперативно оновлювати великі обсяги інформації із зовнішніх джерел в інтерактивному режимі. Для цього потрібно розробити додатковий компонент, що можливо завдяки розвиненим засобам Microsoft CRM 3.0 Software Development Kit (SDK), призначеним для розширення функціоналу стандартного постачання продукту. У ході реалізації одного з таких компонентів було знайдено кілька цікавих рішень, про які ми розповімо в цій статті.
Коротко про завдання: ЦБ Україна надає банкам довідники, у тому числі «Довідник банківських ідентифікаційних кодів учасників розрахунків на території України» («Довідник БІК РФ») у файлі формату DBF із відомою структурою. Оновлення його відбуваються з періодичністю 1-3 місяці. При реалізації CRM-проекту у банку потрібно імпортувати дані з цього довідника в Microsoft Dynamics CRM (де визначено спеціальну сутність new_bik з полями, що відповідають структурі таблиці DBF). Для цього необхідний компонент з автоматичним імпортом кодів із зовнішнього файлу до бази даних Microsoft Dynamics CRM, який дозволить створити та підтримувати в актуальному стані довідник БІК РФ. Записи довідника застосовуютьсяпри заповненні відповідних реквізитів організацій та контактів у формах CRM; таким чином, можна не вводити їх вручну, що знижує можливість помилок при заповненні.
Імпорт даних
Імпорт повинен проводитись за таким алгоритмом:
- додавання нових записів БІК із файлу-довідника до CRM-системи;
- оновлення вже існуючих записів у CRM-системі;
- деактивація тих записів у CRM-системі, які відсутні у довіднику ЦП.
Складність полягає в тому, що довідник містить багато записів, і необхідно деактивувати ті записи, які відсутні в оновленому довіднику.
Найперше рішення було таким. Перший цикл: отримуємо набір активних записів із CRM та перебираємо його. Якщо існуючий запис знайдено у файлі-довіднику, то оновлюємо його, якщо не знайдено – деактивуємо. Другий цикл: отримуємо набір записів із файлу-довідника та перебираємо його. Якщо запис довідника не знайдено в CRM, додаємо його.
Тут слід врахувати, що є два способи перевірити, чи існує CRM певний запис. Перший спосіб («одно звернення до CRM»): спочатку завантажити в пам'ять всі активні записи і перебирати їх (перебір потрібен для пошуку потрібного запису, так як у класі BusinessEntityCollection, що представляє набір даних у CRM, не визначено метод швидкого пошуку, але можна отримати колекцію в DataSet). Другий спосіб («1000 і 1 запит CRM»): fetch-запитом опитувати CRM щодо наявності конкретної записи.
Метод Merge служить злиття двох об'єктів DataSet, які мають схожу (але не обов'язково однакову) схему. У більшості випадків таке злиття використовується у клієнтських програмах, щоб визначити, які зміни відбулися з даними. Це дозволяєвідстежувати лише модифіковані записи [1].
У результаті імпорт довідника БІК має такий вигляд.
1. Отримання існуючих записів із Microsoft Dynamics CRM. Для оптимізації процесу отримаємо набір активних записів БІК безпосередньо з бази даних Microsoft Dynamics CRM, звертаючись до Filtered View. Дана методика, що повністю підтримується системою, найбільш доречна в цьому випадку і забезпечує максимальну продуктивність [2, 3].
2. Читання записів файлу-довідника. Вилучення даних з файлу-таблиці DBF теж не становить особливих труднощів.
Слід звернути увагу на те, що значення параметра Data Source рядка підключення вказується не сам файл DBF, а ім'я директорії, в якій він знаходиться. У виразі ж SQL таблиця має те саме ім'я, як і файл, але не матимуть розширення (filename [.dbf]). Немаловажним є також фрагмент коду, що виставляє всім записам статус DataRowState.Added, щойно завантажені в DataSet. Це необхідно для коректного додавання та оновлення записів під час злиття.
3. Злиття двох наборів даних. Злиття - це теж нескладна операція. Тут базовим набором даних виступають записи, отримані з CRM, які оновлюються даними з довідника у форматі dbf.
Оновлення, створення нових записів та деактивація
Тепер просто перебираємо записи набору, що вийшов у процесі злиття, перевіряємо стан кожного з рядків і викликаємо відповідний метод: створення, оновлення або деактивацію. Це надається можливим, оскільки метод Merge при злитті оновлює статус кожного рядка вихідного DataSet (з даними CRM) відповідно до даних DataSet, переданого в якості джерела оновлень. Рядки, які містяться в обох наборах, оновлюються, та у вихідний набірдодаються нові записи із довідника. Ті записи, які були порушені у процесі злиття, вважаються застарілими і підлягають деактивації.
Таким чином, відбувається єдиний перебір записів з єдиним запитом до CRM на додавання, оновлення або деактивацію необхідних даних.
Тестування показало, що на сервері CRM, розгорнутому як віртуальна машина (процесор 4x833 МГц, 1024 Мбайт пам'яті RAM; Microsoft Windows Server 2003 Enterprise Edition), для імпорту 4500 записів потрібно 15-25 хв, що за умови досить рідкісного оновлення довідника.
Оптимізація
А тепер найголовніше – оптимізація. Досягнутий результат видавався не надто добрим, але після невеликого доопрацювання вдалося майже в 10 разів прискорити процес імпорту.
Описаний вище компонент проводить оновлення довідника БІК у CRM з класу Bik, в якому визначено методи Create(), Update() і Deactivate(), що викликають у свою чергу відповідно методи Create() , Update() та Execute() Web-сервісу Microsoft CRM 3.0 (клас CrmService). Для зручності екземпляр цього класу винесений у private-властивість класу Bik (рис. 1).
Ось код властивості Service класу Bik:
А тепер розглянемо внесені зміни:
Властивість UnsafeAuthenticatedConnectionSharing класу HttpWebRequest дозволяє тримати відкритим з'єднання, автентичність якого встановлено. Значення за промовчанням — false, що викликає закриття з'єднання з сервером, що пройшло аутентифікацію, після кожного запиту. Таким чином, програма повинна проходити через процес аутентифікації при кожному новому запиті.
Виставлення цієї властивості в true дозволяє після першої автентифікації тримати з'єднання відкритим для всіх наступних запитів,які використовують з'єднання без повторної автентифікації. Іншими словами, після підтвердження автентичності користувача A користувач B може працювати через вже перевірене з'єднання користувача A (без процесу аутентифікації), але запит B буде виконуватися з обліковими даними користувача A. Це дозволяє заощадити час на всіх повторних автентичності запитів.
Застереження: оскільки користувачі отримують можливість працювати з перевіреним (authenticated) з'єднанням без повторного контролю, слід переконатися, що це не стане надалі вразливим місцем системи, що розробляється. Якщо програма використовує автентифікацію для кожного конкретного користувача (а саме це характерно для 90% додатків для Microsoft Dynamics CRM), не потрібно включати цю властивість — інакше всі операції, які проводяться в CRM, будуть виконуватися від однієї й тієї самої відповідальної особи.
Якщо ж з метою підвищення продуктивності програми передбачається дозволити використання перевіреного з'єднання, існує варіант включити таку можливість для груп користувачів. Для цього крім виставлення в true властивості UnsafeAuthenticatedConnectionSharing необхідно вказати властивість ConnectionGroupName того ж класу HttpWebRequest (якому успадковує CrmService). З допомогою останнього організуються іменовані групи перевірених сполук. Це виключає використання з'єднання користувачем, що не пройшов аутентифікацію. Інакше кажучи, користувач A має унікальне ім'я своєї групи підключення, відмінне від групи користувача B, що надає певний шар ізоляції для виконання запитів кожного з користувачів.
Таким чином, додавання всього двох рядків до вже існуючого компонента дозволяє імпортувати 4500 записів за 2,5–3 хв,що становить майже десятикратний приріст продуктивності.
Джерела додаткової інформації
- Детальний опис методу Merge класу DataSet у MSDN (http://msdn2.microsoft. com/en-us/library/system.data.dataset.merge.aspx).
- Microsoft Dynamics CRM 3.0 – Reporting and Filtered Views (http://msdn2.microsoft. com/en-us/library/aa681626.aspx).
- Microsoft Dynamics CRM Team Blog - Writing CRM callouts with filtered views.
- HttpWebRequest.UnsafeAuthenticatedConnectionSharing Property (http://msdn2. microsoft.com/en-us/library/system.net.httpwebrequest.unsafeauthenticatedconnectionsharing.aspx).
- Microsoft Dynamics CRM 3.0: Bulk Import - Performance Best Practices (http://msdn2. microsoft.com/en-us/library/bb291036.aspx#mbs_crmbulkim_topic4).
- CrmService Methods (http://msdn2.microsoft.com/en-us/library/aa680899.aspx).
Інші статті з розділу
Інші статті на подібну тему
- Конструктор веб-інтерфейсів ФОРС для PostgreSQL
- Доступна Microsoft Visual Studio 2019
- Сертифіковане рішення Veeam для SAP HANA
- Kubernetes-орієнтоване середовище розробки Red Hat
- Нова версія інтеграційної шини «Галактика»
| Розмістити у блог |
| Коментарі до статті |
| Рекламні посилання |
МФУ Panasonic DP-MB545RU з можливістю друку у форматі А3Хочете підвищити ефективність роботи в офісі? Вам допоможе новий МФУ #Panasonic DP-MB545RU. Пристрій здійснює
Adaptec by PMCRAID-контролери Adaptec Series 5Z з безбатарейним захистом кешуДослідні мережеві адміністратори знають, що задіяння в роботі кеш-пам'яті RAID-контролера дає серйозні переваги в продуктивності …
ChlorideТрьохфазний ДБЖ Chloride від 200 до 1200 кВт: TrinergyTrinergy - нове рішення на ринку ДБЖ, вперше з динамічним режимом роботи, масштабованістю до 9.6 МВт і ККД до 99%. Унікальне поєднання …