1С синхронизация с магазином
Есть цель синхронизировать сайт с 1С.
Текущее решение реализует его так, что 1С напрямую лезет в БД сайта и обновляет поля или добавляет записи.
Вопрос, плохо ли такое решение ?
Смущает то, что взаимодействие идет напрямую, поэтому интересно, есть ли какие-то кейсы, где такая реаилзация может плохо отразиться на БД?
36 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарівREST node.js. в качестве back end. обмен в формате jsone. ftp, csv, xml — вы че шутите !?? в каком веке живем ?
за 2 часа — написал на node.js обработину — которая подключается к SQL (1С таблицы) и выкидывает их в REST (вместе с картинками . . . и т д.)
к этому REST конектятся — и несколько сайтов. и терминалы для сбора данных + фотографии, и мобильные приложения для менеджеров.
Смешно!
Поглянь на дату попередніх коментів =D
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)
И MS SQL можно прикрутить к 1С.
Но тянуть что-то напрямую из БД 1C — очень плохая мысль.Идентификаторы объектов в базах 1С отличаются от конфигурации к конфигурации. Можно вручную проанализировать «внутренности» необходимых таблиц (профайлер и терпение вам в помощь) и сделать распрекрасный сайт. Но при изменении конфигурации (внесения нового кода либо при обновлении) придется опять все заново переделывать.
Особенно радует то, что таблицы в БД 1С называются примерно так: «SP18212», «SequenceBoundary10486». Название полей таблиц столь же осмысленно и информативно.
Первых два-три раза — не особо...
Плохо. Хуже некуда. Просто ужасно. ИМХО, если взаимодействие ведется не через концептуальную модель, а через реляционную схему хранения данных, то это трындец :)
Такая реализация (если она грамотно сделана) на БД плохо не отразиться. Плохо отразится она на поддержке этой синхронизации. Если у вас что-то измениться в БД сайта или в конфигурации 1С — скорее всего вам придется править как 1С, так и сайт/БД сайта.
Логичнее выделить несколько операций и под каждую написать некое соглашение о формате передачи данных. 1С формирует пакет (неважно в каком виде — файла, сообщения или...), сайт его принимает, подтверждает принятие для 1С. В этом случае при изменениях в 1С вы правите только 1С, при изменениях сайта — только сайт. Сам формат изменятся не должен, только дополнятся.Кроме того: описанный мною обмен легко можно сделать двухсторонним (писать что-то напрямую в БД 1С далеко не тривиальная задача, так что описанный вами вариант наверняка будет работать только в одну сторону).
Так же сайт может принимать данные не сразу, а в удобное для него время (как по расписанию, таки в моменты снижения нагрузки до определенного уровня и т.п.). Либо же наоборот, отодвигать другие запросы, до обновления БД новыми данными.
Процесс обмена информацией станет намного более управляемым и предсказуемым.
Если база 1С крутится под SQL сервером, и на другой стороне тоже SQL сервер, то можно, конечно, морочиться с репликацией, или DTS пакеты слать по расписанию, (хоть полностью поддерживать актуальное состояние удаленной базы и все что душе угодно в нее реплицировать). А если 1С крутится на DBF таблицах — это ж...
И в случае SQL, и в случае DBF — это совершенно неоправданный гемор.
Ага... А вы перечитались научной фантастики
К чему ваша фраза выше я не понял.
p.s.GetDBStorageStructureInfo в помощь
Тот же опыт говорит, что в профайлер заглядывать стоит даже при использовании GetDBStorageStructureInfo.
Вы, я так понимаю, теоретик в вопросах 1С?
Вот давайте только не будем меряться линейками, уважаемый гуру в области интеграции, щупающий запросы профайлером
Вы так это сказали, как будто пользоваться профайлером — занятие постыдное и необсуждаемое вслух в приличном обществе =)
p.s. Как подмечено выше, структура 1C закрытая, но не потому, что он азакрытая вообще, а как бы платите деньги — и вам ее откроют :) Разработчики 1С ведь не дураки — надурняк раскрывать технологические таинства: хотите профит-делитесь. А профайлер в данном случае — это хакерство :)
Структура 1С не закрытая. Есть файл описания метаданных (грубо говоря таблиц). С помощью конфигуратора (чтобы видеть структуру данных в нормальных обозначениямх) и файла описания структуры по странному значению поля типа SP100500 можно легко найти соответствие, делать запросы к базу напрямую, вносить изменения в базу и тп. Мы используем обращения к SQL-базе 7.7 при переносах документов/справочников, периодических элементов, определении остатков и другой вспомогательной информации. Раньше применялось обращение напрямую к базе для решения вопросов производительности. Сейчас актуальность этого дела теряется в связи с 8кой.
Скажите, что проще/рациональней:
— городить создание документов с помощью прямых обращений к БД 1С
— написать обработку, которая будет периодически проверять каталог на наличие новых файлов или слушать очередь сообщений или (если совсем по фен-шую) — слушать TCP и создавать документы-справочники внутренними средствами 1С?
А вообще можно делать и так, как Вы описываете, в большинстве случаев так и делается. Главное, чтобы работало и решало бизнес-задачи.
Тут выше писали «если взаимодействие ведется не через концептуальную модель, а через реляционную схему хранения данных, то это трындец». Я бы последнее слово поменял, а так хорошо сказано.
Таки потенциальный вред от потери прямого доступа в базу как бы немного пострашнее. Одно дело когда у 1С есть право послать пакет по TCP, который прочтет сайт и, если ему что-то не понравиться, просто пропустит. Совсем другое дело, когда из 1С можно напрямую писать в БД что угодно...Вообще людей, которым внапряг нормально настроить права доступа, к финансовой информации на пушечный выстрел подпускать нельзя.
К сожалению нет. В большинстве случаев делают так, как описываете вы. Так проще, сущностей поменьше, права настраивать не надо...
Верю, что у Вас может быть и другая статистика. Но, думаю, опыта именно с 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.:А вы чувствуете разницу? :)
Охренеть просто. А знаете, почему у вас файлы бьются? :)
Еще раз, разговор в данном случае про 1С.
тут не к месту.
У меня ничего не бьется. У меня все работает.
Садись, два
Так только же ж писал, что нужно побороться с битыми файлами в папках, где их около 10000 :)
Битые файлы не зря написаны отдельно от жизни пакета. Возникают они, как правило, при выгрузке пакета на ФТП. О разрывах связи программисты 1С как правило не думают.
Не думаю, что Entity Framework поможет 1С быстрее получить список файлов в такой директории. Да и городить внешнюю компоненту для того, что можно сделать внутренними средствами 1С как-то не особо разумно. Разумно избегать ситуаций, при которых в одной директории может скопиться такое количество файлов.
Все претензии к вашему одмину :)
Мы с вами говорим на разных языках. Покурите ссылку хотя-бы минут 5.
Эт не у меня на работе, это у клиентов. Их был не один десяток, и каждый приходил со своим «букетом» проблем. Да и при реальном разрыве связи mode ни на что не повлияет.
Про языки я согласен.
А как же жили лет надцать назад, когда пакеты передавались по телефону с модемом? :) А очень просто — ничего не сыпалось в общую папку, а сначала принималось во временную, а после успешного приема — переносилось в общую папку. Конечно, при частых разрывах связи мусора было во временной папке море, но жалоб на битые пакеты кагбэ не возникало.