Пользователь
0,0
рейтинг
2 марта 2012 в 15:02

Разработка → Моя интеграция с 1С

Привет Хабравчанам!

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

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


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

Для начала обрисую данные, с которыми будем работать. Организация — энергосбытовая компания в дальневосточном регионе — обслуживает приблизительно 400 тыс. абонентов, база 1С на самописной конфигурации. Для каждого абонента хранятся его платежи, начисления, потребляемые услуги и схемы расчета, приборы учета, показания и множество других данных.

Когда-то в организации стояла программа, написанная на Дельфи и использующая в качестве БД MSSQL/Firebird. В те славные времена можно было подключиться к базе с помощью любого языка и совершить множество действий — выбрать абонентов-должников, разнести поступившие оплаты, зафиксировать показания приборов. Неудивительно, что коллекция скриптов, автоматизирующих рутину, постоянно росла. Программисты могли выполнять любые действия, не открывая саму программу.

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

Основные задачи, стоявшие передо мной — это возможность быстрого получения данных по конкретному лицевому счету — ФИО, адрес, приборы учета, показания приборов, платежи, начисления. Плюс формирование документов — акта сверки, платежной квитанции. Итак, возможность прямого соединения с БД отсутствует — каждый, кто просматривал базу 1С на SQL-сервере, видел, что в массе таблиц вида aaa1, aaa2 разобраться трудно. А строить запросы с такими названиями таблиц и полей просто нереально. К тому же, многие таблицы 1С (особенно самые важные, вроде среза последних, остатков и оборотов) являются виртуальными и разбросаны по разным физическим таблицам, собираясь множественными джоинами. Это способ не подходит.

Платфома 1С предоставляет возможность соединяться с ней через COM-соединение. Подобно многим windows-программам, во время установки 1С в системе регистрируются два COM-объекта — Automation Server и COM Connector. С обоими объектами можно работать, используя язык, в котором предусмотрена поддержка COM-технологии.

Объект Automation Server — это приложение 1С, почти ничем не отличающееся от обычного клиентского приложения. Разница в том, что дополнительно появляется возможность программного управления экземпляром приложения. При работе с объектом COM Connector запускается облегченный вариант 1С-приложения, в котором недоступны формы, а так же функции и методы, имеющие отношение к интерфейсу и визуальным эффектам. Само приложение запускается в режиме «Внешнее соединение». Инициализация глобальных переменных (например, определение текущего пользователя и его настроек) должна выполняться в модуле внешнего соединения 1С. Если в режиме внешнего соединения в коде будет вызвана функция, не доступная в этом режиме, то будет вызвано исключение (которое будет передано в наш питон-скрипт). Вызов небезопасных функций следует обрамлять конструкциями вида

#Если НЕ ВнешнееСоединение Тогда
Предупреждение("Привет!");
#КонецЕсли


Поскольку работа с COM-объектами — технология исключительно windows-only, то не удивительно, что в стандартной поставке Питона она отсутствует. Потребуется установить расширение Win32 — набор модулей, предоставляющих весь нужный функционал для программирования под Windows на Питоне. Его можно скачать в виде уже собранного exe-установщика. Само расширение предоставляет доступ к реестру, службам, ODBC, COM-объектам и т.д. В качестве альтернативы можно сразу поставить дистрибутив ActiveState Python, в котором расширение Win32 поставляется из коробки.

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

— COM-соединение работает медленно. Низкая производительность — известный минус COM-технологии.
— Процесс установки соединения с 1С в зависимости от конфигурации может занять от 1 до 8 секунд (в моем случае — 6 секунд). Стоит ли говорить, что установка соединения на каждый запрос приведет к тому, то каждая страница будет загружаться 8 секунд.
— Поскольку веб-приложения на питоне работают как самостоятельные сервера, то предыдущий пункт можно компенсировать хранением соединения в некоторой глобальной переменной и в случае ошибки восстанавливать его. Как поддерживать соединение на PHP, я, честно говоря, еще не думал.
— Теряется кроссплатформенность веб-приложения.

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

Стратегия действий состоит в следующем: питон-скрипт соединяется с 1С, выполняет нужные запросы и выгружает данные в SQLite базу. К этой базе можно подключиться из Питона, PHP, Джавы. Большинство наших проектов работает на питоне, и так как я не выношу писать сырые SQL-запросы руками, то вся работа с базой SQLite выполняется через ORM SQLAlchemy. Потребовалось лишь описать структуру данных базы декларативном стиле:

from sqlalchemy.ext.declarative import declarative_base
from sqlalchemy import Column, Integer, Numeric, DateTime, Unicode, Boolean, LargeBinary, ForeignKey

Base = declarative_base()
class Abonent(Base):
    __tablename__ = "abonents"

    id = Column(Integer, primary_key=True)
    account = Column(Unicode(32), index=True)
    code = Column(Unicode(32))
    address = Column(Unicode(512))
    fio = Column(Unicode(256))
    source = Column(Unicode(16))
    psu = Column(Unicode(256))
    tso = Column(Unicode(256))
    np = Column(Unicode(256))
    street = Column(Unicode(256))
    house = Column(Integer)
    flat = Column(Integer)
    mro = Column(Unicode(256))

