Не согласен. Удобно использовать для раскопок контейнера и для перемещения по складу. Легко определить заполненность склада /ячейки если добавить ярусность. Если использовать стеллажи то удобно понимать где находится к примеру опасный груз или какой-либо вид номенклатуры добавив подсветку по отбору.
Html в 1С действительно расширяет возможности. Можно не НаКлиенте реализовать интерфейсы но и прокинуть их во внешку через http сервисы:) Подписывайтесь на наш блог и узнаете еще много интересных кейсов:)
Здесь очень важно соблюдать удобство работы пользователя (не нагруженность интерфейсов) и глубину интеграций. Вы правы, в случае сложных интеграций или множества условий работа программиста будет лучше и приоритетнее, но таких интеграций в разы меньше (около 20%) по сравнению со стандартными обменами НСИ.
Лично мы решили этот вопрос возможностью вставки запроса написанного программистом в режиме Произвольный запрос. И даже при этом программисту не нужно писать сериализацию и отправку данных, что экономит его время и не требует релизов.
И естественно чтобы работа в такой системе не заглохла - нужны ребята понимающие как это работает, как это поддерживать и чем это лучше ручных интеграций. Это два с половиной человека (программист и аналитик+).
С одной стороны вы правы, сложность разработки с абстракциями возрастает и такая платформа накидывает ограничения и в то же время маппинг 1 к 1 обычно используется только при переносе нси, с другой стороны можно учесть потребности пользователей и добавить left + inner join в генератор запросов, добавив вложенность тч мы получим двухуровневый json который уже легко совместится с другой системой. Я так понимаю вы часто работали с подрядчиками аналогичного софта, именно они могут предложить быстрое костыльное решение.
Перенос кода также легко реализуется т.к. это расширение, а перенос настроек легко через стандартную выгрузку / загрузку xml.
Я лишь подал идею быстрых интеграций и вижу что это многим интересно, данное решение определенно имеет большой потенциал к развитию, а ии инструменты имеют много фантазий, и требуют времени разработки и тестирования что в итоге сильно замедляет процесс. Рекомендую все же присмотреться к моей идее:)
Принимаю замечания, вы правы нужно было использовать СтрШаблон, но это простой и понятный пример при этом создание текста запроса выполняется один раз без каких - либо циклов, поэтому нет влияния на производительность.
Я вас понимаю, но у нас это работает идеально, т.к. конструктор получается очень удобным, то аналитик настраивает маппинг полей самостоятельно. Если добавить Left join для смежных сущностей то запрос собирается не только для НСИ а скажем для документов, остатков и т.д. Главное реализовать максимально удобно и понятно для пользователя. Бизнес - аналитик легко с этим разберется и углубится в структуру системы. В общем это реально работает и сокращает время разработки интеграций от 70% и более!
Пользователь выбирает и версионирует интеграции, а не программист. Возможность написания псевдонимов для полей JSON позволит быстро интегрироваться с любой внешней системой. Возможно это и есть главные отличия:)
Похож, но хорошо расширяем. При этом пользователь выбирает и версионирует интеграции, а не программист. Возможность написания псевдонимов для полей JSON позволит быстро интегрироваться с любой внешней системой. Очевидно так OData не умеет по умолчанию.
Согласен, но можно не использовать сложные функции js, стандартные методы легко поддерживаются, а возможности 1с сильно расширяются.
Не согласен. Удобно использовать для раскопок контейнера и для перемещения по складу. Легко определить заполненность склада /ячейки если добавить ярусность. Если использовать стеллажи то удобно понимать где находится к примеру опасный груз или какой-либо вид номенклатуры добавив подсветку по отбору.
Html в 1С действительно расширяет возможности. Можно не НаКлиенте реализовать интерфейсы но и прокинуть их во внешку через http сервисы:)
Подписывайтесь на наш блог и узнаете еще много интересных кейсов:)
Здесь очень важно соблюдать удобство работы пользователя (не нагруженность интерфейсов) и глубину интеграций. Вы правы, в случае сложных интеграций или множества условий работа программиста будет лучше и приоритетнее, но таких интеграций в разы меньше (около 20%) по сравнению со стандартными обменами НСИ.
Лично мы решили этот вопрос возможностью вставки запроса написанного программистом в режиме Произвольный запрос. И даже при этом программисту не нужно писать сериализацию и отправку данных, что экономит его время и не требует релизов.
И естественно чтобы работа в такой системе не заглохла - нужны ребята понимающие как это работает, как это поддерживать и чем это лучше ручных интеграций. Это два с половиной человека (программист и аналитик+).
С одной стороны вы правы, сложность разработки с абстракциями возрастает и такая платформа накидывает ограничения и в то же время маппинг 1 к 1 обычно используется только при переносе нси, с другой стороны можно учесть потребности пользователей и добавить left + inner join в генератор запросов, добавив вложенность тч мы получим двухуровневый json который уже легко совместится с другой системой. Я так понимаю вы часто работали с подрядчиками аналогичного софта, именно они могут предложить быстрое костыльное решение.
Перенос кода также легко реализуется т.к. это расширение, а перенос настроек легко через стандартную выгрузку / загрузку xml.
Я лишь подал идею быстрых интеграций и вижу что это многим интересно, данное решение определенно имеет большой потенциал к развитию, а ии инструменты имеют много фантазий, и требуют времени разработки и тестирования что в итоге сильно замедляет процесс. Рекомендую все же присмотреться к моей идее:)
Принимаю замечания, вы правы нужно было использовать СтрШаблон, но это простой и понятный пример при этом создание текста запроса выполняется один раз без каких - либо циклов, поэтому нет влияния на производительность.
Я вас понимаю, но у нас это работает идеально, т.к. конструктор получается очень удобным, то аналитик настраивает маппинг полей самостоятельно. Если добавить Left join для смежных сущностей то запрос собирается не только для НСИ а скажем для документов, остатков и т.д. Главное реализовать максимально удобно и понятно для пользователя. Бизнес - аналитик легко с этим разберется и углубится в структуру системы. В общем это реально работает и сокращает время разработки интеграций от 70% и более!
Пользователь выбирает и версионирует интеграции, а не программист. Возможность написания псевдонимов для полей JSON позволит быстро интегрироваться с любой внешней системой. Возможно это и есть главные отличия:)
Похож, но хорошо расширяем. При этом пользователь выбирает и версионирует интеграции, а не программист. Возможность написания псевдонимов для полей JSON позволит быстро интегрироваться с любой внешней системой. Очевидно так OData не умеет по умолчанию.
Возможно у вас есть кейс как именно нужно использовать типовые справочники?
О каких механизмах вы говорите?