← Предыдущая статья

4. Выбрать способ загрузки данных в SAP Sales Cloud.

В процессе миграции у нас на проекте использовались 3 пути загрузки данных в SAP Sales Cloud:

• Data Workbench;
• OData;
• SOAP-сервисы.

Разные объекты загружались разными путями. Ниже поясню, почему так получилось, и приведу особенности этих способов загрузки.

Data Workbench

Это стандартный загрузчик данных в SAP Sales Cloud, которым можно пользоваться через web-интерфейс.

Изначально мы планировали делать миграцию, используя только DWB, но во время загрузки основного массива данных столкнулись с серьезными ограничениями, из-за которых загрузка большого количества данных через DWB оказалась невозможна в адекватные сроки:

• В DWB невозможна одновременная загрузка нескольких файлов.
• В очередь загрузки можно поставить до 10 файлов.
• Низкая скорость загрузки некоторых стандартных объектов (49 тыс. записей по адресам клиентов у нас загружались на продуктивный тенант за 4 часа после всех эскалаций SAP по теме ускорения работы DWB).
• Непредсказуемость влияния кастомного кода на скорость загрузки объектов.
• Нестабильная скорость загрузки.
• Шанс появления ошибок при загрузке, которые неизвестным образом проходят при повторной загрузке файла в DWB.
• Ограничение на количество записей в одном загружаемом файле: на момент нашей миграции это было 50 тысяч записей, а сейчас SAP увеличил это количество до 100 тысяч записей.

В свете вышеперечисленных минусов DWB подходит только для загрузки небольшого количества данных (по моему мнению, до 300–500 тыс. записей).

Для DWB мы использовали файлы с заголовками по 49 тысяч записей.

Столкнувшись с реалиями DWB, расчетное время загрузки всех данных у нас получилось примерно 2 месяца. Это было неприемлемо для заказчика, поэтому мы решили привлечь разработчиков для создания OData и SOAP-сервисов для ускорения времени миграции.

OData

Сторона вендора SAP согласилась нам помочь и выделила свои ресурсы для разработки OData-сервисов.

Текущий подход SAP по отношению SAP Sales Cloud заключается в том, что SOAP-сервисы считаются устаревшими, а использование OData-сервисов – актуальным подходом, так что специалисты SAP использовали именно OData.

Потоки с OData-сервисами создавались на SAP CPI, шаблоны для файлов использовались такие же, как и для DWB (с заголовком), но количество строк в одном файле было 60 тысяч.

Из-за того, что DWB использует для загрузки именно OData-сервисы, то скорость загрузки одной записи не повышалась, но преимущество использования OData-сервисов заключается в возможности параллельной загрузки данных. В нашем случае данные из загружаемых файлов скриптом разделялись на пачки по 1500 записей. Предварительное тестирование показало, что 33 потока SAP CPI выдерживал, а 50 – уже нет. В итоге, для стабильности использовалось 20 параллельных потоков. Таким образом, скорость загрузки была примерно в 20 раз быстрее DWB: если файл с 49 тыс. записей по адресам клиентов через DWB загружался за 4 часа, то через OData он загружался за 5 минут.

Время на создание потока для загрузки каждого объекта через OData – 1–2 дня.

SOAP

Разработчики нашей компании решили использовать SOAP веб-сервисы (далее – WS (web-service)) из-за простоты и быстроты реализации относительно OData-протоколов.

Потоки с SOAP-сервисами также были созданы в SAP CPI, формат загружаемых файлов для SOAP был другой: файлы без заголовка, по 1000 записей в одном файле.

Для загрузки данных через SAP CPI использовался специально развернутый FTP-сервер, в который выкладывались файлы с данными. Созданный поток на SAP CPI определял вновь загруженные файлы посредством стандартного FTP-коннектора SAP CPI, преобразовывал данные из файла в необходимые структуры и вызывал Sales Cloud, используя нужную технологию – SOAP или OData.

На FTP-сервере мы делали отдельные папки для каждого объекта и делили их на подпапки «NEW», «OK», «ERROR»:

