Как написать обмен с 50 поставщиками и не сойти с ума. Теория

Управление - Интеграция

Поставщики бывают разные. Одни готовы подстроиться под наш формат - другие нет; одни обмениваются SOAPом - другие RESTом; одни работают с кодами товаров - другие с идентификаторами предложений; одни готовы отдать статус по заказу - другие нет; у одних есть справочники, элементы которых вам нужно сопоставить со своими - у других нет. В общем очень разные.

Обмен данными с поставщиками нужно автоматизировать. 21-й век на дворе. Понятно, что в идеальном мире надо созвать конференцию поставщиков и потребителей в данной отрасли (в моем случае это автозапчасти), на которой согласовать единый формат обмена информацией и всем будет счастье. У аптечников такое есть. Но мы живем в неидеальном мире.

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

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

Как написать обмен в пятидесяти форматах? Написать пятьдесят обменов? давайте предположим, что в лучшем случае обмен с одним поставщиком писать и тестировать 1 неделю и ставка программиста 3000р/час. Умножили? И это я еще про поддержку и администрирование всего этого зоопарка не вспоминал.

Есть другие варианты? Мой ответ: написать один обмен!

Мы должны придумать себе 51-го поставщика и написать обмен с ним. Это должен быть идеальный для нас, для наших процессов поставщик. Этот поставщик должен иметь общие черты всех поставщиков, отличаясь от них в деталях.

Мы должны начать мыслить не "от поставщика", а "от нас" и картина моментально упростится. У нас то бизнес-процесс один и программист тоже один и все, что выходит за рамки разумного по нашему мнению - нам не особо интересно. Понятно, что такой подход неизбежно приведет к "загрублениям" в логике и какая-то "тонкая" функциональность пойдет под нож, но такова цена простоты. Таких загрублений я насчитал три вида:

  1. Функциональность, нужная нам, но которую некоторые поставщики будут неготовы обеспечить
  2. Функциональность которую поставщики предоставляют, но она нам не нужна.
  3. Функциональность реализованная кардинально разными методами у разных поставщиков.

Придумывая своего идеального поставщика, я перелопатил документацию поставщиков к их API и выработал 4 основных метода, при помощи которых я разработал API своего идеального поставщика.

Метод 1: Обобщение

Обобщение - это основной принцип разработки какой угодно функциональности. Обмен с поставщиками не исключение.
Например, один поставщик может использовать статусы заказов "принят", "в работе", "отгружен", "отказан". Другой "в работе менеджера", "в работе на складе", "в работе транспортной компании", "закрыт успешно", "отменен". Еще у одного поставщика я видел 27 разных статусов. Серьезно, я специально их посчитал. Понятно, что в нашей системе весь этот зоопарк нам не нужен. Мы обобщим статусы до минимально необходимого нам набора: "новый", "в работе поставщика", "отгружен поставщиком", "проблема".
Далее останется просто сопоставить каждый элемент справочника каждого поставщика с элементом нашего справочника. Естественно, заказы некоторым поставщикам никогда не не получат, например, статус "проблема", потому, что у поставщика не будет соответствующего статуса.

Метод 2: Разделение

Обобщить можно не все. Иногда приходится разделять.
Например, если один поставщик принимает заказ целиком (все строки заказа в одном XML), а другой по принципу корзины интернет-магазина (добавить товар в корзину - добавить товар в корзину - заказать корзину) то написать такое каким-то "общим" образом не получится.
В этом случае обмен с нашим идеальным 51-м поставщиком таки должен разделиться. т.е. он должен опционально уметь отправлять заказ и одним и другим методом. У меня это называется "метод отправки заказа" и имеет он два варианта значения: "заказ целиком" и "построчно".
А еще есть настройка "метод проверки статуса" и он имеет уже три варианта: "запрос по заказу - возврат по заказу", "запрос по заказу - возврат построчно" и "запрос построчно - возврат построчно".
Но увлекаться разделением сильно не стоит, поскольку каждое дробление ведет к усложнению системы. И чего точно не стоит делать - это допускать древовидное разделение. Старайтесь все свести к плоским настройкам. Если дробление функциональности по одному признаку будет зависеть от дробления по другому - вы закопаетесь в настройках и вместо элегантной простоты получите ад настроек.

Метод 3: Отсечение

