Суть в том, что перед продакшеном этот код надо проверить!
Потом вернуть новичку на доработку. И так раза три-четыре (а доходило и до десяти раз), пока не получишь более-менее нормальный вариант.
Вообще-то именно так это и работает. Автоматизированная проверка конфигурации. Требование разрабатывать юнит тесты на свой код. Если ошибок автоматических нет и юнит тесты не выдали ошибок — выполнить код ревью. И так это работает не только в командах с 1С новичками, а в любых командах)
И вот вопрос — как долго новичок должен учиться, чтобы пройти сертификацию? Месяц? Два? Полгода?
Зависит от способностей юниора. Обычно от полугода до двух лет. И речь не о сертификации и экзаменах от самой 1С, а о внутреннем устройстве команды разработки.
У всех разный уровень знаний и разное понимание красивого кода, потому надо придерживаться стайл гайда единого, и этот стайл гайд есть стандарты разработки. Это соглашение о том, что хорошо, а что плохо. Не зная их даже оценить ни свой ни чужой код нельзя, либо эта оценка будет субъективной. Требовать от только что пришедшего программиста красивого кода можно только если принято соглашение о том, как и что нужно разрабатывать.
Можете написать свои стандарты, но вряд ли вы это сделаете лучше и учтете все нюансы, которые аккумулируются в стандартах от 1С последнее десятиление.
В python тоже очень низкий порог вхождения, можно сесть и начать писать. Сразу. Но не придерживаясь стайл гайда (например, от Гугла https://google.github.io/styleguide/pyguide.html) можно натворить делов.
В javascript тоже очень низкий порог вхождения, и опять же — если писать не придерживаясь стандартов будет хаос (https://standardjs.com/)
В чем разница подготовки специалистов 1С от подготовки любого другого инженера?
В лени руководителей? В том, что за 1С они не замечают всего остального мира?
1C — это прекрасный инструмент, и хаять надо в первую очередь не его, а тех, кто не умеет им пользоваться. Если что-то нельзя сделать с помощью 1С — это можно сделать иначе. Но чтобы понимать что и как надо делать — надо растить специалистов.
Но иногда мне мечтается о том, чтобы разработчики PVS-Studio вышли на контакт с фирмой 1С и предложили бесплатно один разочек проверить всю кодовую базу платформы 1С (вдруг найдут что-то) с обязательным обнародованием результатов проверки.
Мы используем три разных анализатора:
CppCheck PVS-Studio
Встроенный в Microsoft Visual Studio
Многие из нас знают не по наслышке, что это такое — разбирать код новичка.
Нехрен давать коммитить в продакшин новичкам, пусть сначала пройдут внутреннюю аттестацию по стандартам https://its.1c.ru/db/v8std
Continuous Delivery, Code Review: не — не слышали. 1С, как компания, виновата в том, что код новичка попал в рабочую базу) Зашибись подход)))
Но разработчики, наверное, поняли, что для нормального чтения данных потребуется очень серьезная доработка методов объектной модели.
Настольная книга 1С: Эксперта по технологическим вопросам http://v8.1c.ru/metod/books/book.jsp?id=499
Пожалуйста, сначала прочитайте зачем нужна объектная модель, а зачем модель запросов, а потом рассуждайте об удачных и неудачных моделях.
см. синтаксис помощник ПредопределенноеЗначение():
Результат выполнения кэшируется при первом обращении до изменения конфигурации или версии платформы.
Еще есть ОбщегоНазначенияКлиентСервер.ПредопределенныйЭлемент с кэшированием на время сеанса и проверкой существования предопределенного в ИБ.
А еще с недавних пор (БСП 2.4.3 вроде) ОбщегоНазначения.ЗначенияРеквизитовОбъекта можно вызывать с передачей имени предопределенного и сразу получать его значение (только на сервере).
Конечно хорошо! Наоборот, хочется, чтобы конкурсов было как можно больше. Именно соревновательных конкурсов, выявление талантов, продвижение студентов. Именно потому от конкурса ожидается то, что это будет не генерация идеи и дарственная банку, а некоторый способ засветиться и, возможно, присоединиться к сильной команде. Этот конкурс не понятно на кого рассчитан. Эксперты вряд ли в нем захотят участвовать, их время и так стоит дорого, зачем им шанс выиграть, когда им за их работу просто заплатят. А для студентов — это выглядит слишком не честным, человек придумал, продал банку. Зачем? Они могли установить условием открыть стартап и войти в долю так, чтобы инвестировать в мозги, а не пытаться их использовать и выбросить. Именно от этого и идет весь негатив к конкурсу.
В условиях быстроразвивающегося бизнеса и постоянных изменений бизнес-процессов "работает не трогай" звучит как "давайте не будем зарабатывать деньги".
Эта технология устарела, более не развивается. Ее сложно адаптировать под новые задачи. И еще сложнее поддерживать. Конечно, если подразуиевается, что система не висит мертвым грузом.
Сейчас если компания не развивает ай-ти — то ей не на что надеяться.
Небольшой ликбез для тех, кто захочет участвовать в конкурсе, и при этом не хочет, чтобы его наработки были признаны не защищенными законом об авторских правах:
Необходимо, чтобы исходные коды были подписаны, таким образом имелась гарантия в том, что они сделаны вами, но при этом с обязательным условием временной метки. Без временной метки по подписи можно доказать, что код написали вы, но невозможно доказать, что вы написали код первым.
Либо нужен специальный сертификат ЭЦП, либо финт ушами в роли распечатки исходников и отправки самому себе по почте, хотя еще и с Почтой России связываться...
Участник Конкурса, признанный Победителем, обязуется передать Банку все, в т. ч. исключительные права на разработанные в процессе Конкурса приложения и иные объекты интеллектуальной собственности, в срок не позднее 10 (десяти) рабочих дней с даты признания Победителя на основании отдельного лицензионного договора, заключаемого между Банком и Участником.
Банк оставляет за собой право использовать по своему усмотрению, без получения разрешения со стороны Участников Конкурса и без выплаты им вознаграждения любые идеи, концепции, принципы, методы, процессы, системы, способы, решения технических, организационных или иных задач (не являющиеся в соответствии со статьей 1259 Гражданского кодекса Российской Федерации объектами авторского права), созданные такими Участниками в процессе участия в Конкурсе.
Не нужно к операции "+" относится именно как к сложению в стандартном его понимании. Считайте это просто какой-то операцией, выполняя которую над определенным множеством это множество можно назвать группой.
На самом деле, вся проблема в том, что Вы предлагаете использовать ПолучитьСтруктуруХраненияБазыДанных не по назначению. Полагаться на результат работы данного метода для разработки непосредственных обращений — неправильное решение.
Данный метод существует непосредственно для самих 1Сников. Можно подумать, "Зачем 1Сникам знать низкоуровневую структуру базы данных, если вы все работаете с объектной моделью?". Так вот, он и сделан для того, что бы 1Сники не задумывались об этой низкоуровневой структуре. Так зачем же он нужен?
Запросы в 1С — тоже объектно ориентированные, и работают с типизированными данными, фактически это значит, что по значению колонки, если знать какой тип объекта в ней хранится, можно получить данные вложенного объекта по ссылке, при этом будет неявно выполнено соединение с таблицей, хранящей вложенный объект.
Само собой такие запросы просто так на СУБД не выполняются, предварительно они транспонируются в такой запрос, который понимает СУБД. Но проблема в том, что каждая СУБД может по своему понимать один и тот же запрос 1С. Да еще и перед выполнение запроса СУБД строит план выполнения запроса, который рассчитывается динамически от состава запрашиваемых данных, текущего объема таблиц, и еще множества разных факторов (составы индексов, кластерный индекс, знание о количестве выбираемых строк и.т.д.). Как следствие в некоторых случаях планы выполнения запроса к реляционным таблицам могут быть не оптимальны.
1С позволяет записывать в технологический журнал информацию о том, для какого запроса какой план выполнения был получен у СУБД, а этот план строится самой СУБД и в нем фигурируют именно имена таблиц самой СУБД. Вот для восстановления реальных имен объектов 1С для анализа запросов и их оптимизации и есть метод ПолучитьСтруктуруХраненияБазыДанных.
Написали и выполнили запрос
Получили журнал регистрации
Восстановили реальные имена объектов
Построили граф выполнения плана запроса
Выполнили оптимизацию запроса
Примерно так это все выглядит. Специальные инструменты разработчика, как та же "Консоль запросов", запускаемая в режиме 1С: Предприятие и входящая в состав поставки Библиотеки Стандартных Подсистем, является примером.
После обновления конфигурации 1С или внесения в нее доработок или внесения доработок в ETL изменения в формат высокоуровневой выгрузки требуется внести только в случае, когда: были изменены синхронизируемые таблицы, при этом если изменения такие, что их можно привести к формату пакета обмена (DTO), то изменения вносятся только на той стороне, в которой они были внесены. Изменение самого формата DTO требуется в крайне редких случаях.
От чего прозрачная поддержка и адаптируемость к новым требованиям на будущее.
Реализация на СУБД
После внесения любого изменения в 1С, даже не сильно связанного с вашим обменом, а так же при простых операциях, как реиндексация или реструктуризация данных, что в 1С доступно вообще из административного режима, может формат хранения данных в СУБД измениться. В первую очередь 1С запрещает обращаться к таблицам СУБД как раз из-за того, что это может нарушить работу самого 1С. Если чтение данных — это еще допустимо (образно), то запись непосредственно в базу — полный отказ от гарантий. Соответственно использование данного подхода — постоянный риск привести в неработоспособное состояние обмен с ETL и как следствие постоянные часы внеплановых доработок обмена.
Вопрос с же с производительностью всегда является спорным, при оптимизации запросов чтения и формирования DTO пакетов, определения оптимального размера самого пакета данных, выбором периодичности сообщений обмена, можно даже на медленном сервере с большой базой данных добиться хорошей производительности.
Здесь же речь об одной строке записи прикладного объекта 1С?
Да. Надо для одной строки записи (справочник, документ, регистр сведений или накопления или что-то еще) определить какие его измерения, реквизиты, ресурсы как должны перейти в колонки таблицы базы отчетов. Учитывая типы измерений, будет ли потеря данных, например при конвертации строк размерностью 130 символов в строки размерностью 100, или трита (булево+null) в простое булево и т.д. — это задача аналитика, который должен знать какие данные нужны для формирования отчета в базе отчетов.
Не очень понятно зачем делать какие-то буферные таблицы или файлы, когда сама платформа предлагает для этого механизм планов обмена. На низком уровне происходит так:
Если нужно выпонять какой-то тип обмена с другой системой, разработчик создает новый план обмена и включает в него те объекты 1С, которые должны передаваться в другую систему. Для каждого такого объекта платформа сама создаст таблицу изменений, в которую будет включен идентификатор записи (для справочников и документов, например — это ссылка, а для регистров — это ключ записи) и будет включен узел, в который необходимо отправить данные.
При записи объекта (например при изменении номенклатуры или создании нового документа) если для объекта есть таблица изменений, то он будет там зарегистрирован к отправке (само по себе это платформа выполняет автоматически, однако программно регистрировать и снимать с регистрации тоже можно).
Если есть несколько разных отчетных баз одного типа, то для них достаточно сделать один план обмена в котором уже в режиме предприятия создать несколько узлов, для каждой отчетной базы свой узел. Система благодаря своей структуре таблицы изменений для каждого узла будет регистрировать данные отдельно.
План обмена так же включает в себя по умолчанию номера принятых и отправленных сообщений, это необходимо для подтверждения доставки. Чтобы избежать таких случаев, когда данные в отчетную систему были отправлены, но при этом отчетная база их не приняла. При следующем обмене отправляться будут в том числе и те записи, которые отчетная база не приняла ранее, чтобы гарантировать целостность передачи. Для этого и вводится дополнительная операция — коммит подтверждения доставки. Когда 1С отправляет какие-либо данные она в таблице изменений сохраняет тот номер пакета сообщения, который она отправила и в дальнейшем когда отчетная система пришлет коммит о том, что она этот номер сообщения приняла, 1С может со спокойной совестью снять все данные с регистрации, отправленные по этому номеру сообщения.
Если обмен является двухсторонним, то обычно коммитом является получение пакета из другой базы, если обмен односторонний (как это с выгрузкой в отчетную базу) достаточно реализовать операцию подтверждения).
Сам способ отправки может быть любым. Можно создать регламентное задание, которое будет из 1С по расписанию выгружать данные в стороннюю систему, можно выгружать в файлы, можно записывать непосредственно в базу приемник (все равно какая, 1С может записывать и MySQL, MSSQL, Postgres, Oracle, IBM DB2, вообще во все, для чего есть драйвер подключения к этой базе.
Но делать непосредственные выгрузки так же как инициировать обмен из 1С — это не самая хорошая практика, лучше, когда данные запрашивает та система, которой эти данные нужны. Так же как записывать куда то в стороннее хранилище данные непосредственно тоже не очень правильно, ведь структура данных и в 1С и в сторонней базе может со временем измениться, бизнес требует частых доработок. Потому правильным считается приведение сначала к общему формату обмена, и после отправку и приемку.
Опять же что это будет за формат — не очень важно для 1С, это может быть XML, JSON, какой-то бинарный файл или просто текстовый (тот же CSV) формат, главное чтобы приемная база могла его понять и формат был согласован.
Протокол отправки то же не очень важен, сторонняя система может просто стучаться по COM, на 1С может быть реализован веб-сервис по формату SOAP или сразу передавать ответ, выполнив запрос к 1С по HTTP, ровно как и выгружать в файл на диск или ftp. Тут скорее надо определить что из этого доступно в базе которая хочет интегрироваться с 1С.
Выгружать данные в какую либо отчетную систему непосрндственно не кажется правильным. Ведь та структура данных, которая положена в 1С, сделана такой для внутренних отчетов или механизмов контроля учета (например остатков) самого 1С. Отчетной системе, консолидирующей данные из разных источников, в т.ч. из 1С, может требоваться иная структура данных для формирования своих отчетов. В первую очередь следует провести сопоставление данных и формально описать правило конвертации одной строки записи 1С в строку записи таблицы DWH. Создать в 1С план обмена, в который будет включен узел, соответствующий базе данных отчетов. Включить для этого плана обмена регистрацию изменений для выгружаемой таблицы. Таким образом все новые или удаленные записи будут записаны к отправке. Далее каким либо образом DWH будет инициировать обмен, запрашивая, есть ли для нее новые данные в 1С, например можно поднять веб-сервис SOUP или HTTP прям из 1С. 1С в ответ будет формировать пакет данных, требуемый для базы отчетов. Каждый пакет должен иметь уникальный номер и после загрузки база отчетов должна послать коммит подтверждения загрузки в себя данных, после чего 1С сможет удалять у себя данные из таблицы изменений (снимать записи с регистрации) отправленные по тому номеру сообщения, который приняла база отчетов. Где будет происходить конвертация строк, в 1С или в базе отчетов не так важно, это скорее зависит от того, где дешевле выполнять доработки ззаказчику при необходимости расширить функционал.
Все перечисленные работы вполе реально сделать в одиночку за неделю. Включая составление документации и пром. тестирование.
Пишите запросы для отчетов и выгрузок оптимально. Не можете написать оптимально? Меняйте архитекутуру хранения данных, чтобы написать оптимально.
90% проблем быстродействия связаны с некомпетентностью людей, предлагающих кастомные решения.
А чем усложнили то? И террабайтные базы 1С работают вполне себе шустро. Я бы сказал, что в некоторых моментах dba проще, чем с другими системами, т.к. им не надо задумываться об индексах, о полнотекстовом поиске, это все в зоне ответственности архитекторов 1С. Так же как и оптимизация планов выполнения запросов и установка управлчемых блокировок.
Ну на самом гитхабе можно нажать «Customize your pinned repositories» и выбрать «Repositories you contribute to» который покажет в том числе и проекты, форки которых были удалены.
Так что как минимум эта информация у них есть, хотя, возможно через API напрямую она не доступна.
Ну вот эти же ребята сделали :)
https://opensourcecontributo.rs/
Вообще-то именно так это и работает. Автоматизированная проверка конфигурации. Требование разрабатывать юнит тесты на свой код. Если ошибок автоматических нет и юнит тесты не выдали ошибок — выполнить код ревью. И так это работает не только в командах с 1С новичками, а в любых командах)
Зависит от способностей юниора. Обычно от полугода до двух лет. И речь не о сертификации и экзаменах от самой 1С, а о внутреннем устройстве команды разработки.
У всех разный уровень знаний и разное понимание красивого кода, потому надо придерживаться стайл гайда единого, и этот стайл гайд есть стандарты разработки. Это соглашение о том, что хорошо, а что плохо. Не зная их даже оценить ни свой ни чужой код нельзя, либо эта оценка будет субъективной. Требовать от только что пришедшего программиста красивого кода можно только если принято соглашение о том, как и что нужно разрабатывать.
Можете написать свои стандарты, но вряд ли вы это сделаете лучше и учтете все нюансы, которые аккумулируются в стандартах от 1С последнее десятиление.
В python тоже очень низкий порог вхождения, можно сесть и начать писать. Сразу. Но не придерживаясь стайл гайда (например, от Гугла https://google.github.io/styleguide/pyguide.html) можно натворить делов.
В javascript тоже очень низкий порог вхождения, и опять же — если писать не придерживаясь стандартов будет хаос (https://standardjs.com/)
В чем разница подготовки специалистов 1С от подготовки любого другого инженера?
В лени руководителей? В том, что за 1С они не замечают всего остального мира?
1C — это прекрасный инструмент, и хаять надо в первую очередь не его, а тех, кто не умеет им пользоваться. Если что-то нельзя сделать с помощью 1С — это можно сделать иначе. Но чтобы понимать что и как надо делать — надо растить специалистов.
Цитата из https://habrahabr.ru/company/1c/blog/273591/
Нехрен давать коммитить в продакшин новичкам, пусть сначала пройдут внутреннюю аттестацию по стандартам https://its.1c.ru/db/v8std
Continuous Delivery, Code Review: не — не слышали. 1С, как компания, виновата в том, что код новичка попал в рабочую базу) Зашибись подход)))
Настольная книга 1С: Эксперта по технологическим вопросам http://v8.1c.ru/metod/books/book.jsp?id=499
Пожалуйста, сначала прочитайте зачем нужна объектная модель, а зачем модель запросов, а потом рассуждайте об удачных и неудачных моделях.
xDD
Свой ник как точка входа в новый мир бесплатных инструментов 1С)
Лучше не придумать!
Не злоупотребляйте
https://its.1c.ru/db/v8std#content:-2145782877:hdoc
см. синтаксис помощник ПредопределенноеЗначение():
Результат выполнения кэшируется при первом обращении до изменения конфигурации или версии платформы.
Еще есть ОбщегоНазначенияКлиентСервер.ПредопределенныйЭлемент с кэшированием на время сеанса и проверкой существования предопределенного в ИБ.
А еще с недавних пор (БСП 2.4.3 вроде) ОбщегоНазначения.ЗначенияРеквизитовОбъекта можно вызывать с передачей имени предопределенного и сразу получать его значение (только на сервере).
В любом случае это не то, чем является клиент-серверный вариант
https://youtu.be/0RY9u_mSDcU?t=1365
см. 22:45
ИТ-разработчиков
Конечно хорошо! Наоборот, хочется, чтобы конкурсов было как можно больше. Именно соревновательных конкурсов, выявление талантов, продвижение студентов. Именно потому от конкурса ожидается то, что это будет не генерация идеи и дарственная банку, а некоторый способ засветиться и, возможно, присоединиться к сильной команде. Этот конкурс не понятно на кого рассчитан. Эксперты вряд ли в нем захотят участвовать, их время и так стоит дорого, зачем им шанс выиграть, когда им за их работу просто заплатят. А для студентов — это выглядит слишком не честным, человек придумал, продал банку. Зачем? Они могли установить условием открыть стартап и войти в долю так, чтобы инвестировать в мозги, а не пытаться их использовать и выбросить. Именно от этого и идет весь негатив к конкурсу.
В условиях быстроразвивающегося бизнеса и постоянных изменений бизнес-процессов "работает не трогай" звучит как "давайте не будем зарабатывать деньги".
Эта технология устарела, более не развивается. Ее сложно адаптировать под новые задачи. И еще сложнее поддерживать. Конечно, если подразуиевается, что система не висит мертвым грузом.
Сейчас если компания не развивает ай-ти — то ей не на что надеяться.
ИТ-разработчиков
Небольшой ликбез для тех, кто захочет участвовать в конкурсе, и при этом не хочет, чтобы его наработки были признаны не защищенными законом об авторских правах:
Необходимо, чтобы исходные коды были подписаны, таким образом имелась гарантия в том, что они сделаны вами, но при этом с обязательным условием временной метки. Без временной метки по подписи можно доказать, что код написали вы, но невозможно доказать, что вы написали код первым.
Либо нужен специальный сертификат ЭЦП, либо финт ушами в роли распечатки исходников и отправки самому себе по почте, хотя еще и с Почтой России связываться...
ИТ-разработчиков
Хорошая попытка, Сбербанк, но нет.
Кто-то еще использует технологию 15-ти летней давности?
Не нужно к операции "+" относится именно как к сложению в стандартном его понимании. Считайте это просто какой-то операцией, выполняя которую над определенным множеством это множество можно назвать группой.
На самом деле, вся проблема в том, что Вы предлагаете использовать ПолучитьСтруктуруХраненияБазыДанных не по назначению. Полагаться на результат работы данного метода для разработки непосредственных обращений — неправильное решение.
Данный метод существует непосредственно для самих 1Сников. Можно подумать, "Зачем 1Сникам знать низкоуровневую структуру базы данных, если вы все работаете с объектной моделью?". Так вот, он и сделан для того, что бы 1Сники не задумывались об этой низкоуровневой структуре. Так зачем же он нужен?
Запросы в 1С — тоже объектно ориентированные, и работают с типизированными данными, фактически это значит, что по значению колонки, если знать какой тип объекта в ней хранится, можно получить данные вложенного объекта по ссылке, при этом будет неявно выполнено соединение с таблицей, хранящей вложенный объект.
Само собой такие запросы просто так на СУБД не выполняются, предварительно они транспонируются в такой запрос, который понимает СУБД. Но проблема в том, что каждая СУБД может по своему понимать один и тот же запрос 1С. Да еще и перед выполнение запроса СУБД строит план выполнения запроса, который рассчитывается динамически от состава запрашиваемых данных, текущего объема таблиц, и еще множества разных факторов (составы индексов, кластерный индекс, знание о количестве выбираемых строк и.т.д.). Как следствие в некоторых случаях планы выполнения запроса к реляционным таблицам могут быть не оптимальны.
1С позволяет записывать в технологический журнал информацию о том, для какого запроса какой план выполнения был получен у СУБД, а этот план строится самой СУБД и в нем фигурируют именно имена таблиц самой СУБД. Вот для восстановления реальных имен объектов 1С для анализа запросов и их оптимизации и есть метод ПолучитьСтруктуруХраненияБазыДанных.
Примерно так это все выглядит. Специальные инструменты разработчика, как та же "Консоль запросов", запускаемая в режиме 1С: Предприятие и входящая в состав поставки Библиотеки Стандартных Подсистем, является примером.
Самое главное не написали:
Реализация «высокоуровневого» интерфейса
От чего прозрачная поддержка и адаптируемость к новым требованиям на будущее.
Реализация на СУБД
Вопрос с же с производительностью всегда является спорным, при оптимизации запросов чтения и формирования DTO пакетов, определения оптимального размера самого пакета данных, выбором периодичности сообщений обмена, можно даже на медленном сервере с большой базой данных добиться хорошей производительности.
Каждый сапер ошибается только дважды — первый раз при выборе профессии.
Не очень понятно зачем делать какие-то буферные таблицы или файлы, когда сама платформа предлагает для этого механизм планов обмена. На низком уровне происходит так:
Если нужно выпонять какой-то тип обмена с другой системой, разработчик создает новый план обмена и включает в него те объекты 1С, которые должны передаваться в другую систему. Для каждого такого объекта платформа сама создаст таблицу изменений, в которую будет включен идентификатор записи (для справочников и документов, например — это ссылка, а для регистров — это ключ записи) и будет включен узел, в который необходимо отправить данные.
При записи объекта (например при изменении номенклатуры или создании нового документа) если для объекта есть таблица изменений, то он будет там зарегистрирован к отправке (само по себе это платформа выполняет автоматически, однако программно регистрировать и снимать с регистрации тоже можно).
Если есть несколько разных отчетных баз одного типа, то для них достаточно сделать один план обмена в котором уже в режиме предприятия создать несколько узлов, для каждой отчетной базы свой узел. Система благодаря своей структуре таблицы изменений для каждого узла будет регистрировать данные отдельно.
План обмена так же включает в себя по умолчанию номера принятых и отправленных сообщений, это необходимо для подтверждения доставки. Чтобы избежать таких случаев, когда данные в отчетную систему были отправлены, но при этом отчетная база их не приняла. При следующем обмене отправляться будут в том числе и те записи, которые отчетная база не приняла ранее, чтобы гарантировать целостность передачи. Для этого и вводится дополнительная операция — коммит подтверждения доставки. Когда 1С отправляет какие-либо данные она в таблице изменений сохраняет тот номер пакета сообщения, который она отправила и в дальнейшем когда отчетная система пришлет коммит о том, что она этот номер сообщения приняла, 1С может со спокойной совестью снять все данные с регистрации, отправленные по этому номеру сообщения.
Если обмен является двухсторонним, то обычно коммитом является получение пакета из другой базы, если обмен односторонний (как это с выгрузкой в отчетную базу) достаточно реализовать операцию подтверждения).
Сам способ отправки может быть любым. Можно создать регламентное задание, которое будет из 1С по расписанию выгружать данные в стороннюю систему, можно выгружать в файлы, можно записывать непосредственно в базу приемник (все равно какая, 1С может записывать и MySQL, MSSQL, Postgres, Oracle, IBM DB2, вообще во все, для чего есть драйвер подключения к этой базе.
Но делать непосредственные выгрузки так же как инициировать обмен из 1С — это не самая хорошая практика, лучше, когда данные запрашивает та система, которой эти данные нужны. Так же как записывать куда то в стороннее хранилище данные непосредственно тоже не очень правильно, ведь структура данных и в 1С и в сторонней базе может со временем измениться, бизнес требует частых доработок. Потому правильным считается приведение сначала к общему формату обмена, и после отправку и приемку.
Опять же что это будет за формат — не очень важно для 1С, это может быть XML, JSON, какой-то бинарный файл или просто текстовый (тот же CSV) формат, главное чтобы приемная база могла его понять и формат был согласован.
Протокол отправки то же не очень важен, сторонняя система может просто стучаться по COM, на 1С может быть реализован веб-сервис по формату SOAP или сразу передавать ответ, выполнив запрос к 1С по HTTP, ровно как и выгружать в файл на диск или ftp. Тут скорее надо определить что из этого доступно в базе которая хочет интегрироваться с 1С.
Все механизмы подробно описаны в книжке
Профессиональная разработка в системе 1С: Предприятие 8
Так же многие нюансы описаны в книжке
Настольная книга 1С: Эксперта по технологическим вопросам
Выгружать данные в какую либо отчетную систему непосрндственно не кажется правильным. Ведь та структура данных, которая положена в 1С, сделана такой для внутренних отчетов или механизмов контроля учета (например остатков) самого 1С. Отчетной системе, консолидирующей данные из разных источников, в т.ч. из 1С, может требоваться иная структура данных для формирования своих отчетов. В первую очередь следует провести сопоставление данных и формально описать правило конвертации одной строки записи 1С в строку записи таблицы DWH. Создать в 1С план обмена, в который будет включен узел, соответствующий базе данных отчетов. Включить для этого плана обмена регистрацию изменений для выгружаемой таблицы. Таким образом все новые или удаленные записи будут записаны к отправке. Далее каким либо образом DWH будет инициировать обмен, запрашивая, есть ли для нее новые данные в 1С, например можно поднять веб-сервис SOUP или HTTP прям из 1С. 1С в ответ будет формировать пакет данных, требуемый для базы отчетов. Каждый пакет должен иметь уникальный номер и после загрузки база отчетов должна послать коммит подтверждения загрузки в себя данных, после чего 1С сможет удалять у себя данные из таблицы изменений (снимать записи с регистрации) отправленные по тому номеру сообщения, который приняла база отчетов. Где будет происходить конвертация строк, в 1С или в базе отчетов не так важно, это скорее зависит от того, где дешевле выполнять доработки ззаказчику при необходимости расширить функционал.
Все перечисленные работы вполе реально сделать в одиночку за неделю. Включая составление документации и пром. тестирование.
90% проблем быстродействия связаны с некомпетентностью людей, предлагающих кастомные решения.
Так что как минимум эта информация у них есть, хотя, возможно через API напрямую она не доступна.
Ну вот эти же ребята сделали :)
https://opensourcecontributo.rs/