Обмен данными с поставщиками нужно автоматизировать. 21-й век на дворе. Понятно, что в идеальном мире надо созвать конференцию поставщиков и потребителей в данной отрасли (в моем случае это автозапчасти), на которой согласовать единый формат обмена информацией и всем будет счастье. У аптечников такое есть. Но мы живем в неидеальном мире.
В этой статье мы начнем тему архитектуры мультиформатного обмена данными, в основном я приведу методику анализа и проектирования. Во второй статье мы подойдем ближе к вопросу технической реализации.
Изначальная идея у всех одна: поставщик готов отдать вам элементы своих справочников и готов принять от вас заказ. Но у всех поставщиков бизнес-процессы имеют свои особенности и это накладывает на API поставщиков разные начальные требования, а разные программисты, их реализующие, доводят картину до того, что у разных обменов нет общих черт, кроме изначальной идеи.
Как написать обмен в пятидесяти форматах? Написать пятьдесят обменов? давайте предположим, что в лучшем случае обмен с одним поставщиком писать и тестировать 1 неделю и ставка программиста 3000р/час. Умножили? И это я еще про поддержку и администрирование всего этого зоопарка не вспоминал.
Есть другие варианты? Мой ответ: написать один обмен!
Мы должны придумать себе 51-го поставщика и написать обмен с ним. Это должен быть идеальный для нас, для наших процессов поставщик. Этот поставщик должен иметь общие черты всех поставщиков, отличаясь от них в деталях.
Мы должны начать мыслить не "от поставщика", а "от нас" и картина моментально упростится. У нас то бизнес-процесс один и программист тоже один и все, что выходит за рамки разумного по нашему мнению - нам не особо интересно. Понятно, что такой подход неизбежно приведет к "загрублениям" в логике и какая-то "тонкая" функциональность пойдет под нож, но такова цена простоты. Таких загрублений я насчитал три вида:
- Функциональность, нужная нам, но которую некоторые поставщики будут неготовы обеспечить
- Функциональность которую поставщики предоставляют, но она нам не нужна.
- Функциональность реализованная кардинально разными методами у разных поставщиков.
Придумывая своего идеального поставщика, я перелопатил документацию поставщиков к их API и выработал 4 основных метода, при помощи которых я разработал API своего идеального поставщика.
Метод 1: Обобщение
Обобщение - это основной принцип разработки какой угодно функциональности. Обмен с поставщиками не исключение.
Например, один поставщик может использовать статусы заказов "принят", "в работе", "отгружен", "отказан". Другой "в работе менеджера", "в работе на складе", "в работе транспортной компании", "закрыт успешно", "отменен". Еще у одного поставщика я видел 27 разных статусов. Серьезно, я специально их посчитал. Понятно, что в нашей системе весь этот зоопарк нам не нужен. Мы обобщим статусы до минимально необходимого нам набора: "новый", "в работе поставщика", "отгружен поставщиком", "проблема".
Далее останется просто сопоставить каждый элемент справочника каждого поставщика с элементом нашего справочника. Естественно, заказы некоторым поставщикам никогда не не получат, например, статус "проблема", потому, что у поставщика не будет соответствующего статуса.
Метод 2: Разделение
Обобщить можно не все. Иногда приходится разделять.
Например, если один поставщик принимает заказ целиком (все строки заказа в одном XML), а другой по принципу корзины интернет-магазина (добавить товар в корзину - добавить товар в корзину - заказать корзину) то написать такое каким-то "общим" образом не получится.
В этом случае обмен с нашим идеальным 51-м поставщиком таки должен разделиться. т.е. он должен опционально уметь отправлять заказ и одним и другим методом. У меня это называется "метод отправки заказа" и имеет он два варианта значения: "заказ целиком" и "построчно".
А еще есть настройка "метод проверки статуса" и он имеет уже три варианта: "запрос по заказу - возврат по заказу", "запрос по заказу - возврат построчно" и "запрос построчно - возврат построчно".
Но увлекаться разделением сильно не стоит, поскольку каждое дробление ведет к усложнению системы. И чего точно не стоит делать - это допускать древовидное разделение. Старайтесь все свести к плоским настройкам. Если дробление функциональности по одному признаку будет зависеть от дробления по другому - вы закопаетесь в настройках и вместо элегантной простоты получите ад настроек.
Метод 3: Отсечение
Метод отсечения интуитивно понятен и применяется в тех случаях, когда функциональность поставщика превосходит ту, которая необходима вам.
Например, поставщик может предоставлять возможность редактировать заказ до какого-то определенного момента (например, до передачи в набор).
Но нам это не особо интересно и все остальные поставщики такой возможности не имеют, соответственно нам нужно просто сказать, что мы не будем пользоваться такой возможностью.
Нужно четко обозначить границы автоматизации. Все что выходит за их рамки должно быть исключено из рассмотрения. Игнорируйте аргументы "это дополнительное удобство": если с остальными поставщиками можно обойтись без этого - значит и с этим можно.
Метод 4: Умолчание
Метод умолчания является обратной крайностью метода отсечения. В данном случае, проблема заключается в том, что граница автоматизации включает в себя функциональность, которую не поддерживает поставщик. Например, возврат статуса заказа. Некоторые поставщики могут этого не поддерживать.
В этом случае не стоить городить во всех последующих алгоритмах проверку на то, считать ли статус заказа актуальным или игнорировать его, потому, что поставщик не умеет его возвращать. Гораздо проще поставить "заглушку", которая будет считать такие заказы уже находящимися в последнем статусе.
Таким образом, проанализировав ваши потребности и возможности - вы можете начертить границы автоматизации. Это и будет завершением этапа проектирования API вашего идеального 51-го поставщика. Т.е., если вдаваться в технику - узлов в плане обмена все равно будет 50, по количеству реальных поставщиков, но код выгрузки/загрузки данных будет один и тот же и будет формировать XML для всех 50 поставщиков в формате 51-го поставщика.
Так получилось, что в этой статье я заострил внимание на выгрузке заказа, как на наиболее вариативной и сложной части обмена (по крайней мере у меня), но все написанное можно применять и к загрузке и к выгрузке и заказа и справочника и чего-угодно еще.
О том, как из одного обмена с идеальным поставщиком сделать 50 обменов с реальными - читайте в следующей статье.
