Сортировать:

Новое Популярное

Комментарий от Арман Алексанян 21 января 2021, 11:02

Коллеги, подскажите, что вы думаете о прекращении поддержки SAP модуля HCM в 2025-2030 году?
Является ли это конечной точкой в карьере консультанта модуля HCM ?
Мнения делятся, ибо кто-то говорит - да, sap прекратит поддерживать и будем поддерживать мы (консультанты HCM). Вторая половина полагает полное слияние с другим модулем, соответственно нужно обучаться другому модулю.
 

 
Ссылка на статью:
news.sap.com/2018/01

Комментарий от Олег Точенюк 10 декабря 2020, 02:39

Олег Башкатов 07 декабря 2020, 19:18

Думается, что речь идет о создании/управлении признаками через транзакцию CT04. Вы можете указать длину признака, возможные значения, а также можете "прикрутить" даже функциональные модули проверки.

Ну для Да/Нет оно вряд ли нужно делать программируемые проверки. А так да Олег прав, точка измерения при создании ссылается на признак системы классификации. Соответственно скорее всего вам нужно создать признак с нужными параметрами типа CHAR1 в который внести два возможные значения.

Комментарий от Олег Башкатов 07 декабря 2020, 19:18

наталия невидомская 04 декабря 2020, 20:42

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

Думается, что речь идет о создании/управлении признаками через транзакцию CT04. Вы можете указать длину признака, возможные значения, а также можете "прикрутить" даже функциональные модули проверки.

Комментарий от Александр Козаренко 07 декабря 2020, 13:32

Добрый день.
После BUPA_DEL как я понимаю останутся БЕ и прочие ракурсы типа рынков сбыта. Тогда есть информация о том, как их удалить после BUPA_DEL?

Комментарий от наталия невидомская 04 декабря 2020, 20:42

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

Комментарий от Михаил Колбин 04 декабря 2020, 18:22

Спасибо большое!

Комментарий от Александр Носов 04 декабря 2020, 12:14

Михаил Колбин 04 декабря 2020, 12:09

Вот бы пример такой посмотреть...

Комментарий от Михаил Колбин 04 декабря 2020, 12:09

Александр Носов 04 августа 2020, 16:24

Связь между контроллером и представлением можно ослабить:
1. В контроллер передавать интерфейс представления.
2. Интерфейс представления должен содержать: метод для отображения представления; события взаимодействий с пользователем; контекст (часть модели для отображения).
3. В контроллере нужно реализовать события представления.
4. В конструкторе контроллера нужно подписаться на события представления и связать модель с контекстом представления.

Вот бы пример такой посмотреть...

Комментарий от Ирек Абдуллин 30 ноября 2020, 10:22

Добрый день.
Возможно ли использовать данный инструмент, для рассылки сообщений по создании MM заявки?

Комментарий от Вячеслав Шиболов 28 ноября 2020, 14:42

Роман Бондарев 27 ноября 2020, 19:59

Вячеслав, рекомендации выключить iptables и отключить SELinux основаны на личном опыте или на официальных рекомендациях вендора?

Это в большей части рекомендации вендора

Комментарий от Роман Бондарев 27 ноября 2020, 19:59

Вячеслав, рекомендации выключить iptables и отключить SELinux основаны на личном опыте или на официальных рекомендациях вендора?

Комментарий от Евгений Тенищев 21 октября 2020, 23:21

Было бы не плохо продемонстрировать скриншотом как это выглядит в lsmw. Особенно интересно в разделе где прописывается мэппинг.
Пока, если честно, не понятно как это реализовать в lsmw.

Комментарий от Александр Игнатенко 14 октября 2020, 21:53

Олег Точенюк 14 октября 2020, 21:38

Однако классные консультанты, буферизацию сами включают :-), я как-то думал, это не задача функционального консультанта. Но вы расширили мой кругозор редкими экземплярами. Не знал про таких.

Мир далеко не идеален, есть и такие консультанты. :)

Комментарий от Олег Точенюк 14 октября 2020, 21:38

Александр Игнатенко 14 октября 2020, 17:18

Олег, доброго дня.
Абсолютно согласен, абапер может уложить систему так что базиснику не снилось. Но и консультанты имеют возможности попортить жизнь.
Ни кому не сказав, включает буферизацию на Z-таблицу размером 30ГБ с документами, со словами "а мне **** сказал, что так быстрее". Результат я думаю понятен. Или другой, включил заполнение инфраструктуры на выходные, логи за пару часов забили директорию в которой был 3-х кратный запас, система встала. Для справки, она в результате была 780ГБ. Ещё вариант: включили параллельную обработку, уже не вспомню деталей, всё бы ничего, вот только одновременно этот процесс запускали 30 человек, и рабочих процессов под такую нагрузку не было предусмотренно. Объяснение такое же простое: "на DEV и QAS у меня всё работало".
Список можно продолжать. У каждого свои истории.

Однако классные консультанты, буферизацию сами включают :-), я как-то думал, это не задача функционального консультанта. Но вы расширили мой кругозор редкими экземплярами. Не знал про таких.

Комментарий от Александр Игнатенко 14 октября 2020, 17:18

Олег Точенюк 14 октября 2020, 12:46

====
как производимые ими настройки и разработки могут повлиять на работоспособность системы в целом
====
Да никак, на то она и настройка, это вы ведь не про абаперов писали? Абаперы те да, положить систему могут быстро и качественно :-)

