Хорошие новости от SAP в части лицензирования

Всем привет.

САП решил порадовать всех любителей хардкора: http://news.sap.com/sappire-now-modern-pricing-modern-times/

Теперь можно разрабатывать свой сервисы в режиме «только чтение» для большого количества сотрудников во внешних системах без дополнительного лицензирования. Раньше мы должны были покупать ESS лицензии на каждого пользователя, даже если он просто смотрел свой расчетный листок. Теперь для таких функций «на посмотреть» можно использовать свои решения, мобильные приложения, сторонние порталы, выкачивать туда данные (без XI/PI/PO) и отдавать пользователям.

Отличная новость. Лишь бы теперь контрактный отдел и сейлы САПа ее прочитали 😉


Интересная статистика партнеров в США

Делаю обзор рынка SAP в США. И вот что получается по основным компонентам и продуктам, которые популярны в мире.

Sell партнер имеет право продавать решения. Service партнер имеет право внедрять и поддерживать.

Почему-то практически нет облачных партнеров, хотя все рыночные тенденции к нам приходят с Запада.

sap USA partners statistics


Почему не стоит бояться ABAPа

Часто слышу про такую фантазию как zero-abap project. Проекты, где нет АБАПа. Почему все заказчики так его бояться и почему в России без него нельзя запустить проект? Основной аргумент заказчика обычно таков, что при использовании абапа нельзя нормально обновлять систему, что это влечет к увеличению стоимость сопровождения и бла-бла-бла. Интересно, а изменение схемы, кадровых мероприятий, использования OM объектов не влечет к тем же проблемам? ABAP он хотя бы изолирован от всего остального, его видно издалека, а изменения в настройках системы обычно без стакана чая не разберешь. Особенно, когда приходит нота с необходимостью внести изменения в стандартную схему, которую ты уже похоронил, а тут надо разобраться какие операции вносить, а какие не нужно.

Я считаю, что большее зло, это изначально неверная архитектура системы, затыкание дыр промежуточными решениями, кодинг расширений в схемах. Большая часть абапа зачастую приходится на отчетность и user-exit, которые самостоятельно и мало зависят или влияют на обновления системы. САП предоставил инструмент для разграничения полномочий и сфер влияния. Только в логике настроек такого нет инструмента, так как там все слишком взаимосвязанно.

 


Обновление SAP систем для начинающих

САП действительно обновляется. Как правило один раз в месяц. Ниже я расскажу простые вещи про обновление САП систем в части вообще и HR в частности. Сам я давно обновлениями не занимался, какие-то нюансы могу упустить.

Обновления бывают разные. В общем смысле этого слова и как привыкли считать заказчики, обновление, это исправление ошибок и выход новых форм или реализация требований законодательства. Часто по этому параметру сравнивают САП с 1С. Могу сказать, что САП обновляется достаточно часто для такой махины как САП, но недостаточно проактивно как 1С.

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

Есть ноты, где указываются инструкции по ручному исправлению. Часто это касается заработной платы, где нужно добавить кусочки правил расчета или записи в таблицы. Такие ноты устанавливаются вручную по инструкции в самой ноте. Такие ноты нельзя откатить автоматизированно.

Ноту можно скачать с support.sap.com/notes или в транзакции SNOTE. Просто указываем ноту, она скачивается, выбираем ее в списке и нажимаем применить. Система сама учтет правильную версию ноты именно для вашей системы.

Обычно ноты ставятся в системе разработки, сохраняются в транспортный запрос и дальше переносятся по ландшафту стандартной системой транспортных запросов. БЫвают исключения, когда в ноте содержится какой-нибудь XML файл, справочник основных данных, который нужно применить прямо в продуктивной системе (или в каждой системе в ландшафте). В таких случаях указана инструкция что и как сделать, куда «подсунуть» файлик из ноты.

Читать далее


Автоматизация контроля программного кода в ABAP с помощью SAP Code Inspector

Жизнь подкидывает мне интересные задачки. На днях мне пришлось задуматься об автоматизации контроля качества ABAP разработок. В системе есть инструмент для автоматизации контроля качества программного кода, написанного на языке ABAP. Транзакция ATC созвучна с ABAP Test Cockpit.

Тестирование программного кода в SAP

тестирование программного кода (авторство изображения не установлено)

Например, мы можем сказать системе проверять все деблокированные запросы в части разработок на контроль качества с помощью ABAP Code Inspector, где можно задать правила приемки кода. Можно попросить систему автоматизированно по расписанию проверять код, написанный программистами на заранее определенные правила и не допускать его перенос по ландшафту. Для заказчиков я бы рекомендовал включать такие требования в технические задания, чтобы хоть как-то прививать культуру разработки и тестирования кода. Не забывая, что за качество тоже нужно платить. Хотите обеспечить отсутствие бэкдоров в системе или неэффективного кода — пропишите в Code Inspector правила, которые не позволят переносить такие «сомнительные» разработки до ручного утверждения. Запретите прямые SQL выборки во избежание нарушения полномочий доступов. Разработайте политики безопасности, производительности и управляемости программным кодом — это сэкономит существенное количество денег, если вы хотите их считать. Деньги считать.

Транзакция SCI — Code Inspector — позволяет настраивать правила, перечень объектов/людей для контроля. Правила игры простые:

  1. Код должен быть «чистым» в части производительности, читабельности, безопасности. Иначе рефакторинг.
  2. Код должен быть на 100% покрыт тестами. Иначе вы получите ошибки в продуктивной среде.
  3. Пункты 1 и 2 должны быть регламентированы, документированы и обязательны. Без исключений.
  4. В случае проблем начни с пункта 3.

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

Откроем транзакцию SCI.

Читать далее