• В папку «NEW» вручную загружали файлы с данными.
• В папку «OK» автоматически перемещались успешно обработанные файлы.
• В папку «ERROR» автоматически попадали файлы с ошибками. Текст ошибок смотрели в меню «Администратор» — пункт «Мониторинг сообщений веб-сервиса».

При разработке сервисов следует учитывать, какие операции с файлами вам понадобятся: создание, изменение, удаление; и в зависимости от этого просить разработчиков делать их разработки соответствующим образом.

Время на создание потока для загрузки каждого объекта через SOAP – 1–3 дня.

Скорость загрузки одной записи была немного ниже, чем через OData. Но с учетом того, что через SOAP загружался сразу весь объект целиком, общая скорость загрузки была сопоставима с OData либо была выше.

Также мы заметили, что записи, загруженные через DWB, нельзя было изменять через SOAP-сервисы, которые мы использовали при миграции.

Так что выбрать: OData или SOAP?

Ниже объясню простым языком, чем отличаются OData и SOAP-сервисы SAP Sales Cloud, исходя из моего проектного опыта в роли консультанта.

Создание целых объектов и в OData, и в SOAP происходит одним запросом. Но для изменения объекта в OData обработку каждого узла объекта нужно вызывать отдельным запросом, а в SOAP – единым. Например, для изменения основных данных предложений, их внешних номеров, позиций, участвующих сторон будут использоваться 4 разных OData-сервиса. А SOAP-сервисы служат для создания и изменения объекта полностью, то есть для вышеперечисленных подобъектов будет применен всего один WS.

WS сам определяет, есть ли запись в системе по внешнему или внутреннему ID записи, в зависимости от этого производит создание или изменение объекта. А в OData нужно дополнительно проверять, есть ли запись в системе, и потом делать отдельными запросами изменение каждого узла объекта. При использовании стандартных внешних ID объектов (External ID) количество используемых сервисов OData для обработки одного типа объекта может быть весьма большим.

В целом — через OData можно использовать более гибкий подход к обработке объектов, потому что набор полей в WS предопределен, но при этом времени на разработку потребуется больше.

Бывают редкие случаи, когда SAP «забыл» добавить некоторые стандартные поля объектов в WS, поэтому этот момент нужно проверять на основе конкретного набора нужных атрибутов. Кастомные поля добавляются и в OData, и в WS, но кастомные подобъекты в WS не добавляются.

Также стоит учитывать, что OData-сервисы в SAP Sales Cloud только синхронные, а WS есть как синхронные, так и асинхронные.

5. Нужны ли валидаторы

Изначально мы надеялись, что файлы от заказчика будут хорошего качества, так как он обещал делать проверку данных на своей стороне, поэтому мы не предполагали реализацию каких-либо дополнительных автоматических проверок. Но во время тестовой и полной загрузки данных у нас всё же возникало множество проблем при проверке файлов вручную консультантами и через единичные SQL-запросы в «промежуточной» БД из-за того, что в данных от заказчика постоянно были какие-то ошибки. Поэтому приходилось делать несколько итераций проверки и отправки файлов на исправление заказчику.

При начальной миграции нам казалось, что количество таких ошибок будет небольшим, достаточно будет их прямо сейчас поправить, и миграция пройдет успешно. Но при загрузке дельты (изменений по данным, которые произошли с момента начальной выгрузки из БД Siebel) ошибки всё равно продолжили появляться, и было решено привлечь отдельных разработчиков для разработки «валидаторов» — наборов SQL-запросов для автоматизированной проверки данных на уровне нашей «промежуточной» БД.

Такая автоматизированная проверка позволяет не тратить время на выверку данных из файлов от заказчика и делать ее более точно.

Для создания валидаторов были выписаны все поля по каждому объекту в отдельные таблицы, и консультанты заполнили краткое описание и правила валидации для каждого поля. Ниже привожу пример такой таблицы для части полей в кастомном объекте для указания контактного лица на контракте: