Комментарии 59
1С конечно хороший продукт для разработки прикладных учетных программ, но бесполезен при создании чего-то особенного, например, нельзя создать собственный объект, например, справочник со свойствами регистров, приходится выкручиваться через «связку» этих объектов
Почему вам нужно что-то особенное создавать на 1С? Система же, как раз для разработки прикладных учетных программ. Никто вроде не заявляет, что она универсальная и ставить ей это в минус как минимум странно.
Да, 1С специально предназначен для для разработки прикладных учетных программ. Хотя, если смотреть на продукты 1С, то становится ясно, что на базе одной и той же технологической платформы можно создавать конфигурации для довольно широкого круга задач. Довольно много вещей хорошо укладывается в «прокрустово ложе» заданных объектов конфигурации (справочников, документов, регистров, обработок).
Ваш вопрос относительно справочника со свойствами регистра обоюдоострый.
С одной стороны, всё это упирается в необходимость менять технологическую платформу. Это возможно. Либо нужно вводить дополнительный уровень абстракции, чтобы иметь собственный «конфигуратор» для технологической платформы. Либо существенно дополнить список допустимых объектов теми объектами, которые естественным образом возникают при решении задач, отличных от задач учёта. Состав объектов конфигурации завязан на учётные задачи, но работу по выявлению новых объектов конфигурации можно продолжить и довести до своего логического конца. Но, боюсь, это приведёт к необходимости делать такую продвинутую технологическую платформу частью операционной системы.
Представьте, что будет, если сделать операционную системы чем-то вроде 1С. Это будет означать, что прикладные программисты будут иметь дело только с объектами конфигурации (им не надо будет иметь дело даже с файлами, если операционная система сама будет документно-ориентированной!).
С другой стороны, Ваше желание совместить в одном объекте разные функции разрушает сам подход к организации объектов конфигурации. Смысл подхода заключается именно в том, чтобы каждый объект решал свою задачу. Если хотите, то тут возникает что-то вроде ортогонализации Грамма-Шмидта, которая позволяет перейти от любой линейно независимой системы векторов к ортонормированной системе, в которой скалярные произведения записываются наиболее просто без смешения разноименных элементов. Если бы кто-нибудь сумел проделать аналогичный процесс в программировании, то мы могли бы собирать любые приложения из кубиков-компонентов.
Ваш вопрос относительно справочника со свойствами регистра обоюдоострый.
С одной стороны, всё это упирается в необходимость менять технологическую платформу. Это возможно. Либо нужно вводить дополнительный уровень абстракции, чтобы иметь собственный «конфигуратор» для технологической платформы. Либо существенно дополнить список допустимых объектов теми объектами, которые естественным образом возникают при решении задач, отличных от задач учёта. Состав объектов конфигурации завязан на учётные задачи, но работу по выявлению новых объектов конфигурации можно продолжить и довести до своего логического конца. Но, боюсь, это приведёт к необходимости делать такую продвинутую технологическую платформу частью операционной системы.
Представьте, что будет, если сделать операционную системы чем-то вроде 1С. Это будет означать, что прикладные программисты будут иметь дело только с объектами конфигурации (им не надо будет иметь дело даже с файлами, если операционная система сама будет документно-ориентированной!).
С другой стороны, Ваше желание совместить в одном объекте разные функции разрушает сам подход к организации объектов конфигурации. Смысл подхода заключается именно в том, чтобы каждый объект решал свою задачу. Если хотите, то тут возникает что-то вроде ортогонализации Грамма-Шмидта, которая позволяет перейти от любой линейно независимой системы векторов к ортонормированной системе, в которой скалярные произведения записываются наиболее просто без смешения разноименных элементов. Если бы кто-нибудь сумел проделать аналогичный процесс в программировании, то мы могли бы собирать любые приложения из кубиков-компонентов.
Лично нам зачастую не хватает просто таблиц. Платформа не дает возможности писать запросы на изменение (update). Даже регистр сведений при работе с ним как с набором записей (когда условие отбора можно свести к равенству) при записи делает в СУБД не update, а delete и insert. Соответственно при длительном выполнении операции другие сеансы видят то пропадающие, то появляющиеся данные.
это не связано с версионностью базы данных?
не думаю. в профайлере видим delete from… после этого записи исчезают. после завершения insert записи появляются. пишется набор записей с >10К записей
upd: чтение в другом сеансе не в транзакции. соответственно управляемые блокировки не используются (да и не хочется ожидание)
upd: чтение в другом сеансе не в транзакции. соответственно управляемые блокировки не используются (да и не хочется ожидание)
Может быть, это и хорошо. Определённые ограничения на действия программиста должны обеспечить целостность конструкции. Другое дело, что это оборачивается не такой эффективностью вычислений, какой можно было бы добиться при помощи явного составления прямых запросов к БД и применения оптимизации. За всё приходится платить.
Но!
Всегда есть вероятность того, что при ином построении конфигурации какие-то вещи станет выполнять проще. Возникает вопрос: а что это за задача такая, где необходимо переписывать содержимое регистра?
Но!
Всегда есть вероятность того, что при ином построении конфигурации какие-то вещи станет выполнять проще. Возникает вопрос: а что это за задача такая, где необходимо переписывать содержимое регистра?
Задача специфическая (как и всегда :-)). По многим филиалам заполняется срез определенных данных и стекается в центральный офис. Срез удобнее формировать, т.к. для конкретной задачи история не важна, а само получение данных из вспомогательных занимает слишком продолжительное время. Записывать этот срез
удобнее набором записей, а не по записи. Вот и получается, что в момент обновления пользователь в динамическом списке видит, что данные пропали.
удобнее набором записей, а не по записи. Вот и получается, что в момент обновления пользователь в динамическом списке видит, что данные пропали.
Зачем здесь нужно переписывать содержимое регистра? Зачем нужен UPDATE?
Не совсем понял вопрос… Данные обновляются периодически. update решил бы проблему с тем, что запрос на чтение не возвращает данные до того момента как будет выполнена запись.
Это касается и перепроведения документов, в случае очистки движений. запрос в другом сеансе видит исчезновение записей
Это касается и перепроведения документов, в случае очистки движений. запрос в другом сеансе видит исчезновение записей
Я думал, что такие проблемы решаются на уровне СУБД. По моим (правда, сильно устаревшим) представлениям, регистры более всего «заточены» именно под постоянное добавление новых данных. Да, регистры сведений предусматривают перезапись. Но без полного и точного описания Вашей конкретной ситуации, трудно понять, что лучше всего следует делать. Может быть, Вам нужны периодические регистры (регистры с отметкой времени в качестве одного из измерений), чтобы запросы всегда получали актуальную информацию на момент запроса? Может быть, и отмена проведения не потребуется — я не знаю.
Что еще интересно. Этот подход обеспечивает постоянное развитие системы. Мы добавляем в платформу новые механизмы, и они сразу начинают работать для уже существующих объектов (без усилий разработчика приложений или с минимальными усилиями). Например, недавно мы разработали механизм хранения истории данных (версионирования). Так как система знает в общем виде о семантике данных, то разработчику достаточно поставить флажок, что он хочет хранить историю данных конкретного объекта, и платформа обеспечивает все, что нужно, от хранения истории, до визуализации — отображения пользователю истории изменений в виде различных отчетов.Здорово. А как это выглядит на практике? Речь идёт, например, о конкретном справочнике, или об объекте, который описывается отдельной строкой-записью в этом справочнике?
Пока мы все-таки стараемся удержаться от введения «просто таблиц», чтобы обеспечить чистоту модели и возможность добавлять новую функциональность, опираясь на знание о семантике всех данных. Если каких-то возможностей не будет хватать, то вначале мы все-таки будем рассматривать то, как можно развить состав типов прикладных объектов. Но, конечно, это вопрос дискуссионный и мы будем продолжать про него думать.Не надо вводить «просто таблицы». Лучше попытаться вести новые типы данных (объекты конфигурации): «НаборДанных» (для хранения самих неструкутрированных изначально данных), «МодельДанных» (для описания принципов хранения: «ключ-значение», «документ», «расширяемая запись» и т.д. и т.п.) и «РегистрМетаданныхНаборовДанных» (для описания конкретных обрабатываемых в системе данных). Для решения каждой задачи создаётся свой набор данных, выбирается для него модель, формируется своя схема данных, которая отражается в регистре. Возможно, здесь потребуется принципиально новый объект конфигурации, вроде того, который был нужен Almet'у: справочник со свойствами регистра. Здесь нужна возможность доступа по ключу (по определённой системе «разрезов»), но и возможность ссылки на объект справочника. Получается, что мы, как бы, сначала заглядываем к регистр (со связкой ключей-измерений), чтобы узнать уникальный линейный код объекта, и уже из простого линейного справочника берём всё остальное.
Таким образом, возможности, которые предоставляет в готовом виде платформа 1С: Предприятия и то повышение уровня абстракции, которое ценится прикладными разработчиками, во многом опираются именно на набор типов прикладных объектов. Это является одним из наиболее существенных отличий 1С: Предприятия от других средств разработки и одним из главных инструментов, обеспечивающих быструю и унифицированную разработку.А кто они, конкуренты? Тут одно из двух: либо конкурентов нет, потому как 1С — практически единственная компания, которая использует подход, основанный на типологии прикладных объектов, либо такой подход используется другими компаниями, но в других областях, и, поэтому, прямой конкуренции не получается. Выбранный подход кажется вполне естественным. Вроде бы, все должны заниматься этим. Может быть, всему виною ниша, выбранная 1С, и заблуждение большинства пользователей и разработчиков, что подход 1С — это удел только учётных систем? Ведь, самый главный вопрос разработки программного обеспечения — это то, какова модель управления данными. Если есть подход у правлению, то он общезначим и относится ко всем случаям и ситуациям. ЯТД.
Здорово. А как это выглядит на практике? Речь идёт, например, о конкретном справочнике, или об объекте, который описывается отдельной строкой-записью в этом справочнике?
Об объекте, который описывается отдельной строкой-записью. В статье довольно подробно описано.
Спасибо. Очень информативно.
НЛО прилетело и опубликовало эту надпись здесь
Есть успешные примеры реализации бизнес-софта на этом лучшем архитектурном решении?
НЛО прилетело и опубликовало эту надпись здесь
Не имею понятия. Имелась ввиду идейная составляющая.
Идея может казаться сколь угодно прекрасной, но если с помощью её нет успешных реализаций требуемых задач — есть сомнения, что идея подходит для решения задач из данной предметной области.
Как можно не использовать таблицы ??? Таблица не versus модели. Заголовком вы показали или скрыли: О)))) свой уровень одинэсника. ПТУ отдыхает.
Не буду отвечать — не хочу опускаться с уровня своего ПТУ до вашего уровня.
А кто они, конкуренты?
Давайте посмотрим сюда. Например, на диаграмму из первой ссылки:
Собственно, вот и конкуренты.
А используют ли они подход, основанный на типологии прикладных объектов, или какой-то другой — конкурентами они от этого быть не перестанут.
Картинка красивая, но вызывает чувства противоречивые. С одной стороны, хочется присоединиться к лидеру. С другой — потеснить его. Если говорит серьёзно, то с чем в этом списке присутствует Microsoft? Как это у них называется? Аксапта? Навижн? А Oracle? Ещё я слышал когда-то о Компасе. У них тоже, вроде, есть какая-то своя типология объектов предметной области?
Если говорит серьёзно, то с чем в этом списке присутствует Microsoft?
Есть Navision; недавно появилась облачная версия.
Есть Axapta.
Есть еще Solomon и Great Plains, но об их внедрениях в России я пока не слышал.
Есть еще Microsoft CRM, но тут речь про ERP продукты, CRM к ним вроде бы не относится. Хотя составители графика могли и CRM учесть.
А Oracle?
Есть Oracle E-Business Suite, есть еще Oracle Commerce, Oracle Retail, Micros и т.д…
Ещё я слышал когда-то о Компасе.
Про Компас знаю пока очень мало. Если у вас есть ссылки на профильные материалы — буду благодарен.
Про продукты Epicor знаю побольше — ранее работал в этой компании. Типологии предметной области (по крайней мере в Epicor и iScala) нет, подход к разработке прикладного кода скорее классический.
Кстати о таблицах и запросах. Почему не используется стандарт SQL. Сейчас запросы не соответствуют даже SQL-92. Exists. Есть только IN. Нет скалярных подзапросов. Уже куча языков поддерживает OFFSET,FETCH итд.
Кроме того при записи документов регистров не используется аналог Merge. А именно удаляется весь старый набор, даже если там изменена одна запись и записывается новый набор.
Кроме того при записи документов регистров не используется аналог Merge. А именно удаляется весь старый набор, даже если там изменена одна запись и записывается новый набор.
Просто если взят тот же Linq to EF с их ограничениями на модель, но там язык более продвинутый Linq to EF. Практика использования. Часть III
согласен в целом
правда EXISTS легко заменяется через IN
правда EXISTS легко заменяется через IN
При проведении документов поведение удаления движений можно настраивать.
— Удалять автоматически при отмене проведения
— Удалять автоматически
— Не удалять автоматически
Стандарты SQL описывают запросы к реляционным базам, а запросы 1С — запросы к объектно ориентированной модели данных. Не правильно их сравнивать по возможностям.
Есть хоть один практически необходимый пример использования OFFSET или FETCH? Или может быть Вы с помощью запросов сделать пытаетесь то, что решается архитектурно иначе?
— Удалять автоматически при отмене проведения
— Удалять автоматически
— Не удалять автоматически
Стандарты SQL описывают запросы к реляционным базам, а запросы 1С — запросы к объектно ориентированной модели данных. Не правильно их сравнивать по возможностям.
Есть хоть один практически необходимый пример использования OFFSET или FETCH? Или может быть Вы с помощью запросов сделать пытаетесь то, что решается архитектурно иначе?
Еще раз про удаление.
У тебя есть набор в котором изменена 1 запись. Как этот набор запишется?
OFFSET или FETCH нужны для постраничного получения данных для сайтов и прочих выборок
У тебя есть набор в котором изменена 1 запись. Как этот набор запишется?
OFFSET или FETCH нужны для постраничного получения данных для сайтов и прочих выборок
Кстати я не зря привел ссылку на Linq to EF. Там как раз идеология та же самая, а возможностей больше. При этом в отличии от 1С обращение к выборкам результата еще и типизировано.
Хотелось бы еще и аннотацию типов как в TypeScript
Хотелось бы еще и аннотацию типов как в TypeScript
Покрутить Linq to EF можно?
Конечно. Здесь все ссылки Как вызвать метод из C# в 1С?
Интересная картина получается, модель затачивается исключительно под «быструю разработку», принося в жертву производительность, и даже возможность как бы то ни было повлиять на эту производительность программными методами, вынуждая закидывать проблемы деньгами: «купите железо еще быстрее».
И самое интересное что этот подход работает: железо дешевле и проще приобрести чем разработчиков.
И самое интересное что этот подход работает: железо дешевле и проще приобрести чем разработчиков.
Так этот подход не только у 1С. Посмотрите лекции Яндекса по python. Сейчас вся разработка сводится к быстрому получению результата и вводу его в продакшн, потому что бизнес требует быстрых и частых изменений, потому и для систем учета это особенно важно. Ну а если железо не помогает узкие места производительности можно вынести во внешние компоненты 1С, которые можно написать, например, на C++. Ну а проблемы с параллельностью обработки данных (например взаимоблокировки) вполне успешно и средствами 1С решаются.
На мой чисто субъективный взгляд, возможность совместить быструю разработку и высокую производительность можно будет успешно решить только, если часть технологической платформы встроить в операционную систему (что кажется довольно логичным). Монолитность программного обеспечения порождает проблемы. Но ещё никто не сказал, что нельзя сделать само отображение предметной области на объектную модель данных эффективнее чем это сделано, например, в 1С.
В случае с 1С, правда, срабатывает ещё и такой аргумент: лучше медленная, но прозрачная и, значит, управляемая система с устоявшейся терминологией и устоявшимся рынком поддержки, чем шустрая система с постоянно меняющейся терминологией и без толковой службы поддержки. Я могу ошибаться, но, я думаю, что консерватизм нередко заставляет отказываться от более эффективного в пользу более привычного.
В случае с 1С, правда, срабатывает ещё и такой аргумент: лучше медленная, но прозрачная и, значит, управляемая система с устоявшейся терминологией и устоявшимся рынком поддержки, чем шустрая система с постоянно меняющейся терминологией и без толковой службы поддержки. Я могу ошибаться, но, я думаю, что консерватизм нередко заставляет отказываться от более эффективного в пользу более привычного.
Конкуренты из SAP кстати так и делает, но об этом не принято говорить. Потому что там выходит в десятки раз дороже железки.
Я когда имел неосторожность работать в конторе которая внедряла в первую очередь SAP и 1С чтобы было… Там были постоянные гонения на 1С. На SAP стояли мощнейшие сервера, а под 1С предлагали использовать файловые сервера и еще постоянно сверху письма шли мол что это отдел 1С забил весь файловый сервер… Купили бы для 1С сервера как для SAP проблем бы не было. Как будто нам было охота на медленном файловом сервере гонять базы. А потом все ноют что 1С якобы медленная.
Я когда имел неосторожность работать в конторе которая внедряла в первую очередь SAP и 1С чтобы было… Там были постоянные гонения на 1С. На SAP стояли мощнейшие сервера, а под 1С предлагали использовать файловые сервера и еще постоянно сверху письма шли мол что это отдел 1С забил весь файловый сервер… Купили бы для 1С сервера как для SAP проблем бы не было. Как будто нам было охота на медленном файловом сервере гонять базы. А потом все ноют что 1С якобы медленная.
Есть планы про расширению функционала отборов в наборах записей?
Сейчас условие сравнения только на равенство и только для измерений, хотя поля могут быть проиндексированы.
Из-за этого часто приходится делать запрос и молотить построчно через менеджер записи.
Сейчас условие сравнения только на равенство и только для измерений, хотя поля могут быть проиндексированы.
Из-за этого часто приходится делать запрос и молотить построчно через менеджер записи.
Я сильно далек от 1С, но хорошо знаю EMF. Смотрю вы на Эклипс перешли, так для моделей данных там как раз EMF имеется. Мэппинг в БД для него есть, сериализации разные тоже. Generic работа чере eSet/eGet/etc методы и т.д.
«Я сильно далек от 1С» я вот наоборот далек от «eSet/eGet/etc», но запомнил как пол года будучи уже 1Сником разрабатывал складскую программу на Дельфи под Файрбёрд. Так вот я потратил где-то 2 недели.
Но когда я попробовал повторить все то же самое на 1С у меня ушло 4 часа. И все благодаря объектной модели 1С (тогда ее семерки). В те времена было вообще не принято в 1С знать как реально лежат данные. И вы хотите чтобы наоборот замедлилась разработка, но зато по было все по стандартам из других языков программирования?
Но когда я попробовал повторить все то же самое на 1С у меня ушло 4 часа. И все благодаря объектной модели 1С (тогда ее семерки). В те времена было вообще не принято в 1С знать как реально лежат данные. И вы хотите чтобы наоборот замедлилась разработка, но зато по было все по стандартам из других языков программирования?
мы говорим не о техническом аспекте хранения и манипулирования данными, а об описании данных как способе проектирования приложения— а как оптимизировать доступ к данным при большом их количестве? Понятно, что вы упростили жизнь себе, как архитекторам системы, но усложнили жизнь DBA и эксплуатантам!
А чем усложнили то? И террабайтные базы 1С работают вполне себе шустро. Я бы сказал, что в некоторых моментах dba проще, чем с другими системами, т.к. им не надо задумываться об индексах, о полнотекстовом поиске, это все в зоне ответственности архитекторов 1С. Так же как и оптимизация планов выполнения запросов и установка управлчемых блокировок.
Насколько я знаю, вопросы оптимизации запросов в базах 1С стоят остро. Размер базы ещё не определяет потенциальные проблемы с быстродействием.Прежде всего проблемы с кастомными отчётами, выгрузками в хранилище данных и так далее.
Почему-то вспоминается совет-наставление, которое давали на курсах по 1С: структура регистров должна быть заточена под будущие отчёты: каковы отчёты, таковы и должны быть регистры. Если есть возможность предусмотреть специальный регистр, который помогает составлять некоторый отчёт, то этот регистр обязательно нужно создавать. Ну и, конечно, никому не помешает универсальный совет: составляйте изначально максимально оптимальные запросы к базе данных. Если есть возможность сделать внешнее соединение, то его обязательно нужно сделать. Была бы таблица (например, регистр), а соединение найдётся.
Пишите запросы для отчетов и выгрузок оптимально. Не можете написать оптимально? Меняйте архитекутуру хранения данных, чтобы написать оптимально.
90% проблем быстродействия связаны с некомпетентностью людей, предлагающих кастомные решения.
90% проблем быстродействия связаны с некомпетентностью людей, предлагающих кастомные решения.
мой совет — улучшайте встроенный язык, всё равно ни один бухгалтер в конфигуратор не полезет, а простота языка должна остаться в прошлом… и отучите разработчиков типовых конфигураций писать процедуры на несколько сотен, а то и тысяч строк!
+1 Все таки не хватает функций первого класса и анонимных функций, концепция для прикладного программиста проста (если не мудрить), но возможностей дает очень много…
Запросы в 80т строк как делить?
А процедуры в тысячи строк — это не code smells?
Просто для 1с довольно часто норма совсем не изучать программирование, а изучать предметную область. У нас на работе я единственный кто совершенный код макконела читал (на почти десяток программистов в отделе), с чистым кодом та же история, про работу того же http протокола никто не в курсе. Про SOLID тоже никто не слышал, а ведь у многих опыт работы за 10 лет переваливает, по сравнению с моими тремя годами. С другой стороны — все остальные увешаны 1сными сертификатами на знание платформы и прикладных решений, и знают как стандартными способами некоторые часто встречаемые задачи решать.
А как, например, из регистра накоплений производится выгрузка в таблицы фактов DWH? Это проблема интерфейса на стороне Data Integration Tool, которым будут забирать данные, или у вас есть что-то готовое для прямой интеграции (не через файлы и т.п.)?
Сорри, не сталкивался с 1С.
Сорри, не сталкивался с 1С.
Выгружать данные в какую либо отчетную систему непосрндственно не кажется правильным. Ведь та структура данных, которая положена в 1С, сделана такой для внутренних отчетов или механизмов контроля учета (например остатков) самого 1С. Отчетной системе, консолидирующей данные из разных источников, в т.ч. из 1С, может требоваться иная структура данных для формирования своих отчетов. В первую очередь следует провести сопоставление данных и формально описать правило конвертации одной строки записи 1С в строку записи таблицы DWH. Создать в 1С план обмена, в который будет включен узел, соответствующий базе данных отчетов. Включить для этого плана обмена регистрацию изменений для выгружаемой таблицы. Таким образом все новые или удаленные записи будут записаны к отправке. Далее каким либо образом DWH будет инициировать обмен, запрашивая, есть ли для нее новые данные в 1С, например можно поднять веб-сервис SOUP или HTTP прям из 1С. 1С в ответ будет формировать пакет данных, требуемый для базы отчетов. Каждый пакет должен иметь уникальный номер и после загрузки база отчетов должна послать коммит подтверждения загрузки в себя данных, после чего 1С сможет удалять у себя данные из таблицы изменений (снимать записи с регистрации) отправленные по тому номеру сообщения, который приняла база отчетов. Где будет происходить конвертация строк, в 1С или в базе отчетов не так важно, это скорее зависит от того, где дешевле выполнять доработки ззаказчику при необходимости расширить функционал.
Все перечисленные работы вполе реально сделать в одиночку за неделю. Включая составление документации и пром. тестирование.
>> В первую очередь следует провести сопоставление данных и формально описать правило конвертации одной строки записи 1С в строку записи таблицы DWH.
Здесь же речь об одной строке записи прикладного объекта 1С?
>> Создать в 1С план обмена, в который будет включен узел, соответствующий базе данных отчетов. Включить для этого плана обмена регистрацию изменений для выгружаемой таблицы. Таким образом все новые или удаленные записи будут записаны к отправке.
А есть где-то описание механизма на стороне 1С? Best practice какой-нибудь? С чего стоит начать разбираться в вопросе ETL-щику, который не работал с 1С? Хочется понимать, как люди это делают правильно.
Google говорит, народ инициирует на стороне 1С выгрузку в буферную таблицу/файл, а оттуда уже забирает в DWH. Но все-равно придется как-то бить на серии «новые/обновленные/старые записи».
Здесь же речь об одной строке записи прикладного объекта 1С?
>> Создать в 1С план обмена, в который будет включен узел, соответствующий базе данных отчетов. Включить для этого плана обмена регистрацию изменений для выгружаемой таблицы. Таким образом все новые или удаленные записи будут записаны к отправке.
А есть где-то описание механизма на стороне 1С? Best practice какой-нибудь? С чего стоит начать разбираться в вопросе ETL-щику, который не работал с 1С? Хочется понимать, как люди это делают правильно.
Google говорит, народ инициирует на стороне 1С выгрузку в буферную таблицу/файл, а оттуда уже забирает в DWH. Но все-равно придется как-то бить на серии «новые/обновленные/старые записи».
Здесь же речь об одной строке записи прикладного объекта 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С: Предприятие 8
Так же многие нюансы описаны в книжке
Настольная книга 1С: Эксперта по технологическим вопросам
Интересно в 1С обращают внимание на море новых технологий и о том как они упращают разработку? Я не говорю про Java/C#, ведь есть уже JS фреймворки, объединяющие фронтенд и бэкенд. Что произойдет когда разработка бизнесс приложений на JS станет легче 1С Предприятия? Я не говорю о гитхабе и open-source сообществе, которые являются двигателем прогресса…
Понятно что на данный момент 1С прекрасно справляется со своими задачами, но что будет дальше? Ведь даже сам по себе язык 1С никак не эволюционировал, а работа с DB запрещена пользовательским соглашением. Все этот как бы идет против течения мирового тренда.
Понятно что на данный момент 1С прекрасно справляется со своими задачами, но что будет дальше? Ведь даже сам по себе язык 1С никак не эволюционировал, а работа с DB запрещена пользовательским соглашением. Все этот как бы идет против течения мирового тренда.
Что произойдет когда разработка бизнесс приложений на JS станет легче 1С Предприятия?
Значит, у нас появятся конкуренты.
Одного я уже знаю — Haulmont c платформой CUBA. На мой взгляд, там все еще на порядок сложнее разрабатывать бизнес-приложения, чем на 1С. Возможно, со временем это изменится.
Я не говорю о гитхабе и open-source сообществе, которые являются двигателем прогресса…
Enterprise Development Tools позволяет хранить исходные коды конфигураций в Github. Или вы имеете в виду что-то другое?
Все этот как бы идет против течения мирового тренда.
А в какую сторону течет мировой тренд? Можете обрисовать?
Язык 1с неплох пока не столкнешься с фоновыми заданиями.
отсутствие await и лямбд делает программирование «сексуально» не привлекательным, особенно для мобильных приложений или той же Розницы с колбеками.
Кроме того пора уже идти в сторону необязательной типизации «функция а(в как строка) как строка»
и дать механизм аналогичный тексовым запросам ввиде функции filter, map, fold (LINQ), не как сейчас сделано «для галочки», а удобно и с поддержкой среды и добавить туда например добавление нарастающего итога благо это есть во всех новых языках, а одинесников избавит от кучи кода и т д.
Кроме того хотелось бы иметь механизм правил обмена реализованный в мобильном приложении, да я извращенец, но когда надо быстро что то наклепать не хочется полдня заниматься "____".
отсутствие await и лямбд делает программирование «сексуально» не привлекательным, особенно для мобильных приложений или той же Розницы с колбеками.
Кроме того пора уже идти в сторону необязательной типизации «функция а(в как строка) как строка»
и дать механизм аналогичный тексовым запросам ввиде функции filter, map, fold (LINQ), не как сейчас сделано «для галочки», а удобно и с поддержкой среды и добавить туда например добавление нарастающего итога благо это есть во всех новых языках, а одинесников избавит от кучи кода и т д.
Кроме того хотелось бы иметь механизм правил обмена реализованный в мобильном приложении, да я извращенец, но когда надо быстро что то наклепать не хочется полдня заниматься "____".
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как мы в 1С: Предприятии работаем с моделями данных (или «Почему мы не работаем с таблицами?»)