Как в 1С Odata отфильтровать выборку по дате изменения?
Везде написано как отфильтровать по полям которые возвращаются, например по дате документа: /odata/standard.odata/Document_ПоступлениеНаРасчетныйСчет?$format=json&$filter=Date ge datetime'2024-04-01T00:00:00'
Это неудобно, когда требуется периодическая синхронизация некоторых документов через OData, так как дата документа не совпадает с реальным изменением. Вроде как понятно, что дата изменения также быть обязана.
Sgr_A, возможно, не страшно. Синхронизировать можно по дате например отступая назад несколько месяцев. А если синхронизировать по дате изменения и ориентироваться на номер документа, а ничего другого там тоже нет, то он также может поменяться, и получаются снова проблемы.
Синхронизировать можно по дате например отступая назад несколько месяцев
А если поменяют документ, не попадающий в этот интервал? Тут всё зависит от того, что именно вам надо. Если нужна нормальная синхронизация, то нужно реализовывать механику хранения измененных данных, их получения, очистки (как в планах обмена).
Тогда не получится, для этого можно разве договориться когда происходят 99% изменений. Ничего другого не придумать кроме синхронизации всего с ноля.
Как ранее упомянул, в 1С для подобных задач используется объект под названием "План обмена". Он позволяет для разных узлов (получателей) хранить зарегистрированные данные к отправке. А регистрируются они в общем случае при изменении объекта.
Sgr_A, там слишком много информации. Может проще новый ЯП освоить? Можете в двух-трех словах принцип работы? Odata это по сути обычный API, спросил получил. А план обмена как работает и с кем планирует обмениваться, уж не с другой ли 1C случаем ? Мне аж страшно стало.
Изменения передать можно и в Odata если бы хотели. Каким боком тут план обмена ?
psiklop, хотел лишь сказать, что если вам нужно получать только измененные данные - то протокол oData вам не поможет. Так как протокол стандартизирован и вы его же не доработаете.
Для задачи получения только изменённых данных подходит механика плана обмена, плюс какой-то транспорт обмена. В вашем случае создавать отдельный http сервис.
Sgr_A, ничего там не стандартизировано разве, что кроме правил как писать url, вообще не знаю какие там отличия от самопального api, если я захочу на своем сайте внедрить Odata (чтобы мой сайт отдавал какие-то данные как сервис) я наверняка настрою отдачу любых данных как захочу.
Опять же не читал мануал, но это простая логика и факт наблюдения работы с Odata
И 1с если бы хотели отдавали бы в документах какие-то поля по которым можно было точнее синхронизировать (типа даты изменения и какого уникального номера документа) и этого бы уже хватило любому (хотя мне пока хватило и того что есть). Либо я вообще не понимаю суть разработки под 1С и как все устроено и кто этим должен заниматься и кому вообще платят за эти лицензии и для чего. Я человек простой.
А насчет плана обмена, я не понимаю сходу его суть и принцип работы. Мне в голову идет только что надо синхронизировать между собой сам софт 1С, чего мне вообще не требуется. Так как задача просто забрать немного инфо от 1С для своего сервиса.
ничего там не стандартизировано разве, что кроме правил как писать url, вообще не знаю какие там отличия от самопального api
Видимо плохо выражаю свои мысли. Вкратце, если говорить про 1С, то oData в ней при публикации на веб-сервере генерируется автоматически самой технологической платформой, для всей разработанной конфигурации. То есть ничего поменять нельзя, это идёт из "коробки". https://v8.1c.ru/platforma/rest-interfeys/
я наверняка настрою отдачу любых данных как захочу.
В 1С есть web и http сервисы, с помощью которых можно как раз делать что заблагорассудится. Просто придется их самому разрабатывать.
А насчет плана обмена, я не понимаю сходу его суть и принцип работы. Мне в голову идет только что надо синхронизировать между собой сам софт 1С, чего мне вообще не требуется
Это такой объект в конфигурации. Он используется для реализации механизмов обмена данными. У него есть разные механизмы. В частности, служба регистрации изменений — она обеспечивает регистрацию всех измененных данных, которые подлежат передаче. https://v8.1c.ru/platforma/plan-obmena/
Изменился документ - зарегистрировался в плане обмена на узле "Данные для отправки на сайт". Потом сайт стучится в 1С (http сервис), тот берет из узла зарегистрированные данные, и уже как надо и что надо упаковывает и возвращает.
Но для этого придется план обмена создавать, и http сервис.
Sgr_A, интересное кино. Создавать http-сервис, еще и на языке 1С. План обмена тогда для меня звучит вообще как нечто абстрактное и неосязаемое.
Если бы была 1С версия с СУБД, может проще было бы к ней подключиться и все найти самому, хм.. А уж http-сервис я бы лучше на привычном php написал самопальный, чем дрючиться в 1С, к тому же как я понял он такой же самопальный и получится.
Я тут вспомнил, что в Odata 1С вроде как и был уникальный номер документа varchar(32) формата его обозначил, но даты изменения там точно не было.
Sgr_A, это понятно. С публикацией Odata я кстати тоже не особо вникал. Внешне просто в конфиг апача добавляется модуль wsap24.dll, создается виртуальный хост, но с какими-то отсылками в теге Directory что это приложение 1с, а в папке сайта есть только файлик default.vrd со ссылкой на файл базы 1с
Sgr_A, самое интересное, что после этого и самой 1С программой можно пользоваться в браузере. А Odata как довесок, причем все работает сразу из коробки, как ты и написал.
Вроде как понятно, что дата изменения также быть обязана.
Не обязана, если разработчик не добавил подобного реквизита с соответствующим поведением. В случае типовой конфигурации можете попросить сделать это разработчика с помощью расширений.
А вообще для регистрации изменений в 1с традиционно используются планы обмена - при изменении данных в дополнительные таблички пишут то, что изменилось, для кого эти изменения предназначены и забирал ли он их: https://v8.1c.ru/platforma/plan-obmena/
Нет нужды пока усложнять, все потребности закрыты скриптом php на 2kb добавил в планировщик windows. Спросил скорее из интереса, ну и так можно было бы чуть улучшить метод.
Кстати таблиц там как бы нет, стоит версия 1С с базой в файле.
В типовых решениях, поставляемых вендором, нет такого реквизита у объектов. Только если кастомизировать решение (конфигурацию) и добавлять реквизит самому.
Просто непонимание системы и как она устроена вводит вас в заблуждение.
если база не файловая - то она и есть СУБД (SQL, Postgres и т.п.)
Да, когда база вида клиент-сервер - то разворачивается на какой-либо поддерживаемой СУБД.
Если файловая - то сама 1С (технологическая платформа) внутри себя как бы эмулирует клиент-сервер и использует собственную, внутреннюю СУБД.
Кто хоть раз создавал базу данных под любую задачу или даже читал чужие скрипты, знает, что дата изменения там есть 99.99%
Тут важно понимать, что разработчик, создающий прикладное решение (конфигурацию) используя технологическую платформу 1С, не оперирует внутренними данными базы. Не создает на "низшем" уровне таблицы, поля и пр. Всё это делает сама платформа. И если создать какой-либо элемент, например, справочник "Номенклатура", то по умолчанию никакого реквизита с датой изменения в базе не будет!