class Payment(Base):
    __tablename__ = "payments"

    # и так далее...


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

Предвижу ваш вопрос — «а почему SQLite»? Главная причина — база нужна только для чтения, поэтому проблемы с записью в SQLite нас волновать не должны. Во-вторых, формат этой этой СУБД удобен — ее удобнее просматривать (существуем множество бесплатных утилит, в том числе супер-расширение для FireFox). В-третьих, в некоторых случаях требовалось получить доступ к абонентам с тех машин, на которых нет соединения с MySQL-сервером. В таком случае достаточно скопировать файл SQLite-базы, и на этой машине будет доступ ко всей информации.

Выгрузка происходит раз в сутки ночью. Занесение данных в 1С можно автоматизировать таким же образом. Например, требуется фиксировать показания, оставленные абонентами на сайте личного кабинета. В этом случае опять соединяемся с 1С и программным методом создаем и проводим документ «Акт снятия показаний». Код я приведу чуть ниже.

Работа с COM-объектами в Питоне немного необычна. Во-первых, утрачивается «питоничность» кода — правила именования переменных и функций в 1С, мягко говоря, не соответствуют Дзену Питона. Во-вторых, всем известно, что объекты 1С зачастую именуются кириллическими символами, что вызовет проблемы при разработке на Питоне… но они решаемы. Предлагаю ознакомиться с кодом:

import pythoncom
import win32com.client

V82_CONN_STRING = "Srvr=v8_server;Ref=v8_db;Usr=username;Pwd=megapass;"

pythoncom.CoInitialize()
V82 = win32com.client.Dispatch("V82.COMConnector").Connect(V82_CONN_STRING)


Как видно из кода, инициализируется клиент для работы с 1С. Определение COM-объекта происходит по имени «V82.COMConnector». Обратите внимание, что это название справедливо для платформы V8.2, если у вас версия 8.1, то имя будет «V81.COMConnector».

У инициализированного клиента мы вызываем метод Сonnect(), передавая ему строку подключения. Строка складывается из имени сервера, базы, пользователя и пароля. Полученный объект V82 хранит в себе соединение с приложением 1С. У него нет метода Disconnect() или чего-то в этом роде. Чтобы отключиться о базы, достаточно удалить объект из памяти функцией del() или присвоить переменной None.

Имея объект, можно обращаться к любым полям и методам глобального контекста 1С, оперировать универсальными объеками типа ТабличныйДокумент, ТаблицаЗначений и тд. Важно учесть, что при работе через COM-соединение 1С работает в режиме «Внешнее соединение». В нем недоступны любые функции для интерактивной работы, например, всплывающие диалоги, уведомления, и, что самое главное, формы. Уверен, что вы не раз проклянете разработчиков конфигурации, которые заключают самый важный функционал в процедуру Кнопка1Нажатие() в модуле формы документа.

Давайте поговорим о такой важдной вещи, как киррилические атрибуты. Не смотря на то, что 1С — двуязычная среда и для каждого русского метода есть англоязычный аналог, рано или поздно потребуется обратиться к киррилическому атрибуту. Если на языках PHP или VBSCript это не вызовет никаких проблем,

Set Con = CreateObject("v81.COMConnector")
Set v8 =Con.Connect("строкаПодключения")
Set СчетаМенеджер = v8.Документы.Счета
....
Set СчетаЗапись= СчетаМенеджер.СоздатьЭлемент()
СчетаЗапись.Контрагент = ....
....
СчетаЗапись.Записать()


то код на питоне просто вылетит с ошибкой Syntax Error. Что же делать? Править конфигурацию? Нет, достаточно воспользоваться методами getattr и setattr. Передавая в эти функции COM-объект и кириллическое имя аттрибута, можно соответственно получать и устанавливать значения:

#coding=cp1251

catalog = getattr(V82.Catalogs, "ЛицевыеСчета")


Важно следующее: имена реквизитов, а так же параметры функций и методов должны передаваться в кодировке cp1251. Поэтому, чтобы заранее избежать путиницы с кодировками, имеет смысл объявить ее в начале файла: #coding=cp1251. После этого можно передавать строки, не волнуясь об их кодировке. Но! Все строки, полученные из 1С (результаты вызова функций, запросов), будут в кодировке UTF-8.

Пример кода, который выполняет в среде 1С запрос, перебирает результат и сохраняет в SQLite базу:

