Этот год для всех нас стал особенным. Перечеркнул большинство наших планов и спутал все карты. Пандемия перевела многих из нас на удалённую работу, посадив по домам, квартирам и дачам. Ну а кого-то из счастливчиков, может быть, у синего моря.
Когда-то я написал цикл статей про параметры AS ABAP части SAP системы. В постах я описал где они хранятся и как их изменять. Можете освежить свои знания и прочитать статьи еще раз.
В первой части статьи я вкратце описал что собой представляет типовая архитектура виртуального кластера VMware. Теперь поговорим об отношениях между SAP и VMware.
Существует огромное количество источников знаний по SAP BW – это и курсы вендора, и многостраничные книги, и бесконечные блоги. Однако, найти в них сжатые ответы на практические, касающиеся оптимизации производительности отдельных элементов системы вопросы зачастую сложно либо невозможно.
Практически каждый SAP-новичок, пришедший на проект внедрения ERP-системы, сталкивается с задачей написания функциональной спецификации и дальнейшего тестирования ABAP-разработки. Казалось бы, задача весьма несложная, но не для специалиста, только ступившего на путь SAP.
Миграция данных на первый взгляд представляется низкоприоритетной проектной активностью. Однако это далеко от истины. Особенность процесса миграции заключается в том, что он тесно переплетен с такими задачами как переход (Cutover) и тестирование реализованного ERP-приложения (User Acceptance Test).
Последние 5 лет я развиваюсь в достаточно узкой и интересной сфере - IT-консалтинг по направлению SAP Transportation Management. С каждым новым проектом, идеей, новым или потенциальным клиентом возникают вопросы, на которые я для себя пытаюсь найти ответ. Если однозначного ответа не нахожу, то пытаюсь рассмотреть ситуацию с разных сторон для объективной оценки.
В конце прошлого года я участвовал в проекте миграции систем SAP на новую платформу, где, в частности, использовалась виртуализация. Так как до этого с продуктивным использованием сред виртуализации не сталкивался, а здесь пришлось достаточно глубоко погрузиться в эту область, я хочу поделиться своими знаниями.
В прошлом году наша команда получила запрос на разработку интересного и сложного приложения, которое будет использоваться как сотрудниками компании, так и клиентами. Редкая возможность разработки “с нуля” и полная свобода выбора технологии. Мы приступили к выбору платформы.
Во вселенной SAP сложились жёсткие границы между специалистами из разных областей. Каждый выполняет свои задачи, не выходя за пределы той области, в которой он специализируется. Функциональный консультант делает настройки в SPRO и пишет ТЗ для разработчика, разработчик пишет программы, создаёт объекты словаря, реализуя ТЗ, а администратор после всех этих действий обеспечивает работоспособность системы.
После запуска проекта только у единичных клиентов действительно начинаются работы по сбору и загрузке дополнительных данных по объектам технического обслуживания. Большинство же так и остаётся работать на том минимуме, который успели загрузить.
Резонный вопрос: может, не так уж нужны эти данные, раз компания может работать?
Сегодня я хочу поговорить про отношения между SAP и Oracle. Долгое время каждая компания была сосредоточена на одном виде программных продуктов: компания Oracle создавала базы данных и держала большую часть рынка СУБД, а SAP создавал системы управления предприятиями и владел большим куском "пирога" в своей софто-сфере.
В посте "Версии SAP ERP и SAP NetWeaver. А где же SAP S/4HANA?" я выкладывал таблицу с соответствиями версий основных продуктов компании SAP SE (S4/HANA, SAP ERP, SAP R/3) и технической платформы (NetWeaver, SAP WebAS, SAP_BASIS). Там же был затронут вопрос об окончании поддержки этих продуктов.
Практика показывает, что пользователи не любят запускать фоновые задания, а упрямо предпочитают пользоваться диалоговым режимом работы для всех своих задач и операций. И я так понимаю, что пользователи во всех странах очень похожи, раз в SAP системе был реализован механизм ограничивающий работу в режиме диалога.
В статье "Мониторинг рабочих процессов SAP системы" я описывал транзакцию SM50. Данная транзакция используется для мониторинга рабочих процессов ABAP инстанции. Так же в статье упоминалось, что начиная с релиза системы SAP NetWeaver 7.40 SP08, транзакция получила расширенную функциональность и позволяет просматривать рабочие процессы всех инстанций текущей SAP системы. Таким образом, произошла замена функциональности транзакции SM66.
Налоговый мониторинг – это цифровое будущее налогового контроля. Новая форма способствует переходу от традиционных форм к расширенному информационному взаимодействию. Вы получаете доступ к данным налогоплательщика в режиме реального времени.