Версионность oData сервиса

Технология SAP Gateway предоставляет консультантам и разработчикам возможность задействовать старушку версионность при совершенствовании/доработке своих oData сервисов. Одним из приятных моментов в этом всем является то, что старые версии oData сервиса доступны для использования наряду с новыми. Что я имею ввиду? При разработке новых версий oData сервиса, старые могут использоваться в вашем приложении без каких-либо ограничений.

Далее в заметке будет рассмотрен пример создания oData сервиса с последующим формированием его второй версии, которая, в свою очередь, будет основываться на уже имеющейся первой.

Шаг #1. Создание нового oData сервиса (версия 001)

На следующем видеофрагменте представлена последовательность действий в результате которой создается первая версия oData сервиса.

Пример создания oData сервиса ранее также был рассмотрен в одной из уже опубликованных заметок.

Шаг #2. Подготовка к созданию новой версии oData сервиса

Важным составляющим каждого oData сервиса, разрабатываемого в системе SAP, является пара классов: Model Provider Class и Data Provider Class. Для последующих манипуляций по созданию новой версии, мне потребуется задействовать один из этих классов. В проектной жизни, скорее всего, понадобится выполнить создание новых версий обоих типов классов. Для демонстрации в этой заметке, задействован будет только Data Provider класс.

Я скопирую ранее созданный DPC_EXT класс в новый, и внесу в него небольшие косметические изменения. На следующем видеофрагменте представлена соответствующая последовательность действий.

Шаг #3. Создание и регистрация новой версии oData сервиса (версия 002)

На следующем видеофрагменте представлена последовательность действий, в результате которой в системе создается новая версия oData сервиса с обязательным присвоением ей новой версии DPC_EXT класса (см. пункт Шаг #2. Подготовка к созданию второй версии oData сервиса. Создание нового *DPC_EXT класса). Регистрация новой версии oData сервиса выполняется в транзакции /IWBEP/REG_SERVICE

Пожалуйста, обратите внимание на то, что для вновь создаваемой версии oData сервиса также необходимо указать Model Provider класс, даже если его новая версия вами не создавалась (как в рассматриваемом примере).

Шаг #4. Активация новой версии oData сервиса в системе

Активируйте вновь созданную версию сервиса под номером #002 в системе, используя транзакцию /IWFND/MAINT_SERVICE.

Шаг #5. Проверка вызова новой версии oData сервиса

Посредством все той же транзакции SEGW, проверяю вызов второй версии oData сервиса. Вызвать определенную версию oData сервиса можно, указав соответствующий номер в запрашиваемом URI. Например,

/sap/opu/odata/SAP/ZDEMO_VERS_SRV;v=2/

Проверяю, что получилось.

Шаг #6. Параллельный вызов двух версий oData сервиса из SAPUI5 приложения

Для подтверждения и демонстрации факта параллельного вызова нескольких версий oData сервиса в пределах одного SAPUI5 приложения, предлагаю ознакомиться с короткой демонстрацией работы приложения со следующим исходным кодом его контроллера

onInit: function() {
 
  var sServiceUrl_v1 = \'/sap/opu/odata/SAP/ZDEMO_VERS_SRV;v=1\';
  var OdataModel_v1 = new sap.ui.model.odata.v2.ODataModel(sServiceUrl_v1);
  var sPath1 = "/outTextSet";
  OdataModel_v1.read(sPath1, {
                success: function(oData, response) {
                    console.log(oData.results);
                }
            });
 
   var sServiceUrl_v2 = \'/sap/opu/odata/SAP/ZDEMO_VERS_SRV;v=2\';
   var OdataModel_v2 = new sap.ui.model.odata.v2.ODataModel(sServiceUrl_v2);
   var sPath2 = "/outTextSet";
            OdataModel_v2.read(sPath2, {
                success: function(oData, response) {
                    console.log(oData.results);
                }
            });
 
        }
    });