JavaScript fwdays conf: Node.js, Performance, Tests, Nuxt.js, DevTools, GraphQL | March 14
×Закрыть

1С синхронизация с магазином

Есть цель синхронизировать сайт с 1С.

Текущее решение реализует его так, что 1С напрямую лезет в БД сайта и обновляет поля или добавляет записи.

Вопрос, плохо ли такое решение ?

Смущает то, что взаимодействие идет напрямую, поэтому интересно, есть ли какие-то кейсы, где такая реаилзация может плохо отразиться на БД?

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

REST node.js. в качестве back end. обмен в формате jsone. ftp, csv, xml — вы че шутите !?? в каком веке живем ?
за 2 часа — написал на node.js обработину — которая подключается к SQL (1С таблицы) и выкидывает их в REST (вместе с картинками . . . и т д.)
к этому REST конектятся — и несколько сайтов. и терминалы для сбора данных + фотографии, и мобильные приложения для менеджеров.

Совсем недавно сделал подобную задачу для 1С 8.2 следующим образом:
0. В 1С формирую csv файл
1. После этого 1С по ftp забрасывает файл на сайт

2. Из 1С через HTTP вызываю скрипт, который, в свою очередь, парсит полученный файл.

Решение хорошее, потому что нет промежуточных импортов-экспортов, файлов и тп. А еще оно хорошее, потому что работает.
Если хочется совсем правильно делать, и используется 8ка, то можно использовать вэб-сервисы, 8ка это может, и может обращаться к чужим вэб-сервисам.
Думаю, что в этой реализации к базе сайта она лезет не своими средствами, а при помощи ком-объектов ,оле-дб, скл-дмо и тп, обычные запросы и тп...
Проблемы могут возникнуть только багами в запросах.

Я думаю, что нужно работать и не париться, наверняка есть вообще неохваченные участки деятельности.

По другим комментариям: на больших базах в 7.7 приходится делать прямые запросы к SQL, в структуре базы разобраться несложно, не очень удобно названы поля и таблицы, но это не причина не решать проблемы производительности, описание структуры есть и в 7.7 и в 8.Х. Выборки данных — несложно, а создавать документы-справочники уже сложнее. Для 8ки вполне можно обходится внутренними средствами, там запросы работают хорошо.

В вопросе отсутствует главное — какая версия 1С платформы, какая конфигурация, и приблизительно, в пару предложений, название конкретных данных которые должны отображаться (типо: Справочник.Прайс)

Так как 1С вещь весьма закрытая, то вначале нужно испробовать все законные 1Сные способы
1С-Битрикс
1С веб сервисы

1С веб расширения

и если они ну никак, тогда для разделения веба и базы делается типа такого:
заводится специальный пользователь — web-user
по COM он запускает экземпляр 1С
на 1С же написан код нужных выборок из базы
используя внешние компоненты, например для работы TCP эти выборки отдаются наружу.

(возможно, придется написать свою компоненту на Дельфи, C++, C# - это на самом деле несложно, есть и дока, и примеры в рунете)

А уж снаружи делайте на чем хотите, то что работает с этими данными и работает с web-ui.

Вариант работы с БД напрямую — весьма рисков.
Хотя, если нужно только прочесть несколько основных справочников, то сгодится.

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

P.S.
И логичнее искать ответ по 1С на какой-нить www.forum.mista.ru
Причем вопрос там этот можно и не задавать, потому что стопицот раз задавался :)

А просто покопаться.

P.P.S.
Встречаются интересные фокусы типа j1c.ru
md для 7ки читается и парсится средствами библиотеки, и она же генерирует запросы. то есть для работы сама 1С платформа не нужна. только для разработки.

Риски по использованию — на вас естественно.

Смущает то, что взаимодействие идет напрямую, поэтому интересно, есть ли какие-то кейсы, где такая реаилзация может плохо отразиться на БД?

Любая реализация может плохо отразится на чем угодно. Вопрос: надо ли это исправлять в конкретном случае?

Я вижу проблему в поддержке: Если есть кеш, то кто его будет сбрасывать? Если надо поменять схему БД сайта, надо править на стороне 1С. Если надо будет перейти с 1С на что-то другое, то все переписываем. Покрыть тестами такое, вроде, напряжно.

Если проект должен жить и активно меняться 2+ года, то

ИМХО, лучше сделать сервис (REST) по которому добавлять данные в БД сайта. И на стороне 1С написать что-то что пакует и передает данные на сайт.

Если проект однодневка, и при этом не планируется мега нагрузка, то

ИМХО, можно и так оставить или вообще натравить и сайт и 1С на одну базу (здаетсо шо к 1С можно прикруть DB2 и PostgreSQL)

ИМХО, можно и так оставить или вообще натравить и сайт и 1С на одну базу (здаетсо шо к 1С можно прикруть DB2 и PostgreSQL)

И MS SQL можно прикрутить к 1С.

Но тянуть что-то напрямую из БД 1C — очень плохая мысль.
Идентификаторы объектов в базах 1С отличаются от конфигурации к конфигурации. Можно вручную проанализировать «внутренности» необходимых таблиц (профайлер и терпение вам в помощь) и сделать распрекрасный сайт. Но при изменении конфигурации (внесения нового кода либо при обновлении) придется опять все заново переделывать.

Особенно радует то, что таблицы в БД 1С называются примерно так: «SP18212», «SequenceBoundary10486». Название полей таблиц столь же осмысленно и информативно.

Идентификаторы объектов в базах 1С отличаются от конфигурации к конфигурации
Сложно синхронизировать изменившийся GUID ? :)

Первых два-три раза — не особо...

Вопрос, плохо ли такое решение ?

Плохо. Хуже некуда. Просто ужасно. ИМХО, если взаимодействие ведется не через концептуальную модель, а через реляционную схему хранения данных, то это трындец :)

Такая реализация (если она грамотно сделана) на БД плохо не отразиться. Плохо отразится она на поддержке этой синхронизации. Если у вас что-то измениться в БД сайта или в конфигурации 1С — скорее всего вам придется править как 1С, так и сайт/БД сайта.

Логичнее выделить несколько операций и под каждую написать некое соглашение о формате передачи данных. 1С формирует пакет (неважно в каком виде — файла, сообщения или...), сайт его принимает, подтверждает принятие для 1С. В этом случае при изменениях в 1С вы правите только 1С, при изменениях сайта — только сайт. Сам формат изменятся не должен, только дополнятся.
Кроме того: описанный мною обмен легко можно сделать двухсторонним (писать что-то напрямую в БД 1С далеко не тривиальная задача, так что описанный вами вариант наверняка будет работать только в одну сторону).
Так же сайт может принимать данные не сразу, а в удобное для него время (как по расписанию, таки в моменты снижения нагрузки до определенного уровня и т.п.). Либо же наоборот, отодвигать другие запросы, до обновления БД новыми данными.

Процесс обмена информацией станет намного более управляемым и предсказуемым.

Если база 1С крутится под SQL сервером, и на другой стороне тоже SQL сервер, то можно, конечно, морочиться с репликацией, или DTS пакеты слать по расписанию, (хоть полностью поддерживать актуальное состояние удаленной базы и все что душе угодно в нее реплицировать). А если 1С крутится на DBF таблицах — это ж...

И в случае SQL, и в случае DBF — это совершенно неоправданный гемор.

Ага... А вы перечитались научной фантастики

Человек попросил совета. Я делюсь своим опытом. Реальным опытом реальных интеграций. Если вы с чем-то конкретным не согласны — я с удовольствием выслушаю вашу точку зрения, возможно почерпну из нее что-то полезное.

К чему ваша фраза выше я не понял.

Да какой реальный опыт реальных интеграций, когда речь идет о гадании откуда брать и куда писать через профайлер?

p.s.GetDBStorageStructureInfo в помощь

Вы говорите о 1С8.х. К сожалению, ничего подобного для 1С7.7 нет. А если есть («ViewDD.exe» и т.п.) — то весьма глючное и ненадежное.
Тот же опыт говорит, что в профайлер заглядывать стоит даже при использовании GetDBStorageStructureInfo.

Вы, я так понимаю, теоретик в вопросах 1С?

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

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

Нет: полагаться на профайлер чтобы понять логику работы с базой — это годится для ординарной поделки, но никак не для решения, громко называющего себя интеграция :)

p.s. Как подмечено выше, структура 1C закрытая, но не потому, что он азакрытая вообще, а как бы платите деньги — и вам ее откроют :) Разработчики 1С ведь не дураки — надурняк раскрывать технологические таинства: хотите профит-делитесь. А профайлер в данном случае — это хакерство :)

Структура 1С не закрытая. Есть файл описания метаданных (грубо говоря таблиц). С помощью конфигуратора (чтобы видеть структуру данных в нормальных обозначениямх) и файла описания структуры по странному значению поля типа SP100500 можно легко найти соответствие, делать запросы к базу напрямую, вносить изменения в базу и тп. Мы используем обращения к SQL-базе 7.7 при переносах документов/справочников, периодических элементов, определении остатков и другой вспомогательной информации. Раньше применялось обращение напрямую к базе для решения вопросов производительности. Сейчас актуальность этого дела теряется в связи с 8кой.

Речь идет не о производительности, а о интеграции. Еще точнее именно о создании документов-справочников.
Скажите, что проще/рациональней:
— городить создание документов с помощью прямых обращений к БД 1С

— написать обработку, которая будет периодически проверять каталог на наличие новых файлов или слушать очередь сообщений или (если совсем по фен-шую) — слушать TCP и создавать документы-справочники внутренними средствами 1С?

Создавать объекты сложнее напрямую, проще методами 1С. Но в сабже нет такой задачи. Там даже нет задачи про обращение к базе 1С. Сама 1С лезет в базу сайта и создает документы. Это лучше, чем проверять файлы и тп., тк меньше сущностей в процессе (файлы, права на папки, ftp и тп, модуль экспорта файлов из магазина и тп — просто не нужны при прямом доступе в базу). На практике приходилось делать обратное — переходить от обмена файлами к прямым записям в базу. Документы 1С создавала сама, если вообще чтото создавала, или при помощи вэб-сервиса, который дергала сторонняя софтина. Это что касается интеграции, про производительность я упоминал в контексте возможности доступа к базе 1С напрямую.

А вообще можно делать и так, как Вы описываете, в большинстве случаев так и делается. Главное, чтобы работало и решало бизнес-задачи.

Это лучше, чем проверять файлы и тп., тк меньше сущностей в процессе

Сталкивался с таким подходом. В результате выходит куча сильносвязаного шлако-кода. Малейшее изменение в синхронизируемых системах ведет к совершенно непредсказуемым последствиям.

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

файлы, права на папки, ftp и тп, модуль экспорта файлов из магазина и тп — просто не нужны при прямом доступе в базу

Таки потенциальный вред от потери прямого доступа в базу как бы немного пострашнее. Одно дело когда у 1С есть право послать пакет по TCP, который прочтет сайт и, если ему что-то не понравиться, просто пропустит. Совсем другое дело, когда из 1С можно напрямую писать в БД что угодно...

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

А вообще можно делать и так, как Вы описываете, в большинстве случаев так и делается.

К сожалению нет. В большинстве случаев делают так, как описываете вы. Так проще, сущностей поменьше, права настраивать не надо...

))). Дискуссия отходит от темы. Шлако-кода хватает везде, это не зависит от архитектуры решения. Из моей практики (с чем приходилось сталкиваться) 95% обмена — это файлы и тп (это умеют делать все 1Сники), 5% — прямой доступ (сложнее реализовать). Единичные случаи — вэбсервисы и тп, для этого требуется хорошая квалификация. Про TCP-пакеты, честно говоря, не слышал ни разу ).

Верю, что у Вас может быть и другая статистика. Но, думаю, опыта именно с 1С у меня все же больше.

Про опыт спорить не буду.
У меня статистика примерно такая же:
75% — обмен через файлы.
20% — прямой доступ к БД.
5% — очередь сообщений (MSMQ) или по протоколу TCP/IP.

Вэб-сервисы — так же единичные случаи.

По роду работы ко мне, как правило, приходили с уже кое-как написанной интеграцией, которую надо допилить до рабочего состояния.
Так вот половина обменов через файлы в допиле практически не нуждается (вторая половина это полный мрак, написанный студентами третьекурсниками в эпилептическом припадке. Но допилить можно, параллельно немного переписав).
В 75% прямого доступа к БД допил практически невозможен. Кроме того, кто это писал, никто там ничего понять не может. Как правило, конфигурация 1С в этом случае жестко переписана «под себя» примерно в таком же стиле. На ум приходит только одно, чувак писал это с мыслью «А пусть попробуют меня уволить».
В 25% прямого доступа БД допил вообще не нужен.Более того, достаточно много интересного можно почерпнуть из кода.

5% + единичные случаи которые делают все по фен-шую — в допиле однозначно не нуждаются.

Человеку, который создает топики подобный этому, я бы однозначно советовал начинать с обмена через файлы)))

Если интересно разобраться как работать с TCP/IP из 1С — вот вам для затравки ссылка www.forum.mista.ru/...c.php?id=433524

