Fiori – старые технологии

Удивились?

Не вру ни разу. Что такое Фиори? Набор приложений. Что такое UI5 – HTML5. Давайте серьезно поговорим, может я чего не понимаю. Работа фиори приложения:

СУБД – САПчег ERP – Шлюзик Gateway – Клиентик Фиори

Фиори это страничка, сверстанная на HTML языке разметки, приукрашенная CSS стилями, приправленная AJAX вызовами с тяжелой server-side логикой бизнес функций и косметической приправой client-side проверок.

САПчег ERP. Все наше ESS/MSS-ное, ничего нового особо нет. Те же RFC функции, веб-сервисы, ФМ-ники для управления данными.

Шлюзик Gateway – вот тут уже интересно. Это своего рода прокси – прослойка между клиентом и ERP. Он ретранслирует запросы клиента в вызовы конретных ФМ в ERP. Все это делается через OData сервисы, которые являются частными примером реализации REST технологии. Очень упрощенно это выглядит так.

Есть атомарные операции: прочитать, создать, изменить, удалить. По сути все взаимодействие с САП сводится к ним. Никакая операция не зависит от другой. Поэтому она атомарна. А сопутствующие функции в виде авторизации, целостности, контроля доставки и прочее обеспечивается шлюзом.

Клиентик – страничка, которая загрузилась на устройство. Вдруг устройство видит команды на языке Javascript – прочитай мне список командировок. Отправляется одна атомарная команда на шлюз – я – Иванов, дай мне список командировок. Шлюз не дурак, проверил, что Иванов есть Иванов (по тикетам в куках (cookies)), посмотрел как его послали за списком командировок (проанализировав состав URI запроса), вызвал от имени Иванова ФМ в САП. САП подумал, выдал список командировок. Шлюз подумал, упаковал их в SOAP/JSON и выплюнул обратно клиенту.

Клиент получил набор вида

<trips>
<trip>Моя первая командировка</trip>
<trip>Моя вторая командировка</trip>
<trip>Моя третья командировка</trip>
</trips>

или

{trips: {trip: Моя первая командировка};{trip: Моя вторая командировка};{trip: Моя третья командировка}}

Вот вам пример SOAP и JSON форматов. Язык программирования Javascript на клиенте проанализировал все это и понял (умный!), что ему прислали три командировки. Потом дает команду: в таблицу командировок на экране добавить три элемента. И все. Мы получили список. Если нам нужно удалить командировку, то клиент отправит одну атомарную функцию – удалить командировку номер 2. Сервер ответит 200 “Ок” или “Не согласная я”. Клиент изучит ответ и выдаст пользователю ошибку или удалит запись из таблицы и перерисует экран.

Что мы получаем? Клиент рисует и управляет логикой экрана сам, не тревожа сервер. Это многократно ускоряет его работу. Ввиду того, что все делается через AJAX (асинхронные вызовы), то пока сервер со шлюзом договариваются, клиент работает дальше. И это психологичеси добавляет скорости приложению.

Почему все старье? Да это используется в web программировании уже как минимум лет 5. А то и больше. И если немного расширить кругозор, то можно увидеть, что САП это всего лишь сервер приложений, который предоставляет стандартные интерфейсы по стандартным международным протоколам. Все современные сайты работают на этих технологиях, что позволяет их делать масштабируемыми, быстрыми (сколько секунд уходит у гугла на подбор предложений? А он просто заранее все загружает пока вы набираете в строке поиска запрос). Развивая эту тему можно увидеть и то, что САП легко встраивается в любой сайт, портал как сервис. Один из десятка или сотни других. Стандартные механизмы авторизации и аутентификации позволяют использовать его прозрачно, без дополнительной авторизации, храня лишь набор символов тикета в HTTP заголовке.

Понимаете к чему я веду? Эти все новомодные облачные решения лишь обертка в виде красивых картинок, которые дергают сервисы бэкэнд систем. По тем же старым протоколам. И создается умопомрачительная картинка мгновенного отклика, удобства работы, usability и так далее. Почему SAP Personas так красиво звучал год назад и уже всеми забыт? Да просто все – это слишком тяжело, старо. UI5 работает в разы быстрее, разрабатывать на нем тоже быстро, поддерживать дешево, так как фронтэнд разработчиков сейчас как 1Серов. И выглядит на голову выше.

