Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 65
Прекрасно! Следующим этапом развития будет создания нормального, единого интерфейса для внешних приложений на стороне 1С и сведение всей работы com-объектов и/или web-сервисов только к нему. Чинить 100500 мест после очередного обновления структуры данных в 1С или синхронизировать реализации бизнес-логики очень быстро надоест =)
Класс, по моему отлично подходит картинка здесь: 
Если необходимо обращаться к данным базы 1С, получать их быстро, независимо от платформы (win,lin,mac), языка программирования, то решением является использование web-сервисов — встроенное для платформы 1С: Предприятие 8.2
1. Создаете необходимые функции в базе данных, выбирающие, записывающие и т.д.
2. Публикуете их через объект метаданных web-сервисы… apache, iis (под win, nix)
3. Получаете (передаете) данные из любых внешних систем.
1. Создаете необходимые функции в базе данных, выбирающие, записывающие и т.д.
2. Публикуете их через объект метаданных web-сервисы… apache, iis (под win, nix)
3. Получаете (передаете) данные из любых внешних систем.
Если не ошибаюсь, взаимодействие с веб-сервисами происходит через SOAP-интерфейс?
v8.1c.ru/overview/Term_000000273.htm
Да. А автор на городил какой то херни.
Через жопу ухо почесал.
И еще.
kb.mista.ru/article.php?id=473
Да. А автор на городил какой то херни.
Через жопу ухо почесал.
И еще.
kb.mista.ru/article.php?id=473
В чем преимущество веб-сервисов, если выгнать данные в SQL-базу не составляет труда?
Не могу точно утверждать насчет скорости, но, на мой взгляд, запрос в sqlite-базу будет на порядки быстрее, чем формирование SOAP-запроса, его обработка сервером и парсинг результата? Я специально уточнял у вас насчет SOAP, это весьма громоздкий и неудобный способ взаимодействия.
Не могу точно утверждать насчет скорости, но, на мой взгляд, запрос в sqlite-базу будет на порядки быстрее, чем формирование SOAP-запроса, его обработка сервером и парсинг результата? Я специально уточнял у вас насчет SOAP, это весьма громоздкий и неудобный способ взаимодействия.
Преимущества использования web-сервисов:
— платформенная независимость
— модульность решений
— инкапсуляция
— стабильность
Для скорости можно конечно сделать закешированную базу SQL. Но очевидно, что ваше решение это случай «заплатки» — потяни рядом, и все порвется. Это скорее пример как не нужно делать.
OLE
— платформенная независимость
— модульность решений
— инкапсуляция
— стабильность
Для скорости можно конечно сделать закешированную базу SQL. Но очевидно, что ваше решение это случай «заплатки» — потяни рядом, и все порвется. Это скорее пример как не нужно делать.
OLE
Объясните, как оно «порвется», если работает почти год без моего вмешательства? Что должно произойти, чтобы процесс сбился? Попытайтесь мыслить шире — если в документации 1С что-то написано, то еще не значит, что нужно так делать.
Неправда ваша. Закэшированная БД — правильное решение для скорости, когда не нужно напрягать 1С на каждый чих («показать список .....»).
Веб-сервисы — правильное решение для активной бизнес-логики.
Тут всё более чем просто.
Веб-сервисы — правильное решение для активной бизнес-логики.
Тут всё более чем просто.
Преимущество веб-сервисов в удобстве (вы можете вызывать функции 1С, и обратно — 1С может вызывать ваши функции) и кросс-платформенности. Сайт, разрабатываемый мной по долгу службы, именно так и работает. И других вариантов нет, если нужны активные действия 1С при некоторых действиях на сайте.
Не подумайте что я фанат веб-сервисов — они мне не очень нравятся, от них веет «энтерпрайзностью», тяжёлостью, XML, SOAP и прочим :( В современном мире это далеко не мейнстрим для сайтов.
Далее, я немного тестировал реализацию веб-сервисов 1С, опять же по работе, — на практически обычной машине что-то около 70-100 вызовов в секунду, при 4+ потоках. 100 — для совсем быстрого метода (аля пинг), 70 — для немного более нагруженного.
Но, самое главное не в этом.
Самое главное в том, что в вашем случае можно и нужно заниматься и еженощной выгрузкой.
Единственное что — у вас выгруженная база получается read-only?
В web-интерфейсе нет никакой активной логики получается?
Не подумайте что я фанат веб-сервисов — они мне не очень нравятся, от них веет «энтерпрайзностью», тяжёлостью, XML, SOAP и прочим :( В современном мире это далеко не мейнстрим для сайтов.
Далее, я немного тестировал реализацию веб-сервисов 1С, опять же по работе, — на практически обычной машине что-то около 70-100 вызовов в секунду, при 4+ потоках. 100 — для совсем быстрого метода (аля пинг), 70 — для немного более нагруженного.
Но, самое главное не в этом.
Самое главное в том, что в вашем случае можно и нужно заниматься и еженощной выгрузкой.
Единственное что — у вас выгруженная база получается read-only?
В web-интерфейсе нет никакой активной логики получается?
1) Нужно учитывать не пинг, а время, которое тратит 1С на обработку запроса. Это время зависит от того, что вы хотите получить. Например, у нас документ акта сверки формируется 3 секунды. При этом его нужно сохранить в Эксель, что невозможно без обращения к диску. Некоторые запросы требуют сложных джоинов и тоже выполняются не мгновенно. Если сразу много абонентов бросится выгружать документы, то это будет самый настоящий хабраэффект на рабочую базу.
2) Да, нужно выгружать рабочую базу. Но если скрипт уж написан, а сама выгрузка длится 5 минут и полностью автоматизирована, то что плохого в такой схеме? Выгрузил — и свободен от веб-сервисов, COM-соединений и прочей чепухи.
3) Да, я неоднократно писал, что эта база только для чтения. Показания и заявки абонентов падают в базу личного кабинета, откуда потом подгружаются в 1С, тоже ночью. Так удобней и безопасней, почему — написал чуть ниже: habrahabr.ru/blogs/python/139272/#comment_4655352
2) Да, нужно выгружать рабочую базу. Но если скрипт уж написан, а сама выгрузка длится 5 минут и полностью автоматизирована, то что плохого в такой схеме? Выгрузил — и свободен от веб-сервисов, COM-соединений и прочей чепухи.
3) Да, я неоднократно писал, что эта база только для чтения. Показания и заявки абонентов падают в базу личного кабинета, откуда потом подгружаются в 1С, тоже ночью. Так удобней и безопасней, почему — написал чуть ниже: habrahabr.ru/blogs/python/139272/#comment_4655352
Согласен что в данном случае может быть не оправдано использование именно COM, но для создания веб сервисов в 1С нужно вносить изменение в конфигурацию — а это может повлиять на стоимость её поддержки.
Ладно если 1С Ваша, то может быть можно и внести изменения. А если вы делаете приложение для 1С своих клиентов, то работа через COM соединение это по моему единственный способ получить данные из «чужой» 1С без каких либо её изменений.
Ладно если 1С Ваша, то может быть можно и внести изменения. А если вы делаете приложение для 1С своих клиентов, то работа через COM соединение это по моему единственный способ получить данные из «чужой» 1С без каких либо её изменений.
Последняя ссылка про случай «наоборот» — про вызов внешних веб-сервисов из 1С. Надо заметить, что веб-сервисы в 1С8 — штука капизная весьма: не с каждым внешним сервисом 1ска захочет работать и не каждый внешний клиент заработает с сервисом 1ски. Но всё равно, народ как-то использует, местами даже удачно.
Минусуем? Фиг статью про интеграцию навижн и 1с через получаем…
Что правда, то правда… Такое впечатление, что 1с ведет по пути усложнения и деградации, в том числе и деградации наших программистов, которые вынуждены работать с 1с, чтобы нормально зарабатывать.
Не 1c не туда идет, а бездарности с большими яйцами. Вот они то им и мешают.
Сегодня от внедрения 1С никто не застрахован, к сожалению.
Вообще говря, не совсем так. Для примера могу привести систему компоновки данных. Вот тут написано v8.1c.ru/overview/Term_000000093.htm#1
Аналоги, если они есть, стоят многие тысячи денег. Это к «усложнению».
Теперь о «деградации». Тоже весьма спорный момент. Грамотная разработка под 1С всегда требовала понимания системы более глубокого, чем даёт ЖКК. А появление управляемого интерфейса и тонких клиентов вообще потребовало перестроить подход к разработке. Он, кстати, стал весьма и весьма близок к разрабоке веб-приложений.
Аналоги, если они есть, стоят многие тысячи денег. Это к «усложнению».
Теперь о «деградации». Тоже весьма спорный момент. Грамотная разработка под 1С всегда требовала понимания системы более глубокого, чем даёт ЖКК. А появление управляемого интерфейса и тонких клиентов вообще потребовало перестроить подход к разработке. Он, кстати, стал весьма и весьма близок к разрабоке веб-приложений.
Мсье знает толк в извращениях. Собственно вариантов как подружить 1С с другими системами много:
1. Выгрузка данных из 1С регламентными заданиями — когда на сервере 1С автоматически запускается с некоторой периодичностью выгрузка данных в нужном формате (txt, xls, pdf, rtf, xml, dbf).
2. Использование прямого подключения к 1С через браузер (как недостаток — нужно лицензий по количеству одновременных подключений)
3. Прямой доступ к данным 1С — есть обработки которые показывают соответствие структуры конфигурации 1С и таблиц в SQL
Автор же выбрал то, что ему знакомо — python и сделал всё на нем. Это как лестницу лопатой — только копать долго придется.
Если нет желания разбираться в 1С или денег на внешнюю разработку — вариант автора вполне приемлем. Советовать же ему следовать — только если вы хорошо знаете python и нет возможности сделать всё на 1С.
1. Выгрузка данных из 1С регламентными заданиями — когда на сервере 1С автоматически запускается с некоторой периодичностью выгрузка данных в нужном формате (txt, xls, pdf, rtf, xml, dbf).
2. Использование прямого подключения к 1С через браузер (как недостаток — нужно лицензий по количеству одновременных подключений)
3. Прямой доступ к данным 1С — есть обработки которые показывают соответствие структуры конфигурации 1С и таблиц в SQL
Автор же выбрал то, что ему знакомо — python и сделал всё на нем. Это как лестницу лопатой — только копать долго придется.
Если нет желания разбираться в 1С или денег на внешнюю разработку — вариант автора вполне приемлем. Советовать же ему следовать — только если вы хорошо знаете python и нет возможности сделать всё на 1С.
1. Выгрузка != оперативная работа с данными. Так же вы рискуете изобрести велосипед в виде обработки этих данных, если нужно так же как в 1С. Не говорим о том, что такая схема не годится для онлайн режима взаимодействия с.
2. Автоматизировать работу через браузер — надеюсь имеются ввиду веб-сервисы — иначе это уже тянет на большее извращение нежели com-соединение =)
3. Прямым доступом в базу вы убиваете весь предпроцессинг данных не говоря уже о рисках создать конфликтные состояния данных. Не нужно прыгать через бизнес-логику, нужно с ней взаимодействовать.
Вариант автора ничем не уникален и вполне нормальное решение, а работать с com-объектами можно хоть из vbscript: синтаксис другой, результат тот же =)
2. Автоматизировать работу через браузер — надеюсь имеются ввиду веб-сервисы — иначе это уже тянет на большее извращение нежели com-соединение =)
3. Прямым доступом в базу вы убиваете весь предпроцессинг данных не говоря уже о рисках создать конфликтные состояния данных. Не нужно прыгать через бизнес-логику, нужно с ней взаимодействовать.
Вариант автора ничем не уникален и вполне нормальное решение, а работать с com-объектами можно хоть из vbscript: синтаксис другой, результат тот же =)
Вы вообще статью читали?
1) Какая разница, кто выгружает данные, сама 1С или скрипт через COM-соединение? Можно реализовать и так, и так. Вариант со скриптом кажется удобнее.
2) Браво, ну подключусь я через браузер, увижу список абонентов. Как мне с этими данными работать?
3) Минусы этого подхода были описаны в статье.
1) Какая разница, кто выгружает данные, сама 1С или скрипт через COM-соединение? Можно реализовать и так, и так. Вариант со скриптом кажется удобнее.
2) Браво, ну подключусь я через браузер, увижу список абонентов. Как мне с этими данными работать?
3) Минусы этого подхода были описаны в статье.
Статью читал. Внимательно.
1. Вариант со скриптом работает для машин под Windows. Вариант с регламентным заданием работает под любым сервером Windows/Linux.
2. Прямо из 1С можно реализовать работу пользователей. Ну т.е. модно посмотреть demo-ma.1c.ru/ это работа браузера в виде тонкого клиента для 1С.
Собственно вопрос в том, что вы не разбираясь в 1С ведёте обсуждение в стиле — не читал, но осуждаю.
1. Вариант со скриптом работает для машин под Windows. Вариант с регламентным заданием работает под любым сервером Windows/Linux.
2. Прямо из 1С можно реализовать работу пользователей. Ну т.е. модно посмотреть demo-ma.1c.ru/ это работа браузера в виде тонкого клиента для 1С.
Собственно вопрос в том, что вы не разбираясь в 1С ведёте обсуждение в стиле — не читал, но осуждаю.
Пункт 2 вообще не в кассу. Я настраивал доступ через браузер для пользователей. Речь о том, как работать с данными 1С программно.
А вы пробовали открывать ссылки по приведённому адресу или v8.1c.ru/demo-ma?
Зачем настраивать и делать велик, если платформа позволяет это делать без извратов?
Тут оправдание, только если вы знаете питон и не плохо знакомы с платформой.
Зачем настраивать и делать велик, если платформа позволяет это делать без извратов?
Тут оправдание, только если вы знаете питон и не плохо знакомы с платформой.
> Процесс установки соединения с 1С в зависимости от конфигурации может занять от 1 до 8 секунд (в моем случае — 6 секунд). Стоит ли говорить, что установка соединения на каждый запрос приведет к тому, то каждая страница будет загружаться 8 секунд.
Правильно, потому что для этого скорее всего запусается отдельный процесс 1С, он как-то инициализируется, Неужели не очевидно, что надо сделать Питон-демона, который постоянно держит COM-объект и отвечает на запросы извне.
А копировать информацию в отдельную базу — вы получаете не совсем актуальные сведения. Впрочем, плюсом является то, что если так как вы копируете информацию по расписанию, то перегруженный веб-сервер не сможет положить 1с, что является плюсом.
Вообще, статья интересная. Как хорошо, что мне с этим проприетарным ужасом работать не приходится.
Правильно, потому что для этого скорее всего запусается отдельный процесс 1С, он как-то инициализируется, Неужели не очевидно, что надо сделать Питон-демона, который постоянно держит COM-объект и отвечает на запросы извне.
А копировать информацию в отдельную базу — вы получаете не совсем актуальные сведения. Впрочем, плюсом является то, что если так как вы копируете информацию по расписанию, то перегруженный веб-сервер не сможет положить 1с, что является плюсом.
Вообще, статья интересная. Как хорошо, что мне с этим проприетарным ужасом работать не приходится.
Полностью поддерживаю egorinsk, жаль не могу голосовать пока еще. Конечно же демон, имеющий постоянное соединение, и также поддерживаю использование web services.
Я же писал, что соединение можно хранить как глобальную переменную (в питон-приложении), и тогда задержки не будет. И указал минусы — зависимость от COM-соединения, ограничение его пропускной способности, потеря кроссплатформености. Читайте, пожалуйста, внимательнее.
Демона можно реализовать не на стороне Python, а там где развернута 1С, причем писать его можно на чем угодно, он как посредник, а запросы к нему реализовывать можно как душе угодно, и делать эти запросы кроссплатформенными. Ограничение пропускной способности COM соединения, для ваших задач несущественно, мизерно я бы сказал, время межпроцессного взаимодействия посредством маршалинга, только для того чтобы получить набор данных очень мизерно.
Надо писать весь код выборки данных в 1С, оформлять ее как экспортную процедуру и вызывать по средствам COM из демона, потери производительности на трансляцию (использование IDisapach как дуального интерфейса, с вызовом его метода GetIDsOfNames) каждого метода 1С используемого не на его стороне еще меньше.
Надо писать весь код выборки данных в 1С, оформлять ее как экспортную процедуру и вызывать по средствам COM из демона, потери производительности на трансляцию (использование IDisapach как дуального интерфейса, с вызовом его метода GetIDsOfNames) каждого метода 1С используемого не на его стороне еще меньше.
еще раз отмечу, демон и 1С вместе на одной платформе в связке, но запросы к демону можно реализовать кросс платформенными.
и на одной машине, конечно
И еще, посмотрите внимательно, о чем писал в том числе egorinsk- об актуальности!!!!!!, и в том числе и это побудило меня к нему присоединиться. Какую бы вы в итоге не выбрали технологию взаимодействия с 1С, я сторонник того, чтобы это было в режиме актуальных данных, а не их синхронизации, поскольку очень много может породить проблем неактуальные данные.
Вы представляете 400 тысяч наших далеко не радостных абонентов, со всеми вытекающими из этого последствиями. И добавлю, недокументированные способы интеграции с 1С, например обращение напрямую к данным MSQL тоже чревато, при обновлении платформы все соглашения по именованию таблиц могут резко измениться.
Вы представляете 400 тысяч наших далеко не радостных абонентов, со всеми вытекающими из этого последствиями. И добавлю, недокументированные способы интеграции с 1С, например обращение напрямую к данным MSQL тоже чревато, при обновлении платформы все соглашения по именованию таблиц могут резко измениться.
К сожалению, вы и другие комментаторы не учитываете множество мелочей, которые не видны в проектировании и вылезают в продакшене.
Полный реалтайм на самом деле не нужен. Абоненты платят, как правило, в начале месяца, а расчет происходит в первой неделе следующего. Показания приборов тоже снимаются раз в месяц примерно в одно и то же время. Поэтому по большей части в течении месяца состояние лицевого счета не меняется, задержка в один день тут роли не играет. Достаточно просто уведомить абонента о расчете на день позже, чтобы данные успели подгрузиться.
По поводу COM-соединения — вы не подумали о том, что постоянное соединение с рабочей базой не безапасно? Вдруг в личном кабинете найдется дыра, и хакер сможет уронить сервер 1С? Вдруг хакер напишет бота, который будет слать запрос на страницу со сложным запросом? А если понадобится перезагрузить 1С-сервер или поставить обновление, то личный кабинет и все платежные системы будут недоступны.
Еще вы не учли, что на сервере формируется отчетность. Когда расчетчики собирают отчеты по всей базе, с ней просто нереально работать, скорость COM-соединения снижается раз в 10.
Полный реалтайм на самом деле не нужен. Абоненты платят, как правило, в начале месяца, а расчет происходит в первой неделе следующего. Показания приборов тоже снимаются раз в месяц примерно в одно и то же время. Поэтому по большей части в течении месяца состояние лицевого счета не меняется, задержка в один день тут роли не играет. Достаточно просто уведомить абонента о расчете на день позже, чтобы данные успели подгрузиться.
По поводу COM-соединения — вы не подумали о том, что постоянное соединение с рабочей базой не безапасно? Вдруг в личном кабинете найдется дыра, и хакер сможет уронить сервер 1С? Вдруг хакер напишет бота, который будет слать запрос на страницу со сложным запросом? А если понадобится перезагрузить 1С-сервер или поставить обновление, то личный кабинет и все платежные системы будут недоступны.
Еще вы не учли, что на сервере формируется отчетность. Когда расчетчики собирают отчеты по всей базе, с ней просто нереально работать, скорость COM-соединения снижается раз в 10.
И кстати, по тому же принципу работает личный кабинет MocЭнергоСбыта. У них хоть не 1С, но данные выгружаются в специальную базу для личного кабинета, никакого реалтайма. Данные от абонентов тоже загружаются раз в сутки. Я знаю это, потому что смотрел вебинар конторы, которая им делала личный кабинет.
ну если реалтайм не нужен, то причем тут термин интеграция с 1С, тогда просто называйте вещи своими именами, «мой экспорт данных из 1С для моей web морды». Интеграция предполагает взаимодействие в реальном времени, да еще в идеале взаимное, все остальное это экспорт и импорт данных. В конце концов тут предлагаются альтернативы, ничего не навязывается.
Когда я подключаюсь к 1С из вне скриптом и заставляю ее выполнять нужные мне действия (выгрузка данных, формирование печатных форм, проведение документов), то разве это не интеграция?
Интеграция нескольких систем подразумевает обмен сообщениям между ним и исполнение при этом каждой системы основных своих функций. В вашем же случае происходит дублирование части функции одной системы другой (сбор данных которые уже существуют в 1С, по сути их кэширование). Это тоже можно назвать своеобразной интеграцией, но все же не классической, где каждая система имеет свою основную функцию, в вашем случае 1С как система где сконцентрирована вся бизнес логика и там происходит обработка данных, а ваша надстройка организует к ним доступ во вне.
Получается любое межпроцессное взаимодействие через COM по вашему обречено и дело тут не в 1С, а в технологии в целом, и проблема которую вы описываете с соединением по COM, ее можно адресовать к OS Windows (диспетчеризации потоков). И быть может в вашем случае это действительно критично.
Но я за то, что если существуют технологии взаимодействия, пусть например COM, SOAP, которые официально поддерживает 1С то их и нужно использовать, а если они не эффективны в той или иной реализации, то нужно менять систему 1С, зачем такие гибриды строить.
Получается любое межпроцессное взаимодействие через COM по вашему обречено и дело тут не в 1С, а в технологии в целом, и проблема которую вы описываете с соединением по COM, ее можно адресовать к OS Windows (диспетчеризации потоков). И быть может в вашем случае это действительно критично.
Но я за то, что если существуют технологии взаимодействия, пусть например COM, SOAP, которые официально поддерживает 1С то их и нужно использовать, а если они не эффективны в той или иной реализации, то нужно менять систему 1С, зачем такие гибриды строить.
Я понимаю вас, что вы поставлены в уже существующие условия, и вы на правильном пути и я вас поддерживаю.
Получается любое межпроцессное взаимодействие через COM по вашему обречено
Не то чтобы обречено, но менее прозрачно и устойчиво. Требуется продумывать слишком большое количество условий.
В целом, конечно, вы правы, мой подход — это кэширование для быстрого и стабильного доступа. А ситуация с 1С в моей организации зависит не от меня, я бы уж лучше согласился дорабатывать старую систему на Дельфи.
Помнится под 1С 7.7 писал сам TCP/IP сервер в виде внешней компоненты. В 1 8.х есть отличный вариант использовать MS winsock activex компоненту. Вот пример nastroy-ka.ru/system1c/121--tcpip-udp.html
А уж к TCP/IP серверу можно цепляться практически из любого языка программирования. Попробуйте.
А уж к TCP/IP серверу можно цепляться практически из любого языка программирования. Попробуйте.
В управляемых формах ActiveX не работает. Есть аналогичный метод через .Net Framework для управляемых форм:
Многопоточный веб-сервер для 1С: Предприятие средствами .Net Framework
Многопоточный веб-сервер для 1С: Предприятие средствами .Net Framework
Статья получилась в целом не про 1С вовсе, а про умение работать на python с COM. Полезное, хотя и специфическое. Замечание один: идеологически правильнее было оформить функции (или, если угодно, методы) для получения данных внутри самой конфигурации 1С, да и работать оно будет быстрее. Это делается несложно, причём, при правильном подходе не вызывает трудностей при обновлении конфигурации. А запускать запросы и, тем более, создавать объекты данных непосредственно через COM — это лучше оставить для каких-то разовых задач. Замечание два: с некоторых пор структура таблиц в БД тайной не является — в языке есть средства, позволяющие узнать, какие таблицы к каким объектам относятся. Вполне разумным решением может стать написание некоторого числа view/хранимых процедур для чтения данных непосредственно из СУБД. Только писать в базу таким образом лучше ничего не надо: есть шанс порушить базу. Естественно, такой вариант не подходит для файлового варианта базы. Самое главное замечание: замените слово «функционал» на «функциональность», или «программная логика», или что-то в этом роде.
Спасибо, попробую реализовать прямое чтение из MS SQL-базы.
Есть штука такая — enterprise integrator (ссылок не даю во избежание, всё гуглится) — это сторонняя разработка на платформе 1С8. В частности, она позволяет не только посмотреть, в каких таблицах хранятся объекты, но и делать трассировку запрсов 1С и получение их трансляции на языке SQL в контексте сервера БД. Конечно, всё это можно сделать и штатными средствами, но в Ei всё уже сделано до нас.
У нас задача по интеграции с 1с — выкручивание разнообразных отчетов. Ночью мы проводим выгрузки во второстепенную бд данных в удобном для построения отчетов виде. Актуальность данных на вчера вполне устраивает.
Плюсы нашего решения — работает гораздо быстрее, чем если бы было реализовано в 1с (за счет выгрузки данных в нужной форме), не напрягает 1ску при выкручивании отчетов.
>каждый, кто просматривал базу 1С на SQL-сервере, видел, что в массе таблиц вида aaa1, aaa2 разобраться трудно.
1Cv7.DDS — моя настольная «книга» :) Для восьмерки наверное что-то тоже подобное должно быть
>А строить запросы с такими названиями таблиц и полей просто нереально.
Вполне себе реально, особенно если учесть что с этим разбираться нужно только при настройке выгрузки нового вида данных
>являются виртуальными и разбросаны по разным физическим таблицам, собираясь множественными джоинами.
Собираем)
Плюсы нашего решения — работает гораздо быстрее, чем если бы было реализовано в 1с (за счет выгрузки данных в нужной форме), не напрягает 1ску при выкручивании отчетов.
>каждый, кто просматривал базу 1С на SQL-сервере, видел, что в массе таблиц вида aaa1, aaa2 разобраться трудно.
1Cv7.DDS — моя настольная «книга» :) Для восьмерки наверное что-то тоже подобное должно быть
>А строить запросы с такими названиями таблиц и полей просто нереально.
Вполне себе реально, особенно если учесть что с этим разбираться нужно только при настройке выгрузки нового вида данных
>являются виртуальными и разбросаны по разным физическим таблицам, собираясь множественными джоинами.
Собираем)
Для .Net Framework есть технология обращения через LINQ:
Необычно-экономное использование 1С: Предприятие 8 на Asp.Net-хостинге
Необычно-экономное использование 1С: Предприятие 8 на Asp.Net-хостинге
В 1с есть специальная вещь для интеграции — веб сервисы. и они предпочтительнее с точки зрения
безопасности (подключаемая программа может сделать только то, что нужно),
скорости (не тратится время на создание сом объекта),
расширяемости (разнесение по разным серверам веб части и сервера 1с, что, кстати, и к безопасности добавляет, возможность по нормальному использовать возможности кластера серверов 1с),
гибкости (не зависит от ОС)
формализации (строгое определение формата через WSDL, что позволяет, кстати, потом отказаться от 1с, или от веб части малой кровью — описание протокола взаимодействия уже есть, надо просто его реализовать)
возможностям (намного проще, например, организовать двусторонний онлайн обмен)
Всякие же интеграции через COM или прямое соединение к БД (что, кстати, не так сложно, как почему-то все думают) или их гибрид (с динамическим получением структуры таблиц хранения через COM раз в сколько-то времени и прямое выкачивание данных) — имеют право на существование, например для построения OLAP кубов или получения консолидированных отчетов из нескольких баз 1с, но только не для онлайн интеграции с сайтом. Это мое мнение как специалиста по 1с, другие специалисты могут иметь другое мнение.
безопасности (подключаемая программа может сделать только то, что нужно),
скорости (не тратится время на создание сом объекта),
расширяемости (разнесение по разным серверам веб части и сервера 1с, что, кстати, и к безопасности добавляет, возможность по нормальному использовать возможности кластера серверов 1с),
гибкости (не зависит от ОС)
формализации (строгое определение формата через WSDL, что позволяет, кстати, потом отказаться от 1с, или от веб части малой кровью — описание протокола взаимодействия уже есть, надо просто его реализовать)
возможностям (намного проще, например, организовать двусторонний онлайн обмен)
Всякие же интеграции через COM или прямое соединение к БД (что, кстати, не так сложно, как почему-то все думают) или их гибрид (с динамическим получением структуры таблиц хранения через COM раз в сколько-то времени и прямое выкачивание данных) — имеют право на существование, например для построения OLAP кубов или получения консолидированных отчетов из нескольких баз 1с, но только не для онлайн интеграции с сайтом. Это мое мнение как специалиста по 1с, другие специалисты могут иметь другое мнение.
Не будем лукавить, если скажем, что веб-сервисы в 1С — штука капризная весьма (вроде я это уже говорил?), и поработать с ними «нахрапом» не получится. Кроме того, реализация их такова, что многие «нормальные» (как они думают) программисты, столкнувшись с необходимостью реализации веб-сервиса в 1С, помучившись, плюнут и будут делать более другими способами.
Ну у меня работает как раз онлайн запрос расчета цены из 1с на сайте, ну и онлайн остатки и прочее — чтобы на кассе и на сайте данные и алгоритмы были одинаковые и не надо было хотелки маркетологов отдельно на сайте реализовывать и отдельно в 1с…
А на тему того, что сложно реализовывать… ну никто документацию читать не любит…
А на тему того, что сложно реализовывать… ну никто документацию читать не любит…
Статья интересная. Но меня интересует такой момент: все больше внимания 1С уделяет Linux. И, соответственно, все больше Linux-компьютеров в будущем будут работать c 1C. И с этой точки зрения COM-доступ, описанный здесь, не будет работать. Какая альтернатива доступа к 1С извне, такая же гибкая как COM, но вместе с тем универсально подходит для Windows/Linux?
Альтернатива COM есть. Например, обработка 1С сама выгружает данные в DBF, а питоний скрипт грузит его в Джангу. Все это ночью по крону.
Видите ли — предложенный вами подход не универсальный и предполагает доработку конфигурации 1С. COM-подход же намного гибче. Например, все экспортные процедуры/функции будут автоматически доступны через COM. Т.е. в случае с COM с большей вероятностью не нужно вмешиваться в конфигурацию 1С.
Почему? Пишется внешняя обработка. На крон ставится запуск 1С и запуск этой обработки. Конфигурацию править не нужно. Внутри обработки доступны все функции и модули.
Я согласен, что это один из вариантов — обходных путей. Но COM/OLE предусматривает получение данных по требованию. Например, известно много случаев, когда данные 1С берутся динамически из Asp.Net-сайтов (интернет-магазинов). Или в конвертации данных при выгрузке можно было подключиться по OLE к удаленной информационной базе и отправить данные, тем самым избежав явной операции загрузки данных. В случае с Linux отсутствие COM/OLE приведет к уменьшению функциональности.
Еще один момент остался неясным. Автор скорее всего работал с давно спроектированным приложением 1С, которое работало как неуправляемое приложение. Начиная с 8.2 появился «тонкий» клиент и будет появляться все больше конфигураций для управляемых приложений.
Есть ли вообще возможность подключения по COM к управляемому приложению, например к тому же demo-ma.1c.ru/ удаленно? И если есть, то какие ограничения накладываются на такие подключения по сравнению с подключением к «толстому» клиенту?
Есть ли вообще возможность подключения по COM к управляемому приложению, например к тому же demo-ma.1c.ru/ удаленно? И если есть, то какие ограничения накладываются на такие подключения по сравнению с подключением к «толстому» клиенту?
Вы немного путаете.
COM-подключение осуществляется к серверу 1С. А серверу все равно, как работает конфигурация. Подключение осуществляется к любой конфигурации, независимо от того, под какой режим она написана.
Да, речь в статье шла о конфе, которая работает в обычном режиме. Но я успешно подключаюсь и к тем конфигурациям, которые проектировались для управляемого режима, например, конфигурация Докоборот.
А тонкий клиент — это просто способ отдать данные клиенту с медленным соединением, отношения к статье он не имеет.
COM-подключение осуществляется к серверу 1С. А серверу все равно, как работает конфигурация. Подключение осуществляется к любой конфигурации, независимо от того, под какой режим она написана.
Да, речь в статье шла о конфе, которая работает в обычном режиме. Но я успешно подключаюсь и к тем конфигурациям, которые проектировались для управляемого режима, например, конфигурация Докоборот.
А тонкий клиент — это просто способ отдать данные клиенту с медленным соединением, отношения к статье он не имеет.
Не совсем понятно. По КОМ я могу обратиться не только к серверу 1С, но также к 1С, работающей в файловом режиме. Я установил 8.3 и в реестре у меня появились 2 ссылки
HKEY_CLASSES_ROOT\V83.Application
HKEY_CLASSES_ROOT\V83C.Application
1) Значит ли это, что по COM я будут подключаться к неуправляемому приложению по V83.Application, а к управляемому приложению по V83C.Application? При этом функционал в V83C.Application будет намного урезанным — соответствовать функциям тонкого клиента?
2) Могу ли я установив только тонкий клиент под Windows через V83C.Application обратиться к удаленной базе, например, demo-ma.1c.ru?
HKEY_CLASSES_ROOT\V83.Application
HKEY_CLASSES_ROOT\V83C.Application
1) Значит ли это, что по COM я будут подключаться к неуправляемому приложению по V83.Application, а к управляемому приложению по V83C.Application? При этом функционал в V83C.Application будет намного урезанным — соответствовать функциям тонкого клиента?
2) Могу ли я установив только тонкий клиент под Windows через V83C.Application обратиться к удаленной базе, например, demo-ma.1c.ru?
Немного не так выразился.
COM — это одно из возможных типов соединения.
Подключаться к 1С можно несколькими способами: толстый клиент, тонкий клиент, веб-клиент, внешнее соединение (т.е. COM).
1) Неважно, под какой режим заточена конфигурация. В COM-соединении вы будете иметь доступ ко всем справочникам, документам и т.д. но формы и функции для интеракивной работы будут недоступны. Можно подключаться конфе, работающей как в обычном, так и управляемом режиме.
2) Кажется, нет. Для COM нужно толстое соединение.
COM — это одно из возможных типов соединения.
Подключаться к 1С можно несколькими способами: толстый клиент, тонкий клиент, веб-клиент, внешнее соединение (т.е. COM).
1) Неважно, под какой режим заточена конфигурация. В COM-соединении вы будете иметь доступ ко всем справочникам, документам и т.д. но формы и функции для интеракивной работы будут недоступны. Можно подключаться конфе, работающей как в обычном, так и управляемом режиме.
2) Кажется, нет. Для COM нужно толстое соединение.
Хотя, кажется, на пункт 2 вру. В инете пишут, что можно. Завтра на работе проверю.
В Интернете прочитал, что действительно есть разделение и можно удаленно коннектиться. Для тонкого клиента будет примерно такой код:
Чтобы появилась запись в реестре для «V82c.Application» нужно выполнить:
Соответственно для тонкого клиента весь функционал урезан.
ОбъектПодключения = "V82c.Application";
ТекCOMОбъект = Новый COMОбъект(ОбъектПодключения);
СтрокаПодключения = "ws=""http://192.168.xxx.xxx/TradeTest"";Usr=""Администратор"";Pwd=""Pass"";";
ТекCOMОбъект.Connect(СтрокаПодключения);
ТекCOMОбъект.Visible = Ложь;
Чтобы появилась запись в реестре для «V82c.Application» нужно выполнить:
C:\Program Files\1cv82\8.2.xx.xx\bin\1cv8c.exe /RegServerСоответственно для тонкого клиента весь функционал урезан.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Моя интеграция с 1С