OData API Обсуждаем нюансы использования
OData API Обсуждаем нюансы использования
OData API теперь доступна на всех платформах куда устанавливается FileMaker Server
Технология интересная и важная и может быть альтернативой FileMaker Data API
Предлагаю здесь обсуждать особенности использования, и кто с чем сталкивался.
Андрей Волков сделал большой пост в топике про последнюю версию FM, выношу сюда этот текст:
что интересного в этой ставшей доступной ныне функциональности OData API?
она похожа на FileMaker Data API, но есть значительные преимущества
Во-первых, это почти полноценный REST API по стандарту OData. Почти - потому что некоторые функции недоступны.
Rest API позволяет выполнять очень сложную выборку данных. Это, по сути, аналог SQL запроса. Получать данные намного проще.
Во-вторых, сам запрос выполняется проще. Для FileMaker Data API вы должны сначала подключиться к базе данных и получить токен, затем вы выполняете запросы, следя за сроком действия токена, если время превышено, то вы обновляете. И в конце сессии вы отключаетесь от базы данных через logout
OData API позволяет вам получить или отправить данные без предварительной авторизации. В каждый http реквест вы просто подсовываете пользовательский логин-пароль в заголовок Basic authorization. Удобно
В-третьих, вы можете в рамках одного HTTP запроса выполнить сразу несколько операций, которые будут выполняться транзактно: ошибка на любом шаге ведет к отмене всей цепочки операций.
В-четвертых, вы можете управлять метаданными в вашей базе данных, то есть вы можете удаленно, через http запросы создавать и удалять таблицы, создавать и удалять поля в этих таблицах (кроме калькуляций). Это по сути почти то же самое, что вы можете делать с помощью DataBox Plugin. И актуально, потому что, к сожалению, в режиме веб-запросов функции плагина недоступны. То есть если вы веб-запросом запустите скрипт, использующий функции плагина, то они не будут работать
В-пятых, в OData API вместо макетов вы обращаетесь непосредственно к таблицам (Table Occurences), вам не нужны макеты и размещенные на них поля, чтобы получать данные из таблиц. Это удобно.
В-шестых, вы имеете возможность получить схему базы данных, метаданные. Формат ответа я еще не видел, но надеюсь на максимум. Об этом поговорим отдельно позже, здесь можно выловить много ништяков.
В-седьмых, вы можете выбирать удобный для формат отправки и получения данных в запросе. Это может быть JSON или XML.
В минусы можно записать то, что в трафик включается содержимое контейнеров, и если вы работаете с контейнерами, то ваш лимит может быстро исчерпаться.
Итак, где потенциально это может пригодиться?
1) Если кто-то уже использует FileMaker Data API, то возможно будет более удобно перейти на OData
2) упрощается интеграция веб-форм. Заполняя веб-форму в веб-вьюере, вы можете затем записать данные в базу не с помощью вызова фм скрипта на клиенте (который опять же начнет открывать новое окно, создавать запись и т.д., всячески тормозить процесс), а удаленно, веб-запросом.
3) можно наловчиться загружать данные в веб-вьюер именно запросом к серверу. А раз так - можно делать автоматическое обновление html в веб-вьюере.
4) очень привлекательна возможность получать живые данные о схеме базы данных. Если это сработает, то я поделюсь идеями.
5) Можно запускать асинхронный процесс с помощью веб-вьюера. То есть вы запускаете с помощью веб-вьюера через Http-request удаленно некий скрипт на сервере, потом веб-вьюер дожидается ответа от сервера и когда получает этот ответ, запускает некий файлмейкер скрипт.
Вы же все это время спокойно работаете с файлмейкером.
6) временные таблицы упрощают возможность создания динамических отчетов. Хотя я бы предпочел для таких целей именно DataBox Plugin
Коллеги, делитесь вашими соображениями. Чем это может быть полезно и как это удобнее всего организовать.
https://blog.beezwax.net/odata-for-file ... d-nuances/
Технология интересная и важная и может быть альтернативой FileMaker Data API
Предлагаю здесь обсуждать особенности использования, и кто с чем сталкивался.
Андрей Волков сделал большой пост в топике про последнюю версию FM, выношу сюда этот текст:
что интересного в этой ставшей доступной ныне функциональности OData API?
она похожа на FileMaker Data API, но есть значительные преимущества
Во-первых, это почти полноценный REST API по стандарту OData. Почти - потому что некоторые функции недоступны.
Rest API позволяет выполнять очень сложную выборку данных. Это, по сути, аналог SQL запроса. Получать данные намного проще.
Во-вторых, сам запрос выполняется проще. Для FileMaker Data API вы должны сначала подключиться к базе данных и получить токен, затем вы выполняете запросы, следя за сроком действия токена, если время превышено, то вы обновляете. И в конце сессии вы отключаетесь от базы данных через logout
OData API позволяет вам получить или отправить данные без предварительной авторизации. В каждый http реквест вы просто подсовываете пользовательский логин-пароль в заголовок Basic authorization. Удобно
В-третьих, вы можете в рамках одного HTTP запроса выполнить сразу несколько операций, которые будут выполняться транзактно: ошибка на любом шаге ведет к отмене всей цепочки операций.
В-четвертых, вы можете управлять метаданными в вашей базе данных, то есть вы можете удаленно, через http запросы создавать и удалять таблицы, создавать и удалять поля в этих таблицах (кроме калькуляций). Это по сути почти то же самое, что вы можете делать с помощью DataBox Plugin. И актуально, потому что, к сожалению, в режиме веб-запросов функции плагина недоступны. То есть если вы веб-запросом запустите скрипт, использующий функции плагина, то они не будут работать
В-пятых, в OData API вместо макетов вы обращаетесь непосредственно к таблицам (Table Occurences), вам не нужны макеты и размещенные на них поля, чтобы получать данные из таблиц. Это удобно.
В-шестых, вы имеете возможность получить схему базы данных, метаданные. Формат ответа я еще не видел, но надеюсь на максимум. Об этом поговорим отдельно позже, здесь можно выловить много ништяков.
В-седьмых, вы можете выбирать удобный для формат отправки и получения данных в запросе. Это может быть JSON или XML.
В минусы можно записать то, что в трафик включается содержимое контейнеров, и если вы работаете с контейнерами, то ваш лимит может быстро исчерпаться.
Итак, где потенциально это может пригодиться?
1) Если кто-то уже использует FileMaker Data API, то возможно будет более удобно перейти на OData
2) упрощается интеграция веб-форм. Заполняя веб-форму в веб-вьюере, вы можете затем записать данные в базу не с помощью вызова фм скрипта на клиенте (который опять же начнет открывать новое окно, создавать запись и т.д., всячески тормозить процесс), а удаленно, веб-запросом.
3) можно наловчиться загружать данные в веб-вьюер именно запросом к серверу. А раз так - можно делать автоматическое обновление html в веб-вьюере.
4) очень привлекательна возможность получать живые данные о схеме базы данных. Если это сработает, то я поделюсь идеями.
5) Можно запускать асинхронный процесс с помощью веб-вьюера. То есть вы запускаете с помощью веб-вьюера через Http-request удаленно некий скрипт на сервере, потом веб-вьюер дожидается ответа от сервера и когда получает этот ответ, запускает некий файлмейкер скрипт.
Вы же все это время спокойно работаете с файлмейкером.
6) временные таблицы упрощают возможность создания динамических отчетов. Хотя я бы предпочел для таких целей именно DataBox Plugin
Коллеги, делитесь вашими соображениями. Чем это может быть полезно и как это удобнее всего организовать.
https://blog.beezwax.net/odata-for-file ... d-nuances/
Re: OData API Обсуждаем нюансы использования
Perform Script on Server из под OData API не работает.
То есть, если через OData API запустить на сервере скрипт, то внутри скрипта PSOS (Perform Script on Server) вызвать нельзя - выдает ошибку.
Интересно что FileMaker Data API такое работает. Подключение по FileMaker Data API сервер воспринимает как обычное пользовательское подключение, и хотя вызванный скрипт по сути работает на сервере из под него можно сделать PSOS. PSOS можно запустить без ожидания выполенения. Это позволяет запустить из под API скрипт, который закончит и вернет результат, а что-то "тяжелое" будет продолжать выполянятся в фоне
С OData API похоже такое не прокатывает
То есть, если через OData API запустить на сервере скрипт, то внутри скрипта PSOS (Perform Script on Server) вызвать нельзя - выдает ошибку.
Интересно что FileMaker Data API такое работает. Подключение по FileMaker Data API сервер воспринимает как обычное пользовательское подключение, и хотя вызванный скрипт по сути работает на сервере из под него можно сделать PSOS. PSOS можно запустить без ожидания выполенения. Это позволяет запустить из под API скрипт, который закончит и вернет результат, а что-то "тяжелое" будет продолжать выполянятся в фоне
С OData API похоже такое не прокатывает
-
- Сообщения: 338
- Зарегистрирован: 11 сен 2017, 13:42
- Откуда: Санкт-Петербург
Re: OData API Обсуждаем нюансы использования
надо попробовать поэкспериментировать с асинхронными реквестами.
вроде в JQuery достаточно удобно это реализовано.
асинхронный реквест заставляет браузер ожидать ответа "в фоновом режиме", то есть после отправки реквеста можно продолжить работать со страницей, а когда ответ приходит наконец, то запускается сценарий обработки.
по поводу получения мета-данных, что я писал. ничего особого там нет. минимум сведений, так что ожидания не оправдались
вроде в JQuery достаточно удобно это реализовано.
асинхронный реквест заставляет браузер ожидать ответа "в фоновом режиме", то есть после отправки реквеста можно продолжить работать со страницей, а когда ответ приходит наконец, то запускается сценарий обработки.
по поводу получения мета-данных, что я писал. ничего особого там нет. минимум сведений, так что ожидания не оправдались
Re: OData API Обсуждаем нюансы использования
Понятно что можно из оттуда откуда высылается запрос отправить этот запрос асинхроннно. Если это делать из какой-то страницы (не обязательно используемой в вебвьер), то можно делать это соотвественно на JS (тежелый и устарвеший JQuery использовать совершенно необязательно).надо попробовать поэкспериментировать с асинхронными реквестами.
Но все равно было удобно в FM API выполнить часть работы, отдать ответ запрашиваемому и потом как бы в фоне доделать что-то, о чем "запрашивающий" и не просил или не знает - писать логи, отправлять уведомления, какие-то системные данные обновлять еще что-то такое. То есть по сути тригернуть событие
-
- Сообщения: 338
- Зарегистрирован: 11 сен 2017, 13:42
- Откуда: Санкт-Петербург
Re: OData API Обсуждаем нюансы использования
ну, тады нужно ваять серверный шедулер и табличку с запросами, которые он будет выполнять последовательно
кстати, эта задача еще ждет своего героя. я такой функционал еще не пробовал делать. с удовольствием использовал бы готовую наработку
кстати, эта задача еще ждет своего героя. я такой функционал еще не пробовал делать. с удовольствием использовал бы готовую наработку
-
- Сообщения: 338
- Зарегистрирован: 11 сен 2017, 13:42
- Откуда: Санкт-Петербург
Re: OData API Обсуждаем нюансы использования
кроме того, вероятно вы можете использовать Admin API и запустить удаленно шедулу, которая обработает задачу в некоей таблице задач.
Код: Выделить всё
file:///fmi/admin/api/v2/schedules/{schedule_id}
status=running
Re: OData API Обсуждаем нюансы использования
расписание на ФМ сервере нельзя настроить с запуском чаще чем раз в минуту. Так что у вас будет задержкану, тады нужно ваять серверный шедулер и табличку с запросами, которые он будет выполнять последовательно
Какой смысл через Admin API запускать шедулер чтобы он запустил скрипт, когда можно просто запустить скрипт через oData API ?Вероятно вы можете использовать Admin API и запустить удаленно шедулу,
В любом случае это все костыли.
кстати, эта задача еще ждет своего героя. я такой функционал еще не пробовал делать. с удовольствием использовал бы готовую наработку
Не очень понял, какая здесь идея?
-
- Сообщения: 338
- Зарегистрирован: 11 сен 2017, 13:42
- Откуда: Санкт-Петербург
Re: OData API Обсуждаем нюансы использования
1) через oData API придется ждать завершения скрипта и ответа. шедулер запускается без ожидания ответа.Какой смысл через Admin API запускать шедулер чтобы он запустил скрипт, когда можно просто запустить скрипт через oData API ?
2) шедулер будет исполнять скрипты по очереди, а не все разом каждый через отдельную сессию
таблица, которая обрабатывается серверным скриптом, а он, в свою очередь, триггерится через шедулу.Не очень понял, какая здесь идея?
в серверном скрипте можно предусмотреть цикл, чтобы таблица проверялась на наличие записей не один раз в минуту, а постоянно в течение некоторого времени. Тогда новые задачи, попадающие в таблицу, будут исполняться немедленно.
Здесь важно подгадать так, чтобы цикл прервался незадолго до очередного запуска шедулы. Может, имеет смысл запускать шедулу не раз в минуту, а раз в час, а в самом скрипте ориентироваться на конкретное время, одинаково исчисляемое шедулером и скриптом. Например, выход из цикла, если до истечения часа остается пятнадцать секунд: > 2:59:45, > 4:59:45, > 5:59:45,
я не пробовал настроить такое
Re: OData API Обсуждаем нюансы использования
Помню делал что-то такое, чтобы запрашивать постоянно новые сообщения в телеграмм. Скрипт через шедул запускался раз в час и был в вечном цикле - а в шедуле как раз настроил сброс скрипта по таймауту черз 59 мин, так что скрипт час работал и потом заново запускался.
Но это все костыли, конечно. Я от такого ушел. Постоянно висящий скрипт на сервере мне кажется - фм такое не любит
Но это все костыли, конечно. Я от такого ушел. Постоянно висящий скрипт на сервере мне кажется - фм такое не любит