Комментарии 108
Интересно, можно ли автоматизировать еженедельнрое перепроведение документов при помощи данного механизма? Можно ли через WEB-сервис вызвать штатную процедуру перепроведения документов за заданный период и (самое главное) получить результат, идентичный тому, который мы видим в окне сообщений в клиентской части 1С?
Интересно, можно ли автоматизировать еженедельнрое перепроведение документов при помощи данного механизма?
Можно. Но для начала имеет смысл выяснить, а для чего требуется «еженедельное перепроведение документов». Если оно прямо таки еженедельное, то, кажется, в консерватории что-то не так.
По выходным мы перепроводим документы за последние 1-2 квартала и отправляем отчёт бухгалтерам. Они его просматвивают и исправляют некоторые ошибки учёта. А как делают в цивилизованном мире?
В цивилизованном мире, рассчитывают себестоимость/НДС, закрывают месяц и запрещают проводить документы прошлых периодов. А за тот вандализм, что Вы творите, голой задницей на муравейник сажают.
Шота какой-то трындец… вы МЕНЯЕТЕ УЧЕТНЫЕ ДАННЫЕ по состоявшимся операциям каждую неделю???!!
В цивилизованном мире за такое порют на конюшне, раз уж вы спрашиваете. А потом скажут "1С плохая", ага
Ну и что с этого что мы меняем данные? Зато экономим на трудовых ресурсах, восстановить последовательность дешевле. К сожалению розовые очки еще рано снимать, живая даже с цифровой подписью накладная на поступление товаров/услуг может поступить с большим опозданием. Да и бухгалтерам на много проще откорректировать первичку в рамках доступного времени, чем создать вторичку.
А как делают в цивилизованном мире?
Разделяют оперативный и бухгалтерский контуры учета. Современные типовые 1Ски (УТ, например) давно научились не требовать восстанавливать последовательности на каждый чих. Т.е. вы спокойно работаете, а у вас автоматически по расписанию данные выгружаются в бухгалтерию. И бухгалтеру вообще не требуется вникать, что происходит в управленческом учете. А бухгалтер у себя уже по требованию восстанавливает последовательности. И разово, при нахождении косяков, правит их в управленке.
Ну и 1-2 квартала — раз в неделю… Это — сильно. Я бы еще понял, если бы речь шла про текущий месяц. В крайнем случае — текущий квартал. А так — в консерватории точно есть проблемы.
Интерфейсные сообщения на клиент не передаются, поэтому увидеть какие-то штатные сообщения не получится. Передаются только сообщения об исключениях в виде исключений на клиентской стороне.
Тут можно либо выбрать все документы на стороне клиента и перепровести их в цикле из клиента (с отображением исключений). Либо написать простенькую функцию на стороне 1С, которая будет делать то же самое и возвращать какой-то результат в нужном вам виде. Например, лог перепроведения, или массив каких-то сообщений. А из клиента дергать эту функцию.
Тут можно либо выбрать все документы на стороне клиента и перепровести их в цикле из клиента (с отображением исключений). Либо написать простенькую функцию на стороне 1С, которая будет делать то же самое и возвращать какой-то результат в нужном вам виде. Например, лог перепроведения, или массив каких-то сообщений. А из клиента дергать эту функцию.
Если можно вызывать методы серверного контекста то конечно. 1. достаточно написать такой метод, который будет принимать параметры дат или безусловно выбирать доки за неделю и проводить с обработкой ошибок и генерацией сообщений. 2. Можно воспользоваться выполнением фрагментов кода из статьи, когда процедура выборки и проведения будет написана у вас. Справедливости ради можно отметить, что такое можно сделать и просто через вебсервис и через rest
А чем вас не устраивает стандартное регламентное задание, или написанный вебсервис?
Что с безопасностью?
Тут коллеги подсказывают, что в "расширении Бром" есть функция ExecuteCode, которая позволит выполнить произвольный код в системе удаленно, так что очень полезная вещь, надо устанавливать!
В расширении предусмотрены отдельные роли доступа, отвечающие за те или иные функции. Если нужно запретить вызов методов или отработку произвольных кусков кода, то эти роли можно отключить. Кроме того, само расширение можно установить в безопасном режиме, тогда оно не будет иметь доступ к файловой системе, HTTP и прочим интерфейсам, через которые могут быть утечки.
Доступа на чтение данных достаточно. Главный вопрос: зачем нужно ставить расширение в 1С, если достаточно просто сделать штатное API на стороне 1С и накрыть штатным же механизмом ролей?
Т.е. мне понятно зачем нужна OData-обертка для netcore, но зачем она требует установки ЗАКРЫТОГО (а значит потенциально ВРЕДОНОСНОГО) плагина, который позволит сделать rm -rf в моей базе удаленно. Я должен поверить вашему обещанию, что расширение такого не делает? И что вы действительно хорошо реализовали эти самые «предусмотренные роли доступа»?
Т.е. мне понятно зачем нужна OData-обертка для netcore, но зачем она требует установки ЗАКРЫТОГО (а значит потенциально ВРЕДОНОСНОГО) плагина, который позволит сделать rm -rf в моей базе удаленно. Я должен поверить вашему обещанию, что расширение такого не делает? И что вы действительно хорошо реализовали эти самые «предусмотренные роли доступа»?
Это самое «штатное» API надо писать. Один раз это сделать не лень и интересно, но когда Вы это будете делать в десятый раз, Вы начнете замечать, что все эти API сильно похожи, отличаются только названия справочников, документов и запросы немного разные, а подход во всех конфигурациях 1С идентичный. По сути копипаста кода из одной конфигурации 1С в другую. И скорее всего, Вы захотите написать какой-то более универсальный механизм, чтобы один раз установил на любую конфигурацию и дальше пользуешься. А то, что он избыточный не беда, закрыл правами доступа и радуешься.
Само расширение является частью 1С и не может работать в обход системы ролей доступа 1С. Соответственно, если Ваш пользователь имеет доступ к таблицам только на чтение (или не имеет вообще доступа к ним), то даже с открытой инжекцией кода, он ничего удалить не сможет. А если и на чтение доступ убрать, то и прочитать не сможет.
Само расширение является частью 1С и не может работать в обход системы ролей доступа 1С. Соответственно, если Ваш пользователь имеет доступ к таблицам только на чтение (или не имеет вообще доступа к ним), то даже с открытой инжекцией кода, он ничего удалить не сможет. А если и на чтение доступ убрать, то и прочитать не сможет.
УстановитьПривелигированныйРежим(Истина) — достаточно чтобы в произвольном коде получить все права и на чтение и на запись и на черта лысого)
Поэтому современные конфы уже имеют это API которое называется EnterpriseData и нужно просто использовать это апи, иногда добавляя кастомный сериализатор в этот формат при необходимости.
EnterpriseData используется только в шести типовых конфигурациях и позволяет обмениваться данными только об определенных объектах. Если его пихать в свою отраслевую конфигурацию, то еще на стороне 1С придется повозиться. То есть это достаточно узкая штука. Но я согласен, что по возможности лучше использовать его, т.к. это стандарт.
Вот про «EnterpriseData» лучше не вспоминайте. Чуть что нестандартное захочешь (какой нибудь ТОИР с RCM интегрировать) и приплыли. Или это про CommerceML? Что то подзабыл, давно не возился.
Выглядит здорово. Думаю, кстати, будет удобно использовать если есть необходимость стягивать данные из 1С например в Jupyter.
Зачем писать код 1с на пхп, если можно писать код 1с в 1с и результат отдавать в пхп?
Потому что никто 1с не умеет, 1с — фу фу фу, 1с очень сложно и вообще там на кириллице пишут
Дело в том, что отдавать из 1С становится гораздо проще, т.к. не надо заботиться о упаковке сложных наборов данных (например таблиц). На стороне PHP работать получается тоже проще, т.к. данные не нужно парсить, не нужно их распаковывать.
Кроме того, обычно при интеграции с 1С есть самые простые и распространенные задачи, например получение элементов какого-то справочника. Если вдруг Вам понадобился какой-то новый справочник, то не надо просить 1С-ника писать для этого новую функцию, а можно просто взять и выбрать из него данные самому. Достаточно знать его название.
Другими словами, вы и так отдаете результат в PHP, но тратите на это меньше усилий.
Кроме того, обычно при интеграции с 1С есть самые простые и распространенные задачи, например получение элементов какого-то справочника. Если вдруг Вам понадобился какой-то новый справочник, то не надо просить 1С-ника писать для этого новую функцию, а можно просто взять и выбрать из него данные самому. Достаточно знать его название.
Другими словами, вы и так отдаете результат в PHP, но тратите на это меньше усилий.
Если вдруг Вам понадобился какой-то новый справочник, то не надо просить 1С-ника писать для этого новую функцию, а можно просто взять и выбрать из него данные самому. Достаточно знать его название.
Для этого как раз и существует абсолютно штатный REST-интерфейс OData от 1С. И потом, знать название справочника для интеграции недостаточно. Нужно знать и его состав, потому что после рефакторинга на стороне 1С ваша интеграция может и отвалиться. Поэтому ZEEGIN и пишет Вам, что интеграция должна идти через заранее специфицированные интерфейсы. Временно «здесь и сейчас» Ваше решение подойдет, но если делать по уму, то так нельзя, слишком хрупко. И 1С тут не при чем.
отдавать из 1С становится гораздо проще, т.к. не надо заботиться о упаковке сложных наборов данных (например таблиц)
Что Вы имеете в виду под «упаковкой таблиц»?
То есть сделать http-сервис на стороне 1с, который может вернуть список всех справочников, потом по «имени» конкретного справочника получить список реквизитов (если вы прям вобще не знаете как они называются) и в конце концов получить данные конкретного справочника это очень сложно и слабо выполнимо, а вот это всё намного лучше…
Так то есть OData и все что вы описали уже в 1с встроено из коробки.
В OData нельзя выполнять сложные запросы, нет полноценной поддержки мультитайповых полей, нет возможности удаленного вызова методов 1С. OData, безусловно очень мощный механизм, но он имеет свои ограничения.
Я писал именно про «вернуть список всех справочников, потом по «имени» конкретного справочника получить список реквизитов (если вы прям вобще не знаете как они называются) и в конце концов получить данные конкретного справочника»
Что касается остального — это действительно на мой взгляд неудачное как с точки зрения поддержки и стабильности решение, так и с точки зрения безопасности.
Что касается остального — это действительно на мой взгляд неудачное как с точки зрения поддержки и стабильности решение, так и с точки зрения безопасности.
В бром-клиенте есть доступ к метаданным конфигурации (к основным коллекциям), кроме того там реализована динамическая их подгрузка и кеширование. Если Вам нужно узнать список справочников, или список реквизитов конкретного справочника/документа/регистра, то это можно сделать.
Если для интеграции достаточно иметь доступ к данным БД без лишних наворотов, то использование ODatа, полагаю будет предпочтительнее, т.к. это все таки утвержденный стандарт от Микрософт.
Если для интеграции достаточно иметь доступ к данным БД без лишних наворотов, то использование ODatа, полагаю будет предпочтительнее, т.к. это все таки утвержденный стандарт от Микрософт.
Это не интеграция. Завтра я в 1С сделаю рефакторинг и переименую поле. И все, ваша интеграция — коту под хвост. Или вы предложите запретить рефакторинги?
Нормальные люди под каждую интеграцию делают контракт. Прям жестко описывают что может приходить в систему и что может уходить. И тогда, рефакторящий должен соблюсти все контракты взаимодействия, а если этого не сделал — понятно, кто накосячил.
А интеграция вида HTTP GET /integra?q=«SELECT Field FROM Database» — это жопа, извините. А вы считаете это нормой.
Нормальные люди под каждую интеграцию делают контракт. Прям жестко описывают что может приходить в систему и что может уходить. И тогда, рефакторящий должен соблюсти все контракты взаимодействия, а если этого не сделал — понятно, кто накосячил.
А интеграция вида HTTP GET /integra?q=«SELECT Field FROM Database» — это жопа, извините. А вы считаете это нормой.
Дело в том, что Ваш «контракт» тоже кто-то должен поддерживать в рабочем состоянии. Если 1С изменит какое-то поле, то в рабочем состоянии останутся только те контракты, которые разработаны самой фирмой 1С, потому что они отвечают за их корректную работу.
Но зачастую Вам нужно наладить интеграцию с конфигурацией 1С, которая является отраслевой и разрабатывается вообще третьими лицами (или самим заказчиком). И может так случиться, что никаких интерфейсов специально для Вас там никто не писал, а если и писал, то не те которые Вам нужны конкретно для Вашей задачи. В этом случае этот «контрактный интерфейс» Вам придется изобретать самому.
Кроме того, даже если крупная компания использует типовой программный продукт от самой 1С, то, скорее всего, он сильно доработан и содержит объекты, отражающие их отраслевую специфику. И интегрировать в свой «портал» они, вероятнее всего, захотят именно свою «отраслевую» функциональность, которая ни в каких типовых интерфейсах не отражена. В этом случае придется разрабатывать свой интерфейс и следить за его работоспособностью.
Как вариант, это можно сделать через Бром, отключив в нем все, что нарушает безопасность протокола, а также создав пользователя, который имеет доступы только к конкретным таблицам в 1С.
Но зачастую Вам нужно наладить интеграцию с конфигурацией 1С, которая является отраслевой и разрабатывается вообще третьими лицами (или самим заказчиком). И может так случиться, что никаких интерфейсов специально для Вас там никто не писал, а если и писал, то не те которые Вам нужны конкретно для Вашей задачи. В этом случае этот «контрактный интерфейс» Вам придется изобретать самому.
Кроме того, даже если крупная компания использует типовой программный продукт от самой 1С, то, скорее всего, он сильно доработан и содержит объекты, отражающие их отраслевую специфику. И интегрировать в свой «портал» они, вероятнее всего, захотят именно свою «отраслевую» функциональность, которая ни в каких типовых интерфейсах не отражена. В этом случае придется разрабатывать свой интерфейс и следить за его работоспособностью.
Как вариант, это можно сделать через Бром, отключив в нем все, что нарушает безопасность протокола, а также создав пользователя, который имеет доступы только к конкретным таблицам в 1С.
Вы, видимо, не поняли, что я сказал насчет контрактов
На самом деле все не совем так, давайте рассмотрим типоой сценарий:
- Есть 1С некоторая, допустим УТ или УНФ.
- Есть портал самообслуживания, допустим самописный на питоне.
Надо сделать интерацию.
Как делать правильно?
- Описать протокол обмена, спецификацию пакетов, потоки данных, описать сценарии сущностей базы для автоматического разрешения конфиликтов.
- Написать 2 адаптера, один из 1С в формат и второй из питона в формат. Т.е. тупо сериализатор и десериализатор, без какой-то бизнес логики.
- Написать тесты, которые автономны и которые тестируют только сериализатор и десериализатор на эталонных пакетах.
Почему надо делать так? Потому что обычно команды разработчики — разные. Обычно — владельцы (по скраму) баз данных 1С и сайта тоже разные. Обычно, кроме проектов интеграции есть очень много внутренних проектов, которые не должны влиять на обмен никоим образом.
Как доработать обмен?
Надо открыть техпроект доработки, уточнить спецификацию, доработать два адаптера каждой из сторон.
Как доработать 1С?
Просто доработать, но если будет затронуты объекты участвующие в обмене — достаточно только внутри 1С адаптер уточнить, благо тесты по нему уже написаны. И это самое важное! Не нужно дорабатывать вторую сторону.
Что предлагаете сделать Вы?
Не использовать адаптеров. Вместо спецификаций использовать описание объектов базы данных 1С. Данный подход хорош только в случае, когда 1С никода не будет дорабатываться, потому что в случае доработки объектов метаданных спецификация принимающий стороны на сайте станет отличаться от того, что есть в 1С. Даже после простого обновления 1С на новый релиз могут возникнуть множественные переименования, что моментально потребует доработку сайта, потому что изменилась спецификация. И чаще всего эту доработку будут вынуждена делать группа не 1сников. Т.е. для элементарной задачи обновления 1С нужно будет привлечь группу вебберов для решения последствий этих обновлений.
Потому очень важно контракты оставлять "за 1С". Потому Odata не любят для решения задач иных кроме грабберов данных. Потому 1С в свое время придумал EnterpriseData. Потому обмен с сайтом делают не прямыми вызовами а соблюдая протокол CommerceML.
А кто будет писать весь этот код — программист php или программист 1С? Если программист php — то он 1С не знает, если программист 1С — то он не знает php. Или это все рассчитано на шив многоруких?
Это не совсем так. Достаточно много студий web-разработки, которые предлагаю интеграцию с 1С. Обычно они дописываю что-то в 1С и в PHP, зачастую это может делать один человек.
Вообще говоря, чтобы разобраться в 1С много ума не надо. Не сильно сложнее, чем разобраться в каком-нибудь SOAP-интерфейсе какого-нибудь интеграционного модуля.
Вообще говоря, чтобы разобраться в 1С много ума не надо. Не сильно сложнее, чем разобраться в каком-нибудь SOAP-интерфейсе какого-нибудь интеграционного модуля.
Что?? Но ведь там учет, бизнес-процессы всякие… Вы вообще понимаете что такое учет?
Зачем? Это же для «веб-студий, которые предлагают интеграцию с 1С»!
и вы сейчас серьезно предлагаете дать «веб-студиям, предлагающим интеграции с 1С» практически полный доступ к 1С, и не контролировать тот код, который будет выполняться в вашей боевой 1С? советую углубиться в контрактное программирование, понятие интерфейсов.
EvilBeaver Не забывайте что вы на хабре, тут с пониманием сарказма не всегда все хорошо)) Проф деформация наверно.
Я как раз НЕ предлагаю, если, конечно, вы не промахнулись веткой и отвечаете именно мне
Для того, чтобы кто-то что-то написал, ему в любом случае нужно дать какой-то доступ.
Этот кто-то может быть веб-студией, а может быть франчайзи 1С, или программистом в штате. Если этот кто-то имеет базовые навыки в 1С, ему не составит труда написать необходимые скрипты.
Доступ к 1С вы можете ограничить на сервер 1С правами доступа к конкретным объектам, систему ролей доступа в 1С никто не отменяет. Удаленный вызов тоже можно запретить.
Я, например, даже если пишу серверный код для сторонней студии, всегда прилагаю демонстрационные скрипты на необходимом языке, которые можно вставлять в их код.
Этот кто-то может быть веб-студией, а может быть франчайзи 1С, или программистом в штате. Если этот кто-то имеет базовые навыки в 1С, ему не составит труда написать необходимые скрипты.
Доступ к 1С вы можете ограничить на сервер 1С правами доступа к конкретным объектам, систему ролей доступа в 1С никто не отменяет. Удаленный вызов тоже можно запретить.
Я, например, даже если пишу серверный код для сторонней студии, всегда прилагаю демонстрационные скрипты на необходимом языке, которые можно вставлять в их код.
Там же и понимать не надо, ведь все по-русски написано…
Сейчас много разных программистов вузы выпускают, каких только нет: имеется и отдельная связка по 1С + веб, специальность называется «прикладная информатика в экономике». Сдают бухучёт, налоги, базы данных, кучу сертификаций 1С и ещё много всего, включая веб-программирование.
Хм, а мы на этой специальности семестр изучали программирование на 1с (ну как изучали, я еще перед этим за пару недель практики производственной узнал на порядок больше), веб программирование не изучали практически совсем (ну не считать же html и установку джумлы), немного изучали стандартные делфи, бейсик, базы данных, учет, экономику и кучу гуманитарщины.
Ну это уже много. А я студаков, например, учил делать лабы на 1С и сдавать их мне на проверку в виде пулреквестов на гитхаб.
Я думаю, от кафедры очень много зависит. В моем универе у преподов была довольно цельная позиция по подготовке 1С-программистов в рамках этой специальности и было много предметов с абстрактными названиями (типа «корпоративные информационные системы), которые разбирались на примере стандартных конфигураций 1С. В результате студенты довольно хорошо знали и бухгалтерию и программирование. Веб-программирование давалось в виде PHP, а потом перешли на ASP.NET
И где тут простота и скорость интеграции? Автор, Вы серьезно думаете, что удаленное выполнение кода в базе 1с — это интеграция?
Да, именно так они и думают. Взгляните на их документацию
А как можно что-то синтегрировать без удаленного выполнения кода?
А как можно что-то интегрировать с помощью удаленного выполнения кода?? О_о
Интеграция — это спецификация интерфейсов между системами, договоренность называть атрибуты сущностей так, а не иначе. Обеспечивая тем самым слабую связанность и надежность взаимодействий.
А «выполним запрос в 1С, т.к. мы PHP-шники, нам надо по-быстрому», ну извините, это капец, халтура и кустарщина.
Интеграция — это спецификация интерфейсов между системами, договоренность называть атрибуты сущностей так, а не иначе. Обеспечивая тем самым слабую связанность и надежность взаимодействий.
А «выполним запрос в 1С, т.к. мы PHP-шники, нам надо по-быстрому», ну извините, это капец, халтура и кустарщина.
Потом какой-то кулхацкер получит удалённое исполнение кода в PHP и сдампит 1С базу.
Кулхацкер сдампит ровно то, что ему позволено ролями доступа на стороне 1С. Тем более «клиентское приложение», оно только по отношению к 1С клиентское, а так то оно такое-же серверное как и само 1С.
Первое:
Когда делают интеграции, обычно стараются выделять программный интерфейс, апи, то описание протокола передачи, которое будет неизменно и документированно для систем интеграции. Обычно это или описание пакетов не важно в каком формате, xdto, xsd, или спецификации для построения rest. А может быть это описания пакетов для RabbitMQ или Apache Kafka. Главное, что это описание есть.
Зачем это нужно? Для того чтобы внеся изменения в одну из сторон обмена не нужно было вносить синхронно изменения в другую сторону. Для того чтобы доработку обмена надо было делать техпроетом доработки, когда это реально нужно, а не всякий раз когда одну из систем обновляешь на новый релиз (внутренний или внешний).
Второе:
Вызов на сервере произвольного кода с клиента — это нарушение безопасности и нарушение стандартов разработки 1С. https://its.1c.ru/db/v8std#browse:13:-1:36
И не важно клиентом тут является тонкий или веб клиент 1С или Soup клиент подключенный к веб-сервису. Позволять вызывать произвольный код нельзя. По крайней мере надо хотябы безопасный режим устанавливать.
Третье:
В частной модели нарушителя может быть две группы нарушителей, внутренние и внешние. Обычно специалисты по безопасности стараются уменьшить группу внешних нарушителей или как минимум уменьшить количество средств, через которые внешние нарушители могут воздействовать на систему.
Код расширения закрыт. Возможное наличие программных закладок в совокупности с необходимостью публикации базы и возможности исполнять расширением произвольный код поднимает риски использования расширения до небывалых высот. Любой уважающий себя интегратор не стал бы использовать это расширение без аудита кода на предмет программных закладок.
А поскольку код является нетленкой и закрыт — то вывод о жизнеспособности такого решения напрашивается сам собой. Особенно, если почитать их DISCLAIMER с отказом от ответственности за использование закрытого кода.
Декомпильнуть что-ли и на гитхаб выложить? :)
Декомпильнуть что-ли и на гитхаб выложить? :)
Андрей, без шуток, если вы это сделаете, я Вам буду бесконечно признателен, ибо до сих пор никакого подтверждения, что закрытый код надежно защищает исходники у меня нет.
Если у кого-то получится его открыть, то и в паблик выкладывать его закрытым смысла нет. Я тогда просто выложу его открытым как есть.
Если у кого-то получится его открыть, то и в паблик выкладывать его закрытым смысла нет. Я тогда просто выложу его открытым как есть.
Первое:
Это все верно, если у Вас есть популярная публичная система, и Вам необходимо предоставить доступ неограниченному количеству разработчиков заранее неизвестных. Здесь я с Вами абсолютно согласен, предоставлять им гибкий доступ к системе неприемлемо.
Но чаще всего доступ к системе нужен не публичный, а для конкретного приложения, которое может разрабатываться той-же командой разработчиков для нужд той-же организации, которая использует 1С. Например, когда нужен внутренний портал с ограниченным доступом к данным из 1С, или какое-то специфическое приложение для внутренних сотрудников. В этом случае обе системы по сути являются частью единой более сложной системы и, скорее всего, расположены либо на одном сервере либо в изолированной корпоративной сети. В этом случае гибкий доступ к данным, может быть востребован, т.к. интегрируемому приложению Вы заранее доверяете.
Само описание пакетов не дает вам гарантии, что сервис работает корректно, т.к. нужно чтобы разработчики сервиса поддерживали его в актуальном состоянии, соответствующем имеющемуся описанию. В этом плане ничего не мешает создать интерфейсные методы в 1С на естественном для 1С языке и вызывать их удаленно через Бром (на низком уровне это будет тот же самый SOAP/XSD/XDTO, он описан в документации). Так же как и в первом случае эти методы придется актуализировать при обновлении системы. Разница только в том, что не придется программировать формирование XDTO-пакеты, т.к. упаковку и распаковку XDTO пакетов расширение делает автоматически.
Второе:
Вызов произвольного кода можно запретить (точнее не разрешать). Под клиентским приложением подразумевается серверная часть стороннего приложения, которому Вы доверяете (по отношению к 1С оно — клиент), возможно вы его сами и разрабатываете. Естественно, конечному клиенту не следует как либо взаимодействовать вообще с этим расширением напрямую из пользовательского интерфейса.
Расширение может работать в безопасном режиме. Саму опцию с произвольным кодом можно включать, например, на время отладки/тестирования.
Третье:
По поводу программных закладок полностью согласен. Полагаю, это можно решить в индивидуальном порядке.
Это все верно, если у Вас есть популярная публичная система, и Вам необходимо предоставить доступ неограниченному количеству разработчиков заранее неизвестных. Здесь я с Вами абсолютно согласен, предоставлять им гибкий доступ к системе неприемлемо.
Но чаще всего доступ к системе нужен не публичный, а для конкретного приложения, которое может разрабатываться той-же командой разработчиков для нужд той-же организации, которая использует 1С. Например, когда нужен внутренний портал с ограниченным доступом к данным из 1С, или какое-то специфическое приложение для внутренних сотрудников. В этом случае обе системы по сути являются частью единой более сложной системы и, скорее всего, расположены либо на одном сервере либо в изолированной корпоративной сети. В этом случае гибкий доступ к данным, может быть востребован, т.к. интегрируемому приложению Вы заранее доверяете.
Само описание пакетов не дает вам гарантии, что сервис работает корректно, т.к. нужно чтобы разработчики сервиса поддерживали его в актуальном состоянии, соответствующем имеющемуся описанию. В этом плане ничего не мешает создать интерфейсные методы в 1С на естественном для 1С языке и вызывать их удаленно через Бром (на низком уровне это будет тот же самый SOAP/XSD/XDTO, он описан в документации). Так же как и в первом случае эти методы придется актуализировать при обновлении системы. Разница только в том, что не придется программировать формирование XDTO-пакеты, т.к. упаковку и распаковку XDTO пакетов расширение делает автоматически.
Второе:
Вызов произвольного кода можно запретить (точнее не разрешать). Под клиентским приложением подразумевается серверная часть стороннего приложения, которому Вы доверяете (по отношению к 1С оно — клиент), возможно вы его сами и разрабатываете. Естественно, конечному клиенту не следует как либо взаимодействовать вообще с этим расширением напрямую из пользовательского интерфейса.
Расширение может работать в безопасном режиме. Саму опцию с произвольным кодом можно включать, например, на время отладки/тестирования.
Третье:
По поводу программных закладок полностью согласен. Полагаю, это можно решить в индивидуальном порядке.
Под клиентским приложением подразумевается серверная часть стороннего приложения, которому Вы доверяете (по отношению к 1С оно — клиент), возможно вы его сами и разрабатываете.
Решаем простую математическую задачку. Пусть в 1с X уязвимостей. Пусть в серверной части стороннего приложения Y уязвимостей. В случае если у нас 1с не имеет возможности получать произвольний код для исполнения — у нас уязвимойстей X и остается. В случае если такая возможность есть — получаем X+Y уязвимостей. Плюс к этому стороннему приложению не исключена возможность что можно получить доступ через еще пару других приложений — таким образом злоумышленники вам скажут большое спасибо. Понятно что не все так просто и прямолинейно, но все же.
Давайте лучше решим практическую задачу. Вы заходите в расширение в дерево конфигурации, выделяете тот метод, который кажется вам небогоугодным и нажимаете кнопку «Delete». После этого расширение становится безопасным, можно его даже под своей редакцией выпустить.
А остальные пользователи не нажимают эту кнопку и радуются тому, что у них есть возможность писать уязвимости.
А остальные пользователи не нажимают эту кнопку и радуются тому, что у них есть возможность писать уязвимости.
Блин, почитал доки…
И это все удаленно, т.е. предлагается самостоятельно установить в свое бизнес-приложение плагин, который позволит его безнаказанно изнасиловать удаленно по API…
Парни, кто вас так учил системы интегрировать? Необходимость выполнения кода в интегрируемой системе — это не интеграция, это красная лампочка о том, что у вас бардак в ландшафте и что надо выпороть вашего архитектора.
Расширение «Бром» позволяет:
— получать данные различных ссылочных коллекций (справочников, документов, ПВХ и тд...) с учетом сложных условий отбора и сортировки;
— модифицировать данные коллекций (добавлять, удалять и редактировать элементы справочников, документов и пр. объектов);
— получать и изменять значения констант;
— получать данные с помощью произвольных запросов на языке 1С: Предприятие;
— вызывать процедуры и функции серверных модулей (общих модулей и модулей менеджеров) с передачей произвольного количества параметров вызова и с передачей полученного значения обратно в качестве результата вызова;
— исполнять произвольный код 1С на стороне сервера с возможностью передачи параметров и получения возвращаемого значения.
И это все удаленно, т.е. предлагается самостоятельно установить в свое бизнес-приложение плагин, который позволит его безнаказанно изнасиловать удаленно по API…
Парни, кто вас так учил системы интегрировать? Необходимость выполнения кода в интегрируемой системе — это не интеграция, это красная лампочка о том, что у вас бардак в ландшафте и что надо выпороть вашего архитектора.
Выделенные опции можно отключить. Никто не мешает использовать их только для отладки.
Они же по умолчанию сразу после установки расширения, разумеется, выключены, верно? И только осознавая весь груз ответственности админ должен зайти в настройки и эти опции включить, да?
Само расширение становится доступно только после установки конкретных ролей расширения. Если Вы будете работать от лица нового пользователя, то ему необходимо будет также прописать права и на основные объекты конфигурации, потому как у пустого пользователя даже на запуск 1С прав нет, а на доступ к БД тем более.
Насколько я могу себе представить в результате все равно в качестве транспорта будет использоваться Apache или Майкрософт-интернет-сервер с плагинами к ним, то есть та же связка что используется в реализации веб-сервисов SOAP?
У меня есть одно мобильное приложение которое довольно активно обращается через эту связку с 1с. И как результат — неприятная задержка в ответах на несколько секунд. Это после проведения ряда оптимизаций на стороне 1с. До этого запросы могли проходить и более 10с.
То что быстрее проходит разработка — это тоже хорошо. Но есть ли возможность или есть ли разработанные плагины которые позволили бы более быстро (за миллисекунды) общаться с 1с из связанных систем, например бэкендов мобильных приложений?
У меня есть одно мобильное приложение которое довольно активно обращается через эту связку с 1с. И как результат — неприятная задержка в ответах на несколько секунд. Это после проведения ряда оптимизаций на стороне 1с. До этого запросы могли проходить и более 10с.
То что быстрее проходит разработка — это тоже хорошо. Но есть ли возможность или есть ли разработанные плагины которые позволили бы более быстро (за миллисекунды) общаться с 1с из связанных систем, например бэкендов мобильных приложений?
Дело в том, что перед использованием любых SOAP методов 1С предварительно создает полноценную (или почти полноценную) сессию. Такую же, как если бы вы работали через интерфейс 1С. На создание этой сессии тратится куча времени и ресурсов, т.к. в ней просчитываются роли доступа, устанавливаются параметры сеанса и еще куча всего условно ненужного. Если запросы на сервер идут в короткие промежутки, то сессия берется уже созданная из пула, но если запросы на сервер идут редко, то в промежутках между запросами сессия может помереть, и тогда ее придется создавать заново (это действительно долго, особенно для крупных конфигураций).
Время жизни сессии можно прописывать в общих настройках публикации на вкладке «Прочие» и дополнительно еще в настройках самого web-сервиса. Я обычно еще делаю на стороне сервера приложения примитивный скрипт, который вызывает пустой метод «Ping» через определенные промежутки времени, чтобы постоянно висела хотя бы одна живая сессия.
Еще необходимо проверить, как происходит работа с WSDL. Например, в php WSDL-описание сервиса загружается каждый раз при обращении к php скрипту, это увеличивает время ответа примерно в 10 раз. Но там можно установить специальный флажок ini_set('soap.wsdl_cache_enabled', '1'), который кеширует wsdl на стороне php сервера, и тогда скорость ответа сокращается до единиц миллисекунд. Возможно, в вашем приложении есть что-то подобное.
Время жизни сессии можно прописывать в общих настройках публикации на вкладке «Прочие» и дополнительно еще в настройках самого web-сервиса. Я обычно еще делаю на стороне сервера приложения примитивный скрипт, который вызывает пустой метод «Ping» через определенные промежутки времени, чтобы постоянно висела хотя бы одна живая сессия.
Еще необходимо проверить, как происходит работа с WSDL. Например, в php WSDL-описание сервиса загружается каждый раз при обращении к php скрипту, это увеличивает время ответа примерно в 10 раз. Но там можно установить специальный флажок ini_set('soap.wsdl_cache_enabled', '1'), который кеширует wsdl на стороне php сервера, и тогда скорость ответа сокращается до единиц миллисекунд. Возможно, в вашем приложении есть что-то подобное.
По ini_set('soap.wsdl_cache_enabled', '1') спасибо проверю.
После приведения в порядок разнообразных настроек когда мы уперлись в то что запросы не работают параллельно а чисто выстраиваются в очередь что в свою очередь добавляет времени на ожидание — реальное что помогло это сконфигурировать несколько десятков юзеров чтобы бэкенд рандомно обращался от имени одного из юзеров и это сделало работу более гладкой. Есть большое подозрение что основное проседание идет на стороне модуля который работет в Apache или ISS.
У меня сейчас появилась такая идея а что если юзать для обмена что-то вроде rabbitmq или другого сервера например работающего по mqtt протоколу. Сможет ли 1с напрямую общаться с каким-нибудь серверов типа очередей сообщений?
После приведения в порядок разнообразных настроек когда мы уперлись в то что запросы не работают параллельно а чисто выстраиваются в очередь что в свою очередь добавляет времени на ожидание — реальное что помогло это сконфигурировать несколько десятков юзеров чтобы бэкенд рандомно обращался от имени одного из юзеров и это сделало работу более гладкой. Есть большое подозрение что основное проседание идет на стороне модуля который работет в Apache или ISS.
У меня сейчас появилась такая идея а что если юзать для обмена что-то вроде rabbitmq или другого сервера например работающего по mqtt протоколу. Сможет ли 1с напрямую общаться с каким-нибудь серверов типа очередей сообщений?
Включено «повторное использование сеансов»? Оно круто ускоряет http вызовы 1С
Ну да. Я тоже давно жду что бы к примеру сайт интернет магазина на прямую тянул данные из 1С. Это очень бы помогало. Не нужны были бы лишние обмены вообще. Сайт наполнять тоже было бы проще. 1С фактически была бы админкой для сайта. Но запросы больше 1 сек это вилы. Никто столько ждать не будет!
Боже мой! Откуда такое желание отстрелить себе обе ноги, да еще и с одного выстрела? :)
Вам накидать простейшие мысли, почему так делать нельзя, или сами догадаетесь?
Ну вопрос первый: что произойдет с вашим интернет-магазином, если 1С — ляжет?
Второй: насколько популярными будут ваши приватные данные на черных рынках, если ваш горе-интернет-магазин ломанут?
третий: что произойдет с вашей 1ской при наплыве посетителей интернет-магазина?
и четвертое: в чем упрощение наполнения сайта? Вы уверены, что вы хотите ваш бардак в 1С выложить в интернет? Наполнение интернет-магазина — это всегда боль. Потому что в 1с обычно жопа, а в интернет-магазине и картинки приличные нужны и описания толковые, и список свойств…
Вам накидать простейшие мысли, почему так делать нельзя, или сами догадаетесь?
Ну вопрос первый: что произойдет с вашим интернет-магазином, если 1С — ляжет?
Второй: насколько популярными будут ваши приватные данные на черных рынках, если ваш горе-интернет-магазин ломанут?
третий: что произойдет с вашей 1ской при наплыве посетителей интернет-магазина?
и четвертое: в чем упрощение наполнения сайта? Вы уверены, что вы хотите ваш бардак в 1С выложить в интернет? Наполнение интернет-магазина — это всегда боль. Потому что в 1с обычно жопа, а в интернет-магазине и картинки приличные нужны и описания толковые, и список свойств…
Наполнение интернет-магазина из 1с это не всегда означает тянуть весь каталог.
Именно. Зачем тогда иметь возможность с инет-магазина выполнять код на стороне 1с? Вы все равно делаете дополнительную работу. По причесыванию каталога. Включить обмен с сайтом в этих условиях — это меньше 0.1% времени. Вообще сама идея «1С — это админка для сайта» должна умереть даже не родившись :) По крайней мере в варианте, когда сайт тащит все данные, выполняя код на стороне сайта.
Вместо этого можно делать адекватные вещи: например, веб-сервисы, которые выполняются на стороне 1С и отдают данные сайту.
Вместо этого можно делать адекватные вещи: например, веб-сервисы, которые выполняются на стороне 1С и отдают данные сайту.
Не до конца ясно зачем нужно писать код на 1С внутри пхп, если можно писать код на 1С внутри 1С и отдавать результаты в пхп.
Если честно, то проще разместить 1С на том же сервере что и приложение, благо 1С поддерживает linux сервера и подключить базу любого Net, python или PHP приложения к себе во внешние источники и уже в 1С писать в них и читать из них все что угодно. И работает и быстрее и делать можно почти все что угодно и без этих извращений с кириллицей в коде приложений и более безопаснее, как мне кажется и публиковать на радость хакерам не нужно)). Как-то так.
Тогда у вас функциональность будет внутри 1С. А здесь то идея в том, чтобы можно было сделать какое-то приложение/сайт/портал, пользователи которого, не имеют доступа к 1С, но должны с ним взаимодействовать. Например портал студентов ВУЗа, портал сотрудников, портал чего-либо еще.
функция ExecuteCode это называется «не имеют доступа»?
Ну все равно скорость запроса данных слабая. Права все равно выдавать как-то нужно в 1с. Хотя не знаю как ограничивать права если данный способ под логином даёт выполнять почти любой код. Разве что для логина ограничивать доступ к чему либо. Опасность в том что 1с лучше на https не публиковать — это черева-то сливом инфы. И 1с гарантии безопасности https не даёт. В ообщем все же безопаснее работать с базой приложухи из 1с по средствам внешних источников. Если нужно портал студентов вузов. То 1с сама зальёт в базу сайта список студентов если нужно и выполнит нужную логику. В общем аргументы очень сомнительные.
У меня два вопроса:
Как лицензия MIT совместима с поставкой без исходников?
Как использование конструкции «выполнить» и «вычислить» совместимо с безопасностью?
С таким же успехом можно для json-rpc накидать на коленке что-то.
Как лицензия MIT совместима с поставкой без исходников?
Как использование конструкции «выполнить» и «вычислить» совместимо с безопасностью?
С таким же успехом можно для json-rpc накидать на коленке что-то.
1. Лицензия MIT регулирует лишь права на использование программного обеспечения в том виде, в котором оно предоставляется. Про исходники в нем не упоминается.
Код пока закрыт только в расширении которое можно ставить в безопасном режиме, в клиентских библиотеках код НЕ защищен.
2. Само расширение в первую очередь предназначено для сервер-серверного взаимодействия между известными надежными узлами. Эту опцию Вы можете использовать для отладки и запретить на уровне ролей доступа на сервере 1С в рабочем проекте.
3. Накидать можно все что угодно, а можно уже накиданное взять.
Код пока закрыт только в расширении которое можно ставить в безопасном режиме, в клиентских библиотеках код НЕ защищен.
2. Само расширение в первую очередь предназначено для сервер-серверного взаимодействия между известными надежными узлами. Эту опцию Вы можете использовать для отладки и запретить на уровне ролей доступа на сервере 1С в рабочем проекте.
3. Накидать можно все что угодно, а можно уже накиданное взять.
Ктулху Всеблагой, ну ведь не просто так на сайте битая ссылка на PHP-клиент! Зачем, ну зачем я её поправил и скачал ЭТО...
При использовании подобных расширений есть смысл помнить ещё и о лицензионных ограничениях самой 1С. А условия, в общем случае, интересные.
«В соответствии с действующим Лицензионным соглашением Организация должна приобрести Клиентские лицензии по количеству пользователей, в действительности одновременно работающих с системой 1С: Предприятие 8. Использование программных или аппаратных средств, уменьшающих количество пользователей, которые имеют непосредственный доступ к 1С: Предприятию 8, как это происходит при использовании «Web-расширения», не уменьшает количества требуемых лицензий.»
Даже такую формулировку можно трактовать по разному, и, наверное, при строгом взаимодействии сервер-сервер, отвязанном как либо от клиентской стороны, можно иметь свободных лицензий по количеству одновременных соединений.
Но, например, если делать интеграцию с неким сайтом, и лишний раз из него дёргать что-то в 1С… Тут уже нужно разбираться, происходит ли «уменьшение количества пользователей программными средствами», или же нужна 1000 лицензий на всю ту 1000 пользователей, что заходит на ваш интернет-магазин в сутки (условно).
«В соответствии с действующим Лицензионным соглашением Организация должна приобрести Клиентские лицензии по количеству пользователей, в действительности одновременно работающих с системой 1С: Предприятие 8. Использование программных или аппаратных средств, уменьшающих количество пользователей, которые имеют непосредственный доступ к 1С: Предприятию 8, как это происходит при использовании «Web-расширения», не уменьшает количества требуемых лицензий.»
Даже такую формулировку можно трактовать по разному, и, наверное, при строгом взаимодействии сервер-сервер, отвязанном как либо от клиентской стороны, можно иметь свободных лицензий по количеству одновременных соединений.
Но, например, если делать интеграцию с неким сайтом, и лишний раз из него дёргать что-то в 1С… Тут уже нужно разбираться, происходит ли «уменьшение количества пользователей программными средствами», или же нужна 1000 лицензий на всю ту 1000 пользователей, что заходит на ваш интернет-магазин в сутки (условно).
Ваше замечание полностью уместно. Однако оно относится скорее не к расширению, а вообще к механизму web-сервисов. Полагаю, в этом случае имеет смысл ориентироваться все же на количество одновременных соединений.
Ведь если пользователь сайта, например, увидел на сайте цену на товар, взятую из 1С, то его вряд-ли можно назвать пользователем программы 1С.
Однако, если создать приложение, которое подменяет пользовательский интерфейс 1С, полагаю тут уже будет нарушение.
Ведь если пользователь сайта, например, увидел на сайте цену на товар, взятую из 1С, то его вряд-ли можно назвать пользователем программы 1С.
Однако, если создать приложение, которое подменяет пользовательский интерфейс 1С, полагаю тут уже будет нарушение.
Посмотрел код расширения.
Я так не смеялся со времен выпускных экзаменов )))
Закрытый код — это реально шедевр
За это люблю программистов 1С
Я так не смеялся со времен выпускных экзаменов )))
Закрытый код — это реально шедевр
За это люблю программистов 1С
// Функция для страпонации декомпилятора, не содержит смысла
Функция СтрапонаторДекомпилятора()
ПеременнаяСтрапонации = "";
МассивСтрапонации = Новый Массив();
ИтоговыйСтрапонатор = "";
Для Каждого Элемент Из МассивСтрапонации Цикл
ВременнаяПеременнаяСтрапонации = СокрЛП(ПеременнаяСтрапонации + Элемент);
Если ВременнаяПеременнаяСтрапонации = ПеременнаяСтрапонации Тогда
СтруктураСтрапонации = Новый Структура();
СтруктураСтрапонации.Вставить(«ХуитологическаяКонстанта», ВременнаяПеременнаяСтрапонации + «КонстантаВдупления»);
Пока СтруктураСтрапонации.ХуитологическаяКонстанта <> Неопределено Цикл
ЕщеПеременная = 1 / (2 + 5) + СтруктураСтрапонации.ХуитологическаяКонстанта;
Если ЕщеПеременная <> «ПарметрАдекватности» Тогда
СтруктураСтрапонации.Очистить();
Иначе
Если ЕщеПеременная <> «ФакторБыдлокода» Тогда
СтруктураСтрапонации.Вставить(«ПоПолной», «Полнее не бывает»);
Иначе
Для к = 69 По 69 * 69 Цикл
п = к — (к / 2);
к = к + п;
Переменная_С_Палками = "| | | | | |";
Если к > п Или п = «Страпонированное состояние почти достигнуто» Тогда
Для о = 69 По 69 * (69 — 68) Цикл
п = о — (к / 2);
к = к + п;
Если к > о Или п = «Уже вот вот страпонируется» Или Строка(Истина и Не Ложь) = Истина Тогда
СтруктураСтрапонации.Вставить(«ВставлялиУже», «Во внешнем цикдле по полной заправили!»);
Иначе
КайфовыйПараметр = " Мир, брат! ";
Возврат СокрЛП(КайфовыйПараметр);
КонецЕсли;
Попытка
Для Каждого БесполезныйПараметр Из СтруктураСтрапонации Цикл
Сообщить(БесполезныйПараметр.Значение);
КонецЦикла;
Исключение
Сообщить(«Не фортануло!»);
Попытка
Для Каждого БесполезныйПараметр Из СтруктураСтрапонации.ПоПолной Цикл
Если БесполезныйПараметр > 0 Тогда
ПеременнаяОтсутствияСмыслаЖизни = «НеопределеноКакСтрока»;
Иначе
Сообщить(«Иполнение кода достиго критической безысходности.»);
КонецЕсли;
КонецЦикла;
Исключение
Сообщить(«Опять не фортануло!»);
КонецПопытки;
КонецПопытки;
КонецЦикла;
МассивСтрапонации[0] = ПеременнаяСтрапонации;
МассивСтрапонации[к + 0] = СтруктураСтрапонации.ПоПолной;
КонецЕсли;
МассивСтрапонации[1] = 5 + ПеременнаяСтрапонации + «Этот код обречен быть непонятым...»;
КонецЦикла;
КонецЕсли;
КонецЕсли;
КонецЦикла;
Возврат «Смысл не найден!»;
КонецЕсли;
КонецЦикла;
Возврат «Декомпилятор успешно страпонирован. Возрадуемся!»;
КонецФункции
Функция ИнформацияОбАвторе() Экспорт
Возврат «Модуль разработан ООО „“ИТВОРКС»". Автор исходного кода — Шаганов Антон Павлович (ООО "«ИТВОРКС»").";
КонецФункции
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Быстрая интеграция с 1С: Предприятие