дальше гугл поможет =)

Ну про топикстартера: у него уже все и так работает, не нужно трогать то, что работает))).
По поводу «пусть попробуют уволить» — то же самое можно сказать про типовые конфигурации. Дело не во вредительстве, а в недостаточной квалификации. Я придерживаюсь вывода, что мировой заговор гораздо менее эффективен чем раздолбайство, воровство и непрофессионализм.

По TCP спасибо.

Прям клуб анонимных мазохистов какой-то. Особенно, MSMQ и TCP/IP (небось еще на отфонарном порту, да? :). Любите долбаться с проксями и фаерволлами? :)

Сначала надо побороться с битыми файлами, полным циклом жизни пакета (создание, архивирование, передача на ФТП, подтверждение получения, архивирование, удаление, падение скорости работы в папках с 10к файлов и т.п.) , поиском документа в 2-3к однотипных пакетов, блокировками постоянно дополняемых файлов, переодическим обрезанием устаревших данных из таких файлов и т.п. чтобы понять, что проблемы с проксями и фаерволами это полная ерунда. Нормально реализованное ожидание ответа (без «подвисания» 1С), роллбек/автоповтор при отсутствии связи (на выбор пользователя) да удобоваримое логирование работы 1С с MSMQ и TCP/IP решает все описанное выше. Чувствуете разницу?

P.S.: еще хотел бы добавить, что при прямом доступе к БД сайта из 1С достаточно хорошим решением будет использование хранимых процедур. То есть 1С не пишет данные в БД, а вызывает ХП, передавая данные как аргументы/аругмент ХП (как правило длинную строку с определенной разметкой). При изменении структуры БД сайта мы правим хранимки, а не интеграцию с 1С.

Ограничение, которым тут может стать максимальная длинна строки, очень легко обходиться с помощью разбивания строки на несколько подстрок и ХП с неопределенным количеством параметров.

P.P.S.:

Шлако-кода хватает везде, это не зависит от архитектуры решения.

msdn.microsoft.com/...us/data/ef.aspx

А вы чувствуете разницу? :)

Сначала надо побороться с битыми файлами

падение скорости работы в папках с 10к файлов

Охренеть просто. А знаете, почему у вас файлы бьются? :)

Еще раз, разговор в данном случае про 1С.

msdn.microsoft.com/...us/data/ef.aspx

тут не к месту.

Охренеть просто. А знаете, почему у вас файлы бьются? :)

У меня ничего не бьется. У меня все работает.

тут не к месту.

Садись, два

У меня ничего не бьется

Так только же ж писал, что нужно побороться с битыми файлами в папках, где их около 10000 :)

Читайте внимательно.

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

падение скорости работы в папках с 10к файлов

Не думаю, что Entity Framework поможет 1С быстрее получить список файлов в такой директории. Да и городить внешнюю компоненту для того, что можно сделать внутренними средствами 1С как-то не особо разумно. Разумно избегать ситуаций, при которых в одной директории может скопиться такое количество файлов.

Возникают они, как правило, при выгрузке пакета на ФТП

ИМХО, FTP сервер у вас работает в active mode, в связи с чем он может переоткрывать новый сокет и снова коннектится к вам. А их кол-во ограничено, и они не reusable. Используйте passive mode (это — известная проблема, можете почитать внимательно, например, wiki.filezilla-project.org/...k_Configuration раздел ActiveMode, со слов «Due to the nature of TCP...»)

Все претензии к вашему одмину :)

Не думаю, что Entity Framework поможет 1С быстрее получить список файлов в такой директории

Мы с вами говорим на разных языках. Покурите ссылку хотя-бы минут 5.

ИМХО, FTP сервер у вас работает в active mode, в связи с чем он после каждого сеанса открывает новый сокет и коннектится к вам. Используйте passive mode (это — известная проблема)

Эт не у меня на работе, это у клиентов. Их был не один десяток, и каждый приходил со своим «букетом» проблем. Да и при реальном разрыве связи mode ни на что не повлияет.

Про языки я согласен.

Да и при реальном разрыве связи mode ни на что не повлияет

А как же жили лет надцать назад, когда пакеты передавались по телефону с модемом? :) А очень просто — ничего не сыпалось в общую папку, а сначала принималось во временную, а после успешного приема — переносилось в общую папку. Конечно, при частых разрывах связи мусора было во временной папке море, но жалоб на битые пакеты кагбэ не возникало.

Подписаться на комментарии