Hello world на metadata.js
Программирование - Инструментарий
offline offline-first веб веб клиент веб приложение автономная работа javascript
Демо-задача
Автономное веб-приложения для учета движения наличных денег:
- Два справочника:
- Кассы (считаем, что кошельки, контрагенты, подотчетники и т.д. – это просто разные кассы)
- Статьи ДДС – для простейшей аналитики
- Один документ: Перемещение денег (куда, откуда, статья, сумма)
- Один отчет: Ведомость по денежным средствам
Приложение должно обеспечивать возможность ввода и редактирования документов как из веб-интерфейса, так и средствами 1С и сохранять работоспособность при недоступности сервера или поломках доступа в Интернет.
Чтобы не усложнять пример, ограничение прав на уровне записей не рассматриваем. Пользователь веб-приложения увидит и сможет изменять документы по всем кассам. В реальных задачах используется фильтрованная репликация, когда документы передаются в браузер с учетом RLS.
Результат
Живое демо доступно по ссылке: https://light.oknosoft.ru/helloworld/
- Движок легко справляется с тысячами одновременных сеансов
- Сервер 1С для обслуживания веб-клиентов не используется
- Публикации SOAP и HTTP сервисов не требуется
Содержание
- Подготовка базы 1С. Готовая dt-шка есть в прикрепленных файлах. Опишу, что именно делалось со стороны конфигуратора
- Подготовка инфраструктуры. Для отладки и публикации, нужны установленный локально NodeJS, а так же серверы CouchDB и Nginx. CouchDB и Nginx могут располагаться как на локальном компьютере, так и удаленно на любом компьютере в Интернет
- Настройка состава метаданных, а так же, синонимов и начальное заполнение, выполняются в режиме 1С:Предприятие
- Подготовка веб-приложения. Структуру каталогов и необходимые файлы развернём в любой удобной папке на локальном компьютере с помощью npm
- Публикация веб-приложения. Рассмотрим необходимые и достаточные шаги для публикации приложения в Интернет
Одно без другого недостаточно информативно.
Шаг №1 CouchDB
Выбору CouchDB для back-end metadata.js предшествовала большая работа. В первую очередь, рассматривался PostgreSQL, ставились эксперименты с MySQL, Couchbase и MongoDB, но я не смог устоять перед уникальными возможностями CouchDB:
- В разработку собственного движка синхронизации данных, я вложил не менее года, но когда увидел математику master-master репликации CouchDB, без сожаления выбросил своё творчество на помойку
- Запас масштабируемости – есть примеры систем на кластере CouchDB с посещаемостью 500 млн. запросов в сутки (до 10000 транзакций в секунду)
- 100% HTTP API – не требуются никаких бинарных драйверов
- Возможность подключить внешний низкоуровневый движок обработки запросов и построения индексов. Например, скрипт на NodeJS.
Прочтите последний пункт еще раз: Metadata использует для хранения данных CouchDB, которая, в свою очередь, может использовать метадату для низкоуровневого построения индексов и агрегатов!!!
С установкой CouchDB проблем не возникнет – готовые образы виртуальных машин Linux для VMDK, OpenStack, Xen, Docker, ProxMox или установочный iso-файл можно взять, например, в turnkeylinux. Исходные тексты и дистрибутивы для всех платформ доступны официальном сайте couchdb.org
После установки, необходимо выполнить два действия:
- Задать пароль администратора
- Указать в секции httpd, слушать все ip-адреса (установить bind_address = 0.0.0.0). По умолчанию, служба CouchDB, слушает только localhost и обратиться к серверу снаружи невозможно
Остальные настройки библиотека интеграции сделает из режима 1С:Предприятие.
Задачи CouchDB при взаимодействии с 1С:
- CouchDB предоставляет 1C-ке http интерфейс для записи и чтения произвольных данных. Повторюсь, в ранних редакциях metadata, предпринимались попытки использовать для этих целей файловую систему или базу SQL. Эти подходы имели проблемы с версионированием и удобством отслеживания и синхронизации изменений. CouchDB чем то похожа на Git, где с версионированием всё хорошо, но Git – это не база данных. Map/reduce индекса на нём не построишь.
Для простоты можно считать, что CouchDB – это такая штука, в которую 1С-ка в любой момент может без блокировок записать любой сериализуемый объект (в CouchDB запись и чтение неблокирующие. 1000 клиентов могут одновременно читать и писать одни и те же данные) - На начальном этапе и при изменении структуры конфигурации, 1С складывает в CouchDB подробное описание своих метаданных. По этому описанию, движкок metadata компилирует javascript-файлы с конструкторами объектов данных, Плюс, создаёт скрипты sql для таблиц в памяти браузера
- Далее, при редактировании в 1С любого объекта, в подписке на событие «при записи», изменения этого объекта отправляются в CouchDB. Происходит подобие «регистрации изменений в плане обмена»
- В фоновых заданиях, 1С-ка запрашивает у CouchDB список объектов, изменённых с момента последней синхронизации, читает и записывает изменённые объекты. При интенсивной работе, фоновые задачи репликации можно запускать в несколько потоков
Шаг №2 Nginx
Nginx используется в нашем проекте по прямому назначению: для отдачи статических файлов, балансировки нагрузки и редиректов http запросов к сервисам. Апологеты Apache или IIS, могут настроить те же функции средствами их любимых серверов, но лично мне, ближе синтаксис nginx.conf. Особенно, после того как в нём поддержаны сценарии javascript. Пример nginx.conf есть в прикрепленных файлах. В большинстве случаев, годятся настройки по умолчанию. Достаточно указать путь к папке с файлами веб-приложения.
В production-окружении, службы CouchDB, Apach и Nginx, обычно размещают на разных физических или виртуальных серверах. Рекомендуется перенаправлять браузеры клиентов с http на https, чтобы пароли и прочие данные веб-приложения передавались исключительно по шифрованному каналу.
Исходные тексты и дистрибутивы для всех платформ доступны официальном сайте nginx.org
Шаг №3 NodeJS
В нашей задаче, Node.js используется только на этапах подготовки и сборки проекта. С его помощью, мы развернём структуру папок и файлов приложения helloworld, а так же, скомпилируем итоговые файлы для публикации в Интернет.
Исходные тексты и дистрибутивы для всех платформ доступны официальном сайте nodejs.org
Шаг №4 IDE
Если у вас уже установлен любимый редактор кода javascript, этот абзац можно пропустить. Для остальных, предлагаю обратить внимание на WebStorm и NetBeans. WebStorm платный, NetBeans не требует денег за подписку. Выбор за вами.
Шаг №5 Файлы проекта
Создадим пустой каталог. Например, c:\www и перейдём в него в командном интерпретаторе. Предполагается, что nodejs уже установлен.
Выполним команды:
PS C:\users> cd c:\www
PS C:\www> npm install -g metadata-js@0.11.223
Metadata.js будет установлена глобально и зарегистриуется утилита командной строки metadata.
PS C:\www> npm install -g gulp-cli
Установит глобально и зарегистрирует утилиту командной строки менеджера задач gulp
PS C:\www> metadata init
Создаст начальную структуру проекта
PS C:\www> npm install
Установит дополнительные библиотеки (зависимости), необходимые движку metadata.js
Инсталляция потребует некоторого времени. Из Интернета загружается около 200Mb кода.
При установке зависимостей, могут появляться сообщения об ошибках. Обычно, это не мешает работе веб-приложения.
Мы в одном шаге от запуска демо-примера.
Если CouchDB установлен локально, на этом же компьютере, проект можно не пересобирать и сразу открыть файл c:\www\index.html в браузере Chrome. Должно открыться демо-приложение и ругнуться на отсутствие данных в CouchDB. Их мы подготовим на следующем шаге.
Если CouchDB установлен на другом компьютере в локальной или глобальной сети, необходимо пересобрать проект, предварительно, указав в настройках по умолчанию, строку подключения к серверу. Отредактировать файл настроек package.json можно любым текстовым редактором. Указываем в параметре config->couchdb тот же путь, который указан для этого параметра в 1С.
Чтобы перекомпилировать файлы проекта, выполним в командной строке:
PS C:\www> gulp full
Для отладки в файловом режиме, просто открываем c:\www\index.html в Chrome. Остальные браузеры блокируют исходящие запросы со страниц, открытых по протоколу file:///.
Чтобы наше приложение заработало в любом браузере локальной сети, достаточно поместить файлы из c:\www\ в папку веб-сервера. Папка не обязана быть корневой. Например, если корень apache или nginx смотрит на c:\www-data\, можно создать папку c:\www-data\helloworld\ и поместить в неё содержимое нашего проекта. В браузере проект будет доступен по http://localhost/helloworld/ или http://имякомпьютера/helloworld/. На вебсервер нет необходимости переносить всю структуру проекта.
Достаточно скопировать папку dist и файлы index.html, cache.appcache и manifest.json.
Вместе со структурой папок, которую мы получили командой metadata init, в каждой папке был создан файл README.md, поясняющий назначение папки. Исходные тексты и шаблоны, располагаются в иерархии папки src. Особый интерес представляют папки внутри src/modifiers. Там живут модули объектов и менеджеров наших документов и справочников, а так же, общие модули.
В демо-примере задействована единственная подписка на событие – при создании документа «ПеремещениеДенег». Обработчик живёт в файле src\modifiers\documents\doc_cash_moving.js и выполняет единственное действие: назначает номер новому документу
// Подписываемся на события
$p.doc.cash_moving.on({
/**
* Обработчик при создании документа
*/
after_create: function (attr) {
//Номер документа
return this.new_number_doc();
}
});
Клиентский код про формы в демке отсутствует - используются автоформы.
При необходимости, можно добавить обработчики на событие «при изменении реквизита» и пересчитывать одни поля при изменении других. Например, рассчитывать итог в табличной части или подставлять договор при изменении организации или контрагента.
Есть возможность полностью переопределить любую форму, добавив соответствующий метод в менеджере объекта.
Еще, в папке модификаторов есть несколько служебных модулей (cat_users_acl.js, cch_predefined_elmnts.js и cch_properties.js). Эти файлы – аналог модулей объектов из БСП, реализующих стандартную функциональность.
Шаг №6 конфигурация 1С
Можно взять готовую dt-шку из прикрепленных файлов и добавить в неё объекты прикладной задачи. Для полноты картины, рассмотрим, как делалась эта каркасная dt-шка:
- Создаём пустую конфигурацию, присваиваем ей имя (в нашем случае «МетадатаДемо»), создаём подсистему «МетадатаДемо»
- Т.к. библиотека интеграции использует БСП, производим сравнение-объединение с актуальной версией БСП с постановкой на поддержку
- Включаем возможность внесения изменений в следующие объекты БСП:
- Общие модули «ПодсистемыКонфигурацииПереопределяемый» и «УправлениеСвойствамиПереопределяемый»
- Справочник «ВидыКонтактнойИнформации» – в него добавим предопределенные элементы, чтобы у наших касс появилась закладка с контактной информацией
- Справочник «НаборыДополнительныхРеквизитовИСведений» – в него добавим предопределенные элементы, чтобы у наших касс появились настраиваемые дополнительные реквизиты
- План видов характеристик «ДополнительныеРеквизитыИСведения» - при необходимости расширения состава типов дополнительных реквизитов
- Добавляем общий модуль «ОбновлениеИнформационнойБазыМетадатаДемо» и указываем на него ссылку в модуле «ПодсистемыКонфигурацииПереопределяемый»
Рассмотренные шаги – стандартная процедура подключения БСП. Далее, подключаем библиотеку интеграции (cf-ка есть в прикрепленных файлах)
- Производим сравнение-объединение с библиотекой интеграции с постановкой на поддержку
- Включаем возможность внесения изменений в определяемые типы библиотеки интеграции и БСП – изменим их состав после того, как в конфигурацию будут добавлены наши документы и справочники
- Включаем возможность внесения изменений в общий модуль «ИнтеграцияПереопределяемый» - в нём укажем ссылку на процедуру формирования начального образа данных. Так же, в этом модуле можно переопределить правила сериализации данных, но в демо-примере эта возможность не используется
- Добавляем справочники «ДДС» и «Кассы» и документ «ПеремещениеДенг»
- Добавляем общий модуль «ИнтеграцияМетадатаДемо» и реализуем в нём процедуру НачальноеЗаполнениеФинализация()
Из-за внедренных библиотек БСП и Окнософт:Интеграция, конфигурация получается довольно толстой (400 общих модулей, 70 справочников, 100 регистров и т.д.), но при включенном отборе по подсистемам, объекты демо-задачи помещаются на один экран.
Важную роль при настройке конфигурации имеют определяемые типы библиотеки интеграции:
- ИнтеграцияСсылка – в состав этого типа надо включить все ссылочные метаданные, которые потребуются веб-приложению. Для экономии трафика и памяти браузера, не рекомендуется включать в этот тип неиспользуемые метаданные. С другой стороны, важно не забывать про связанные ссылочные типы. Например, при добавлении справочника «Номенклатура», следует добавить справочники «Виды номенклатуры» и «Номенклатурные группы»
- ИнтеграцияОбъект – включает авторегистрацию изменений. Если предыдущий тип определяет, можно ли в принципе передать в CouchDB некие данные, то текущий, указывает, должны ли изменения передаваться в CouchDB автоматически при записи каждого объекта
- ИнтеграцияНаборЗаписей – аналогично предыдущему, но относится к регистрам сведений и накопления, а не к ссылочным типам
Работа со стороны конфигуратора закончена, дальнейшую настройку будем делать в режиме 1С:Предприятие.
Шаг №7 Связь с CouchDB и начальный образ данных
- Задать адреса сервисов
- Включить CORS
- Настроить базы
- Выгрузить описание метаданных
- Зарегистрировать начальный образ
Запускаем 1С в режиме предприятия и открываем обработку «Интеграция: настройка»
На первой закладке необходимо указать:
- Адрес (url) сервера CouchDB с префиксом баз проекта. В нашем случае, сервер крутится на компьютере с именем
i980порт5984и префикс =hw_. Префиксы позволяют разместить базы нескольких, разных по структуре или одинаковых проектов на одном сервере - Имя и пароль администратора CouchDB – с этими учетными данными, подсистема интеграции 1С будет взаимодействовать с CouchDB
- В табличную часть «Пользователи», необходимо добавить минимум одного пользователя и указать для него пароль и роли на сервере CouchDB. Роли задаются в виде массива строк. Разработчик прикладного решения может при необходимости добавить произвольное число ролей. По умолчанию, в metadata.js используются роли:
- doc_reader – может читать объекты из базы doc
- ram_reader – может читать объекты из базы ram
- doc_editor – может изменять объекты в базе doc, но для него действуют фильтры RLS
- ram_editor – может изменять объекты в базе ram
- doc_full - может изменять объекты в базе doc, RLS на него не распространяется
- Галку «Active» на этапе начальной настройки можно снять. Она включает режим авторегистрации изменений, когда при записи любого объекта в 1С, изменения синхронно передаются в CouchDB
- Галку «Check» на этапе начальной настройки можно снять. Она включает режим обязательного контроля регистрации изменений в CouchDB. Если галки Check и Active взведены, а сервер CouchDB выключен, при попытке записать документ или элемент справочника, включенный в состав обмена, при записи возникнет ошибка – изменения записаны не будут
- Поле «Zone» в демо-примере не используется. С его помощью, библиотека интеграции реализует функциональность, схожую с 1С:Fresh, когда к одной физической базе 1С подключено несколько абонентов (групп пользователей) с полностью изолированными или частично пересекающимися областями данных
- Поле «Since» и кнопка «Прочитать» используются для отладки обратной связи с CouchDB
На второй закладке перечислены объекты метаданных 1С, которые должны быть доступны в веб-приложении. Список заполняется автоматически при первом старте, но разработчик может в любой момент добавить или удалить из этого списка любые классы данных.
Ряд объектов используются ядром metadata.js. Их удаление из состава обмена, испортит работу веб-приложения. Вот этот список:
- Перечисление «ИнтеграцияСостоянияТранспорта»
- Перечисление «ИнтеграцияТипКеширования»
- Перечисление «ИнтеграцияТипСвёртки»
- Справочник «Пользователи»
- Справочник «ИнтеграцияПраваПользователей»
- Справочник «ЗначенияСвойствОбъектов»
- Справочник «ИдентификаторыОбъектовМетаданных»
- Справочник «НаборыДополнительныхРеквизитовИСведений»
- Справочник «Формулы»
- План видов характеристик «ДополнительныеРеквизитыИСведения»
- План видов характеристик «ПредопределенныеЭлементы»
Колонка «Кешировать» указывает, в какой базе CouchDB будут зарегистрированы изменения и способ обработки этих изменений браузером.
Устройство баз в NoSQL отличается от привычного реляционного. Главные особенности: права на чтение и фильтр репликации задаются для базы в целом, а не на конкретный тип объектоав. Metadata.js создаёт для каждого проекта три базы (ram, doc и meta), в которых хранит разные классы объектов.
- ram – рекомендуется для справочников и прочих редко изменяющихся данных. Объекты с типом кеширования ram, загружаются в ОЗУ браузера при старте веб-приложения и доступны в синхронном режиме. Изменения постоянно синхронизируются в одну сторону: из CouchDB в indexedDB и оперативную память браузера
- doc – как правило, используется для документов. Внутри базы doc работает RLS, изменения синхронизируются в обе стороны между CouchDB, 1С и indexedDB браузера
- doc_remote – объекты не кешируются в браузере и доступны только online. Чтение-запись через CouchDB
- meta – используются для больших неразделенных классификаторов. Сюда можно положить классификатор банков или КЛАДР. В отличие от doc_remote, данные не дублируются в разных зонах в режиме разделения данных
- e1cib – Не регистрировать в CouchDB. Этот режим можно рассматривать, как «лёгкий клиент 1С». Потребуется опубликовать rest http сервис библиотеки интеграции. Объекты будут доступны только online через стандартные http интерфейсы 1С.
Разработчику дана свобода при назначении типов кеширования. В экзотических случаях, можно держать документы в памяти, а за справочниками ходить на сервер.
Колонка «Свёртка» в текущей редакции библиотеки интеграции не используется.
Объекты, для которых взведена галка «Скрыть», не видны в автоматически генерируемом интерфейсе веб-приложения, но формы этих объектов полностью доступны через ссылочные реквизиты других объектов. Например, справочник «пользователи» спрятан в общем списке справочников, что не мешает выбрать пользователя в поле «ответственный» документа «перемещение денег».
Колонка «Разрешен IREST» в текущей редакции библиотеки интеграции не используется.
CouchDB может работать в качестве универсальной шины данных, к которой подключены разные ИБ 1С, сканеры, ТСД, АСУ и прочие «не 1С программы». Использование синонимов упрощает интеграцию с разнородными базами.
Указывать синонимы для новых объектов и реквизитов не обязательно. Проблем с русскоязычными названиями не возникает. Разработчик самостоятельно принимает решение, нужны ли синонимы для его задачи. Если принято решение синонимы не использовать, в таблице синонимов необходимо сохранить записи, относящиеся к предопределенным реквизитам и объектам ядра metadata.js (см. список объектов предыдущего абзаца).
Настало время пошевелить CouchDB из 1С.
- Включаем CORS. Рекомендую по возможности не использовать кроссдоменные запросы в production. Всегда можно сделать проксирование через Nginx и перенаправить запросы к разным серверам таким образом, чтобы браузеру казалось, что все серверы располагаются в одном origin. Главная неприятность от CORS – снижение быстродействия из-за использования preflight запросов. Если сайт и сервер расположены в разных доменах, перед тем, как отправить реальный запрос серверу, браузер направляет ему запрос с методом OPTION, на который сервер должен ответить «да, я согласен обрабатывать запросы из чужого домена». Теряем драгоценные миллисекунды на каждом запросе.
С другой стороны, использование CORS упрощает инфраструктуру и реализацию отказоустойчивости. Если основной сервер не отвечает, веб-приложение может самостоятельно отправить запрос на резервный сервер в другом дата-центре.
CORS в CouchDB включается кнопкой «Включить CORS» на закладке «Регистрация». На маленьких экранах, эта кнопка может прятаться внутри кнопки «еще» левой табличной части. - Создаём базы. При нажатии на кнопку «Настроить CouchDB» закладки «Регистрация»
- будут созданы три базы (doc, ram и meta)
- будут созданы пользователи и привязаны к базам
- в базах будут созданы или перезаполнены служебные документы с базовыми настройками
- Выполняем команду «Записать мета». Возвращаемся на закладку «Метаданные» и жмём кнопку. На основании списка метаданных к обмену и с учетом синонимов, будет сформирован и записан в CouchDB, объект описания метаданных
- Выполняем команду «Начальное заполнение». Это подготовительная команда выполняет цикл запросов и заполняет табличную часть ссылками на объекты, из которых будет составлен начальный образ данных. По умолчанию, регистрируются все объекты, включенные в состав обмена. Математику начальной регистрации можно дополнить и переопределить в процедурах «НачальноеЗаполнение» и «НачальноеЗаполнениеФинализация» общего модуля «ИнтеграцияМетадатаДемо».
- Выполняем команду «Зарегистрировать». По этой команде, список ссылок отправляется в CouchDB и начинает синхронизироваться со всеми подключенными веб-клиентами
- Любуемся результатом
В базы hw_* можно «провалиться» щелчком мыши и изучить содержимое записанных со стороны 1С объектов.
Все необходимые от 1С данные получены – можно переходить к сборке веб-приложения.
Шаг №8 Отчеты
Полностью автоматического формирования отчетов на текущий момент не нет. Доступна форма типового отчета со стандартной разбивкой на поле табличного документа и панель параметров. Данные для отчета можно получать из разных источников. В текущем примере, данные извлекаем из map/reduce индекса CouchDB. Про индексы в NoSQL поговорим в отдельной статье. Сейчас, предлагаю просто открыть в браузере /_utils/database.html?hw_0_doc/_design/doc/_view/cash_moving_date_cashbox#
Это индекс CouchDB, используемый в данном случае, как аналог регистра накопления 1С.
При записи каждого объекта, выполняется код похожий на обработчик проведения. Формируется составной индекс (дата + касса) и рассчитывает промежуточные итоги. Эти итоги используются при построении отчета.
Полный код отчета здесь не дублирую - он доступен в модуле src/modifiers/reports/rep_cash_moving.js
Шаг №9 Публикация в Интернет
Если у вас есть VPS, VDS или dedicated сервер, просто разверните на нём couchdb и nginx и скопируйте файлы проекта в подходящую директорию.
Если выделенного сервера нет, но хочется «пощупать» технологию, есть бесплатные хостинги CouchDB:
- Smileupps. Сервис довольно тормозной, но вполне работоспособный. Для ознакомительных целей годится
- IBM Cloudant, лично не тестировал, но там есть бесплатный тариф, при условии небольшого трафика
При включенном CORS, файлы проекта можно разместить на любом, дешевом или бесплатном хостинге. Никакой нагрузки на http сервер они не создают – это обычные статические файлы небольшого размера.
В CouchDB есть еще одна фича: он может работать http-сервером. То есть, можно построить back-end на голом CouchDB – без Apache и Nginx.
Итоги
Демо-задача решена. Понимаю, что в короткой статье невозможно рассмотреть даже вершину айсберга.
Если тема покажется аудитории интересной - голосуйте за продолжение. Буду по мере сил выкладывать новые материалы.
Скачать файлы
| Наименование | Файл | Версия | Размер | |||
|---|---|---|---|---|---|---|
|
mdhello.zip
.zip 48,78Mb
29.06.17
110
|
.zip | 48,78Mb | 110 | Скачать |
См. также
Специальные предложения
Для сложных сортировок, по прежнему требуется создавать map/reduce индекс.
Cразу маленькое уточнение: правильнее говорить не о "схеме взаимодействия с 1С", а о "схеме взаимодействия 1С с базами метадаты".
По отношению к CouchDB, сервер 1С является клиентом. Он пишет в CouchDB и запрашивает изменённые объекты, но не наоборот.
CouchDB стоит в сторонке и никого не трогает.
Когда кому то из клиентов (не важно, браузеру или серверу 1С) захотелось что-то прочитать или записать, клиент формирует запрос, а CouchDB этот запрос исполняет.
И еще одно: к шине данных CouchDB может быть одновременно подключено несколько баз 1С разной структуры (например, торговля и бухгалтерия). При этом, можно формировать индексы по сводной информации из физически разных баз 1С.
2. Получается, что 1С является поставщиком метаданных и данных для CouchDB. Верно?
3. Например, есть некая база 1С. Хочется организовать одновременную работу с ее данными через http-сервисы для 1000+ пользователей
и не хочется покупать 1000+лицензий у 1С
То ваш движок с этим справится, на сколько я понял.
Какая часть этого зоопарка будет принимать на себя 1000+запросов пользователей?
Каким образом данные по этим запросам будут добываться из 1С?
Сколько лицензий 1С при этом будет израсходовано?
4. Не обязательно же делать страницу работы с веб приложением именно такой как у вас на демо? ну чтобы она не была похожа на 1С внешне?
5. Как например быть, если для какой то части информации из 1С один файл html, для других - другой? Это все можно сделать самому и какими средствами?
6. Кроме 1С из всего набора программ и сервисов какие из них платные?
Если ваш проект с открытым кодом - можно никому не платить. Если ваш код закрыт, потребуется несколько коммерческих лицензий.
То есть CouchDB будет клоном базы 1С.
А за даными в 1С оно все таки лазит. Тратит ли она лицензии 1С при подключении через http-сервис? Я так полагаю, что как минимум 1 точно тратит.
то есть сочинять страницу html нужно с использованием данных базы CouchDB?
или например текст страницы сочинить на стороне 1С и хранить ее в виде текста + стили + скрипты в базе 1С, а уже CouchDB заберет себе этот текст и покажет его в виде странички как есть в веб приложении. Я все верно понимаю?
Если потребовался нестандартный компонент, прикладной программист переодевается в костюм веб-дизайнера, садится за другой стол и там рисует овальную кнопку. При этом, забывает всё, что знал про объекты данных.
Важно, чтобы задачи бизнес-логики и дизайна никогда не пересекались. Иначе, возникает го*нокод
Я подытожу для себя:
1. CouchDB будет клоном не по структуре, а по данным.
Не даром же с обоих концов можно поменять один объект и увидеть сразу (почти) везде эти изменения.
Но инициатором заполнения базы CouchDB является 1С, поэтому ни одной лицензии потрачено не будет.
2. Веб приложение общается не с 1С, а с базой CouchDB
Теперь про примерчик.
Предположим, что производитель некоего товара для огромной армии своих дистрибьюторов создал некую веб морду,
на которой публикует для них разные новости, в том числе о новинках, акциях и прочей не учетной ерунде.
Страницы с текстом этой ерунды могут использовать данные базы 1С.
Веб приложение в этом случае не выглядит как таблица с документами + отчет.
Веб приложение выглядит как сайт с новостями, личным кабинетом и пожалуй все.
На стороне 1С специально обученный человек верстает страницу как ему взбрендит, использует информацию из 1С и складывает
это в регистр или справочник как текст.
в CouchDB 1C отправляет этот текст страницы и всю сопутствующую шелуху (картинки, стили, лист со скриптами).
Веб приложение это все показывает как страницу с новостями например. И актуально изменяет, когда в 1С поместили новый текст страницы.
В личном кабинете пользователь может посмотреть данные о своих заказах, задолженности и личные предложения по скидкам
там же может завести заявку и пр, т.е это уже привычный интерфейс с таблицей + отчет.
Вроде ничего не забыл. ))
Возможно ли такое?
- Один и тот же справочник в CouchDB и 1С может иметь разный состав реквизитов
- В 1С могут быть объекты, недоступные на сайте
- На сайте могут быть объекты, которых нет в 1С
- Из-за RLS, для разных абонентов, в CouchDB могут быть обрезанные данные (например, оплаты и отгрузки только конкретного дилера)
Может, лучше не статическую страницу, а шаблон, в который веб-приложение подставит некие данные, ассоциированные с текущим пользователем?
Вообще, так работают большинство сегодняшних сайтов и использование metadata для этой задачи не даёт ничего нового.
Это, как использовать сложный координатный станок для простого отрезания заготовок, но такую возможность у вас отнять никто не в праве.
Сделать, чтобы запись элемента справочника с текстом приводила к изменению страницы на сайте, конечно, можно.
Описанные задачи можно прикрутить к .
Вопрос (16) был в другом: решение каких элементарных шагов нужно проиллюстрировать?
Проще всего, наверное, будет вести пару дней дневник и записывать в него все действия по проекту
Я понял в чем суть вопроса (16)
В моем примере:
- основная страница выглядит не так как в демке, значит нужно проделать ряд шагов и сделать эту страницу.
Показать как научить ее читать данные о новостях.
Для этого потребуется что-то разрабатывать на JavaScript ?
- интерфейс а-ля 1С спрятан в другой раздел.
это потребует доп разработки? это можно показать наглядно?
Главное начать, а там и подробности появятся.
Может это потому, что не знаю, как разрабатывают на JavaScript.
Но все же неплохо было бы увидеть Hello Dev с этой стороны, чтобы было видно работу разработчика в среде разработки.
сделал - посмотрел - переделал - посмотрел - получил результат и т.д
Сможете такой примерчик замутить?
Вы можете ускорить подготовку такого примера, если придумаете конкретные простые шаги. Не абстрактные "сделал - посмотрел - переделал - получил результат", а внятные задачи, про которые можно написать инструкцию и снять ролик.
Картинку с ошибкой прикрепил. Как понятно из ошибки проблема с авторизацией в hw_0_ram, hw_meta.
Пробовал добавлять новых пользователей, менять пароли и т.д. тщетно. Что я упустил ?
Далее, если получается войти под вашим пользователем в , то и вход в программу должен отрабатывать нормально.
У гостевого пользователя из демо-dt-шки пароль 333
Как поведет себя все связка если, мы меняем объект в браузере, записываем, но при записи в 1с возникает ошибка?
Как происходит синхронизация Couch и 1с, если 1с клиент то он сам запрашивает инфу по обновлениям или есть тригеры в коуче, которые пушат клиентам?
Неплохо было бы разъяснить схему синхронизации 1с - metadata, metadata-1с, metadata-metadata (между клиентами)
В фоновых заданиях, 1С-ка запрашивает у CouchDB список объектов, изменённых с момента последней синхронизации
- В 1С есть крутые типовые конфигурации и metadata может работать для них поставщиком данных
- В 1С есть компоновка и регистры, по которым проще строить сложные отчеты, чем по индексам CouchDB
- На 1С автоматизирована куча рабочих мест. С ней выгоднее интегрироваться, чем конкурировать
CouchDB всё равно придется поставить на компьютер программиста, чтобы скрипт сборки проекта заработал.
Сейчас для очистки используется встроенный механизм браузера, но он не генерирует события "при изменении".
Встроенные парсер и сериализотор используются (см. код модуля ИнтеграцияJsonКлиентСервер), но им необходима обёртка для обработки ссылочных и иных типов типов данных, не поддержанных платформой 1С нативно.
Сборки библиотеки интеграции для 8.2 используют полифилл для работы с JSON, в 8.3 задействованы стандартные механизмы.
Библиотека интеграции выполняет много не очевидной, но важной работы: транслирует имена объектов и реквизитов по словарю, трансформирует структуры данных, выполняет дозаполнение реквизитов и табличных частей при экспорте и импорте, обслуживает версионирование couchdb и мн. др.
JSON-сериализация - важная, но очень маленькая часть подсистемы интеграции
Опубликован . Постараюсь в ближайшие месяцы сделать части системы более автономными и отказаться от использования проприетарных библиотек в визуальной части.
На сегодня, использовать для ui библиотеки, напрямую манипулирующие dom - не очень целесообразно.
jsx гораздо выразительнее и эффективнее. metadata v2 разрабатывается в react-стилистике.
Еще, замечание: metadata вообще то не про интерфейс, а про обработку данных в javascript в стиле 1С.
Наличие ui - побочный эффект. Данные ведь надо показывать и как то обрабатывать ввод пользователя.
Вопрос по работе с CouchDB, я так понимаю пока особо вопрос ревизий не беспокоит? В плане того что их удалить не так то просто. Понимаю, что это возможно никогда и не станет проблемой, но это чуть ли не первый вопрос, который волнует многих кто берет коуч, а не монго например (у того свои траблы есть конечно).
А вообще большое спасибо за труды. И за metadata.js - хорошая разработка. Особенно радуют планы на версию 2. Удачи в разработке.
Что касается места на диске, в моих реальных задачах его хватает.
Чтобы ограничить аппетиты CouchDB, есть
Еще, есть - на больших данных может создавать тормоза
А еще, базу можно пересоздать на лету и прибить исходную - получим автоматическое сжатие.
(46) честно скажу мне не знакома "react - стилистика". Так что даже интересно что будет в 2.0. Остальное спрошу в ЛС.
Если вас и заказчика устраивает надежность, производительность и функциональность традиционной платформы 1С, будет проще достать из кармана нужную сумму и купить эти 1000+ лицензий.
Смотреть в сторону metadata имеет смысл в том случае, если нужна экстремальная надежность, высокая производительность или сложный интерфейс.
Я конечно прекрасно понимаю, что это для репликации, но если мне под конкретную задачу не нужна репликация, а нужно просто быстро обновлять данные в документах. А то приходиться сначала сделать запрос получив все _rev потом, а уже потом только делать запрос с обновлением.
В связи с этим вопрос к Евгению. Ведь конечно не очень хорошо делать так как в вашей демо лайт конфигурации, вешать на подписчика "ПриЗаписи" все это движение с синхронныим HTTP запросами.
И вы в комментарии в коде написали:
// TODO: Возможно, для ускорения стоит реализовать асинхронную прослойку в NODEJS?
Скажите, не реализовывали пока такую прослойку ?
Синхронизация с CouchDB внутри 1С-ной транзакции гарантирует идентичность данных.
На моих серверах, запись занимает 20-100 мс, что на порядок быстрее обычной записи 1С-ного документа.
Серверы 1С и CouchDB желательно размещать в одной подсети и синхронизировать с большим Интернетом, а не пытаться писать сразу из 1С на удаленный CouchDB
Заинтересовала CouchDB отсюда возникло пару вопросов:
1.
С помощью "_changes" можно получить список изменений документов, как из него исключить документы которые уже были синхронизированы с 1С ?
2. Каким образом синхронизируются данные когда одновременно правится документ в 1С и в браузере
Каким образом синхронизируются данные когда одновременно правится документ в 1С и в браузереПри необходимости, вы можете реализовать сколь угодно сложный конфликт-резольвер. Можно объединять изменения, блокировать объект, как в 1С или синхронно обновлять поля, как в google-docs
Например мне нужно ускорить работу с вводом документов в ERP, чтоб не тормозило дико по минуте каждое сохранение, но и интерфейс был тот же.
Надо окно того же вида и с той же логикой. Получается я должен пару тысяч строк и десятков процедур переписать на JS?
В v2 ядро совсем маленькое. Интерфейсную шелуху и функциональность, зависящую от поставщика данных решено вынести в плагины. На текущий момент, для ознакомления доступны:
import MetaEngine from 'metadata-core'
import metadata_pouchdb from 'metadata-pouchdb'
import metadata_redux from 'metadata-redux'
MetaEngine
.plugin(metadata_pouchdb) // connect pouchdb-adapter to metadata-core
.plugin(metadata_redux) // connect redux-actions to metadata-core
const $p = new MetaEngine()Развернул систему на 3-х разных серверах: 1С - Win2012, Nginx - Linux1, CouchDB - Linux2.
Попытка 1:
- загрузил демо конфигурацию 1С. Создались базы в CouchDB, данные вижу.
- прописал сетевой путь к CouchDB в package.json проекта metadata (Nginx). Пересобрал проект.
При попытке зайти браузером видно только окно ввода логина/пароля. Дальше ничего не происходит. Не заходит ни под Гость, ни под добавленными пользователями.
Попытка 2:
- создал пустую конфигурацию из БСП и integration_light_2_3_0_217.cf
- добавил новый справочник. Создались базы CouchDB, данные нового справочника вижу.
- пересобрал проект. Изначально была ошибка. У вас в integration_light_2_3_0_217.cf в макете _design_meta обработки ИнтеграцияПанельАдминистрирования не прописано создание объекта meta_patch в базе meta. Добавил, пересобралось успешно. В ./tmp/prebuild.js виден добавленный справочник.
- При попытке зайти браузером видно только окно ввода логина/пароля. Дальше ничего не происходит.
В обоих случаях в логах CouchDB видно, что происходит обращение к базе только в момент открытия окна авторизации. После этого никаких действий в ней при вводе логина не происходит.
Подскажите пожалуйста, в чем может быть причина и на что обратить внимание?
- Чему равны значения параметров сеанса zone и zone_demo? (посмотреть можно в localStorage)
- Какая используется версия metafata.js? (узнать можно набрав $p.version в консоли браузера)
- Предлагаю поставить точки останова в функциях $p.iface.frm_auth и auth_click или просто сказать браузеру "останавливайся на всех ошибках" и посмотреть проблемное место в отладчике
Вот данные:
При загрузке страницы в консоли видна одна ошибка: "app.min.js:4 Uncaught TypeError: Cannot read property '__define' of undefined"
Задан только параметр zone - 0. Параметра zone_demo в localStorage нет. Из всех там присутствующих заданы еще browser_uid и skin.
0.11.220 - устанавливал через npm
Функция auth_click отсутствует.
При нажатии кнопки Войти в консоли Chrome видны вот такие ошибки:
GET ? 404 (Object Not Found)
10.26.1.15:5984/hw_0_doc/_local/dxaE34OVSBNyEKh3Z4DyFA%3D%3D?:1
GET ? 404 (Object Not Found)
momentjs@2.14,alasql@0.3,pouchdb@6.0,jquery@2.2,metadata@0.11.220(dhtmlx.min.js+metadata.min.js):519
/* это позиция 20939 в строке 519: "n.send(e.body)" */
GET ? 404 (Object Not Found)
10.26.1.15:5984/hw_0_doc/_local/loOTT55eUP0rg0SplTLI7g%3D%3D?:1
GET ? 404 (Object Not Found)
10.26.1.15:5984/hw_0_ram/_local/3Cf0ypm9lHniSkfHOKA5Mg%3D%3D?:1
Для последних 3-х ошибок следует сообщение:
The above 404 is totally normal. PouchDB is just checking if a remote checkpoint exists.
В консоли Firefox таких ошибок не видно и действий тоже никаких.
Также есть обратная ситуация:
1. в Firefox при нажатии Настройки отображаются настройки за окном авторизации, но в консоли видна ошибка: ReferenceError: event is not defined
InterfaceObjs/this.cancel_bubble()
momentjs@2.14,alasql@0.3,pouchdb@6.0,jquery@2.2,metadata@0.11.220(dhtmlx.min.js+metadata.min.js):576
$p.iface.open_settings()
momentjs@2.14,alasql@0.3,pouchdb@6.0,jquery@2.2,metadata@0.11.220(dhtmlx.min.js+metadata.min.js):581
onclick()
2. В Chrome при нажатии Настройки ничего не происходит. Ни в консоли нет сообщений, ни отображения окна настроек.
Затрудняюсь сказать что-то полезное не видя вашего кода.
Предлагаю сделать либо публичный git, либо пример в
Что именно и как нужно выложить для просмотра.
Хочу обратить внимание - проект метадаты лежит на линуксе.
Я заметил особенность поведения nodejs разных версий. Например, если использовать версию 6.6.*, то npm некорректно загружает пакет memdown для pouchdb-adapter-memory - отсутствует собственно описание точки входа. Для nodejs версии 4.6.* такой проблемы нет.
Также при загрузке метадаты необходимы установленные gcc/gcc-c++, т.к. происходит компиляция модуля leweldown.
Может эти ошибки как-то связаны с тем, что nodejs под виндовс загружает другие модули?
Как с этим разбираться?
Проблемы с компиляцией memdown и leveldown при установке pouchdb известны. На них можно не обращать внимания. В работе эти плагины не используются.
Git рекомендую попробовать - он очень удобен для версионирования и коллективной разработки.
Доступ при необходимости организуем.
Пока сделал следующее:
1. На отдельном win сервере развернул все локально (CouchDB, Nginx, metadata, 1C).
Демо-пример заработал.
Попытался добавить свой справочник "Тестовый справочник". Прописал в определяемые типы интеграции. Обновил meta и данные в CouchDB. В самих базах hw_ новый справочник и его данные видны.
Пересобрал метадату.
В web-интерфейсе демо нет ни справочника ни соответственно его данных.
Какая должны быть последовательность действий при добавлении нового объекта и возможно ли это в демо-примере?
2. Создал пустую базу на основе БСП и последней конфигурации с сайта integration_light_2_3_1_220.
Добавил новый справочник, прописал ... выгрузил в отдельную базу CouchDB (с другим префиксом)
Создал для этого новый проект метадаты, пересобрал.
При входе в web-интерфейс - ошибка: "app.min.js:4 Uncaught TypeError: Cannot read property '__define' of undefined(…)". Ошибка происходит в функции $p.cat.users_acl.__define.... модуля app.min.js
Я так понимаю, в демо-примере заполнено что-то еще, чего нет в предлагаемой для интеграции конфигурации.
Какие должны быть действия для создания своего демо-примера на основе пустой конфигурации?
Могли бы вы у себя повторить мои действия по созданию нового демо-примера с нуля?
Мне необходимо в итоге создать демо на своей базе со своими данными для демонстрации возможностей пользователям. Для начала нужно увидеть нормальное создание с пустой базы и добавление произвольных объектов.
3. Выгрузил конфигурацию из демопримера. Создал из нее новую базу без данных. Выгрузил в CouchDB и пересобрал метадату (для нового префикса). Через web заходит нормально - вижу справочники пустые. Добавил новый справочник (выгрузил, пересобрал...) - в web-интерфейсе он так и не появился.
$p.cat.users_acl - Это справочник ИнтеграцияПраваПользователей - редактируется из формы справочника Пользователи. Для каждого пользователя сервиса должна существовать запись в справочнике ИнтеграцияПраваПользователей.
Скорее всего, ваша гипотеза про недозаполненность верна и касается она данных, а не кода.
Обсуждение, наверное, правильнее вести в
На самом деле, появился. если в консоли браузера набрать $p.cat.имявашегосправочника.form_list() - должна открыться форма справочника.
Для лучшего понимания, поставьте точку останова в функции . Так же, имеет смысл прорешать примеры из .
Выкладываю последовательность действий для создания СВОЕГО примера и дальнейшей интеграции в реальную систему.
1. Создаем конфигурацию из БСП + Конфигурация Метадаты. В моем случае integration_light_2_3_1_220. При объединении выключить объекты БСП, которые пытается заместить конфигурация метадаты - я так понимаю из-за различия версий БСП.
2. В определяемых типах ИнтеграцияОбъект и ИнтеграцияСсылка ставим флажки объектов БСП и Метадаты как в демо-конфигурации.
3. В макете _design_doc обработки ИнтеграцияПанельАдминистрирования удаляем код связанный с cash_moving (это документ из демо-примера, он не нужен)
4. В макет _design_meta обработки ИнтеграцияПанельАдминистрирования добавляем код по созданию объекта meta_patch из демо-конфигурации. Область "doc": {"cash_moving"... пока оставляем.
5. В форме обработки ИнтеграцияПанельАдминистрирования в процедуре ЗаполнитьИзТабличногоДокумента указываем ИмяМакета = "МетадатаДемо", т.к. наша конфигурация называется совсем по другому. Или создать свой макет скопировав "МетадатаДемо" и присвоив ему имя конфигурации.
6. В общем модуле ИнтеграцияПереопределяемый в функцию НачальноеЗаполнение вставляем код из конфигурации демо-примера функции НачальноеЗаполнение общего модуля ИнтеграцияМетадатаДемо.
7. Добавляем справочники и документы, которые хотим увидеть в метадате. Прописываем их в определяемых типах ИнтеграцияОбъект и ИнтеграцияСсылка.
8. В макете _design_meta обработки ИнтеграцияПанельАдминистрирования меняем код области "doc" - переименовывем "cash_moving" в "<Название нашего документа>" и оставляем поля "date", "number_doc". Это форма списка. Если не будет хоть одной формы для списка документов - будет ошибка. Можно задать для данного документа вывод других полей, но тогда на форме других документов эти поля будут неотображаемые, но ширина формы останется. Как задать форму по умолчанию для любых документов пока не разобрался.
9. Загружаемся в приложение 1С. Обновляем справочник ИдентификаторыОбъектовМетаданных чтобы увидеть наши добавления. Можно сразу создать какие-то элементы в добавленных объектах. В справочнике пользователей переходим у нужных для метадаты на "Объекты доступа (RLS)" и нажимаем "Сохранить" (пока без добавления объектов) - вроде как должна быть прописка в доп.справочнике.
10. В обработке Интеграция на закладке Метаданные добавляем наши объекты. Можно прописать их в макете из п.5.
11. Создаем базу CouchDB со своим префиксом (например mt_, вроде как "My Test"), записываем "meta".
12. В начальном заполнении (в текущей конфигурации кнопка "Заполнить" на закладке "Регистрация") добавляем свои созданные элементы (если создавали).
13. Регистрируем в CouchDB
14. Переходим в Nginx. Создаем каталог для проекта. Подразумевается, что nodejs и metada-js уже установлены глобально. Выполняем команды metadata init, npm install, npm install through2, npm install gulp-util.
15. Меняем файл package.json - прописываем свой префикс (например "mt_" из п.11). Если CouchDB не расположена локально - путь.
16. В подкаталогах проекта ./src/modifiers/ удаляем файлы *cash_moving*.js. Это модули для демо-примера - они мешают и с ними не заработает.
17. Пересобираем проект - gulp full.
18. Наслаждаемся своими данными в web-интерфейсе. ))
19. До отчетов и обратной синхронизации пока не добрался.
Важно: после любой пересборки проекта в Chrome надо удалять данные о просмотренных страницах. Он почему-то много кэширует.
Евгений, на текущий момент такие вопросы:
1. Как задать форму списка для документов по умолчанию? Т.е. не для одного документа, как я сделал сейчас и она для всех остальных работает.
2. Как в принципе редактировать форму документа. Надо ли писать свою обработку, которая будет переопределять код формы в CouchDB или уже есть какие-то механизмы? Сейчас изменение макета _design_meta не меняет уже созданную форму.
P.S. Надеюсь в новой версии конфигурации для интеграции будут учтены изменения которые я привел.
Также из проекта скачиваемого npm лучше удалить преднастройки для демо-примера - это как-то неправильно.
Я подразумевал, что все действия происходят после прочтения вашей статьи. И это само собой разумеется.
Согласен. Но зачем при первичной загрузке модулей метадаты я вижу модификаторы объектов демо-версии? В моей базе нет ни касс, ни движений денег. При загрузке того же самого gulp мне не валятся демо примеры, которые потом надо удалить. чтобы он заработал.
Если в базе meta для объекта doc не казана хоть какая-нибудь форма списка - список документов (именно ссылок) не отображается - ошибки валятся.
Об этом и вопрос. Для одного документа задал - все остальные тоже нормально отображаются, но на форме видно, что ширина задана с учетом полей прописанного документа. Можно для каждого свой список задать - это не вопрос.
Речь о том, что изменение этого макета в 1С после уже готовой регистрации в CouchDB не меняет форму. Т.е. например, я создал форму списка документа с 2-мя полями. Все это распространил в метедату. Потом решил добавить пару полей в список, но форма не поменялась после пересборки проекта. Если файлы проекта удалить и создать заново - вижу свои поля.
Я ж здесь все выложил. Вы уж сами определяйте что из этого полезно для внесения изменений.
Сейчас пытаюсь нарисовать простенький отчет на своих данных.
Столкнулся с небольшой проблемой: как во view посчитать сумму по колонке табличной части документа?
Если в map function пытаюсь прописать "emit([Number(d[0]),Number(d[1]),Number(d[2]),doc.Заказчик],{Товары: sum(doc.goods.amount)});" то получаю всегда 0.
Если обратиться по индексу (например, "emit([Number(d[0]),Number(d[1]),Number(d[2]),doc.Заказчик],{Товары: doc.goods[0].amount});") , то сумма строки видна.
Подскажите пожалуйста как правильно использовать агрегатные функции в данном случае?
Да, это я конечно смотрел. Но reduce, как пишут в мануалах, обрабатывает результаты рассчитанные в map. Т.е. сумма колонки табличной части должны быть вычислена в map. Пока получилось только расчетом в цикле. Думал, может есть какие-то готовые агрегатные функции для этого.
Спасибо за подсказку. Я не так понял про reduce.
Теперь нарисовалась следующая проблема:
Я загрузил в метадату порядка 100 тысяч документов. И после этого журнал документов перестал открываться вообще. В консоли такие ошибки:
Database has a global failure DOMException: An attempt was made to add something to storage that exceeded the quota.
Failed to load resource: net::ERR_CONNECTION_RESET
Как это поправить?
Также при входе в программу теперь происходит жутко долгая синхронизация, которая на некоторых компьютерах просто зависает. Можно ли ее как-то отключить?
И еще - могли бы вы привести пожалуйста код отчета "Движение денег" где можно было бы посмотреть реализацию элементов управления:
1. Редактируемый Grid списка касс, в котором в ячейке можно выбрать произвольную кассу из справочника.
2. Отдельный элемент (OCombo видимо) в котором можно было бы выбрать кассу.
Интересует именно создание элементов. В примерах Codex работы с Grid нет, а пример OCombo повторить не удается - не устанавливается тип справочника.
зачем такой длинный список в ram??? может, лучше его положить в doc c фильтрованной репликацией или в remote?
Может и умеет. Пока я увидел, что когда были загружены документы одного месяца, то список открывался долго и получалось 1500 страниц. Т.е. ВСЕ документы загружались в таблицу, как я понял.
У меня список документов не открывается возможно из-за этого. Использую Chrom. Может какие-то параметры где-то указать, чтобы не читал полностью все документы?
Это справочники. Согласно рекомендациям разместил их в ram. Попробую переложить в doc_remote.
Исходники это здорово, а живой пример другое. Можно исходники неделями лопатить в поисках одной строчки. Я же писал: "пример OCombo из Codex повторить не удается - не устанавливается тип справочника.".
Поэтому прошу привести такой пример на существующем отчете. Логику переделывать не надо, просто элементы управления.
При выборе типа кеширования (ram, doc, doc_remote, remote, meta, e1cib и pgsql) для каждого объекта метаданных нужно учитывать множество факторов.
Тип кеширования - это только вершина айсберга. Еще есть свёртка, функция фильтрованной репликации, сервисворкеры для фоновой репликации и мн. др.
Евгений, я сейчас подготавливаю презентацию для бизнеса, чтобы было принято решение - использовать ваш продукт или нет. Для этого необходимо показать наши живые данные - 2 документа загруженных за текущий год и простенький отчет по ним. И меня тоже поджимают сроки.
Отсюда все мои вопросы.
Я перезагрузил все (справочники и документы) в doc_remote за 1 месяц. Синхронизация в начале исчезла - это хорошо.
Но документы открываются очень долго - список всех документов загружается в таблицу. Вижу "Записи с 1 по 30 из 9887". Я так понимаю, если я загружу еще 9 месяцев, то журнал документов открыться не сможет. Что нужно сделать, чтобы была возможность просматривать журнал с "с десятками миллионов документов без видимых задержек со стороны интерфейса пользователя". Сейчас такие тормоза я не могу показывать бизнесу - никого такое не заинтересует.
Также, если есть возможность, постарайтесь выделить несколько минут для приведения примера по элементам управления в отчете. Я думаю, вам как разработчику, это сделать достаточно просто и быстро.
Если ваш "бизнес" знает, как построить серьезный веб-сервис без метадаты - флаг им в руки - путь рисуют на других платформах.
1. Евгений, при покупке коммерческой лицензии в каком объеме осуществляется тех.поддержка?
2. Пример с миллионным справочником некорректный - отдельно написанная форма для динамического списка. Из метадаты там почти нечего нет. Я правильно понял, что автоформы списков не поддерживают динамическое считывание? Мне ведь тоже нужно создать максимально простой пример на автоформах, а не выдать конечное решение со своими написанными формами.
3.
Например накупить тучу лицензий у 1С для web.
Тот же пример справочника с миллионом записей можно построить без метадаты - напрямую читая CouchDB.
Условия предоставления услуг описаны в
Не видя кода, нельзя с уверенностью определить даже место проблемы: доставка данных с сервера, медленный запрос к indexeddb или ошибки при отрисовке dom в браузере
Хорошая новость. Можно немного подробней? Я для журнала документа прописал форму изначально с несколькими полями ( в meta_patch ). Где указать необходимый индекс и что он должен содержать для дин.списка автоформы. Примеров не нашел ((
Кода собственно нет особо. Заданы поля для отображения по аналогии с демопримером.
2. Странная сортировка по дате-времени. Вроде сортировка воспринимает время 13:00 как 01:00 и т.д.
3. Сортировка по названию (кириллица) не работает почему-то и в справочниках и соответственно (видимо) в комбобоксе.
4. Справочники все положил в doc. Теперь в журнале поля, которые ссылочные, отображаются со второго раза. Т.е. надо нажать "Обновить". Как и в отчете. Почему так?
PS. С OCombo я разобрался (немного по другому, чем в примере Codex создавать надо), отчет наваял. Осталось решить проблему с дин.списком.
Из вопросов про сортировку и справочники в doc видна пропасть непонимания, как metadata работает с данными.
Конечно, это моя проблема и недоработка. Видимо, я не смог отразить в документации фундаментальные архитектурные вещи. Возможно, их получится описать с вашей помощью.
Недопонимание конечно есть. Но беда в том, что ни примеров ни описания нет.
Я ни в одном из примеров (Бухгалтерия, УНФ, HelloWorld) не увидел работающей сортировки по разным полям. Ее там просто нет. Единственное, где есть сортировка это у поля дата в журнале документов у демопримера HW.
И то, потому, что индекс by_doc гвоздями забит в коде модуля toolbar_filter.js. Но и тут время как попало - надо включать в индекс.
Реализация правда тоже мне не совсем понятна - к индексу обращение идет только если документы в базе doc, если в doc_remote, то не используется. Также устаналивается странный лимит: options.limit = 100000; Это разве по итогу динамический список?
Если бы коде демопримеров была прописана сортировка, я бы постарался сделать по аналогии.
Индексы дополнительные я создал.
Подскажите куда их надо прописать для понимания формами и может они должны иметь какие-то шаблонные названия?
Я так смотрю, что в attr как-то и нужно передать названия этих индексов. Как я понимаю в attr.selection? Только как?
Я подготовлю для вас похожую базу с тестовыми данными.
При нажатии на кнопки проверить подключение, Ошибка работы с Интернет: Не могу установить соединение, что я не так делаю. (поднимаю все локально)
Просмотры 38772
Загрузки 103
Комментарии 200
Создание 11.08.16 14:03
Обновление 29.06.17 14:16
№ Публикации 540168
Рубрики
Инструментарий,
Интеграция с WEB,
Мобильные приложения
Кому Программист
Тип файла Архив с данными
Платформа Платформа 1С v8.x (все механизмы)
Конфигурация Конфигурации 1cv8
Операционная система Не имеет значения
Страна Не имеет значения
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Раздел учета Не имеет значения
Доступ к файлу Абонемент ($m)
Код открыт Да
|
АКЦИЯ! Все формы! Всего за 9 $m!
|