Олег, доброго дня.
Абсолютно согласен, абапер может уложить систему так что базиснику не снилось. Но и консультанты имеют возможности попортить жизнь.
Ни кому не сказав, включает буферизацию на Z-таблицу размером 30ГБ с документами, со словами "а мне **** сказал, что так быстрее". Результат я думаю понятен. Или другой, включил заполнение инфраструктуры на выходные, логи за пару часов забили директорию в которой был 3-х кратный запас, система встала. Для справки, она в результате была 780ГБ. Ещё вариант: включили параллельную обработку, уже не вспомню деталей, всё бы ничего, вот только одновременно этот процесс запускали 30 человек, и рабочих процессов под такую нагрузку не было предусмотренно. Объяснение такое же простое: "на DEV и QAS у меня всё работало".
Список можно продолжать. У каждого свои истории.

Комментарий от Олег Точенюк 14 октября 2020, 12:46

====
как производимые ими настройки и разработки могут повлиять на работоспособность системы в целом
====
Да никак, на то она и настройка, это вы ведь не про абаперов писали? Абаперы те да, положить систему могут быстро и качественно :-)

Комментарий от Олег Точенюк 01 октября 2020, 09:30

Виталий Глущенко 01 октября 2020, 00:16

все ж было б неплохо указать в статье, что не стоит параллелить пока не выжали все из последовательной обработки. А то находятся последователи индуских талмудов, так напараллелят, что другие процессы стоят.
 
Пример в статье идеальный, 20 задач, 9 параллельных процессов, задача грузит только CPU, поэтому отлично подходит для параллезации. Получили шикарный прирост производительности 80/12 ~= 6,7 раз. Реальный пример, от Олега дает всего лишь 20 632 688/11 520 002 ~1,79 увеличение, при 3-х кратной парализации.
Лучше вначале разобраться, где у вас узкое место и почему оно именно настолько узкое. Иначе есть риск наткнуться на "бо-бо" в продуктивной системе, после "новаторской" оптимизации.

По поводу последующей параллельности, при таком подходе когда сначала сделали как сделали, а через год пришли к тому, что нужно параллелить, есть одна проблема, потом это сделать практически невозможно, точнее это значит полностью переписать программу, т.е. если есть мысль последующей параллелизации программы, то я бы сразу ее делал с параллельным выполнением, но ставил бы 1 процесс и на год бы забывал о проблеме :-)

Комментарий от Виталий Глущенко 01 октября 2020, 00:16

Олег Точенюк 31 августа 2020, 14:28

Чего-то у меня цифры не бьются. Например на установку статуса пусть уходит 1 секунда, и время закрытия 5 часов итого за это время при последовательном закрытии у тебя закрывается 5 * 3600 = 18 000 заказов. После распараллеливания, заказ как зарывался за 1 секунду так и будет закрываться, что его параллельно, что последовательно грузить (бапишке фиолетово она в своем процессе отработает необходимое ей время как ты ее не крути). По твоим словам, теперь это все стало отрабатывать за пару минут, ну пусть это будет 5 минут для ровности. Итого у тебя каждую минуту закрывается сколько? Правильно 3600 / 5 = 720 заказов. Короче я в своей жизни систему с 720 свободными процессами не видел еще, твоя видимо первая будет, ну это чтобы оно таки за пару, точнее 5 минут отработало. В общем если бы была реальная статистика с рабочей системы приведена, было бы чуть интереснее. В свое время когда такое делал я просто привел цифры, чтение 120 000 документов:
 
Паралельно 3 процесса: 11 520 002 милисекунд
Последовательно : 20 632 688 милисекунд
 
А ну и сейчас перформы уже не модно Василий К. придет будет говорить, что это не правильное программирование :-), на классах параллельность выглядит чуток интереснее и красивее в реализации, программа обработки выглядит типа так:
LOOP AT <по каким-то объектам которые надо обработать>.
lcl->read( ).    "Прочитали что надо обработать в процесе
lcl->process( ). "Запустили процесс обработки
lcl->wait( ).    "Ждем если нет свободных процессов, иначе идем на следующий шаг.
ENDLOOP.

все ж было б неплохо указать в статье, что не стоит параллелить пока не выжали все из последовательной обработки. А то находятся последователи индуских талмудов, так напараллелят, что другие процессы стоят.
 
Пример в статье идеальный, 20 задач, 9 параллельных процессов, задача грузит только CPU, поэтому отлично подходит для параллезации. Получили шикарный прирост производительности 80/12 ~= 6,7 раз. Реальный пример, от Олега дает всего лишь 20 632 688/11 520 002 ~1,79 увеличение, при 3-х кратной парализации.
Лучше вначале разобраться, где у вас узкое место и почему оно именно настолько узкое. Иначе есть риск наткнуться на "бо-бо" в продуктивной системе, после "новаторской" оптимизации.

Комментарий от Федор Иванов 25 сентября 2020, 07:50

"Обучение ABAP. Отладчик. Основы" на сайте 29.09
в календарь пришло приглашение на 30.09
где то неточность!

Комментарий от Олег Точенюк 03 сентября 2020, 23:07

Наталья Сурмак 03 сентября 2020, 09:49

Статья замечательная. Но хотелось бы подробнее узнать по настройке проводок.

Настройки проводок это то, за что Мари Лоран, получает деньги, поэтому спасибо ей, что она поделилась, скажем так безвозмездно, т.е. даром, о том что есть такая вот функциональность. Теперь у вас есть два варианта, разобраться самой или пригласить независимого консультанта Мари Лоран, которая сделает это за вас, конечно уже не безвозмездно, т.е. не даром :-)