Интеграция
Чтобы интегрировать API AliExpress необходимо создать профиль на странице https://console.aliexpress.com/. Нажимаем кнопку "Create app", после выбираем тип приложения "Self-Developer". В созданном кабинете нам нужны значения нескольких полей "App Key" и "App Secret", запишите их куда-нибудь, они нам понадобятся. Зайдем на страницу "Basic Settings" приложения, указываем Callback Url: для примера, я использовал СберМегамаркет. Настройка будет закончена через какое то время. После необходимо получить token - это специальный ключ, который будет идентифицировать Ваше приложение при работе с API. В любом браузере, хром, яндекс или сафари, переходим по адресу: https://oauth.aliexpress.com/authorize?response_type=code&client_id=
ВашAppKey&redirect_uri=CallbackURL&state=123&view=web&sp=ae
нужно будет указать ВашAppKey - Ваш ключ модуля, CallbackURL - https://uvmarket.info, свойства из предыдущего метода. Когда откроется страница, Вас перенаправят на страницу CallbackURL, в параметрах URL Будет указан код, скопируйте его. Далее необходимо сделать POST запрос по адресу: https://oauth.aliexpress.com/token?code=Code&state=123&grant_type=authorization_code&client_id=ВашAppKey&client_secret=ВашAppSecret&sp=ae&redirect_uri=CallbackURL
где Code - код, который мы получили только что, остальные параметры из п.1.
В ответ сервер вернет json с полем access_token - скопируйте это значение. Чтобы упросить процесс получения токена, прикладываю отдельную обработку в конце статьи. На этом подготовительная часть закончена, переходим в 1С. В 1С открываем обработку UVmarket нажимаем кнопку "UVmarket: Настройки ALI" и указываем полученные параметры которые были ранее. Нажимаем кнопку "UVmarket", для того, чтобы хранить значения для обмена с AliExpress, нажимаем кнопку "Записать", чтобы сохранить настройки/ Если у Вас уже есть товары в личном кабинете на AliExpress (UVmarket), то их необходимо сопоставить с номенклатурой в базе 1С. Для этого в модуле СберМегаМаркет, есть форма номенклатуры нужно указать значение AliExpress_UVmarket_ID - идентификатор товара из личного кабинета. Если товаров еще нет, их необходимо добавить в личный кабинет, любым из любых способов. Дальше всё как хотим: для всех товаров, у которых установлен AliExpress_UVmarket_ID можно поставить цены и остатки по необходимости из 1С. Для этого нажмите в модуле UVmarket, кнопку
"Заполнить список" и "Выгрузить в ЛК". Цены и остатки будут выгружены в личный кабинет AliExpress (и дополнительно записаны в 1С в значениях дополнительных свойств товара).
ВашAppKey&redirect_uri=CallbackURL&state=123&view=web&sp=ae
нужно будет указать ВашAppKey - Ваш ключ модуля, CallbackURL - https://uvmarket.info, свойства из предыдущего метода. Когда откроется страница, Вас перенаправят на страницу CallbackURL, в параметрах URL Будет указан код, скопируйте его. Далее необходимо сделать POST запрос по адресу: https://oauth.aliexpress.com/token?code=Code&state=123&grant_type=authorization_code&client_id=ВашAppKey&client_secret=ВашAppSecret&sp=ae&redirect_uri=CallbackURL
где Code - код, который мы получили только что, остальные параметры из п.1.
В ответ сервер вернет json с полем access_token - скопируйте это значение. Чтобы упросить процесс получения токена, прикладываю отдельную обработку в конце статьи. На этом подготовительная часть закончена, переходим в 1С. В 1С открываем обработку UVmarket нажимаем кнопку "UVmarket: Настройки ALI" и указываем полученные параметры которые были ранее. Нажимаем кнопку "UVmarket", для того, чтобы хранить значения для обмена с AliExpress, нажимаем кнопку "Записать", чтобы сохранить настройки/ Если у Вас уже есть товары в личном кабинете на AliExpress (UVmarket), то их необходимо сопоставить с номенклатурой в базе 1С. Для этого в модуле СберМегаМаркет, есть форма номенклатуры нужно указать значение AliExpress_UVmarket_ID - идентификатор товара из личного кабинета. Если товаров еще нет, их необходимо добавить в личный кабинет, любым из любых способов. Дальше всё как хотим: для всех товаров, у которых установлен AliExpress_UVmarket_ID можно поставить цены и остатки по необходимости из 1С. Для этого нажмите в модуле UVmarket, кнопку
"Заполнить список" и "Выгрузить в ЛК". Цены и остатки будут выгружены в личный кабинет AliExpress (и дополнительно записаны в 1С в значениях дополнительных свойств товара).
Как начать интеграцию с маркетплейсами? Каждый продавец, который хочет выйти на Маркетплейс, хочет чтобы у него была интеграция с его учетной системой сразу. Для этого и существует модуль интеграции UVmarket: Обмен данными между СберМегаМаркет и 1С. Данное решение Вам позволяет это всё сделать и не только, что Вы хотите, а намного больше.
UVmarket: Обмен данными между СберМегаМаркет и 1С
Вы владелец бизнеса? Вы хотите увеличить продажи и у Вас 1С? - тогда Вам в любом случае необходим модуль обмена UVmarket. Вы сможете получать заказы с Маркетплейчаса, полностью их обрабатывать и закрывать в личном кабинете!
Чтобы интегрировать маркетплейс WB,OZON, Сбермегамаркет, Вам в любом необходим модуль UVmarket, так как он предназначен именно для этого. Чтобы обмениваться заказами, передавать остатки в так называемом фиде. А модуль UVmarket Все это позволяет. Если Вы пользуетесь данным решением, то у Вас не будет никаких проблем с обменом и интеграцией.
Часто у бизнеса возникает потребность предоставить крупным клиентам возможность самостоятельно оформлять заказы на B2B-портале, интегрированном с 1С. Как организовать такую интеграцию на конференции Infostart Event 2019 Inception рассказал исполнительный директор компании «Гильдия консультантов» Николай Елатонцев.
Реализация хороших B2B-площадок – это тренд последних лет. Заказчики хотят облегчить жизнь своих менеджеров – переложить часть работы непосредственно на пользователей. И бизнес тоже к этому идет. Решать вопросы по телефону сейчас не модно. Сейчас модно общаться в чатах, ставить задачи где-нибудь в таск-трекерах, писать вопросы в хелп-деске и т.д.
Задача – интегрировать B2B-портал с 1С
Сегодня я буду обращаться к вам, как к разработчикам B2B-портала, ответственным за 1С. Вы можете работать непосредственно в команде заказчика или поддерживать его на правах аутсорсинговой команды – сути это не меняет. Наша с вами сегодня задача – это запустить хороший работающий B2B-портал.
Поэтому мой доклад будет состоять из некоторых важных тезисов, чтобы в конце у вас был некий алгоритм, по которому вы сможете это сделать хорошо и безболезненно.
При этом договоримся, что хотя интеграция – это всего лишь часть разработки B2B-портала, мы непосредственно о разработке портала сегодня говорить не будем, мы будем говорить только о том, что касается именно интеграции с 1С.
Общие моменты разработки и интеграции
Сначала немного об общих моментах.
Выгрузка номенклатуры
Теперь по конкретике.
По выгрузке номенклатуры в принципе никаких особенностей нет, но все равно важно учесть следующие моменты.
Наличие по складам и регионам и условия доставки
Что касается наличия товаров по складам и регионам – какие здесь особенности:
Что нужно иметь в виду при реализации выгрузки остатков по складам?
Ценообразование по сложным алгоритмам
Дальше самое вкусное – это ценообразование. Какие здесь особенности в отличие от стандартного интернет-магазина? Это:
Что здесь важно иметь в виду?
Пакет документов и обмен документами
Следующий момент – это пакет документов и обмен документами.
Какие моменты здесь важно решить, на какие особенности обратить внимание:
При интеграции с 1С важно договориться – что мы передаем в личный кабинет B2B-площадки.
Управление контрагентами и платежные балансы
Следующий момент - управление контрагентами и платежные балансы.
На что здесь нужно обратить внимание?
Пользователь выбирает разных контрагентов, и тут нужно решить – одна учетная запись равна одному контрагенту или нет? Понятно, что выбор контрагента – это удобно, но это требует часов доработок. Иногда лучше зафиксировать, что у нас одна учетная запись – это один контрагент. Система тоже живая, иногда, когда нужно запуститься быстрее, вполне рабочая. Эти моменты важны.
Обработка заказов
Дальше – «кит интеграции». Это непосредственно обработка заказов.
Какие могут быть особенности у обработки заказов?
Особенностей много. Несмотря на то, что каждая компания заказы обрабатывает одинаково, нюансы здесь значат очень много.
Поэтому как мы вообще реализуем интеграцию, на что обращаем внимание.
Интеграция с CRM
Дальше – интеграция с CRM. О ней я уже немного вначале сказал.
Какие у интеграции с CRM особенности:
В этом плане вам нужно внедрить в ваши системы специальные защиты.
Также важно
Если все это подытоживать, то, что хочется сказать:
Вопросы
Реализация хороших B2B-площадок – это тренд последних лет. Заказчики хотят облегчить жизнь своих менеджеров – переложить часть работы непосредственно на пользователей. И бизнес тоже к этому идет. Решать вопросы по телефону сейчас не модно. Сейчас модно общаться в чатах, ставить задачи где-нибудь в таск-трекерах, писать вопросы в хелп-деске и т.д.
Задача – интегрировать B2B-портал с 1С
Сегодня я буду обращаться к вам, как к разработчикам B2B-портала, ответственным за 1С. Вы можете работать непосредственно в команде заказчика или поддерживать его на правах аутсорсинговой команды – сути это не меняет. Наша с вами сегодня задача – это запустить хороший работающий B2B-портал.
Поэтому мой доклад будет состоять из некоторых важных тезисов, чтобы в конце у вас был некий алгоритм, по которому вы сможете это сделать хорошо и безболезненно.
При этом договоримся, что хотя интеграция – это всего лишь часть разработки B2B-портала, мы непосредственно о разработке портала сегодня говорить не будем, мы будем говорить только о том, что касается именно интеграции с 1С.
Общие моменты разработки и интеграции
Сначала немного об общих моментах.
- Первое, самое важное – вы обязательно должны участвовать в написании технического задания, особенно спецификации интеграции. Обычно в этом никому участвовать не хочется, и согласование спецификации скидывается на какого-нибудь менеджера. И этот менеджер без вашего ведома может произнести следующую волшебную фразу: «Ребята, давайте начнем работу, мне уже нужно показывать, что все это запущено, а наши 1С-ники без проблем выгрузят вам все, как вы захотите – в любом формате, в любой структуре». Если менеджером такая волшебная фраза произносится, то, когда доходит непосредственно до выгрузки, начинаются слезы, боль и большая переделка. Поэтому берите на себя этот момент, участвуйте в написании технического задания. Особенно, что касается интеграции.
- Также нужно понимать ваше место в этапах разработки. Дело в том, что чтобы проект не растягивался в сроках и держался календарного плана, вы в какие-то моменты должны будете что-то реализовать, чтобы весь проект двигался дальше. Например, это какой-то веб-сервис на стороне 1С, чтобы при запросе что-то отдавал. И вроде как написать его не сложно – нужно максимум два-три дня, но после того, как вы его реализуете, нужно будет написать какую-то инструкцию для веб-программистов, чтобы они им грамотно пользовались. А еще потом сделать пусконаладку, все это протестировать, запустить, и все это растягивается на две-три недели. Поэтому находите это время, оно у вас очень дорогое и очень важное. Иначе проект может затянуться на годы. Хотя он очень часто и затягивается на годы вне зависимости от наличия инструкций.
- Дальше – участвуйте в выборе транспорта. Дело в том, что ребята из веб-студий не очень хорошо знают, какие могут быть варианты, поэтому берите это на себя. Говорите, что мы будем делать вот так и вот так. Конечно, лучше использовать что-то более понятное и стандартное типа CommerceML, который себя хорошо зарекомендовал.
- Также очень важно учитывать, что могут возникнуть сложности в случае, если у вас уже есть какая-нибудь внедренная CRM не на 1С (сейчас это частая ситуация), в которой уже работают менеджеры по продажам и которая тоже интегрирована с 1С. В этом случае, если появляется B2B-площадка, получается некий треугольник, в котором все себя не очень хорошо чувствуют. Учитывайте это обязательно. Иначе может получиться следующая ситуация: например, сделка в CRM уже интегрирована с 1С, а когда появляется B2B-портал, заказ оттуда тоже падает сразу в 1С – происходит задвоение. Нельзя этого допускать, нужно это учитывать. И самое главное, что вам нужно будет коммуницировать с командами, которые делают web-портал, поэтому самое главное напутствие – это терпение и лояльность. В некоторых моментах можно будет хотеть наругаться на них очень сильно, но до добра это не доведет.
Выгрузка номенклатуры
Теперь по конкретике.
По выгрузке номенклатуры в принципе никаких особенностей нет, но все равно важно учесть следующие моменты.
- Сначала нужно зафиксировать транспорт – как будет происходить выгрузка.
- Что-то можно выгрузить стандартно через CommerceML, а для остатков, которые нужно выгружать очень часто, возможно, придется реализовать какой-то веб-сервис (следовательно, имейте в виду, что это нужно будет сделать).
- Вообще структура данных в 1С такая, что ее редко когда можно выгрузить на B2B-площадку – там требуется совершенно другая структура. Вспоминаем менеджера, который сказал, что наши программисты вам все выгрузят. Именно по этой причине нельзя доверять менеджеру, чтобы он говорил такие слова. Поэтому нужно договориться – или вы пересобираете структуру на стороне 1С, или вы отдаете как есть, а на стороне сайта она уже пересобирается.
- Есть еще более тонкий момент. Очень хочется, чтобы на B2B-площадке была красивая карточка товара с выбором торгового предложения, но, допустим, разрез характеристик в 1С не ведется, потому что в свое время, когда переходили с 7.7, с этим разбираться не стали – оставили все, как отдельные товары. Что тогда можно сделать? Можно выгружать товары, пересобрать их на стороне веба, а когда они будут падать обратно в 1С, чтобы заказ приходил в виде товаров. Об этом тоже нужно договориться и сказать, что мы будем выгружать вот так, а вы уже там смотрите, ничего не потеряйте – нужно, чтобы отображалось вот так. Это прямо крайне важный момент.
- В конечном итоге это опять сводится к тому, что вам нужно в каком-то техническом задании описать, как каталог на основе ваших данных должен отобразиться на B2B-площадке.
Наличие по складам и регионам и условия доставки
Что касается наличия товаров по складам и регионам – какие здесь особенности:
- конечному пользователю мало знать – есть товар или нет;
- ему важно знать, в каком он количестве, на каких он складах – ближе, дальше, разные регионы и прочее;
- плюс еще есть частичные отгрузки – сначала что-то ему отгрузили, потом он еще подождал неделю, ему еще отгрузили.
Что нужно иметь в виду при реализации выгрузки остатков по складам?
- Никогда не надо бояться ограничивать пользователя, потому что, когда мы убираем менеджера, у нас заказ происходит уже не в форме диалога, а в форме кликания. В этом случае нужно вводить какие-то ограничения – не бойтесь это делать.
- Особенно это важно, если не налажена система перемещения внутри компании между складами. Сделайте четко: один заказ – один склад. Если это самовывоз, сделайте, чтобы клиент видел, где можно забрать одни товары и где другие. Эта схема хорошо себя зарекомендовала. Имейте это в виду, никогда не бойтесь ограничивать, иногда это очень хорошо спасает.
Ценообразование по сложным алгоритмам
Дальше самое вкусное – это ценообразование. Какие здесь особенности в отличие от стандартного интернет-магазина? Это:
- индивидуальные цены по договорам;
- индивидуальные скидки в зависимости от условий;
- накопительные скидки;
- скидки в зависимости от объема.
Что здесь важно иметь в виду?
- Сначала нужно описать все группы пользователей, особенно на пограничных случаях. Например: нужно ли пользователя верифицировать, что делать, если он ввел новое юрлицо и т.д. Эти моменты очень важно оговорить. Ни в коем случае нельзя позволять им делать заказ, пока в 1С это юрлицо не появится.
- И еще очень важный момент – это непосредственно цена. Не надо гнаться за отображением пользователю конечной цены. Важнее, чтобы заказ сформировался по той цене, по которой пользователь ждет. Поэтому сосредоточиться нужно именно на этом.
- Соответственно, так как на цену влияет огромное количество скидок и прочего – иногда даже выгрузить не получается, потому что документ имеет огромное количество строк.
- Какое здесь есть хорошее красивое решение, которое себя прекрасно зарекомендовало? Это веб-сервис на стороне 1С, который работает следующим образом. Когда товар попадает в корзину (меняется состав или количество), все это прилетает в 1С, и 1С отдает обратно ту цену, которая у этого пользователя именно для того юрлица, которое он хочет. Веб-сервис в этой задаче себя зарекомендовал очень хорошо, имейте это в виду.
Пакет документов и обмен документами
Следующий момент – это пакет документов и обмен документами.
Какие моменты здесь важно решить, на какие особенности обратить внимание:
- к каждому заказу должен быть полный комплект документов;
- и хорошо бы предусмотреть в личном кабинете также сервисы для взаимодействия – чтобы если нам что-то нужно от системы, мы могли бы получить это в личном кабинете.
При интеграции с 1С важно договориться – что мы передаем в личный кабинет B2B-площадки.
- В подавляющем числе случаев это могут быть данные, на основе которых генерируются печатные формы. Если вам по какой-то причине удобнее передавать файлы – ничего страшного в этом нет, это тоже будет вполне работоспособная система.
- А вот по поводу того, чтобы интегрировать с 1С какие-то сервисы – это не всегда нужно. Это дорого и не оправдывает средств. Например, сколько наши клиенты ни пытались обязательно собирать в 1С все рекламации, в конечном итоге от этого отказывались и экономили на этом много денег. Потому что пока еще на этой стадии все решается на уровне коммуникаций и в дальнейшем может пойти по разным путям, т.е. все это интегрировать не имеет смысла.
Управление контрагентами и платежные балансы
Следующий момент - управление контрагентами и платежные балансы.
На что здесь нужно обратить внимание?
Пользователь выбирает разных контрагентов, и тут нужно решить – одна учетная запись равна одному контрагенту или нет? Понятно, что выбор контрагента – это удобно, но это требует часов доработок. Иногда лучше зафиксировать, что у нас одна учетная запись – это один контрагент. Система тоже живая, иногда, когда нужно запуститься быстрее, вполне рабочая. Эти моменты важны.
Обработка заказов
Дальше – «кит интеграции». Это непосредственно обработка заказов.
Какие могут быть особенности у обработки заказов?
Особенностей много. Несмотря на то, что каждая компания заказы обрабатывает одинаково, нюансы здесь значат очень много.
Поэтому как мы вообще реализуем интеграцию, на что обращаем внимание.
- Первое – это статусы. Как заказ будет выгружаться, как он будет меняться. Вообще не стоит делать большое количество статусов. Даже если вам хочется фиксировать каждый шаг по заказу с помощью изменения статуса – не нужно стремиться к этому. Но в то же время мало иметь всего три статуса – заказ принят, в обработке и завершен. Наша рекомендация в этом плане всегда – разделяйте статус логистики и статус заказа в целом. Обычно в B2B-порталах доставка и оплата могут обрабатываться абсолютно по-разному – для каких-то контрагентов обязательна предоплата, кто-то платит по постоплате и пр. Логистический статус нужно передавать как отдельное свойство, чтобы на основе этого свойства менялся нужный статус.
- Еще важен вопрос обратной интеграции, потому что все равно убрать телефон окончательно мы не можем. И что делать, если один и тот же заказчик часть сделал сам, а часть по телефону? Нужно ли заказ, оформленный по телефону, также отдавать на B2B-площадку? Это важно зафиксировать. И если это надо, реализовывать это придется довольно долго.
Интеграция с CRM
Дальше – интеграция с CRM. О ней я уже немного вначале сказал.
Какие у интеграции с CRM особенности:
- часто CRM не является частью 1С;
- это вызывает определенную нагрузку на менеджеров – они работают в нескольких системах и по этому поводу сильно нервничают;
- и интеграция необходима не только с порталом – мы меняемся данными и с B2B-порталом и с CRM-системой.
В этом плане вам нужно внедрить в ваши системы специальные защиты.
- Обычно, как только менеджеры начинают работать в какой-нибудь популярной CRM-системе, у них появляется желание перевести туда все обеспечение сделки, хотя CRM-система не должна за это отвечать. Они хотят видеть там все «от и до», чтобы, не дай Бог, не заходить в 1С. Безусловно, это круто, но это очень дорого.
- Поэтому стремитесь скорее к единому информационному пространству (чтобы не вводить одну и ту же информацию несколько раз). Что я имею в виду под единым информационным пространством? Необходимо обеспечить такую интеграцию между системами, чтобы заказ падал в CRM-систему, и после того как менеджер вводил по нему всю необходимую информацию, в 1С все данные по заказу уже должны быть сформированы – заведены все нужные контрагенты и пр. Потому что если этого нет, менеджер начинает нервничать. А если это есть, то это хорошая, отличная схема, по которой можно работать.
- Более того, рассмотрите такой вариант, чтобы интегрировать 1С с чем-то одним. Хорошо себя зарекомендовала следующая схема – есть портал, есть 1С и есть CRM. Что бы ни происходило в 1С, это сначала выгружается в портал, а из портала выходит в CRM. И наоборот. Такая система тоже вполне себя хорошо зарекомендовала.
Также важно
Если все это подытоживать, то, что хочется сказать:
- Старайтесь выбирать разработчиков, которые понимают процессы, происходящие в 1С – такие сейчас на рынке появляются, и если вам удастся их найти, это очень сильно облегчит дальнейшую разработку.
- Участвуйте в процессе создания ТЗ – это самое важное, я считаю. Важно не лениться.
- И понимайте, что вы в первую очередь решаете бизнес-задачи, поэтому необходимы лояльность и терпение в коммуникациях с разработчиками веб-части.
Вопросы
- Если мы цены рассчитываем через веб-сервис, что будет в случае обновлений, падений 1С и т.д. – клиент не сделает заказ?
- Да, клиент не сделает заказ. Все эти темы нужно отдельно оговаривать. Например, сервер с порталом тоже могут упасть – в этом случае клиент тоже не сможет сделать заказ. Отказоустойчивость – это, безусловно, отдельная тема, но если интеграция нарушена, то лучше, чтобы клиент не делал заказ, чем потом это синхронизировать дополнительно вручную. Хотя иногда говорят – пусть наоборот, делает с теми ценами, которые на сайте, а мы потом сами все это перепроведем.
- А если B2B-портал организовывать внутри 1С-ной CRM-системы – это хорошая идея или плохая?
- Вообще пока классическая схема, что учетная система на 1С – отдельно, CRM – отдельно и портал – отдельно. Иногда бывает, что портал тоже реализуется на связке с CRM – например, Битрикс сделал на своем CRM-движке интернет-магазин и уже поставляет это в коробке. Но там с интеграцией пока очень все сложно – она плохо работает.
- А как быть, если мы на портале для дилеров, предположим, предоставляем функциональность бронирования объектов – и такую же функциональность мы предоставляем в CRM-системе – как такие механизмы решать?
- Поучаствовать в написании технического задания, чтобы не навертеть чего-нибудь лишнего. Если мы говорим про бронирование объектов, то это менее популярный случай, чем обычный каталог товаров, поэтому мне сходу сложно ответить. Нужно осознать, какой здесь оптимальный механизм будет.
- А насколько нормально не показывать цену в каталоге товаров?
- Нормальная практика. Раз это B2B, то, как правило, все, кто приходят на портал, уже являются вашими постоянными клиентами. Они прекрасно знают, по каким ценам они работают, и если им просто в личном кабинете дать информацию, что заказ будет по этим ценам, но в целом в каталоге отображать цены по типам, без конкретных значений, то какого-то большого негатива быть не должно. Но формироваться заказ, безусловно, должен по тем ценам, по которым клиент с вами работает.
- Если у вас уникальный продукт – это возможно. Но в основном закупщики, даже если они наши клиенты, они мониторят рынок и что-то могут купить у нас, а что-то не у нас. И ладно, если это одна позиция – сформировал счет, получил цену. А если закупщику интересно три-четыре-пять позиций?
- Если говорить именно о нашем опыте, то за последние два года мы выполнили около 8 проектов, где было принято решение не отображать финальную цену. От них не было требования переделывать эту особенность.
- А в чем главный бонус неотображения цены?
- Тут дело в том, как организован вывод цены в веб-части в том же Битриксе. Там, чтобы вывести нужную цену – это нужно постараться. Тем более если они индивидуальные, назначены по группам пользователей. Хорошо, если есть пять цен и есть пять групп. А когда начинаются тонкости, когда клиент часть товара может по одной цене покупать, другую часть – по другой, а остальное – по третьей, то нужно думать. Так устроено назначение цен в популярном Битриксе. И из-за сложности отображения цены покупателя для данного товара этот вопрос приходится тщательно прорабатывать. Из-за этой сложности и происходит отказ от показа цены для ее вывода только при оформлении. Потому что иначе это приводит к удорожанию проекта.
- Я правильно понимаю, что вы не показываете цену в списке, но ничего не стоит сделать кнопку «Показать цену» для конкретной позиции?
- Тот пример, о котором я говорю, это в принципе – клиент видит товар по тем ценам, которые назначены группе пользователей, к которой он относится. Но когда он будет оформлять, конечная цена может отличаться, потому что действуют какие-то тонкости, связанные с маркетинговой активностью и пр. Для бизнеса нет никакого бонуса в том, что мы не показываем цены, но мы экономим очень много часов веб-разработки, а это экономия денег.
- Если мы говорим про интеграцию 1С и Битрикс, вы используете типовой обмен, который предлагает Битрикс, или у вас практика писать свой уникальный под конкретную задачу.
- Если говорить про подход к решению задачи, то, безусловно, если что-то можно решить с помощью стандартного модуля, мы предлагаем этим воспользоваться, тем более, что последние версии у него действительно неплохие. Например, если можно хотя бы пересобрать каталог через модуль, то без проблем. Но в целом для B2B того, что предлагает именно этот модуль Битрикса для 1С, очень мало. Этот модуль не для B2B. Он очень хорошо покрывает запросы обычного интернет-магазина, но для B2B-площадок он не очень подходит. Мы в последнее время очень многое делаем на стороне 1С через веб-сервисы и на стороне портала. А в модуле Битрикса для 1С этого нет.
- Интересно узнать ваш опыт в интеграции команд веб-разработчиков и 1С-разработчиков. Есть ли какой-то утвержденный формат взаимодействия в плане ТЗ на написанный веб-сервис? К примеру, веб-разработчик ожидает какой-то экспортный файл для Postman, а 1С-ник дает ему только какое-нибудь описание в Word.
- Для этого и нужно участвовать на этапе технического задания. Вообще коммуницировать обязательно, договариваться обязательно. Но лучше в этом плане все брать на себя в плане того, что если нужно что-то выгрузить, и вы можете сделать такой веб-сервис, вы просто пишете к нему какую-то инструкцию. Если говорить в целом про объединение команд – это всегда боль. Если мы берем частый случай (веб-команда, которая делает одну часть, и 1С-команда) – они не любят коммуницировать друг с другом. И, к сожалению, у веб-студии нет понимания этого языка – они не знают различия между свойствами и характеристиками, поэтому очень часто могут не понять, о чем вы говорите. Универсальной таблетки тут нет. А наш опыт такой, что это понятие – системный интегратор и родилось из того, что мы понимаем, что происходит на стороне обоих систем, и это позволяет нам находить взаимопонимание между отделами. А в целом я не вижу какой-то таблетки, как сделать четко. Если мы говорим про документацию – да, очень важно давать хорошоописываемые методы. Например, если мы что-то реализовали, то у нас обязательно для API еще приложено описание для разработчиков, где все видно, чтобы у них никаких проблем не возникало.
- А какой у вас самый популярный инструментарий для создания документации? Чем вы пользуетесь? Как-то автоматизируете это или нет?
- Если честно, то у нас невысокий уровень написания технической документации. Есть команды, которые это делают очень круто – мы завидуем. Но автоматизацию по созданию документации мы сами пока не внедряли, поэтому у нас инструментарий стандартный, и вся автоматизация заканчивается гуглдоксами.
- Два вопроса – используете ли вы в интеграции протокол oData и читали ли вы про новые механизмы, которые появились в 8.3.16, когда есть возможность встраивать веб-клиент в iframe сайтов. И как вы думаете, повлияет ли эта возможность на B2B-сектор и CRM-сектор.
- Безусловно, рано или поздно, повлияет. Но мое субъективное видение в том, что пока лучше оставаться на этой консервативной связке и делать порталы на вебовских движках, и интеграцию проводить именно передачей данных, а не встраиванием чего-то. Пока так. А что касается oData – да, используем.
- Какое вы считаете среднестатистическое удовлетворительное время обмена между порталом, CRM-системой и 1С? Пять, десять минут, полчаса, час?
- Если мы говорим про удовлетворение, то удовлетворяет любое время, которое демонстрирует система. Как пример – если у нас номенклатура в 90000-100000 SKU, то стандартный модуль делает первую полную выгрузку за 16 часов. И никак это мы не ускорим. Именно поэтому мы клиенту говорим – давайте мы сейчас будем писать много кода, чтобы обмен происходил не средствами стандартного модуля обмена, или вы устанавливаете бесплатно этот модуль и 16 часов выгружаете. Он всегда выберет второе. Поэтому нельзя сказать, какое время для клиента будет удовлетворительным – клиент будет удовлетворен любым временем, которое занимает обмен. Разумеется, если мы говорим про остатки, которые должны обновляться раз в полчаса – тут совершенно другая история, понятно, что такие обмены должны происходить быстро.
Если ты хочешь, чтобы СберМегаМегамаркет интегрировался с 1С, то тебе точно нужно решение 1С: Обмен данными 1с и СберМегамеркет. Для связи необходимо просто оставить заявку на сайте uvmarket.ru. Данная интеграция решает все необходимые момент, что Вы интегрировали маркетплейсы у себя в системе. Если Вы купили данную интеграцию, то Вы всегда будите уверены, что остки будут выгружаться всегда корректно и обмен между системами 1с и СберМегамаркет будет вседа верный.
Интеграция модуля 1С и маркетплейса lamoda дает возможность увеличить продажи с маркетплейс lamoda и получать заказы в 1С, УТ, ERP, КА. Автоматически можно выгружать номенклатуру из 1С на lamoda и загружать заказы из lamoda в нашу конфигурацию.
Что дает данная интеграция:
Что дает данная интеграция:
- Выгрузка всех товаров из 1С на сайт lamoda;
- Обмен заказами между 1С и площадкой lamoda;
- Передача статусов;
- Остатки и цены выгружаются автоматом
Вопрос в заголовке включает в себя неочевидную часть, ведь перед тем, как рассказывать про создание хорошей интеграции стоит определить, какую интеграцию мы считаем хорошей. А ответ на этот вопрос не однозначен.
Что такое хорошо, определяют наши ценности, а они у всех разные. Поэтому для кого-то хорошая интеграция — это та, которую написал сам, где все красиво, и нет костылей, обходящих ошибки навязанных средств. Для других — это та, которая работает на базе надежных, проверенных временем инструментах и концепциях. А для третьих — наоборот, использующая самые современные, передовые технологии и подходы. Но это все — неверный подход, потому что опирается он на мнение создателей интеграции, а смотреть надо с позиции тех, кому эта интеграция приносит ценность.
Кому же интеграция приносит ценность? В первую очередь — пользователям, которые в результате могут совместно использовать несколько систем. И им важно, чтобы интеграция работала быстро и без ошибок. А когда ошибки и случались бы, то быстро и технологично исправлялись бы, и не только в коде, но и в данных. Еще пользователям важно, чтобы интеграция была адаптивна к изменениям и развитию этих систем, чтобы ее расширение не требовало больших трудозатрат и не становилось ограничением развития, равно как и масштабирование по объемам передаваемых данных.
Обо всем этом я написал статью, опираясь на опыт 25+ лет разработки и внедрения корпоративных систем, включающий разработку собственной интеграции и использование различных вендорских платформ. Статья получилась очень большая, поэтому рассказ будет в нескольких частях с продолжением. Сегодня я начну с достаточно неожиданной темы.
Хорошая интеграция – это интеграция с хорошей админкой
Почему? Потому что именно админка определяет, насколько быстро и технологично служба поддержки может разобраться с возникшими инцидентами и устранить проблему. Так что с позиции использования и эксплуатации это логично. И, казалось бы, проектировать и реализовывать ее должны именно в этой логике.
Однако, на практике дело обстоит совсем не так — разработчики начинают с выбора технологической платформы и после этого упоенно пишут ядро. А админку делают по остаточному принципу, при этом ориентируясь на ситуацию, когда инциденты — редки и уникальны. Конечно, этому есть причины. С одной стороны, разработчики верят в свой код, который (конечно) будет работать правильно и без ошибок. А, с другой стороны, заказчик хочет сократить стоимость, поэтому тоже верит разработчикам. Ну, или делает вид, что верит, при этом имея План Б — жестко связать их SLA оперативного исправления инцидентов. Обычно такой план срабатывает плохо, — и теряет от этого, конечно, бизнес. Потому что в ситуации, когда админка только показывает ошибку, но не позволяет с ней работать, служба поддержки обращается к разработчикам для разбора инцидентов. Те разбирают инциденты вручную долго и дорого, напрямую работая с базой данных или через технические средства для прямых обращений по http или другим протоколам.
А инцидентов может быть много. Мир не стоит на месте, и интегрируемые системы регулярно развиваются и обновляются. Далеко не всегда доработки ведут опытные разработчики, знакомые с кодом, их вполне могут отдать новичкам без достаточного опыта, потому что авторы кода делают новые проекты, и, возможно, уже в другой компании. По разным причинам очередной релиз могут выпускать быстро, без полноценного тестирования.
Да и при тестировании очередное неудачное обновление с ошибкой запросто может породить вал из сотен или тысяч ошибок. Все таки тестовый контур не полноценно эмулирует реальный поток данных. Особенно, если этот поток новый и касается функционала, которого раньше не было. А ограничения целостности в сложном IT-ландшафте носят распределенный характер и изменения данных, допустимые в одной системе, могут оказаться неприемлемыми в другой, об этом мы отдельно поговорим в статье.
Также встречаются ошибки, которые проявляются только в каких-то редких ситуациях и потому сложно локализуемы. Но при этом регулярно повторяются по десятку в месяц или, что еще хуже — всплесками в сотню штук раз в полгода. Потом выясняется, например, что из-за внутренней ошибки Oracle некоторые транзакции завершаются не совсем корректно. Вполне может быть, что где-то в глубине инцидентов об этом уже несколько лет стоит баг, запланированный к устранению в будущем, а пока для этих ситуаций предлагается workaround. Другой пример, когда разработчики обнаруживают ошибку в собственном старом коде.
Поэтому хорошая интеграция — это такая, в которой админка позволяет быстро и технологично разбираться с инцидентами. Что же такая админка должна поддерживать?
При обработке сообщений
Прием сообщений не должен полностью останавливаться на первой же ошибке
Остановка потока при любой ошибке — очень плохо, так как при любой частной ошибке, вызванной, например, обработкой нового типа сообщений, мы получаем вал инцидентов и нарушение взаимодействия систем. После исправления остановленный поток будет невозможно обработать быстро, при этом среди необработанных сообщений могут быть важные и срочные изменения, совершенно не связанные с той самой частной ошибкой. В целом практика показывает, что большинство сообщений могут быть обработаны независимо друг от друга.
Необходимо контролировать последовательность обработки сообщений
Хотя в целом сообщения можно обрабатывать независимо, для для конкретной цепочки нарушение порядка часто чревато ошибками на системе-приемнике. При этом, сквозная нумерация всех сообщений и остановка всей интеграции из-за этого при первой же ошибке — недопустимо, как я уже говорил. А во многих случаях простая последовательная нумерация невозможна, потому что отправка и прием сообщений часто выполняется многопоточно.
Поэтому должны быть механизмы для связывания сообщений в цепочки с блокировкой последующих при ошибке внутри конкретной цепочки. Например, при разработке распределенного каталога товаров в такую цепочку выстраиваются все изменения и вызовы методов, связанные с одним объектом. А также все изменения цен и скидок на конкретный артикул, поскольку они часто взаимодействуют друг с другом.
Интерфейсы обработки инцидентов должны позволять обработать сообщения с нарушением последовательности или пропускать отдельные сообщения. Однако очень важно, чтобы обработка с нарушением последовательности была выведена на отдельные действия, чтобы избежать ошибок.
Надо уметь посмотреть сообщение, письмо или вызов, который будет выполняться
Я помню свой шок при работе с удаленными транзакциями Oracle в конце 90-х, когда выяснилось, что ошибочную транзакцию можно выполнить, но посмотреть ее содержание невозможно. Поэтому важно показать не только конверт сообщения, но и внутреннее его содержание в структурном виде, несмотря на обобщенный характер таких интерфейсов.
Длинный упакованный xml или json — не слишком хороший вариант. Особенно сложно, когда у нас есть несколько конвертов, а внутренние сообщения шифруются и, в том числе, потому, что их содержание не всегда должно быть доступно службе поддержки. Тут могут быть неразрешимые ситуации, когда инженер поддержки не может разобраться с ошибкой, потому что не видит содержания сообщений, а бизнес-специалист, имеющий доступ и способный провести диагностику, не использует служебный интерфейс службы поддержки.
Надо уметь запустить сообщение на обработку в системе-получателе
Это актуально, если при обработке была внутренняя ошибка в коде или данных, которую исправили. Это часто бывает при расширении протокола интеграции — новые поля обрабатываются неверно, ошибку исправляют, и после этого для исправления данных необходимо повторно обработать сообщения. Аналогично может быть нужно, если сообщения оказались чувствительны к порядку обработки, а это не предусмотрели.
Например, в систему обработки заказов вдруг приходит с сайта заказ на товар, которого нет в каталоге. При разборе оказалось, что новые заказы поступают сразу при создании на сайте, а каталог обновляется по ночам. Когда покупателям позволяли заказывать только тот товар, который есть в наличии, а для появления товара на сайте в третьей системе должны были принять его поставку, то остатки появлялись на сайте только на следующий день и товар успевал распространиться по всем системам. А когда покупателям позволили делать заказы на отсутствующий товар, в том числе новый, никто не подумал, что информация о нем может еще не дойти до других систем.
Надо уметь найти сообщение в системе-источнике и повторно его отправить
Иногда сообщения теряются по дороге. Протокол http не гарантирует ни доставку сообщений, ни получение ответа. При этом повторная отправка при отсутствии ответа чревата дублированием сообщений — ведь потерять могли именно ответ, а не само сообщение. Кроме того, цепочка передачи часто включает несколько этапов и получение ответа о доставки по всей цепочки не всегда просто. Аналогична ситуация и с другим транспортом. Поэтому при надежном транспорте предпочитают контролировать успешную постановку в очередь. Однако, если было выяснено, что сообщение пропущено и ожидаемые изменения не пришли, надо уметь найти сообщение в системе-источнике и повторно отправить:
Интерфейсы работы с инцидентами должны быть ориентированы на массовую обработку
Массовые ошибки будут всегда. И нужно уметь отбирать сообщения для обработки по тексту сообщения об ошибке и другим атрибутам, чтобы избежать ситуации отбора вручную, отслеживая только глазами в большой таблице, что нужно обработать, а что — нет.
При изменении объектов
Если передаются не просто сообщения, то для хорошей интеграции с технологичным решением проблем нужны дополнительные пункты:
Поддержка распределенных ограничений целостности
Бизнес-логика очень часто накладывает ограничения на атрибуты объектов не только в пределах одного объекта, но и в совокупности. Например, НДС в заказе зависит от категории товара и от налогового режима контрагента — покупателя или продавца. И такие ограничения важно контролировать, особенно если ошибки ведут к налоговым или другим регуляторным последствиям. В случае, если изменения происходят в рамках одной системы, контроль относительно прост: при создании заказа проверяются атрибуты товара и контрагента, а при изменении атрибутов контрагентов или товаров — что это изменение не нарушает существующих данных.
А вот если каталог товаров ведет одна система, справочник контрагентов — другая, а заказы — третья, то задача усложняется. При обработке заказа проверить атрибуты товара проблем не будет. А вот при изменении атрибутов товара или контрагента проверить заказы будет непросто. Потому что систем ведения заказов может быть много, а какие атрибуты являются значимыми — неизвестно. Можно, конечно, эмулировать двухфазную транзакцию, когда сначала во все системы посылается сообщение о намерении изменить атрибуты, и только после подтверждения всеми системами готовности к такому изменению — сообщать о нем. Но это — чрезвычайно сложный протокол. К тому же в полной реализации между подтверждением готовности к изменению и приходом новых значений система-получатель должна работать в особом режиме, обеспечивающим как принятие изменений, так и отказ от него. По сути, в этот период атрибут теряет конкретное значение, у него оказывается два варианта. И хотя я видел реализацию таких двухфазных протоколов, на практике от них больше проблем, чем пользы.
Именно поэтому в админке, с технологичным сопровождением инциденты, связанные с невозможностью принять конкретные изменения в конкретной системе, быстро, технологично диагностируются и разбираются. И принимается решение по существу: изменения могут быть отменены в основной системе, или проведены обратные изменения, или, наоборот, будет решено что такие изменения не нарушают бизнес-логику и правила проверки следует изменить:
Сверка данных
И, наконец, интеграция должна включать систему независимой сверки данных между системами в автоматическом режиме или по запросу. И хорошо, если это поддерживает админка, а не разработчик, вручную выгружающий данные из систем и сравнивающий их. Очень много ошибок, как показывает практика, связано с эффектами косвенного изменения объектов, которые не попадают в сообщения по интеграции. Например, когда изменения повешены на триггеры базы данных, и сервер приложений о них поэтому не в курсе. Поэтому важно при сверке передавать интегральные показатели, причем отражающие не только то, что попало в поток интеграции, а характеризующие множества синхронизируемых объектов в целом.
Конечно, при больших объемах независимая передача всех объектов для контроля невозможна. Однако для разбора ошибок однократная выгрузка всех объектов из обеих систем с их сверкой может оказаться вполне приемлемым решением. В случае, если их все-таки слишком много — можно проводить сверку интегральных показателей по группам объектов. Например, эффективным способом сверки часто является сравнение текстовых файлов — если их выгружать отсортированными по ключу или так, чтобы первые позиции обеспечивали текстовую сортировку. Можно пользоваться стандартным diff или его аналогами. А с некоторыми командами мы использовали такой подход не только для сортировки, но и для интеграции с legacy-системой, которая не умела выгружать изменения, в то время как по бизнес-процессам были правки документов в прошлое. Приходилось выгружать полную витрину за полтора года, а потом сортировать, сравнивать и получать ежедневную порцию изменений. И все это тянул слабенький комп под unix с помощью стандартных утилит — это было еще до эпохи облаков.
Если же по интеграции передаются вызовы процедур, изменяющие множество объектов, то результат может зависеть от состояния данных, включая обработку других сообщений, поступивших по интеграции (при том, что порядок может быть не гарантирован). Например, в одной из наших систем была передача назначения скидок, действующая на группы магазинов и товаров — интерфейс пользователя работал именно в этих категориях. И оказалось, что в системе-получателе на результат действия влияет в том числе текущее состояние классификации товаров и магазинов по группам (которое также поступало из основной системы). Поэтому последовательность обработки сообщений была очень существенной, а при ошибке вообще приходилось останавливать всю серию связанных сообщений. Переходить на низкий уровень передаче не хотелось из-за объемов информации, но работа без контроля иногда приводила к сложным ошибкам, которые было невозможно поймать. Решением стала передача в сообщении количества объектов, на которые должна подействовать скидка — сигнал об ошибке начал своевременно приходить, а так как сама ситуация была крайне редкой, ее ручной разбор не вызывал проблем.
Уведомления
Для оперативной реакции на ошибки интеграции, естественно, необходимы оперативные уведомления службе поддержки. К сожалению, ошибки интеграции часто имеют кумулятивный эффект и носят массовый характер, что часто проявляется при установке обновлений. При этом, не всегда сразу — обновления часто проносят вечером или ночью, в период минимальной нагрузки, а работа с данными, которая породит ошибки, будет на следующий день, или через день, если поток данных идет не в оперативном режиме, а по ночам. Или вообще имеет свой недельный или месячный ритм, и тогда эффект может проявиться еще более отдаленно. Поэтому чем раньше будут замечены ошибки репликаций, тем меньше придется потом исправлять в данных.
Для этого в интеграции должны быть средства для мониторинга и настройки уведомлений. Раньше для этого разрабатывали собственную систему уведомлений, а сейчас целесообразнее пользоваться стандартными средствами мониторинга, например, на основе Prometheus и Grafana. Однако, разработка системы запросов для мониторинга все равно относится к конкретной системе интеграции, потому что здесь очень важно выделить группы проблем по их критичности, чтобы обеспечить оперативную эскалацию и решение проблем. И важно учитывать, что если ошибки возникают при приеме ночного потока, то они могут блокировать нормальную работу пользователей, которые привыкли начинать рабочий день рано. В отличие от разработчиков, которые любят приходить достаточно поздно — а ведь им еще нужно время для локализации и исправления ошибок.
Продолжение следует
На этом я заканчиваю сегодняшнюю статью.
В следующий раз мы будем говорить уже про сами транзакции и их консистентность, а также про идемпотентные операции, обеспечивающие устойчивость, про обеспечение возможностей развития и некоторые другие аспекты хорошей интеграции.
На весенний и осенний сезоны 2021 года открыт прием докладов на конференции. Для 2021 года мы подготовили 14 конференций, в том числе и перенесенных с этого года. Смотрите
план
наших конференций на весь 2021 год с датами закрытия Call for Papers.
Изучайте, подбирайте конференцию для себя!
Теги: интеграция приложенийразработкаdevopsweb-разработка
Хабы: Блог компании Конференции Олега Бунина (Онтико)Анализ и проектирование системERP-системыУправление разработкойDevOps
+20
70
7
+7
Редакторский дайджест
Присылаем лучшие статьи раз в месяц
Конференции Олега Бунина (Онтико)
Профессиональные конференции для IT-разработчиков
FacebookFacebookTwitterTelegram
Архитектор и бизнес-аналитик
Комментарии 7
bks
30.12.2020 в 08:28
Огромная работа. Поставил за нее плюсы, но во многом не согласен.
Тема важная, поскольку считаю, что за интегрированными системами будущее. Времена больших ERP, где автоматизируются все функции в одной системе проходят. А если выбираешь лучшее решение отдельно для каждой функции, то интеграция должна быть действительно хорошо работающей.
Но не согласен я с подходом основанным на лечении симптомов.
Будет эффективнее находить ключевые проблемы, базовые причины проблем, которые на поверхности повседневной практики.
Например. Контрагенты, договоры, валюти и пр. — это просто таблицы в базе данных, хранящие набор признаков, которые используются в других таблицах, типа «проводки». Кстити Учетные счета — это тоже просто таблица. Если в двух системах есть таблица с функцией хранения реестра Контрагентов, то при консолидации будут проблемы. Но такие же проблемы будут с любыми другими справочными таблицами в базе данных.
Решение будет также одно. Например, мы предпочитаем урегулировать все несоответствия через таблицу «Правила соответствия» где просто указываются синонимы из разных баз и эта таблица учитывается при взаимодействии данных по алгоритмам. Но часто встречаю попытки сделать в холдингах единые справочники (по мне дак очень плохая идея).
Но больше всего в вопросах интеграции меня беспокоят закрытые базы данных. Разработчики считают что в структуре их баз прям вот ценность и делают так, что интегрироваться можно через их, зачастую очень кривое, API, без нормальной документации и с очень урезанными возможностями. Если базы открытые и могут запросами общаться друг с другом, то меньше проблем.
Когда Вы пишите вот прямо по конкретностям, но это становится учебником, который никто не читает. Для меня вопрос мега актуальный, но признаюсь честно, с третьего абзаца уже пошла диагональ.
0
Ответить
MaximTsepkov
30.12.2020 в 10:41
Спасибо за комментарий. Потому что тема важная и сложная, и такие обсуждения дают новые грани понимания.
Да, время больших ERP точно в прошлом, да и самих ERP больше нет, все решения от одного вендора (как SAP) — просто множество модулей, просто там проблемы интеграции как-то решил вендор — и не всегда хорошо. И в практической работе мы вписываемся в тот исторически сложившийся IT-ландшафт, который есть.
Он — разный, в одних ландшафтах есть централизованное ведение справочников в одной системе, в других — есть попытка для каждого справочника определить одну мастер-систему, выделив Каталог товаров отдельно, а справочник контрагентов — отдельно, в третьих — в каждой системе свои справочники. Это As Is. И еще есть разное представление о To Be, может быть идти проект внедрения MDM (Master Data Management), часто многолетний, может идти проект внедрения CRM с решением «и всех клиентов перенесем туда, это будет главная система» и так далее. То есть везде по-разному. И в чем я точно уверен — это что это разнообразие точно будет, а вопросы развития надо решать «по месту», идеальной картины — нет, и у всех решений есть свои недостатки.
Я согласен с вами, единый MDM — не слишком хорошая идея, потому что он часто становится узким горлом в развитии. Мастер-система для каждого справочника разбивается о подробности следующего уровня, в части ведения контрагентов — клиенты и контрагенты разных типов и, особенно, договора с ними, требуют разного описания в разных системах, а один может быть во многих ролях и тут начинаются проблемы с определением мастер-системы.
Главная проблема — когда из-за ограничений в одной системе один партнер (ЮЛ) зарегистрирован несколько раз, например, потому что нет балансов расчета по разным договорам, или нельзя указать несколько валют расчета по сделкам, или предполагается, что партнер не может быть одновременно покупателем и поставщиком, а при этом в другой системе то же самое ЮЛ должно быть зарегистрировано в единственном экземпляре, иначе становятся невозможными взаимные зачеты требований-обязательств или ведение лимитов по рискам. То есть рассыпаются синонимы. Клиенты и контрагенты — самое частое, я сталкивался со случаями, когда заводили дубли в справочнике валют :) И вот я не представляю, как тут написать учебник о правильной штуке?
А с базой данных вопрос очень простой. Если там — только хранилка, логика в других местах, и именно они обеспечивают согласованность, то чтобы писать напрямую в БД надо очень хорошо знать эту логику и соблюдать ограничения целостности, иначе можно с легкостью нарушить ограничения целостности и система будет неверно работать. А API при этом — да, кривое. На чтение, обычно, проще, тут мы упираемся тупо в вопросы нагрузки.
А так же в вопросы развития системы — потому что таблицы ведь не статичны, меняются, а вечную обратную совместимость поддерживать непросто. И наиболее тяжелый вопрос — когда один объект развалили на две, например, был у контрагента расчетный счет, а теперь их может быть много, при этом другим системам по-прежнему нужен один. Вот и делают промежуточные view в надежде решить проблему.
Вообще в нынешней эпохе микросервисов и множественности баз данных, в том числе в одной системе, которые вовсе не обязательно реляционные, вопрос об организации хранения становится самостоятельным и сложным.
Я тут хочу спросить, а что именно вы предлагаете? Например, для контрагентов — легче обсуждать на конкретном примере. Единую таблицу и прямой доступ к БД? Или центральную систему, в которой собраны таблицы из всех систем и есть таблица соответствия между ними? А в чем отличия этого решения от единой системы справочников?
0
Ответить
meteozond
15.02.2021 в 16:01
По контрагентам — очень хороший пример, но встают следующие вопросы:
1. Кто в таком случае должен вести справочники/правила соотвествия? Не будет ли это попыткой решить недостатки архитектуры одной системы (или архитектуры в целом) неоправданным усложнонением?
2. Кто будет отвечать за объект за разные части которого отвечают разные системы? Больше похоже на то, что это все же разные но взаимосвязанные объекты
2. Что делать если интегрируется коробочное решение, доработка которого невозможна или нежелательна? Реализовывать некую прокси, которая будет в этом ELT выполнять функцию трансформации? или полноценный ETL?
3. Какие еще есть решения кроме MDM и справочников соотвествия?
0
Ответить
MaximTsepkov
15.02.2021 в 21:05
По моему опыту, все эти вопросы решаются ситуативно. Есть некоторый парк легаси-систем, в которых исторически сложилось ведение клиентов и контрагентов, и при внедрении новой системе ставится задача — как ее вписать в сложившийся ландшафт. Ответы — различны, зависят от места системы. Иногда она объявляется мастером по ведению некоторой части справочников или даже всех, для клиентов и контрагентов так часто поступают при внедрении CRM, а не только МДМ. В других случаях она будет ведомой и получает справочники по интеграции.
Самое главное тут — прописать картину ответственности по совокупности систем. В хороших компаниях за этим следят, но в большинстве тут печалька — потому что специалисты разделены по системам, и каждый знает только про свое…
А коробку интегрируем как можем, все зависит от объема необходимого преобразований…
Я понимаю, что ответ формальный в стиле «все сложно», но реально общего решения нет.
+1
Ответить
meteozond
16.02.2021 в 10:39
Разумеется архитектору на одном решении фиксироваться не стоит, но для команд должны быть прописаны четкие правила для как минимум для 80% случаев. Если такие правила не установлены, обязательно найдутся люди, решающие свои задачи за чужой счет (и не важно «лапки» у них или они «равнее» всех). Особенно в больших холдингах. Я это вижу сплошь и рядом.
Я не верю в регламенты. Сколько не прописывай отвественность — крайним, как в поговорке становится или стрелочник или последний или вообще никто. Отвественность должна ественно проистекать из построенного процесса. Кто виноват — источник и никаких других вариантов.
Возвращаясь к моему вопросу, может быть вы дополните список, который я сформулировал для себя:
1. MDM + создание связанных сущностей типа Контрагент и Юрик со ссылкой на первого при необходимости.
2. Справочники/правила соотвествия.
3. Создание прокси-сервисов, которые как бы предоставляют стандартный интерфейс для легаси и коробочных систем.
4. Полноценное ETL решение, перенаправляющее и приобразующее сущности по необходимости на лету.
P.S. Еще не надо забывыть, что инвестируя в разработку стейкхолдер держит в голове потенциальную возможнось продавать результат в виде коробок, SaaS или PaaS. Как полностью так и покомпонентно. По-этому полностью ксатомные интеграции изнутри отдельных сервисов — на мой взгляд недопустимы.
0
Ответить
MaximTsepkov
16.02.2021 в 11:29
Я тут не очень понимаю, к решению какой именно задачи такой список вариантов? Задача ведения справочника контрагентов компании? Или любых справочных данных (НСИ)? Или задача интеграции новой системы в существующий ландшафт и определение принципов ведения справочника контрагентов/всех справочников. То есть разные пункты в моем представлении — разнозначимы, применимы для разных задач. И я не всегда понимаю, какой вы вкладываете смысл, например, в «Справочники/правила соответствия» — потому что вижу разные варианты.
Что касается инвеста в разработку — то есть заказная разработка для крупных компаний в области их сложных собственных процессов, которые заведомо обобщаются и не продаются. Тут фишка в том, что на большом масштабе деятельности возникает более глубокое разделение труда, специализация сотрудников, в том числе и при обработке особых случаев в процессах, которые в более мелких компаниях выполняются «на руках». У меня преимущественный опыт именно в этих проектах.
+1
Ответить
meteozond
16.02.2021 в 16:50
Задача — цифровизация немаленькой группы компаний. Масштаб и интенсивность деятельности — обязывают.
Имеется множество как микросервисов, так и монолитов, не считая коробок, партнерских и легаси систем. В этих системах практически нет данных, которые не нужны другим (точнее людям в других системах и сервисах). По сути все — MDM. Все данные во всех системах становятся Master (контрагенты, сотрудники, учетки, номенклатуры, документы, товары, продажи и т.д.). Естественно в этом богатстве есть данные, которые меняются реже и нуждаются в отдельном процессе заведения — одни вынесены в НСИ системы, но грань эта призрачна (этакий градиент).
Будучи пущенной на самотек такая архитектура интеграций превращается не в набор продуманных решений оправданной в каждом конкретном случае. А набор реализаций, которые на момент разработки показались самыми удобными для разработчиков. Подрядчики задачи интеграции решают по остаточному признаку — бизнес вообще это с трудом понимает. Все это усугубляется зоопарком стеков и разнородностью компетенций разработчиков. Ну и никакой админки в таких случаях для решения проблем быть не может.
Собственно в моем (возможно искаженном) понимании решение состоит в том, что бы как минимум четко зафиксировать правила взаимодействия, что бы новые интеграции происходили просто и понятно.
Варианты одного из таких правил —
Как оперировать сущностями если они отличаются в разных системах
я и предложил в предыдущем комментарии.
По второму пункту. Справочники соответствия и справочники правил соответствия — это данные о том как объекты одних систем соотносятся со справочниками других. Такое на мой взгляд допускается в том случае когда мы пытаемся сопоставить смежные области, например перечень услуг показываемый клиентам и деятельность регулируемую государством. Но никак не в контрагентах, которых в наших масштабах и так немало, а если будут еще и справочники соответствия — вообще туши свет.
Что касается третьего — вопрос продажи в конечном счете поднимается всегда. Какой бы крупной/мелкой не была организация. Лишних денег не бывает. Тем более в кризис. Чаще не целиком, а отдельными решениями — по-этому и важно строить архитектуру так, что бы любой компонент мог быть заменен. И не важно по необходимости или при продаже и развертывании в урезанном окружении. Продают конечно те системы, работа в которых характеризуется не глубиной разделения труда а его количеством. В крупных конторах работает с системой 10 человек в мелкой — 1. Это не отменяет потребность в ней для этого одного человека. Наличие же понятного интерфейса интеграции сделает линейку продуктов более привлекательной и повысит шанс что приобретая одно решение клиент будет приобретать и другие.
0
Ответить
Только полноправные пользователи могут оставлять комментарии.
Войдите
, пожалуйста.
ПОХОЖИЕ ПУБЛИКАЦИИ
Что такое хорошо, определяют наши ценности, а они у всех разные. Поэтому для кого-то хорошая интеграция — это та, которую написал сам, где все красиво, и нет костылей, обходящих ошибки навязанных средств. Для других — это та, которая работает на базе надежных, проверенных временем инструментах и концепциях. А для третьих — наоборот, использующая самые современные, передовые технологии и подходы. Но это все — неверный подход, потому что опирается он на мнение создателей интеграции, а смотреть надо с позиции тех, кому эта интеграция приносит ценность.
Кому же интеграция приносит ценность? В первую очередь — пользователям, которые в результате могут совместно использовать несколько систем. И им важно, чтобы интеграция работала быстро и без ошибок. А когда ошибки и случались бы, то быстро и технологично исправлялись бы, и не только в коде, но и в данных. Еще пользователям важно, чтобы интеграция была адаптивна к изменениям и развитию этих систем, чтобы ее расширение не требовало больших трудозатрат и не становилось ограничением развития, равно как и масштабирование по объемам передаваемых данных.
Обо всем этом я написал статью, опираясь на опыт 25+ лет разработки и внедрения корпоративных систем, включающий разработку собственной интеграции и использование различных вендорских платформ. Статья получилась очень большая, поэтому рассказ будет в нескольких частях с продолжением. Сегодня я начну с достаточно неожиданной темы.
Хорошая интеграция – это интеграция с хорошей админкой
Почему? Потому что именно админка определяет, насколько быстро и технологично служба поддержки может разобраться с возникшими инцидентами и устранить проблему. Так что с позиции использования и эксплуатации это логично. И, казалось бы, проектировать и реализовывать ее должны именно в этой логике.
Однако, на практике дело обстоит совсем не так — разработчики начинают с выбора технологической платформы и после этого упоенно пишут ядро. А админку делают по остаточному принципу, при этом ориентируясь на ситуацию, когда инциденты — редки и уникальны. Конечно, этому есть причины. С одной стороны, разработчики верят в свой код, который (конечно) будет работать правильно и без ошибок. А, с другой стороны, заказчик хочет сократить стоимость, поэтому тоже верит разработчикам. Ну, или делает вид, что верит, при этом имея План Б — жестко связать их SLA оперативного исправления инцидентов. Обычно такой план срабатывает плохо, — и теряет от этого, конечно, бизнес. Потому что в ситуации, когда админка только показывает ошибку, но не позволяет с ней работать, служба поддержки обращается к разработчикам для разбора инцидентов. Те разбирают инциденты вручную долго и дорого, напрямую работая с базой данных или через технические средства для прямых обращений по http или другим протоколам.
А инцидентов может быть много. Мир не стоит на месте, и интегрируемые системы регулярно развиваются и обновляются. Далеко не всегда доработки ведут опытные разработчики, знакомые с кодом, их вполне могут отдать новичкам без достаточного опыта, потому что авторы кода делают новые проекты, и, возможно, уже в другой компании. По разным причинам очередной релиз могут выпускать быстро, без полноценного тестирования.
Да и при тестировании очередное неудачное обновление с ошибкой запросто может породить вал из сотен или тысяч ошибок. Все таки тестовый контур не полноценно эмулирует реальный поток данных. Особенно, если этот поток новый и касается функционала, которого раньше не было. А ограничения целостности в сложном IT-ландшафте носят распределенный характер и изменения данных, допустимые в одной системе, могут оказаться неприемлемыми в другой, об этом мы отдельно поговорим в статье.
Также встречаются ошибки, которые проявляются только в каких-то редких ситуациях и потому сложно локализуемы. Но при этом регулярно повторяются по десятку в месяц или, что еще хуже — всплесками в сотню штук раз в полгода. Потом выясняется, например, что из-за внутренней ошибки Oracle некоторые транзакции завершаются не совсем корректно. Вполне может быть, что где-то в глубине инцидентов об этом уже несколько лет стоит баг, запланированный к устранению в будущем, а пока для этих ситуаций предлагается workaround. Другой пример, когда разработчики обнаруживают ошибку в собственном старом коде.
Поэтому хорошая интеграция — это такая, в которой админка позволяет быстро и технологично разбираться с инцидентами. Что же такая админка должна поддерживать?
При обработке сообщений
Прием сообщений не должен полностью останавливаться на первой же ошибке
Остановка потока при любой ошибке — очень плохо, так как при любой частной ошибке, вызванной, например, обработкой нового типа сообщений, мы получаем вал инцидентов и нарушение взаимодействия систем. После исправления остановленный поток будет невозможно обработать быстро, при этом среди необработанных сообщений могут быть важные и срочные изменения, совершенно не связанные с той самой частной ошибкой. В целом практика показывает, что большинство сообщений могут быть обработаны независимо друг от друга.
Необходимо контролировать последовательность обработки сообщений
Хотя в целом сообщения можно обрабатывать независимо, для для конкретной цепочки нарушение порядка часто чревато ошибками на системе-приемнике. При этом, сквозная нумерация всех сообщений и остановка всей интеграции из-за этого при первой же ошибке — недопустимо, как я уже говорил. А во многих случаях простая последовательная нумерация невозможна, потому что отправка и прием сообщений часто выполняется многопоточно.
Поэтому должны быть механизмы для связывания сообщений в цепочки с блокировкой последующих при ошибке внутри конкретной цепочки. Например, при разработке распределенного каталога товаров в такую цепочку выстраиваются все изменения и вызовы методов, связанные с одним объектом. А также все изменения цен и скидок на конкретный артикул, поскольку они часто взаимодействуют друг с другом.
Интерфейсы обработки инцидентов должны позволять обработать сообщения с нарушением последовательности или пропускать отдельные сообщения. Однако очень важно, чтобы обработка с нарушением последовательности была выведена на отдельные действия, чтобы избежать ошибок.
Надо уметь посмотреть сообщение, письмо или вызов, который будет выполняться
Я помню свой шок при работе с удаленными транзакциями Oracle в конце 90-х, когда выяснилось, что ошибочную транзакцию можно выполнить, но посмотреть ее содержание невозможно. Поэтому важно показать не только конверт сообщения, но и внутреннее его содержание в структурном виде, несмотря на обобщенный характер таких интерфейсов.
Длинный упакованный xml или json — не слишком хороший вариант. Особенно сложно, когда у нас есть несколько конвертов, а внутренние сообщения шифруются и, в том числе, потому, что их содержание не всегда должно быть доступно службе поддержки. Тут могут быть неразрешимые ситуации, когда инженер поддержки не может разобраться с ошибкой, потому что не видит содержания сообщений, а бизнес-специалист, имеющий доступ и способный провести диагностику, не использует служебный интерфейс службы поддержки.
Надо уметь запустить сообщение на обработку в системе-получателе
Это актуально, если при обработке была внутренняя ошибка в коде или данных, которую исправили. Это часто бывает при расширении протокола интеграции — новые поля обрабатываются неверно, ошибку исправляют, и после этого для исправления данных необходимо повторно обработать сообщения. Аналогично может быть нужно, если сообщения оказались чувствительны к порядку обработки, а это не предусмотрели.
Например, в систему обработки заказов вдруг приходит с сайта заказ на товар, которого нет в каталоге. При разборе оказалось, что новые заказы поступают сразу при создании на сайте, а каталог обновляется по ночам. Когда покупателям позволяли заказывать только тот товар, который есть в наличии, а для появления товара на сайте в третьей системе должны были принять его поставку, то остатки появлялись на сайте только на следующий день и товар успевал распространиться по всем системам. А когда покупателям позволили делать заказы на отсутствующий товар, в том числе новый, никто не подумал, что информация о нем может еще не дойти до других систем.
Надо уметь найти сообщение в системе-источнике и повторно его отправить
Иногда сообщения теряются по дороге. Протокол http не гарантирует ни доставку сообщений, ни получение ответа. При этом повторная отправка при отсутствии ответа чревата дублированием сообщений — ведь потерять могли именно ответ, а не само сообщение. Кроме того, цепочка передачи часто включает несколько этапов и получение ответа о доставки по всей цепочки не всегда просто. Аналогична ситуация и с другим транспортом. Поэтому при надежном транспорте предпочитают контролировать успешную постановку в очередь. Однако, если было выяснено, что сообщение пропущено и ожидаемые изменения не пришли, надо уметь найти сообщение в системе-источнике и повторно отправить:
Интерфейсы работы с инцидентами должны быть ориентированы на массовую обработку
Массовые ошибки будут всегда. И нужно уметь отбирать сообщения для обработки по тексту сообщения об ошибке и другим атрибутам, чтобы избежать ситуации отбора вручную, отслеживая только глазами в большой таблице, что нужно обработать, а что — нет.
При изменении объектов
Если передаются не просто сообщения, то для хорошей интеграции с технологичным решением проблем нужны дополнительные пункты:
- Желательно видеть на интерфейсе те изменения, которые сообщение вносит в существующий объект. Идеально, когда мы можем видеть также изменения предыдущих сообщений (которые его меняли) и последующих необработанных (при их наличии).
- В случае проблем полезна возможность отправить из системы-отправителя объект целиком, со всеми его атрибутами. И, конечно, принять его, проигнорировав при этом предыдущие ошибочные сообщения.
- Хороший инструмент — возможность изменить объект вручную средствами системы — возможно, с выходом в нештатный режим для объектов, правки которых запрещены, и с последующим контролем, что объект действительно получился идентичным. Контроль тут — важная часть, так как сложные ошибки иногда возникают из-за одинаковых символов с разными кодами, двойных, неразрывных или концевых пробелов и прочих деталей кодировки. При этом стоит учитывать, что интеграция, хранение и интерфейс системы могут работать в разных кодировках.
Поддержка распределенных ограничений целостности
Бизнес-логика очень часто накладывает ограничения на атрибуты объектов не только в пределах одного объекта, но и в совокупности. Например, НДС в заказе зависит от категории товара и от налогового режима контрагента — покупателя или продавца. И такие ограничения важно контролировать, особенно если ошибки ведут к налоговым или другим регуляторным последствиям. В случае, если изменения происходят в рамках одной системы, контроль относительно прост: при создании заказа проверяются атрибуты товара и контрагента, а при изменении атрибутов контрагентов или товаров — что это изменение не нарушает существующих данных.
А вот если каталог товаров ведет одна система, справочник контрагентов — другая, а заказы — третья, то задача усложняется. При обработке заказа проверить атрибуты товара проблем не будет. А вот при изменении атрибутов товара или контрагента проверить заказы будет непросто. Потому что систем ведения заказов может быть много, а какие атрибуты являются значимыми — неизвестно. Можно, конечно, эмулировать двухфазную транзакцию, когда сначала во все системы посылается сообщение о намерении изменить атрибуты, и только после подтверждения всеми системами готовности к такому изменению — сообщать о нем. Но это — чрезвычайно сложный протокол. К тому же в полной реализации между подтверждением готовности к изменению и приходом новых значений система-получатель должна работать в особом режиме, обеспечивающим как принятие изменений, так и отказ от него. По сути, в этот период атрибут теряет конкретное значение, у него оказывается два варианта. И хотя я видел реализацию таких двухфазных протоколов, на практике от них больше проблем, чем пользы.
Именно поэтому в админке, с технологичным сопровождением инциденты, связанные с невозможностью принять конкретные изменения в конкретной системе, быстро, технологично диагностируются и разбираются. И принимается решение по существу: изменения могут быть отменены в основной системе, или проведены обратные изменения, или, наоборот, будет решено что такие изменения не нарушают бизнес-логику и правила проверки следует изменить:
Сверка данных
И, наконец, интеграция должна включать систему независимой сверки данных между системами в автоматическом режиме или по запросу. И хорошо, если это поддерживает админка, а не разработчик, вручную выгружающий данные из систем и сравнивающий их. Очень много ошибок, как показывает практика, связано с эффектами косвенного изменения объектов, которые не попадают в сообщения по интеграции. Например, когда изменения повешены на триггеры базы данных, и сервер приложений о них поэтому не в курсе. Поэтому важно при сверке передавать интегральные показатели, причем отражающие не только то, что попало в поток интеграции, а характеризующие множества синхронизируемых объектов в целом.
Конечно, при больших объемах независимая передача всех объектов для контроля невозможна. Однако для разбора ошибок однократная выгрузка всех объектов из обеих систем с их сверкой может оказаться вполне приемлемым решением. В случае, если их все-таки слишком много — можно проводить сверку интегральных показателей по группам объектов. Например, эффективным способом сверки часто является сравнение текстовых файлов — если их выгружать отсортированными по ключу или так, чтобы первые позиции обеспечивали текстовую сортировку. Можно пользоваться стандартным diff или его аналогами. А с некоторыми командами мы использовали такой подход не только для сортировки, но и для интеграции с legacy-системой, которая не умела выгружать изменения, в то время как по бизнес-процессам были правки документов в прошлое. Приходилось выгружать полную витрину за полтора года, а потом сортировать, сравнивать и получать ежедневную порцию изменений. И все это тянул слабенький комп под unix с помощью стандартных утилит — это было еще до эпохи облаков.
Если же по интеграции передаются вызовы процедур, изменяющие множество объектов, то результат может зависеть от состояния данных, включая обработку других сообщений, поступивших по интеграции (при том, что порядок может быть не гарантирован). Например, в одной из наших систем была передача назначения скидок, действующая на группы магазинов и товаров — интерфейс пользователя работал именно в этих категориях. И оказалось, что в системе-получателе на результат действия влияет в том числе текущее состояние классификации товаров и магазинов по группам (которое также поступало из основной системы). Поэтому последовательность обработки сообщений была очень существенной, а при ошибке вообще приходилось останавливать всю серию связанных сообщений. Переходить на низкий уровень передаче не хотелось из-за объемов информации, но работа без контроля иногда приводила к сложным ошибкам, которые было невозможно поймать. Решением стала передача в сообщении количества объектов, на которые должна подействовать скидка — сигнал об ошибке начал своевременно приходить, а так как сама ситуация была крайне редкой, ее ручной разбор не вызывал проблем.
Уведомления
Для оперативной реакции на ошибки интеграции, естественно, необходимы оперативные уведомления службе поддержки. К сожалению, ошибки интеграции часто имеют кумулятивный эффект и носят массовый характер, что часто проявляется при установке обновлений. При этом, не всегда сразу — обновления часто проносят вечером или ночью, в период минимальной нагрузки, а работа с данными, которая породит ошибки, будет на следующий день, или через день, если поток данных идет не в оперативном режиме, а по ночам. Или вообще имеет свой недельный или месячный ритм, и тогда эффект может проявиться еще более отдаленно. Поэтому чем раньше будут замечены ошибки репликаций, тем меньше придется потом исправлять в данных.
Для этого в интеграции должны быть средства для мониторинга и настройки уведомлений. Раньше для этого разрабатывали собственную систему уведомлений, а сейчас целесообразнее пользоваться стандартными средствами мониторинга, например, на основе Prometheus и Grafana. Однако, разработка системы запросов для мониторинга все равно относится к конкретной системе интеграции, потому что здесь очень важно выделить группы проблем по их критичности, чтобы обеспечить оперативную эскалацию и решение проблем. И важно учитывать, что если ошибки возникают при приеме ночного потока, то они могут блокировать нормальную работу пользователей, которые привыкли начинать рабочий день рано. В отличие от разработчиков, которые любят приходить достаточно поздно — а ведь им еще нужно время для локализации и исправления ошибок.
Продолжение следует
На этом я заканчиваю сегодняшнюю статью.
В следующий раз мы будем говорить уже про сами транзакции и их консистентность, а также про идемпотентные операции, обеспечивающие устойчивость, про обеспечение возможностей развития и некоторые другие аспекты хорошей интеграции.
На весенний и осенний сезоны 2021 года открыт прием докладов на конференции. Для 2021 года мы подготовили 14 конференций, в том числе и перенесенных с этого года. Смотрите
план
наших конференций на весь 2021 год с датами закрытия Call for Papers.
Изучайте, подбирайте конференцию для себя!
Теги: интеграция приложенийразработкаdevopsweb-разработка
Хабы: Блог компании Конференции Олега Бунина (Онтико)Анализ и проектирование системERP-системыУправление разработкойDevOps
+20
70
7
+7
Редакторский дайджест
Присылаем лучшие статьи раз в месяц
Конференции Олега Бунина (Онтико)
Профессиональные конференции для IT-разработчиков
FacebookFacebookTwitterTelegram
18
Карма
0
Рейтинг
Максим Цепков @MaximTsepkovАрхитектор и бизнес-аналитик
Комментарии 7
bks
30.12.2020 в 08:28
Огромная работа. Поставил за нее плюсы, но во многом не согласен.
Тема важная, поскольку считаю, что за интегрированными системами будущее. Времена больших ERP, где автоматизируются все функции в одной системе проходят. А если выбираешь лучшее решение отдельно для каждой функции, то интеграция должна быть действительно хорошо работающей.
Но не согласен я с подходом основанным на лечении симптомов.
Будет эффективнее находить ключевые проблемы, базовые причины проблем, которые на поверхности повседневной практики.
Например. Контрагенты, договоры, валюти и пр. — это просто таблицы в базе данных, хранящие набор признаков, которые используются в других таблицах, типа «проводки». Кстити Учетные счета — это тоже просто таблица. Если в двух системах есть таблица с функцией хранения реестра Контрагентов, то при консолидации будут проблемы. Но такие же проблемы будут с любыми другими справочными таблицами в базе данных.
Решение будет также одно. Например, мы предпочитаем урегулировать все несоответствия через таблицу «Правила соответствия» где просто указываются синонимы из разных баз и эта таблица учитывается при взаимодействии данных по алгоритмам. Но часто встречаю попытки сделать в холдингах единые справочники (по мне дак очень плохая идея).
Но больше всего в вопросах интеграции меня беспокоят закрытые базы данных. Разработчики считают что в структуре их баз прям вот ценность и делают так, что интегрироваться можно через их, зачастую очень кривое, API, без нормальной документации и с очень урезанными возможностями. Если базы открытые и могут запросами общаться друг с другом, то меньше проблем.
Когда Вы пишите вот прямо по конкретностям, но это становится учебником, который никто не читает. Для меня вопрос мега актуальный, но признаюсь честно, с третьего абзаца уже пошла диагональ.
0
Ответить
MaximTsepkov
30.12.2020 в 10:41
Спасибо за комментарий. Потому что тема важная и сложная, и такие обсуждения дают новые грани понимания.
Да, время больших ERP точно в прошлом, да и самих ERP больше нет, все решения от одного вендора (как SAP) — просто множество модулей, просто там проблемы интеграции как-то решил вендор — и не всегда хорошо. И в практической работе мы вписываемся в тот исторически сложившийся IT-ландшафт, который есть.
Он — разный, в одних ландшафтах есть централизованное ведение справочников в одной системе, в других — есть попытка для каждого справочника определить одну мастер-систему, выделив Каталог товаров отдельно, а справочник контрагентов — отдельно, в третьих — в каждой системе свои справочники. Это As Is. И еще есть разное представление о To Be, может быть идти проект внедрения MDM (Master Data Management), часто многолетний, может идти проект внедрения CRM с решением «и всех клиентов перенесем туда, это будет главная система» и так далее. То есть везде по-разному. И в чем я точно уверен — это что это разнообразие точно будет, а вопросы развития надо решать «по месту», идеальной картины — нет, и у всех решений есть свои недостатки.
Я согласен с вами, единый MDM — не слишком хорошая идея, потому что он часто становится узким горлом в развитии. Мастер-система для каждого справочника разбивается о подробности следующего уровня, в части ведения контрагентов — клиенты и контрагенты разных типов и, особенно, договора с ними, требуют разного описания в разных системах, а один может быть во многих ролях и тут начинаются проблемы с определением мастер-системы.
Главная проблема — когда из-за ограничений в одной системе один партнер (ЮЛ) зарегистрирован несколько раз, например, потому что нет балансов расчета по разным договорам, или нельзя указать несколько валют расчета по сделкам, или предполагается, что партнер не может быть одновременно покупателем и поставщиком, а при этом в другой системе то же самое ЮЛ должно быть зарегистрировано в единственном экземпляре, иначе становятся невозможными взаимные зачеты требований-обязательств или ведение лимитов по рискам. То есть рассыпаются синонимы. Клиенты и контрагенты — самое частое, я сталкивался со случаями, когда заводили дубли в справочнике валют :) И вот я не представляю, как тут написать учебник о правильной штуке?
А с базой данных вопрос очень простой. Если там — только хранилка, логика в других местах, и именно они обеспечивают согласованность, то чтобы писать напрямую в БД надо очень хорошо знать эту логику и соблюдать ограничения целостности, иначе можно с легкостью нарушить ограничения целостности и система будет неверно работать. А API при этом — да, кривое. На чтение, обычно, проще, тут мы упираемся тупо в вопросы нагрузки.
А так же в вопросы развития системы — потому что таблицы ведь не статичны, меняются, а вечную обратную совместимость поддерживать непросто. И наиболее тяжелый вопрос — когда один объект развалили на две, например, был у контрагента расчетный счет, а теперь их может быть много, при этом другим системам по-прежнему нужен один. Вот и делают промежуточные view в надежде решить проблему.
Вообще в нынешней эпохе микросервисов и множественности баз данных, в том числе в одной системе, которые вовсе не обязательно реляционные, вопрос об организации хранения становится самостоятельным и сложным.
Я тут хочу спросить, а что именно вы предлагаете? Например, для контрагентов — легче обсуждать на конкретном примере. Единую таблицу и прямой доступ к БД? Или центральную систему, в которой собраны таблицы из всех систем и есть таблица соответствия между ними? А в чем отличия этого решения от единой системы справочников?
0
Ответить
meteozond
15.02.2021 в 16:01
По контрагентам — очень хороший пример, но встают следующие вопросы:
1. Кто в таком случае должен вести справочники/правила соотвествия? Не будет ли это попыткой решить недостатки архитектуры одной системы (или архитектуры в целом) неоправданным усложнонением?
2. Кто будет отвечать за объект за разные части которого отвечают разные системы? Больше похоже на то, что это все же разные но взаимосвязанные объекты
2. Что делать если интегрируется коробочное решение, доработка которого невозможна или нежелательна? Реализовывать некую прокси, которая будет в этом ELT выполнять функцию трансформации? или полноценный ETL?
3. Какие еще есть решения кроме MDM и справочников соотвествия?
0
Ответить
MaximTsepkov
15.02.2021 в 21:05
По моему опыту, все эти вопросы решаются ситуативно. Есть некоторый парк легаси-систем, в которых исторически сложилось ведение клиентов и контрагентов, и при внедрении новой системе ставится задача — как ее вписать в сложившийся ландшафт. Ответы — различны, зависят от места системы. Иногда она объявляется мастером по ведению некоторой части справочников или даже всех, для клиентов и контрагентов так часто поступают при внедрении CRM, а не только МДМ. В других случаях она будет ведомой и получает справочники по интеграции.
Самое главное тут — прописать картину ответственности по совокупности систем. В хороших компаниях за этим следят, но в большинстве тут печалька — потому что специалисты разделены по системам, и каждый знает только про свое…
А коробку интегрируем как можем, все зависит от объема необходимого преобразований…
Я понимаю, что ответ формальный в стиле «все сложно», но реально общего решения нет.
+1
Ответить
meteozond
16.02.2021 в 10:39
Разумеется архитектору на одном решении фиксироваться не стоит, но для команд должны быть прописаны четкие правила для как минимум для 80% случаев. Если такие правила не установлены, обязательно найдутся люди, решающие свои задачи за чужой счет (и не важно «лапки» у них или они «равнее» всех). Особенно в больших холдингах. Я это вижу сплошь и рядом.
Я не верю в регламенты. Сколько не прописывай отвественность — крайним, как в поговорке становится или стрелочник или последний или вообще никто. Отвественность должна ественно проистекать из построенного процесса. Кто виноват — источник и никаких других вариантов.
Возвращаясь к моему вопросу, может быть вы дополните список, который я сформулировал для себя:
1. MDM + создание связанных сущностей типа Контрагент и Юрик со ссылкой на первого при необходимости.
2. Справочники/правила соотвествия.
3. Создание прокси-сервисов, которые как бы предоставляют стандартный интерфейс для легаси и коробочных систем.
4. Полноценное ETL решение, перенаправляющее и приобразующее сущности по необходимости на лету.
P.S. Еще не надо забывыть, что инвестируя в разработку стейкхолдер держит в голове потенциальную возможнось продавать результат в виде коробок, SaaS или PaaS. Как полностью так и покомпонентно. По-этому полностью ксатомные интеграции изнутри отдельных сервисов — на мой взгляд недопустимы.
0
Ответить
MaximTsepkov
16.02.2021 в 11:29
Я тут не очень понимаю, к решению какой именно задачи такой список вариантов? Задача ведения справочника контрагентов компании? Или любых справочных данных (НСИ)? Или задача интеграции новой системы в существующий ландшафт и определение принципов ведения справочника контрагентов/всех справочников. То есть разные пункты в моем представлении — разнозначимы, применимы для разных задач. И я не всегда понимаю, какой вы вкладываете смысл, например, в «Справочники/правила соответствия» — потому что вижу разные варианты.
Что касается инвеста в разработку — то есть заказная разработка для крупных компаний в области их сложных собственных процессов, которые заведомо обобщаются и не продаются. Тут фишка в том, что на большом масштабе деятельности возникает более глубокое разделение труда, специализация сотрудников, в том числе и при обработке особых случаев в процессах, которые в более мелких компаниях выполняются «на руках». У меня преимущественный опыт именно в этих проектах.
+1
Ответить
meteozond
16.02.2021 в 16:50
Задача — цифровизация немаленькой группы компаний. Масштаб и интенсивность деятельности — обязывают.
Имеется множество как микросервисов, так и монолитов, не считая коробок, партнерских и легаси систем. В этих системах практически нет данных, которые не нужны другим (точнее людям в других системах и сервисах). По сути все — MDM. Все данные во всех системах становятся Master (контрагенты, сотрудники, учетки, номенклатуры, документы, товары, продажи и т.д.). Естественно в этом богатстве есть данные, которые меняются реже и нуждаются в отдельном процессе заведения — одни вынесены в НСИ системы, но грань эта призрачна (этакий градиент).
Будучи пущенной на самотек такая архитектура интеграций превращается не в набор продуманных решений оправданной в каждом конкретном случае. А набор реализаций, которые на момент разработки показались самыми удобными для разработчиков. Подрядчики задачи интеграции решают по остаточному признаку — бизнес вообще это с трудом понимает. Все это усугубляется зоопарком стеков и разнородностью компетенций разработчиков. Ну и никакой админки в таких случаях для решения проблем быть не может.
Собственно в моем (возможно искаженном) понимании решение состоит в том, что бы как минимум четко зафиксировать правила взаимодействия, что бы новые интеграции происходили просто и понятно.
Варианты одного из таких правил —
Как оперировать сущностями если они отличаются в разных системах
я и предложил в предыдущем комментарии.
По второму пункту. Справочники соответствия и справочники правил соответствия — это данные о том как объекты одних систем соотносятся со справочниками других. Такое на мой взгляд допускается в том случае когда мы пытаемся сопоставить смежные области, например перечень услуг показываемый клиентам и деятельность регулируемую государством. Но никак не в контрагентах, которых в наших масштабах и так немало, а если будут еще и справочники соответствия — вообще туши свет.
Что касается третьего — вопрос продажи в конечном счете поднимается всегда. Какой бы крупной/мелкой не была организация. Лишних денег не бывает. Тем более в кризис. Чаще не целиком, а отдельными решениями — по-этому и важно строить архитектуру так, что бы любой компонент мог быть заменен. И не важно по необходимости или при продаже и развертывании в урезанном окружении. Продают конечно те системы, работа в которых характеризуется не глубиной разделения труда а его количеством. В крупных конторах работает с системой 10 человек в мелкой — 1. Это не отменяет потребность в ней для этого одного человека. Наличие же понятного интерфейса интеграции сделает линейку продуктов более привлекательной и повысит шанс что приобретая одно решение клиент будет приобретать и другие.
0
Ответить
Только полноправные пользователи могут оставлять комментарии.
Войдите
, пожалуйста.
ПОХОЖИЕ ПУБЛИКАЦИИ
- 8 сентября 2021 в 12:58
- Эффективный DevOps
- +24
- 7.3K
- 51
- 0
- 12 августа 2021 в 13:16
- Из техлида в менеджеры продукта: чем поможет бэкграунд разработки и стоит ли переходить именно вам
- +30
- 4.9K
- 33
- 3
- +3
- 20 января 2021 в 10:38
- Как сделать хорошую интеграцию? Часть 2. Идемпотентные операции – основа устойчивой интеграции
- +23
- 6.9K
- 71
- 4
- +4
- сегодня в 02:38
- Flipper Zero — мы начали доставку
- +144
- 16K
- 39
- 36
- +36
- сегодня в 17:55
- Питон против Безумного Макса, или как я посты на Хабре замораживал
- +127
- 3.7K
- 18
- 42
- +42
- сегодня в 10:38
- Война с компилятором и собой: об оптимизациях вещественной арифметики на Эльбрусе
- +107
- 9.4K
- 28
- 37
- +37
- вчера в 23:10
- Мировая атомная энергетика в 2021 году
- +77
- 14K
- 41
- 27
- +27
- сегодня в 12:00
- Как отправить сообщение на пейджер — the hard way
Если Вы хотите интегрироваться с lamoda, то в модуле UVmarket это всё есть, Вам только нужно будет заполнить необходимые настройки и Вы уже полноценный продавец, на данном маркетплейсе. В любом случае, если покупать модуль обмена, UVmarket, то Вы получите спектр услуг по внедрению, которые не предлагает ни одна компания. Любые интернет продажи, они всегда зависят от модулей интеграции, так как если ты не успеваешь их обрабатывать, ты не в теме
Если Вы готовы интегрировать СбермегаМаркет и 1с, то я Вам поздравляю, Вы один из счастливчиков, которые могут претендовать на большие прибыли. Так ка к Если Вы интегрировали данное решение UVmarker, то Вы в любом случае, будите получать сверхприбыли и для этого Вам ничего не нужно делать, просто установить модуль и бизнес будет работать за Вас. Если Вам важно время на интеграцию и чтобы быстро решать любые процессы в бизнесе, то тут только модуль UVmarket. СберМегаМаркет работает на 3 схемах, стандартная, это витрина и доставка. закажи и забери, когда клиент заказывает товар и после он получает сам его из магазина. И когда доставка силами продавца. Когд клиент заказал и Мы как мерчант/ продавец его доставляем до конечного потребителя. Если хочется наладить бизнес с маркетлейсами, то тут только решение UVmarket. В нем возможны все интеграции, которые только возможны и даже больше. Вам остаётся только оставить свой номер и у Вас уже появится, готовый модуль который будет работать постоянно и приносить Вам прибыль. У Вас даже не будет необходимости подходить к экрану и что то анализировать, так как модуль СберМегаМаркет будет работать за Вас. Нужно просто поставить модуль интеграции и бизнес будет работать за Вас. Мы предлагаем решение по всей России, так как схема закажи и забери она актуальна очень в регионах. Поэтому модуль UVmarket: Обмен данными между 1С и СберМегаМаркет решает все вопросы, которые могут возникать при внедрении данного функционала. Если ВЫ хотите экономить на издержках и быть всегда в прибыли, то без модуля. UVmarket, будет очень сложно. Так как, всё что модуль предлагает, всё покрывает в Ваших бизнес процессах. Осталось только связаться с Владельцем сайта и модуля и прибыль у Вас в кармане. Я в принципе отношусь к интеграции, как к своего родному и очень люблю это дело. Поэтому, если будет куплен мой модуль, точно не будете удовлетворены всем внедрением.
Интеграция СберМегаМаркет