Error Code

736

Error CodeДобрый день, уважаемые читатели блога! Сегодня хочу рассказать об обращениях пользователей myBI Connect, которые связаны с обработкой данных выгрузки в MS Power BI.

В myBI Connect заложена определенная логика выгрузки данных из CRM систем, согласно которой, я создал модели данных. Однако, у пользователей сервиса встречаются иные представления и ожидания о структуре данных и работе с ними, что  служит почвой для ошибок и вопросов при развертывании модели или полноценного отчёта. Если говорить более детально, то касается это таблиц дополнительных параметров всех видов сущностей.


Например, для сделок в amoCRM вы создали уникальные дополнительные поля, которые заполняют ваши менеджеры. Название и количество подобных полей неизвестно изначально, они хранятся в базе данных как “параметр-значение-сущность”.

А далее, чтобы это было корректно, в Power Query проводится операция сведения. В итоге, все уникальные значения в поле наименования параметра превращаются в новые столбцы, группируются по сущности, а значения, разумеется, берутся из поля значения. И всё это прекрасно работает… 

До момента, когда появляется сделка, у которой пользовательские поля с одинаковыми названиями, или с возможностью множественного выбора — мультисписок.

К чему это приводит. Дело в том, что при выполнении сведения, для 1 ID сделки в роле “РАССЫЛКИ” приходится 2 значения. А должно быть только одно.

Error Code

Вот так выглядит ряд ошибок. Чтобы бы удостовериться в том, что это именно эта ошибка, кликните на Error. Должно появиться значение “List”, значит в ячейке содержится список значений.

Ну хорошо, умник, скажете вы. На первый извечный вопрос (“Кто виноват?”) мы, предположим, ответ нашли. А что делать? читать Чернышевского. Находим эту сделку в вашей amoCRM и смотрим, насколько это поле важно, активно ли вообще (может оно было удалено и более неактивно). Если активно, то однозначно нужно сменить название поля, а далее провести полную перезагрузку за весь интервал. Тут есть несколько особенностей:

  1. Если ваши исторические данные собраны больше чем за 2 года — перезагрузить полностью их не получится, таковые ограничения сервиса. 
  2. Выгрузка большого интервала при может занять весьма продолжительное время, а для самых крупных CRM могут возникнуть проблемы с API.
  3. И, наконец, такие перезагрузки будут расходовать запас строк и соответственно ваш бюджет в сервисе myBI Connect.

Поэтому далее я опишу несколько вариантов прямого вмешательства, которые помогут решить эти проблемы в Power BI.

  1. Если таких строк по счастью не много, проще просто удалить их вручную в Power Query или SQL-запросом. По первому понятно. Включаем ID строки, и перед шагом сведения фильтруем проблемные строки.


    Теперь пример с помощью SQL. Заходим в базу данных и формируем такой запрос:

    DELETE FROM amocrm_contacts__attributes
    WHERE  “id” = 5060940

    ОБРАЩАЮ ВНИМАНИЕ! Если вы не знаете, где этот запрос писать, не нужно и пытаться. Перейдите к пункту 2. Иначе с вероятностью 100% вы удалите всю таблицу, или выгрузку, что потребует перезагрузки. Все подобные действия лежат на плечах пользователя myBI Connect и восстанавливаются полной перезагрузкой данных, которая влечет за собой дополнительные затраты.
    Но, если вы искушены в SQL запросах, можно удалять все более сложной командой.
  2. Путь второй проще. Вмешательство на уровне Power Query.
    Вы отключаете проблемные строки аналогично SQL Запросу. Разница в том, что тут что-то сломать весьма тяжело, да и шаг можно удалить и переделать. Обращаю внимание, это нужно делать ДО ПРОЦЕДУРЫ сведения.
  3. Этот путь самый простой. Но требует выполнения условия — столбец с ошибками вам просто не нужен. И тогда, мы просто его удаляем.


И теперь общая рекомендация — заранее обдумывайте, какие поля в CRM-системах вам нужны в БД, а какие нет, чтобы не случалось подобных казусов. Это самый надежный способ не только избежать этих ошибок, но и облегчить выгрузку, упростить работу с моделью, ускорить обновление отчета ну и, наконец, сократить бюджет. Здесь я откланяюсь:) До новых встреч.