Что я думаю на этот счет? Ребят, учите Javascript, CSS, HTML. И китайский с индийским.

 

P.S. Не забывайте, что вам перепост ничего не стоит, а нам даст новых читателей, вопросы и темы для обсуждения 😉

Fiori – старые технологии: 5 комментариев

  1. Vasiliy

    Согласен, насчет того, что вместо того, чтобы посещать все лето вечернюю школу ABAP, лучше учить актуальный SAP-овский Frontend (Javascript, CSS, HTML) и бэкенд для расширений (Java, HANA XS – для очень специфичных задач).
    В Core систему S4/HANA, Cloud Edition они никого уже абапить не пустят, клиентская специфика будет разрабатываться на HCP, где это действительно имеет смысл, в том и числе и легкое создание “обертки” с помощью FIORI на SAP WEB IDE, используя стандартные OData сервисы Core системы.
    Также советую забыть, как страшный сон, все эти BSP, WDJ, WDA. В этом отношении, движение SAP к индустриальным стандартам можно только приветствовать.

  2. Vasiliy

    Стоит сказать, что Fiori – это в первую очередь перспективная UX стратегия SAP для всех своих решений (разработанных и приоритенных) и парадигма разработки Frontend: Role-based, Responsive, Simple, Coherent, Delightful приложений. И технологический стек – адаптированная часть SAPUI5 (Javascript, CSS, HTML) – уже вторичная часть. Разработанное на HTML5 приложение для SAP не делает его “Fiori-styled”.
    Заинтересованным рекомендую ознакомиться с SAP Fiori Design Guidelines:
    http://experience.sap.com/fiori-design/
    а также с замечательным OpenSAP-курсом Build Your Own SAP Fiori App in the Cloud:
    https://open.sap.com/courses/fiux1/
    Кстати, в рамках его задания я делал Fiori-приложение, как расширение для процессов SuccessFactors (используя его OData Api), которое вообще не имеет отношения к SAP ERP и SAP Gateway – т.е. описанный в статье сценарий – только частный случай реализации Fiori.

  3. VirVit Автор записи

    Разумеется 🙂 Это лишь концепция современного Web-приложения. Три шага, три клика, три окна. Маркетинговая обертка и сервисный подход к бизнесу.

  4. Calm

    >>Почему все старье? Да это используется в web программировании уже как минимум лет 5.
    А я знал, т.к. в прошлой жизни был web-разработчиком 🙂

    >>UI5 … разрабатывать на нем тоже быстро, поддерживать дешево, так как фронтэнд разработчиков сейчас как 1Серов

    Нет.
    Во-первых, OData – это всё же экзотика. Только для интеграции всяких монстров вроде сапа со “всем, чем угодно” (т.е. ни с чем). Интеграция с монстрами – это местячковые задачи, ими не занимаются все подряд web-разработчики. Доли процента, не более.

    Во-вторых, web-разработчики пользуются насколько удобными, производительными инструментами, что уж извините, сап не осилит никогда. А время разработчика – оно деньги. Если чувак делает web-приложение за 1000 за 1 месяц, он не будет делать его за ту же 1000, но за полтора месяца.

    В итоге, да, web-разработчиков много, а сделать UI5 приложение по-прежнему геморно и дорого.

  5. Vasiliy

    Calm, я без специальных навыков web-разработки сделал свое первое Fiori демо приложение – прохождения испытательного срока для Successfactors за 1 час на SAP WEB IDE (правда, без действий, только просмотр). Что я делал не так?
    Так же посмотрите галерею приложений победителей соревнования (разыгрывалось 3 макбука) упоминавшегося MOOC курса Build Your Own SAP Fiori App in the Cloud.
    https://cloudnwcportal-cplto.hana.ondemand.com/opensap
    Это в большинстве своем функциональщики, а не разработчики, и занимались приложением несколько часов в нерабочее время в рамках курса.

Добавить комментарий