#coding=cp1251

    q = '''
ВЫБРАТЬ
	ЛицевыеСчета.Код КАК code,
	ЛицевыеСчета.Строение.НаселенныйПункт.Наименование + ", " + ЛицевыеСчета.КраткийАдрес КАК address,
	ЛицевыеСчета.Абонент.Наименование КАК fio,
	ЛицевыеСчета.Дивизион.Наименование КАК psu,
	ВЫРАЗИТЬ(ХарактеристикиЛицевыеСчетаСрезПоследних.Значение КАК Справочник.ТерриториальноСетевыеОрганизации).Наименование КАК tso,
	ЛицевыеСчета.Строение.НаселенныйПункт.Наименование КАК np,
	ЛицевыеСчета.Строение.Улица.Наименование КАК street,
	ЛицевыеСчета.Строение.Дом КАК house,
	ЛицевыеСчета.ОсновноеПомещение.НомерПомещения КАК flat,
    ЛицевыеСчета.Дивизион.Родитель.Наименование КАК mro
ИЗ
	Справочник.ЛицевыеСчета КАК ЛицевыеСчета
		ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ХарактеристикиЛицевыеСчета.СрезПоследних(, ВидХарактеристики = ЗНАЧЕНИЕ(Справочник.ВидыХарактеристик.ТерриториальноСетеваяОрганизация)) КАК ХарактеристикиЛицевыеСчетаСрезПоследних
		ПО ЛицевыеСчета.Ссылка = ХарактеристикиЛицевыеСчетаСрезПоследних.Объект
'''
    query = V82.NewObject("Query", q)
    selection = query.Execute().Choose()

    CONN = db.connect()
    CONN.query(models.Abonent).delete()

    while selection.Next():
        abonent = models.Abonent()

        abonent.account = selection.code.strip()
        abonent.code = selection.code
        abonent.fio = selection.fio
        abonent.address = selection.address
        abonent.psu = selection.psu
        abonent.tso = selection.tso
        abonent.source = u"ASRN"
        abonent.np = selection.np
        abonent.street = selection.street
        abonent.house = selection.house
        abonent.flat = selection.flat
        abonent.mro = selection.mro

        CONN.add(abonent)

   CONN.commit()


Здесь CONN — это сессия соединения с SQLite-базой. Создается объект запроса query, заполняется его текст. Как было замечено выше, текст запроса должен быть в cp1251, для чего вначале объявлена кодировка. После выполнения запроса в базе удаляются все абоненты, чтобы не добавить дубли, затем добавляются в цикле и следует финальный комит.

При работе с запросами я выявил следующие правила.

— Выбирая поля, назначайте им названия латиницей, будет гораздо удобнее обращаться к ним через селектор (точку), вместо getattr().
— Выбирайте только примитиные типы данных: строки, числа, дату и булево. Никогда не выбирайте ссылки на объект (документ, справочник)! В данном контексте ссылки вам абсолютно не нужны и даже вредны, потому что любое обращение к реквизиту или методу ссылки приведет к запросу через COM-соединение. Если обращаться к атрибутам ссылки в цикле, то это будет крайне медленно.
— Если вы выбираете поле типа Дата, то оно буде возвращено как объект PyTime. Это специальный тип данных для передачи даты-времени в COM-соединении. С ним не так удобно работать, как с привычным datetime. Если передать этот объект в int(), то вернется timestamp, из которого потом можно получить datetime методом fromtimestamp().

Теперь рассмотрим, как формируются печатные документы. Дело в том, что потребителю нужно предоставлять возможность скачивать заранее подготовленные документы, например, платежную квитанцию или акт сверки. Эти документы формируются в 1С в соответствии установленным требованиям, их реализация на Питоне займет много времени. Поэтому лучше сгенерировать документы в 1С и сохранять их в формат Excel.

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

link = getattr(V82.Catalogs, "ОтчетыСистемы").FindByDescription("Акт Сверки Элэн")
nav_url =  V82.GetURL(link, "Отчет")
name =  V82.ExternalReports.Connect(nav_url)
ExternalReport =  V82.ExternalReports.Create(name)

setattr(ExternalReport, "ЛицевойСчет", reference)
table_doc = ExternalReport.GetDoc()
path =  V82.GetTempFileName("xls")
table_doc.Write(path,  V82 .SpreadsheetDocumentFileType.XLS)

report = models.Report()
report.account = reference.Code.strip()
report.type = u"act"
report.document = open(path, "rb").read()

CONN.add(report)


В приведенном фрагменте выполняется следующее. Подключается обработка, формирующая документ. Обработка может быть встроена в конфигурацию, храниться на диске или в базе данных 1С (в каком-то справочнике). Поскольку обработки часто меняются, то, чтобы каждый раз не обновлять конфигурацию, самые часто меняющиеся обработки хранятся в справочнике «ОтчетыСистемы», в реквизите типа «хранилище значения» с именем Отчет. Обработку можно инициализировать, выгрузив ее из базы на диск и подгрузив, либо методом GetURL(), в который нужно передать ссылку на элемент справочника и имя реквизита. Полученному объекту обработки мы назначаем значения реквизитов, вызываем экспортируемую функцию GetDoc(), получаем табличный документ, который сохраняется во временный Excel-файл. Содержимое этого файла записывается в SQlite-базу.

