Архив метки: fiori

Допрыгались. SAP BUILD + WebIDE = нафиг мы кому нужны

Я люблю немного приукрашивать события, но обычно так оно и складывается. Все упрощается до безобразия. SAP HCM в США уже никому не нужен, все помешались на SF. Учите SF, друзья. ABAPеры тоже никому не сдались, ибо HANу-ц, ибо облака, ибо WebIDE, где Angular, Mustach, jQuery, jScript рулят. Бегите, одним словом, чтобы не остаться позади.

На этом лирическая часть заканчивается, начинается практическая. За два часа мне удалось сделать микропроект для микропонимания того, что написано абзацем выше.

Открываем SAP BUILD. Создаем проект для целей прототипирования. Идея Build в том (кстати, САП купил этот проект, раньше он был опенсорсным), чтобы создать визуальную модель, отправить ее на рецензию пользователям, разработчикам, дизайнерам. Собрать со всех обратную связь, допилить решение до готового прототипа. И как только оно всем понравится, то перенести этот прототип в WebIDE для наполнения бизнес-логикой и данными. И решение готово. Достаточно просто, быстро и эффективно.

Сегодня мы сделаем микропрототип и запустим его на WebIDE. В следующий раз подключим к SAP и подергаем данные.

Первые полтора часа ушли на то, чтобы накидать несколько страничек. Хелп по Build отвратительный. Мало что понятно. Какие-то элементы у меня не работают, другие странно себя ведут. Понятно, что в коде потом можно все поправить, но непонятно, почему в редакторе такие сложности.

Вот мой опус.

Читать далее

Автоматизация тестирования SAPUI5 и Fiori приложений. Часть 1

Рано или поздно сложность разработки приложений, многообразие способов взаимодействия с пользователем, скорость изменения технологий приводят к необходимости все более тщательной проверки функционирования приложения. Внешне простое приложение на экране телефона часто содержит большое количество строк кода и логики, схем взаимодействия с внешней средой. Сегодня, во времена «облачной революции» в Сети, мы все чаще работаем с сервисами, которые предоставляют нам услуги. То же простое приложение может использовать не один сервис, а несколько и даже из разных мест. Например, заявка на отпуск может вызывать сервисы для получения персональной информации о сотруднике, о его руководителе, об остатке дней отпуска, о проверке возможности зарезервировать дни отпуска, — это все частные сервисы, выраженные функциями в системе SAP HCM, но функционирующими как сервисы.

Есть и другое приложение, которое отвечает за согласование заявки на отпуск. Разумно предположить, что это приложение использует сервис для получения персональной информации о сотруднике. Тот самый, что и заявка на отпуск. Мы реализовали сервис один раз, а уже окупили его разработку двумя потребителями сервиса. Два приложения получают информацию из одного сервиса, но однажды появляется третье приложение, которому необходимо расширенный набор данных о сотруднике. Например, вывести его пол или возраст. Простейшая задача про добавление поля в выгрузку данных может стать кошмаром в большой системе. Все дело в том, что приложения разрабатывались в различное время, на разных уровнях систем, разными людьми, возможно с разными подходами и технологиями. И это изменение структуры данных, которую отдает сервис, одним приложением может обработаться корректно, а второе перестанет работать.

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

Другая часть приложения обычно отвечает за взаимодействие с пользователем. В приложении есть табличная форма заявок на отпуск, несколько кнопочек, включая кнопочку «Создать». На одном телефоне, где программист тестировал приложение, все работает отлично. На телефоне соседа табличка заезжает за поля экрана, кнопочку не видно. На компьютере кнопочка «Создать» не реагирует на нажатие, а у Ивана при нажатии на кнопку «Обновить» приложение завершает свою работу.

Такие ситуации, связанные с взаимодействием с пользователем, необходимо тестировать. Тестировать на различных платформах, разрешениях экранов, различных версиях браузеров и операционных систем. Такое многообразие вариантов потребует огромных ресурсов, которыми мало кто из разработчиков располагает. Для упрощения жизни тестировщиков появились серверы непрерывного тестирования, в задачу которых входит автоматизированное тестирование одного и того же приложения в различных средах. Такой сервер по заранее определенному сценарию запускает приложение в отдельной среде (нужная версия браузера, нужное разрешение, нужная операционная система), запускает все сценарии тестирования и записывает результаты в протокол. Разработчик уже работает с итоговым протоколом, где отражены ошибки, возникшие в конкретной среде. Локализация такой ошибки, исправление и перезапуск полного цикла тестирования экономит весомое количество времени, а значит и денег. Несомненно, что такое тестирование существенно повышает качество продукта, с которым будет работать конечный пользователь.

