Введение в OpenEdge Mobile: RUN-TIME АРХИТЕКТУРА

Доступ к AppServer-классам и процедурам через объекты JavaScript

На рисунке 3 более детально демонстрируется как мобильный сервис маппирует операции одного мобильного ресурса к методам JSDO в мобильном приложении на стороне клиента и к ABL-процедурам singleton-объекта на стороне сервера приложений.

На рисунке объект singleton-класса Customers предоставляет ABL-методы для выполнения операций мобильного ресурса Customers. На рисунке проиллюстрированы все операции, которые доступны для мобильного ресурса. Стандартными, встроенными, мобильными операциями являются Create, Read, Update и Delete (также известны как операции CRUD). Вы можете использовать Developer Studio для аннотирования ABL-подпрограмм соответствующего мобильного интерфейса, который их реализует. Для каждой встроенной мобильной CRUD-операции вы можете аннотировать только одну ABL-подпрограмму как реализацию ABL-метода. Все ABL-подпрограммы, реализованные как мобильные операции, должны поддерживать одинаковую схему в виде одиночной временной таблицы (temp-table) или ProDataSet-параметра. Кроме того, реализация операции чтения должна предоставлять начальный входной параметр (CHARACTER) с именем filter (см. таблицу). Для невстроенных вызовов операций вы можете аннотировать любое количество ABL-процедур с использованием любых поддерживаемых ABL-сигнатур. Тем не менее, ABL-процедуры, аннотированные как вызываемые операции не могут одновременно быть аннотированы для реализации встроенных CRUD-операций.

Следующая таблица содержит список необходимых параметров для ABL-подпрограмм (методы классов, внутренние процедуры, или пользовательские функции), которые реализуют встроенные мобильные CRUD-операции.

Как показано на рисунке 3 для ресурса Customer, когда вы создаете JSDO для этого ресурса, JSDO предоставляет JavaScript-методы, которые связываются с каждой мобильной операцией, определенной для этого ресурса. Каждый JSDO поддерживает одинаковый набор встроенных методов для вызова встроенных мобильных операций. Например, вызов метода fill() всегда выполняет мобильную операцию чтения, которая в этом случае реализована ABL-методом ReadCustomers(). Эта операция возвращает все записи временной таблицы, предоставляемые соответствующей ABL-подпрограммой, и сохраняет их во внутреннее хранилище данных JSDO, которое называется локальное хранилище JSDO (JSDO local storage).

Локальное хранилище JSDO всегда соответствует схеме поддерживаемой JSDO-ресурсом, как это определено в каталоге JSDO для мобильного сервиса. Поэтому, если ресурс JSDO поддерживает единственную схему временной таблицы, то и локальное хранилище JSDO будет хранить записи, полученные из единственной временной таблицы. Если схема представлена в виде единого набора ProDataSet, то сохраняются все записи, возвращенные для всех временных таблиц ProDataSet, для которых по умолчанию поддерживаются все связи, определенные между этими записями.

Для обновления контекста своего локального хранилища JSDO поддерживает дополнительные встроенные методы. Например, метод add() в JSDO создает новую запись в локальном хранилище JSDO. Аналогично, метод assign() обновляет, а метод remove() удаляет существующие записи в локальном хранилище JSDO. Когда мобильное приложение вызывает встроенный метод JSDO saveChanges(), то выполняется соответствующая встроенная мобильная операция (Delete, Create, или Update), по одной за раз для каждой записи, которая была изменена в локальном хранилище. Что произойдет с записью на AppServer при выполнении конкретной операции, полностью зависит от реализации ABL-подпрограммы. На рисунке 3 подпрограммы, которые реализуют эти встроенные операции на стороне AppServer`а, это DeleteCustomer(), CreateCustomer() и UpdateCustomer(), соответственно.

Для встроенных CRUD- операций JSDO всегда выполняет вызываемые методы асинхронно и поддерживает события, на которые мобильное приложение может подписать функции для обработки результата. Эти результаты возвращаются в OpenEdge-объекте (объект запроса) со свойствами, которые зависят от результата работы и события. Таким образом, каждая ABL-подпрограмма, которая реализует встроенные операции, может возвратить ошибку и ту же (или её модифицированную версию) запись, которую она получила, в зависимости от того, успешно или нет, была выполнена операция. Объект запроса, возвращающий эти результаты, поддерживает большое разнообразие успешных и неуспешных вариантов ответов, которые могут быть определены для данного мобильного приложения. Обратите внимание на то, что при сбое в работе встроенной операции любые изменения, связанные с этой операцией, будут отменены в локальном хранилище JSDO.

Для вызываемых невстроенных операций каждая ABL-подпрограмма принимает и возвращает  собственные входные и выходные параметры, возвращаемые значения не оказывают влияния на локальное хранилище JSDO. Каждая вызываемая операция позволяет параметрам и любым возвращаемым значениям быть переданными в соответствии с требованиями реализуемой ABL- подпрограммы. Входящие параметры передаются как входящие свойства объекта JavaScript, а все результаты, в том числе любые выходные параметры, возвращаемые значения и ошибки, возвращаются в выходном объекте запроса подобно объекту, возвращаемому для встроенных операций.

Чтобы выполнить операцию вызова, мобильное приложение вызывает соответствующий JSDO- метод вызова (JSDO invocation method), который выполняет соответствующую ABL-подпрограмму. По умолчанию метод вызова выполняется асинхронно, но может быть выполнен синхронно путем его вызова с использованием той же сигнатуры с добавлением логического (Boolean) параметра со значением false. Например, на рисунке 3 обращение к методу вызова getCreditHIstory() на JSDO выполняет метод GetCreditHistory() на AppServer`е. Если getCreditHIstory() вызывается асинхронно, то результирующий JavaScript объект запроса будет возвращен в мобильное приложение как параметр некоторой функции подписанной в качестве обработчика соответствующего JSDO-события. Если же вызывать синхронно, то getCreditHIstory() вернет тот же JavaScript объект запроса как возвращаемое значение метода.