Последнее, что остается рассмотреть — это программное занесение данных в 1С. Предположим, что требуется занести показания от абонентов. Для этого достаточно создать и провести документ «Акт снятия показаний»:

#coding=cp1251

acts = getattr(V82.Documents, "АктСнятияПоказаний")
act = acts.CreateDocument()

setattr(act, "Показание", 1024.23)
setattr(act, "Абонент", "Иванов")

# Заполнение прочих реквизитов...

act.Write()


Теперь занесение данных автоматизированно.

Итак, я изложил способ, который основан на программной выгрузке и загрузке даных с использованием COM-соединния. Этот метод успешно функционирует в моей организации почти год. База, формируемая из 1С, обслуживает 3 платежные системы, интернет-эквайринг (оплата картами через интернет), а так же личный кабинет. Помимо этого, к базе подключаются различные скрипты для автоматизации рутины.

Несмотря на недостатки метода (медленная скорость COM-соединения), в целом он функционирует стабильно. У нас есть данные в платформонезависимом виде (SQLite), с которыми можно работать из любого языка. И основная часть кода написана на Питоне, а значит, доступны множество средств и приемов, о которых даже нельзя мечтать в 1С.

Это один из возможных способов взаимодейстия с 1С. Я уверен, что он не нов и наверняка уже был кем-то опробован, оптимизирован. Однако, я постарался изложить максимум деталей процесса, чтобы уберечь вас от подводных камней, на которые сам наступал.