SAPUI5 основан на «китах Интернета» в лице HTML структуры, CSS разметки, JavaScript кода. Приложения, которые мы видим на экранах, созданы с помощью этих элементов статически или динамически. Когда мы нажимаем на кнопочку «Создать», то открывается новое окно. Мы заполняем его информацией и отправляем на сервер для создания записи в базе данных. Это уже целый процесс, где задействованы элементы экрана, коды для формирования запроса серверу и анализа результата. Раз все формализовано, то мы можем проверить работу процесса автоматизировано с помощью специальных инструментов.

Рассмотрим работу кнопки «Создать». По нажатию на кнопку происходит обращение к серверу (в общем случае) с запросом формы для окна создания новой записи. Сервер обрабатывает запрос и присылает необходимые поля, их оформление для визуализации на экране. Для пользователя это просто смена картинки, для автоматизированного теста это многоступенчатый процесс, который нужно проверить в нескольких ракурсах:

  • После нажатия на кнопку сформировался ли запрос к серверу?
  • Сервер вернул положительный ответ или ошибку?
  • Положительный ответ сервера, это страница с формой для ввода данных или что-то другое?
  • Форма для ввода данных содержит поля, которые мы ожидали или другие?
  • Форма для ввода данных осуществляет проверку на формат вводимых данных?

Выше приведен пример простейших тестов, которые должна выполнить система автоматизированного тестирования для проверки одной пользовательской операции «Создать». Если перемножить количество операций на вариативность сред для выполнения приложения и на возможные ракурсы, то мы понимаем, что без автоматизации не обойтись.

Предлагаю об этом нам и поговорить в следующих заметках.

UI5/Fiori = ?

Что вам интересно было бы почитать в этом блокнотике про UI5, Fiori?

WEB-ификация SAP

Недавно ко мне подошел один из моих сотрудников и задал вопрос: «А что такое аякс?». Вот прямо молодец, ни разу не про САП, не поленился, погуглил, сформировал мнение, пришел удостовериться. Андрюха, молодец! Хвалю. Аякс, это AJAX — технология, которая позволила ускорить интернет в разы. Если раньше информация о каждой страничке, всех ее составляющих формировалась на стороне сервера, заставляла выделить отдельный поток (через старый fork, а не thread), следом по старому протоколу HTTP 1.0 создавалась куча запросов вида клиент-сервер. Все это вываливалось на клиента = браузер, который оголтело начинал разбирать синтаксис полукривого HTML приправленного CSS соусом в неупакованном виде. Каналы перегружены, сервера перегружены, клиенты перегружены. Тотальный перегруз на планете.

И тут один умник придумывает передавать информацию кусочками, только то, что нужно конкретно сейчас, а не вообще. Простой пример — загрузка картинок в гугле в поиске. Вы пишите слово, картинки начинают подгружаться по мере пролистывания страницы вниз. Представьте тоже самое на старой технологии, когда весь интернет загружался бы к вам на компьютер. В те времена трафик еще был по-мегабайтный. Так вот аякс умеет загружать в фоновом режиме только то, что нужно или его намеренно попросили. Переключили вкладку на страничке — быстро сформировался запрос только той информации, которая нужна для этой вкладки. Оформление все отрисуется на клиенте в браузере. Результат — свободный сервер (он отдал минимум информации за короткое время), свободные каналы связи, довольный клиент. Современные компьютеры, смартфоны, *фоны умеют быстро анализировать документы и отрисовывать их на экранах, поэтому эту часть работы переложили с серверов на клиентов.

Вы, наверное, догадались, что я опять гадости писать буду про фиори. Покопаемся в кишках. Сервер приложений САП написан на базе бесплатного сервера J2EE Tomcat (если я не ошибаюсь). Это бесплатный опенсорсный продукт. Соблюдена правильная MVC архитектура с логикой на клиенте на базе JavaScript. Созданы хорошие курсы по разработке приложений на коленке. Сейчас все индусы и консультанты ринуться изучать, разрабатывать, наполнять рынок продуктами. Все как бы клево. У меня только появляется вопрос, а кто же учит тем вещам, которые скрыты за курсами и High Load системами? Представьте себе компанию с десятками тысяч сотрудников. Бывшие консы сели за фиори, наколбасили прожект. Например, табель рабочего времени. Простая вроде бы вещь. Однако в период закрытия месяца все пользователи начинают ломиться в систему, вешают все что можно и расстраиваются. Почему?

Читать далее

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

Удивились?

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

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

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

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

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