Метод отсечения интуитивно понятен и применяется в тех случаях, когда функциональность поставщика превосходит ту, которая необходима вам.
Например, поставщик может предоставлять возможность редактировать заказ до какого-то определенного момента (например, до передачи в набор).
Но нам это не особо интересно и все остальные поставщики такой возможности не имеют, соответственно нам нужно просто сказать, что мы не будем пользоваться такой возможностью.
Нужно четко обозначить границы автоматизации. Все что выходит за их рамки должно быть исключено из рассмотрения. Игнорируйте аргументы "это дополнительное удобство": если с остальными поставщиками можно обойтись без этого - значит и с этим можно.

Метод 4: Умолчание

Метод умолчания является обратной крайностью метода отсечения. В данном случае, проблема заключается в том, что граница автоматизации включает в себя функциональность, которую не поддерживает поставщик. Например, возврат статуса заказа. Некоторые поставщики могут этого не поддерживать.
В этом случае не стоить городить во всех последующих алгоритмах проверку на то, считать ли статус заказа актуальным или игнорировать его, потому, что поставщик не умеет его возвращать. Гораздо проще поставить "заглушку", которая будет считать такие заказы уже находящимися в последнем статусе.

Таким образом, проанализировав ваши потребности и возможности - вы можете начертить границы автоматизации. Это и будет завершением этапа проектирования API вашего идеального 51-го поставщика. Т.е., если вдаваться в технику - узлов в плане обмена все равно будет 50, по количеству реальных поставщиков, но код выгрузки/загрузки данных будет один и тот же и будет формировать XML для всех 50 поставщиков в формате 51-го поставщика.

Так получилось, что в этой статье я заострил внимание на выгрузке заказа, как на наиболее вариативной и сложной части обмена (по крайней мере у меня), но все написанное можно применять и к загрузке и к выгрузке и заказа и справочника и чего-угодно еще.

О том, как из одного обмена с идеальным поставщиком сделать 50 обменов с реальными - читайте в следующей статье.

См. также

Комментарии
1. борян петров (TODD22) 17 09.04.18 10:32 Сейчас в теме
ставка программиста 3000р/час

Можно узнать где такие щедрые ставки, в каком городе?
А то смотрел буквально час назад вакансии программистов от 350 руб до 1200 руб максимум что предлагают.
5. Константин Нагибович (gradi) 09.04.18 12:24 Сейчас в теме
(1)
Можно узнать где такие щедрые ставки, в каком городе?

В одной из компаний, где я работал, именно такой ценник выставлялся заказчику. Понятно, что до исполнителя доходила несколько иная сумма.
2. shuhard shuhard (shuhard) 09.04.18 10:36 Сейчас в теме
и ставка программиста 3000р/час

читать дальше бессмысленно
3. Валерий М (VmvLer) 09.04.18 10:50 Сейчас в теме
ни о чем, статья "попахивает" разводом или это просто неудачный пиар
4. straus (straus) 09.04.18 11:15 Сейчас в теме
ставка программиста 3000р/час

У Вас поставщики наркоту поставляют, что программист за $50 в час вам обмены пилит?
formica32; +1 Ответить
6. Геннадий Николаев (genayo) 09.04.18 12:28 Сейчас в теме
наиболее вариативной и сложной части обмана

Вы тут кого обманываете :))?
И 50 совершенно различных обменов заказами с различными поставщиками - так не бывает, с прайсами еще может быть, но не с заказами.
7. Роман Марков (m-rv) 282 09.04.18 13:09 Сейчас в теме
(6)
(6)
Вы тут кого обманываете :))

спасибо )
совершенно различных естественно не бывает, всех можно сгруппировать в 5-7 групп, внутри которых они будут довольно похожи, но все равно не станут идентичными
8. Геннадий Николаев (genayo) 09.04.18 13:22 Сейчас в теме
(7) И тут встает вопрос - а не правильнее ли сначала преобразовать 5-7 форматов в 1, и только его уже непосредственно грузить (так, кстати, поступают многие крупные компании, сами, либо через EDI - провайдеров)?
9. Александр Дмитриев (МимохожийОднако) 119 11.04.18 08:20 Сейчас в теме
Начал статью красиво...И всё...
11. Константин Н (zakidonoff) 13.04.18 07:20 Сейчас в теме
Как написать обмен с 50 поставщиками и не сойти с ума.
Метод 1: отрицание.
Метод 2: гнев.
Метод 3: торг.
Метод 4: депрессия.
Метод 5: принятие.
Diego_Iv; +1 Ответить
Оставьте свое сообщение