Желаю всем удачи, и помните, что не так страшен 1С, как его малюют!
Иван Гришаев @igrishaev
карма
99,0
рейтинг 0,0
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (65)

  • +3
    Прекрасно! Следующим этапом развития будет создания нормального, единого интерфейса для внешних приложений на стороне 1С и сведение всей работы com-объектов и/или web-сервисов только к нему. Чинить 100500 мест после очередного обновления структуры данных в 1С или синхронизировать реализации бизнес-логики очень быстро надоест =)
  • +9
    Класс, по моему отлично подходит картинка здесь: image
    • –1
      не подходит…

      1С: Предприятие 8.2 — запускается:

      — серверная часть win, lin ( rpm, deb)
      — клиентская часть win, а через web везде
      — конфигуратор и «толстый клиент» под виндой, но ожидаю, что тенденция сохраниться, и это будет под lin.

  • 0
    Если необходимо обращаться к данным базы 1С, получать их быстро, независимо от платформы (win,lin,mac), языка программирования, то решением является использование web-сервисов — встроенное для платформы 1С: Предприятие 8.2

    1. Создаете необходимые функции в базе данных, выбирающие, записывающие и т.д.
    2. Публикуете их через объект метаданных web-сервисы… apache, iis (под win, nix)
    3. Получаете (передаете) данные из любых внешних систем.

    • 0
      Если не ошибаюсь, взаимодействие с веб-сервисами происходит через SOAP-интерфейс?
      • +2
        v8.1c.ru/overview/Term_000000273.htm

        Да. А автор на городил какой то херни.

        Через жопу ухо почесал.

        И еще.

        kb.mista.ru/article.php?id=473
        • +2
          В чем преимущество веб-сервисов, если выгнать данные в SQL-базу не составляет труда?
          Не могу точно утверждать насчет скорости, но, на мой взгляд, запрос в sqlite-базу будет на порядки быстрее, чем формирование SOAP-запроса, его обработка сервером и парсинг результата? Я специально уточнял у вас насчет SOAP, это весьма громоздкий и неудобный способ взаимодействия.
          • –1
            Преимущества использования web-сервисов:
            — платформенная независимость
            — модульность решений
            — инкапсуляция
            — стабильность

            Для скорости можно конечно сделать закешированную базу SQL. Но очевидно, что ваше решение это случай «заплатки» — потяни рядом, и все порвется. Это скорее пример как не нужно делать.

            OLE
            • –1
              Объясните, как оно «порвется», если работает почти год без моего вмешательства? Что должно произойти, чтобы процесс сбился? Попытайтесь мыслить шире — если в документации 1С что-то написано, то еще не значит, что нужно так делать.
            • +1
              Неправда ваша. Закэшированная БД — правильное решение для скорости, когда не нужно напрягать 1С на каждый чих («показать список .....»).
              Веб-сервисы — правильное решение для активной бизнес-логики.

              Тут всё более чем просто.
          • +1
            Преимущество веб-сервисов в удобстве (вы можете вызывать функции 1С, и обратно — 1С может вызывать ваши функции) и кросс-платформенности. Сайт, разрабатываемый мной по долгу службы, именно так и работает. И других вариантов нет, если нужны активные действия 1С при некоторых действиях на сайте.
            Не подумайте что я фанат веб-сервисов — они мне не очень нравятся, от них веет «энтерпрайзностью», тяжёлостью, XML, SOAP и прочим :( В современном мире это далеко не мейнстрим для сайтов.

            Далее, я немного тестировал реализацию веб-сервисов 1С, опять же по работе, — на практически обычной машине что-то около 70-100 вызовов в секунду, при 4+ потоках. 100 — для совсем быстрого метода (аля пинг), 70 — для немного более нагруженного.

            Но, самое главное не в этом.
            Самое главное в том, что в вашем случае можно и нужно заниматься и еженощной выгрузкой.

            Единственное что — у вас выгруженная база получается read-only?
            В web-интерфейсе нет никакой активной логики получается?
            • –1
              1) Нужно учитывать не пинг, а время, которое тратит 1С на обработку запроса. Это время зависит от того, что вы хотите получить. Например, у нас документ акта сверки формируется 3 секунды. При этом его нужно сохранить в Эксель, что невозможно без обращения к диску. Некоторые запросы требуют сложных джоинов и тоже выполняются не мгновенно. Если сразу много абонентов бросится выгружать документы, то это будет самый настоящий хабраэффект на рабочую базу.

              2) Да, нужно выгружать рабочую базу. Но если скрипт уж написан, а сама выгрузка длится 5 минут и полностью автоматизирована, то что плохого в такой схеме? Выгрузил — и свободен от веб-сервисов, COM-соединений и прочей чепухи.

              3) Да, я неоднократно писал, что эта база только для чтения. Показания и заявки абонентов падают в базу личного кабинета, откуда потом подгружаются в 1С, тоже ночью. Так удобней и безопасней, почему — написал чуть ниже: habrahabr.ru/blogs/python/139272/#comment_4655352
            • 0
              Согласен что в данном случае может быть не оправдано использование именно COM, но для создания веб сервисов в 1С нужно вносить изменение в конфигурацию — а это может повлиять на стоимость её поддержки.

              Ладно если 1С Ваша, то может быть можно и внести изменения. А если вы делаете приложение для 1С своих клиентов, то работа через COM соединение это по моему единственный способ получить данные из «чужой» 1С без каких либо её изменений.

              • 0
                Все это было давно и неправда. Сразу после публикации переделал на 1С — Апач — веб-сервисы
                • 0
                  документации по COM соединению мало. тут на бросились что com это плохо. есть случаи когда без него никак. вот и все что хотел сказать
        • +1
          Последняя ссылка про случай «наоборот» — про вызов внешних веб-сервисов из 1С. Надо заметить, что веб-сервисы в 1С8 — штука капизная весьма: не с каждым внешним сервисом 1ска захочет работать и не каждый внешний клиент заработает с сервисом 1ски. Но всё равно, народ как-то использует, местами даже удачно.
    • –2
      Минусуем? Фиг статью про интеграцию навижн и 1с через получаем…
  • 0
    Что правда, то правда… Такое впечатление, что 1с ведет по пути усложнения и деградации, в том числе и деградации наших программистов, которые вынуждены работать с 1с, чтобы нормально зарабатывать.
    • –2
      Не 1c не туда идет, а бездарности с большими яйцами. Вот они то им и мешают.

    • +3
      Сегодня от внедрения 1С никто не застрахован, к сожалению.
    • +1
      Вообще говря, не совсем так. Для примера могу привести систему компоновки данных. Вот тут написано v8.1c.ru/overview/Term_000000093.htm#1
      Аналоги, если они есть, стоят многие тысячи денег. Это к «усложнению».
      Теперь о «деградации». Тоже весьма спорный момент. Грамотная разработка под 1С всегда требовала понимания системы более глубокого, чем даёт ЖКК. А появление управляемого интерфейса и тонких клиентов вообще потребовало перестроить подход к разработке. Он, кстати, стал весьма и весьма близок к разрабоке веб-приложений.
  • 0
    Мсье знает толк в извращениях. Собственно вариантов как подружить 1С с другими системами много:
    1. Выгрузка данных из 1С регламентными заданиями — когда на сервере 1С автоматически запускается с некоторой периодичностью выгрузка данных в нужном формате (txt, xls, pdf, rtf, xml, dbf).
    2. Использование прямого подключения к 1С через браузер (как недостаток — нужно лицензий по количеству одновременных подключений)
    3. Прямой доступ к данным 1С — есть обработки которые показывают соответствие структуры конфигурации 1С и таблиц в SQL

    Автор же выбрал то, что ему знакомо — python и сделал всё на нем. Это как лестницу лопатой — только копать долго придется.

    Если нет желания разбираться в 1С или денег на внешнюю разработку — вариант автора вполне приемлем. Советовать же ему следовать — только если вы хорошо знаете python и нет возможности сделать всё на 1С.
    • +6
      1. Выгрузка != оперативная работа с данными. Так же вы рискуете изобрести велосипед в виде обработки этих данных, если нужно так же как в 1С. Не говорим о том, что такая схема не годится для онлайн режима взаимодействия с.

      2. Автоматизировать работу через браузер — надеюсь имеются ввиду веб-сервисы — иначе это уже тянет на большее извращение нежели com-соединение =)

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

      Вариант автора ничем не уникален и вполне нормальное решение, а работать с com-объектами можно хоть из vbscript: синтаксис другой, результат тот же =)
    • 0
      Вы вообще статью читали?
      1) Какая разница, кто выгружает данные, сама 1С или скрипт через COM-соединение? Можно реализовать и так, и так. Вариант со скриптом кажется удобнее.
      2) Браво, ну подключусь я через браузер, увижу список абонентов. Как мне с этими данными работать?
      3) Минусы этого подхода были описаны в статье.
      • 0
        Статью читал. Внимательно.
        1. Вариант со скриптом работает для машин под Windows. Вариант с регламентным заданием работает под любым сервером Windows/Linux.
        2. Прямо из 1С можно реализовать работу пользователей. Ну т.е. модно посмотреть demo-ma.1c.ru/ это работа браузера в виде тонкого клиента для 1С.

        Собственно вопрос в том, что вы не разбираясь в 1С ведёте обсуждение в стиле — не читал, но осуждаю.
        • 0
          Пункт 2 вообще не в кассу. Я настраивал доступ через браузер для пользователей. Речь о том, как работать с данными 1С программно.
          • 0
            А вы пробовали открывать ссылки по приведённому адресу или v8.1c.ru/demo-ma?

            Зачем настраивать и делать велик, если платформа позволяет это делать без извратов?
            Тут оправдание, только если вы знаете питон и не плохо знакомы с платформой.
            • 0
              Василий, речь идет не о веб-клиенте. Рассматривается выгрузка vs веб-сервисы.
  • +1
    > Процесс установки соединения с 1С в зависимости от конфигурации может занять от 1 до 8 секунд (в моем случае — 6 секунд). Стоит ли говорить, что установка соединения на каждый запрос приведет к тому, то каждая страница будет загружаться 8 секунд.

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

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

    Вообще, статья интересная. Как хорошо, что мне с этим проприетарным ужасом работать не приходится.
    • –1
      Полностью поддерживаю egorinsk, жаль не могу голосовать пока еще. Конечно же демон, имеющий постоянное соединение, и также поддерживаю использование web services.
    • 0
      Я же писал, что соединение можно хранить как глобальную переменную (в питон-приложении), и тогда задержки не будет. И указал минусы — зависимость от COM-соединения, ограничение его пропускной способности, потеря кроссплатформености. Читайте, пожалуйста, внимательнее.
      • 0
        Демона можно реализовать не на стороне Python, а там где развернута 1С, причем писать его можно на чем угодно, он как посредник, а запросы к нему реализовывать можно как душе угодно, и делать эти запросы кроссплатформенными. Ограничение пропускной способности COM соединения, для ваших задач несущественно, мизерно я бы сказал, время межпроцессного взаимодействия посредством маршалинга, только для того чтобы получить набор данных очень мизерно.
        Надо писать весь код выборки данных в 1С, оформлять ее как экспортную процедуру и вызывать по средствам COM из демона, потери производительности на трансляцию (использование IDisapach как дуального интерфейса, с вызовом его метода GetIDsOfNames) каждого метода 1С используемого не на его стороне еще меньше.
        • 0
          еще раз отмечу, демон и 1С вместе на одной платформе в связке, но запросы к демону можно реализовать кросс платформенными.
          • 0
            и на одной машине, конечно
            • 0
              И еще, посмотрите внимательно, о чем писал в том числе egorinsk- об актуальности!!!!!!, и в том числе и это побудило меня к нему присоединиться. Какую бы вы в итоге не выбрали технологию взаимодействия с 1С, я сторонник того, чтобы это было в режиме актуальных данных, а не их синхронизации, поскольку очень много может породить проблем неактуальные данные.
              Вы представляете 400 тысяч наших далеко не радостных абонентов, со всеми вытекающими из этого последствиями. И добавлю, недокументированные способы интеграции с 1С, например обращение напрямую к данным MSQL тоже чревато, при обновлении платформы все соглашения по именованию таблиц могут резко измениться.
              • 0
                К сожалению, вы и другие комментаторы не учитываете множество мелочей, которые не видны в проектировании и вылезают в продакшене.

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

                По поводу COM-соединения — вы не подумали о том, что постоянное соединение с рабочей базой не безапасно? Вдруг в личном кабинете найдется дыра, и хакер сможет уронить сервер 1С? Вдруг хакер напишет бота, который будет слать запрос на страницу со сложным запросом? А если понадобится перезагрузить 1С-сервер или поставить обновление, то личный кабинет и все платежные системы будут недоступны.

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

                • 0
                  И кстати, по тому же принципу работает личный кабинет MocЭнергоСбыта. У них хоть не 1С, но данные выгружаются в специальную базу для личного кабинета, никакого реалтайма. Данные от абонентов тоже загружаются раз в сутки. Я знаю это, потому что смотрел вебинар конторы, которая им делала личный кабинет.
                  • 0
                    ну если реалтайм не нужен, то причем тут термин интеграция с 1С, тогда просто называйте вещи своими именами, «мой экспорт данных из 1С для моей web морды». Интеграция предполагает взаимодействие в реальном времени, да еще в идеале взаимное, все остальное это экспорт и импорт данных. В конце концов тут предлагаются альтернативы, ничего не навязывается.
                    • 0
                      Когда я подключаюсь к 1С из вне скриптом и заставляю ее выполнять нужные мне действия (выгрузка данных, формирование печатных форм, проведение документов), то разве это не интеграция?
                      • 0
                        Интеграция нескольких систем подразумевает обмен сообщениям между ним и исполнение при этом каждой системы основных своих функций. В вашем же случае происходит дублирование части функции одной системы другой (сбор данных которые уже существуют в 1С, по сути их кэширование). Это тоже можно назвать своеобразной интеграцией, но все же не классической, где каждая система имеет свою основную функцию, в вашем случае 1С как система где сконцентрирована вся бизнес логика и там происходит обработка данных, а ваша надстройка организует к ним доступ во вне.
                        Получается любое межпроцессное взаимодействие через COM по вашему обречено и дело тут не в 1С, а в технологии в целом, и проблема которую вы описываете с соединением по COM, ее можно адресовать к OS Windows (диспетчеризации потоков). И быть может в вашем случае это действительно критично.
                        Но я за то, что если существуют технологии взаимодействия, пусть например COM, SOAP, которые официально поддерживает 1С то их и нужно использовать, а если они не эффективны в той или иной реализации, то нужно менять систему 1С, зачем такие гибриды строить.

                        • 0
                          Я понимаю вас, что вы поставлены в уже существующие условия, и вы на правильном пути и я вас поддерживаю.
                        • 0
                          Получается любое межпроцессное взаимодействие через COM по вашему обречено

                          Не то чтобы обречено, но менее прозрачно и устойчиво. Требуется продумывать слишком большое количество условий.
                          В целом, конечно, вы правы, мой подход — это кэширование для быстрого и стабильного доступа. А ситуация с 1С в моей организации зависит не от меня, я бы уж лучше согласился дорабатывать старую систему на Дельфи.
  • 0
    Помнится под 1С 7.7 писал сам TCP/IP сервер в виде внешней компоненты. В 1 8.х есть отличный вариант использовать MS winsock activex компоненту. Вот пример nastroy-ka.ru/system1c/121--tcpip-udp.html
    А уж к TCP/IP серверу можно цепляться практически из любого языка программирования. Попробуйте.
  • +3
    Статья получилась в целом не про 1С вовсе, а про умение работать на python с COM. Полезное, хотя и специфическое. Замечание один: идеологически правильнее было оформить функции (или, если угодно, методы) для получения данных внутри самой конфигурации 1С, да и работать оно будет быстрее. Это делается несложно, причём, при правильном подходе не вызывает трудностей при обновлении конфигурации. А запускать запросы и, тем более, создавать объекты данных непосредственно через COM — это лучше оставить для каких-то разовых задач. Замечание два: с некоторых пор структура таблиц в БД тайной не является — в языке есть средства, позволяющие узнать, какие таблицы к каким объектам относятся. Вполне разумным решением может стать написание некоторого числа view/хранимых процедур для чтения данных непосредственно из СУБД. Только писать в базу таким образом лучше ничего не надо: есть шанс порушить базу. Естественно, такой вариант не подходит для файлового варианта базы. Самое главное замечание: замените слово «функционал» на «функциональность», или «программная логика», или что-то в этом роде.
    • 0
      Спасибо, попробую реализовать прямое чтение из MS SQL-базы.
      • +2
        Есть штука такая — enterprise integrator (ссылок не даю во избежание, всё гуглится) — это сторонняя разработка на платформе 1С8. В частности, она позволяет не только посмотреть, в каких таблицах хранятся объекты, но и делать трассировку запрсов 1С и получение их трансляции на языке SQL в контексте сервера БД. Конечно, всё это можно сделать и штатными средствами, но в Ei всё уже сделано до нас.
  • 0
    У нас задача по интеграции с 1с — выкручивание разнообразных отчетов. Ночью мы проводим выгрузки во второстепенную бд данных в удобном для построения отчетов виде. Актуальность данных на вчера вполне устраивает.

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

    >каждый, кто просматривал базу 1С на SQL-сервере, видел, что в массе таблиц вида aaa1, aaa2 разобраться трудно.
    1Cv7.DDS — моя настольная «книга» :) Для восьмерки наверное что-то тоже подобное должно быть

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

    >являются виртуальными и разбросаны по разным физическим таблицам, собираясь множественными джоинами.
    Собираем)
  • +1
    В 1с есть специальная вещь для интеграции — веб сервисы. и они предпочтительнее с точки зрения

    безопасности (подключаемая программа может сделать только то, что нужно),
    скорости (не тратится время на создание сом объекта),
    расширяемости (разнесение по разным серверам веб части и сервера 1с, что, кстати, и к безопасности добавляет, возможность по нормальному использовать возможности кластера серверов 1с),
    гибкости (не зависит от ОС)
    формализации (строгое определение формата через WSDL, что позволяет, кстати, потом отказаться от 1с, или от веб части малой кровью — описание протокола взаимодействия уже есть, надо просто его реализовать)
    возможностям (намного проще, например, организовать двусторонний онлайн обмен)

    Всякие же интеграции через COM или прямое соединение к БД (что, кстати, не так сложно, как почему-то все думают) или их гибрид (с динамическим получением структуры таблиц хранения через COM раз в сколько-то времени и прямое выкачивание данных) — имеют право на существование, например для построения OLAP кубов или получения консолидированных отчетов из нескольких баз 1с, но только не для онлайн интеграции с сайтом. Это мое мнение как специалиста по 1с, другие специалисты могут иметь другое мнение.
    • +1
      Не будем лукавить, если скажем, что веб-сервисы в 1С — штука капризная весьма (вроде я это уже говорил?), и поработать с ними «нахрапом» не получится. Кроме того, реализация их такова, что многие «нормальные» (как они думают) программисты, столкнувшись с необходимостью реализации веб-сервиса в 1С, помучившись, плюнут и будут делать более другими способами.
      • 0
        Ну у меня работает как раз онлайн запрос расчета цены из 1с на сайте, ну и онлайн остатки и прочее — чтобы на кассе и на сайте данные и алгоритмы были одинаковые и не надо было хотелки маркетологов отдельно на сайте реализовывать и отдельно в 1с…
        А на тему того, что сложно реализовывать… ну никто документацию читать не любит…
  • 0
    Статья интересная. Но меня интересует такой момент: все больше внимания 1С уделяет Linux. И, соответственно, все больше Linux-компьютеров в будущем будут работать c 1C. И с этой точки зрения COM-доступ, описанный здесь, не будет работать. Какая альтернатива доступа к 1С извне, такая же гибкая как COM, но вместе с тем универсально подходит для Windows/Linux?
    • 0
      Альтернатива COM есть. Например, обработка 1С сама выгружает данные в DBF, а питоний скрипт грузит его в Джангу. Все это ночью по крону.
      • 0
        Видите ли — предложенный вами подход не универсальный и предполагает доработку конфигурации 1С. COM-подход же намного гибче. Например, все экспортные процедуры/функции будут автоматически доступны через COM. Т.е. в случае с COM с большей вероятностью не нужно вмешиваться в конфигурацию 1С.
        • 0
          Почему? Пишется внешняя обработка. На крон ставится запуск 1С и запуск этой обработки. Конфигурацию править не нужно. Внутри обработки доступны все функции и модули.
          • 0
            Я согласен, что это один из вариантов — обходных путей. Но COM/OLE предусматривает получение данных по требованию. Например, известно много случаев, когда данные 1С берутся динамически из Asp.Net-сайтов (интернет-магазинов). Или в конвертации данных при выгрузке можно было подключиться по OLE к удаленной информационной базе и отправить данные, тем самым избежав явной операции загрузки данных. В случае с Linux отсутствие COM/OLE приведет к уменьшению функциональности.
            • 0
              Тогда понадобится одна Виндовая машина или виндовая виртуалка.
              В конторе, где используется 1С, должна найтись хотя бы одна виндовая машина.
              • 0
                Понятно, спасибо!
  • 0
    Еще один момент остался неясным. Автор скорее всего работал с давно спроектированным приложением 1С, которое работало как неуправляемое приложение. Начиная с 8.2 появился «тонкий» клиент и будет появляться все больше конфигураций для управляемых приложений.
    Есть ли вообще возможность подключения по COM к управляемому приложению, например к тому же demo-ma.1c.ru/ удаленно? И если есть, то какие ограничения накладываются на такие подключения по сравнению с подключением к «толстому» клиенту?
    • 0
      Вы немного путаете.
      COM-подключение осуществляется к серверу 1С. А серверу все равно, как работает конфигурация. Подключение осуществляется к любой конфигурации, независимо от того, под какой режим она написана.
      Да, речь в статье шла о конфе, которая работает в обычном режиме. Но я успешно подключаюсь и к тем конфигурациям, которые проектировались для управляемого режима, например, конфигурация Докоборот.
      А тонкий клиент — это просто способ отдать данные клиенту с медленным соединением, отношения к статье он не имеет.
      • 0
        Не совсем понятно. По КОМ я могу обратиться не только к серверу 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?
        • 0
          Немного не так выразился.
          COM — это одно из возможных типов соединения.
          Подключаться к 1С можно несколькими способами: толстый клиент, тонкий клиент, веб-клиент, внешнее соединение (т.е. COM).

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

          2) Кажется, нет. Для COM нужно толстое соединение.
          • 0
            Хотя, кажется, на пункт 2 вру. В инете пишут, что можно. Завтра на работе проверю.
            • 0
              В Интернете прочитал, что действительно есть разделение и можно удаленно коннектиться. Для тонкого клиента будет примерно такой код:
              ОбъектПодключения = "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
              Соответственно для тонкого клиента весь функционал урезан.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.