про http-сервисы согласен, это сейчас самый вменяемый вариант из коробки. но 1с:шина и odata - это же всё равно требует, чтобы на стороне 1с кто-то нормально опубликовал и поддерживал, а вот тут обычно и начинается «у нас доработанная конфигурация»

Важно, чтобы данные в обмене соответствовали единому формату. Это проблема тех, кто дорабатывал.

У меня ощущение, что поставленная задача интеграции WMS и 1С в реальном времени поставлена по принципу «на слабо». В учете практически нет задач с требованием реального времени. Если нет темы по BI или управленческих дашбордов, то даже актуальность на час рассматриваться как прорыв оперативности. Механизм регламентных заданий в 1С почти норма для обменных операций. Например, мы при всех онлайнах сделали фоновые синхронизации в ночь для актуализации данных.

Так что если вы сформулируете конкретную задачу интеграции, я мог бы вам помочь с выбором и метода.

да, про «на слабо» в точку - часто бизнес просто не может объяснить, зачем ему реальное время, и по инерции просит «чтоб сразу». у нас тоже в итоге сошлись на регламентных заданиях раз в 15 минут, и никто не умер

не нытьё, а конкретика - xml раз в час это когда данные нужны в реальном времени, а тебе говорят «ну подождите до следующего часа». и ладно бы просто xml, так ещё и структура плавает от релиза к релизу

Может проблема не в 1С? 😁

ну может и не только в 1с, но когда тебе говорят «мы выгружаем xml раз в час и это нормально» - сложно не списать на платформу

Списать на платформу невозможно, если учитывать то, что периодичность выгрузки можно задать хоть раз в секунду. Там нет ограничений. Ограничения диктуются только здравым смыслом и возможностями железа.

На самом деле в 1С есть возможность отправки инфы в JSON и даже свой REST API

да всё подряд - склад, crm, внутренний сервис учёта. каждый раз новый зоопарк форматов и транспортов, отсюда и вопрос про универсальный подход

Универсальный это работать через стэк базу данных. А для чего Вам вообще интеграции? Какая цель?

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

Вас вводят в заблуждкние. Интегрировал (как РП) как раз внешний WMS с 1С через http-сервис и json. Работает в регионом реальном времени.

а как решили вопрос с тем, что wms ожидает ответ за секунды, а 1с иногда задумывается на постинг? просто интересно, там таймауты на стороне wms выставляли или 1с реально стабильно отвечает

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

Чуть сложнее способ (мы его проектировали, но в итоге не понадобился) это асинхронный обмен. 1С это умеет, но нужен программист, который в этом хорошо разбирается. Там вопросы блокировок и производительности.

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

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

про типовые регистры мысль здравая, но на практике «правильно сформировать массив» упирается в то, что на стороне 1с кто-то обязательно допилит конфигурацию между релизами и парсер ломается молча - узнаёшь об этом по факту, когда данные уже уехали

Системный регистры никто не трогает. Они заполняются автоматически в регламентных операциях. Того, кто трогает их, надо сразу на вылет

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

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

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

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

Самый честный и полезный комментарий по поводу доработок 1с и интеграции с ним)))

Дааааа, в таких легаси системах проблем бывает очень много. Поэтому проще подстроиться под легаси, чем воевать с ним. (:

вот именно что подстроиться - это и есть тот самый «нормальный путь», который на деле оказывается ещё одним слоем адаптации под чужие доработки. хочется-таки чего-то, где ты не зависишь от того, как 1сник вчера переименовал регистр

Как бы выше писал - только не использовать 1С. ((:

На самом деле не всё так плохо. Когда профессиональный 1С, то просто договориться о правилах и работать. Например, часто делаю промежуточный шлюз, где в виде API отдаю или получаю данные. И как уже там в 1С разгребают их - не моего ума дело.

желание загнать всë в 1С - порочное, вообще говоря За финансовую информацию точно могу это сказать. Никто не обязывал учëтные регистры хранить в одном месте.

Дык, люди они такие. Есть возможность - будем всё делать в одном месте и тем инструментом, который есть сейчас. ((:

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

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

Вот, а остальное это учить использовать TDD, DDD, Чистую архитектуру. (;

Ооо, мобильное приложение их посмотри)))

а бухгалтеры, Игорь, - это такие люди, но в квадрате ;)

Что поделать, у них свой подход к жизни. Сам регулярно сталкиваюсь при интеграции и каждый раз уникальный попадается. ((:

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

Программисты точно такие же в этом вопросе, да и многие люди. ((: Делают себе всякие ИИ и знать не ведают, чем живёт простой человек. ((:

это так Я по молодости питал иллюзию, что уж программисту объясню, что и зачем делать. Сам, во-первых, кодил в школе и универе. Алгоритмы могу написать внятно и прочее. Ан нет. Скорее, исключение, чем правило: быть на одной волне.

Особенности общения и развития Человека они такие. Поэтому и друзей сложно бывает найти, а команду для работы бывае ищут дольше жены. ((:

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