Рекомендации понятны. И скорее всего, действительно имеют место быть. Но, они как-то все вокруг ведения основных данных: пункты 1, 2, 6, 9 и 10 - это по сути все о ведении основных данных.
Пункт 3 - это понятно, но слишком очевидно чтобы быть дельной рекомендацией.
Пункт 5 - по сути частный случай пункта 3.
Пункты 4, 7 и 8 - рекомендации относительно производительности. Это полезные рекомендации, особенно для тех, кто не имел опыта продуктивных эксплуатаций.
К сожаление не описано ничего касательно именно самой функциональности SNP. Видимо это было за рамками того, что автор хотел описать в статье, но тем не менее - это по сути именно то, ради чего ставят АРО. Систему не ставят чтобы озадачиться ведением основных данных или оптимизацией быстродействия. Основная задача SNP - оптимизация долгосрочного и среднесрочного планирования. А особенности и рекомендации именно применение оптимизационных алгоритмов APO в данной статье не описаны.
Стаья написана достаточно простым и понятным языком. Понравилось, что заострено внимание на важных моментах процесса. Хорошо проиллюстрирована.
Хотя на практике такая необходимость встречается редко, но знать подобные возможности полезно.
Конечно в период кризиса все хотят уменьшить свои расходы и экономят на всем, это не новость. Только по-моему опасно отказываться от обновлений, которые содержат изменения в логике работы программы в соответствии с изменением законодательства.
Первые два способа имеют право на существование, но в моей практике ни разу не использовались, т.к. при изменении бизнес-логики приложения очень часто нужно знать не все BADI/USER-EXIT\'ы которые имеются в программе, а только те которые будут относиться к какому-то событию. Для этого больше всего подходит способ \"Поиск BAdI при помощи трассировки SQL\", но у него есть огромный недостаток, это наличие прав на запуск ST05. На некоторых проектах в которых участвовал я, базисники отказывались давать права на ST05. В таких ситуациях помогало наличие прав на запуск отладчика(у ABAP-разработчиков они практически всегда есть). На примере который привел УСМАН необходимо запустить отладчик(/h или /hs), непосредственно перед нажатием кнопки \"save\". Потом нажимаем кнопку \"save\" и в отладчике нажимаем F9 и вводим CALL CUSTOMER-FUNCTION для остановки на всех USER-EXIT\'ах и F9 на вкладке Method вводим
Class name: CL_EXITHANDLER
Method name: GET_INSTANCE
и нажимаем F8. Теперь мы будем останавливаться на каждом расширении и можно будет изучить передаваемые в расширение параметры. Так проще найти BADI, которые лучше всего подходят, для данного случая. Есть и другие способы, но использование отладчика помогает решить 90% проблем с поиском расширений.
Интересная статья. По сути небольшой и очень простой проект с технической точки зрения, т.к. нет интеграции с другими решениями, а для крупных проектов это почти всегда необходимо; также довольно простой воркфлоу без кучи согласований \"всех со всеми\":). В общем, почти Best Practice.
весьма неплохая статья. Имеет качественно другой уровень, нежели предыдущие статьи.
Я бы здесь дополнительно рассмотрел бы связку xs - sap nw в режиме доступа online. Но в целом автору удалось осветить основные моменты интеграции продуктов
очередной плохо переписанный хелп. В аннотации говориться о методах, которые позволят свести к нулю время простоя. В самой статье ничего об этом не сказано, тупо переписан хелп и курсы и сделана отсылка к статье Майкла Лавлеса (Michael Loveless) и Георгия Патчова (Gueorgui Patchov) Load Data into Two BW Systems from One R/3 Source with Zero Downtime (“Загрузка данных из одной исходной системы R/3 в две системы BW с нулевым периодом простоя”). Эта статья была опубликована в базе знаний BI Expert в феврале 2005 г.
Статья представляет интерес, как с теоретической точки зрения, для лучшего понимания происходящих процессов, так и с точки зрения возможного практического применения в будущем.
Мешает восприятию наличие непереведенных терминов, например, названия статусов прогонов.
Рекомендации достаточно очевидные. Если работаешь не консультантом по внедрению, а на внтуреннем проекте, то так и так сталкиваешься практически со всеми описываемыми задачами.
Но удобно, что они собраны в одной статье. Хорошая стартовая точка для специалистов (наверное, в основном молодых :) ), чтобы улучшить свою квалификацию и повысить стоимость.
Экстракция из логистических источников данных сложный процесс и освещен здесь не полностью. Ничего не сказано про настройку пульта управления, про специфические очереди (типа MCEX03) из которых данные попадают в очереди BW (*2LIS*) только после выполнения задания.
Но если уже приходилось сталкиваться с загрузкой 2 lis, то можно воспользоваться идеей использования DSO для устранения двойных документов, вместо ручного удаления их из очереди. Хорошо бы еще сказать о плюсах и минусах(дополнительные собственные объекты) этого решения.
Безумно полезная и качественная статья на довольно сложную проблему. Аудит как таковой является важным этапом в жизни организации или проекта, и через этот этап проходят все. Именно поэтому подготовка к такому ответственному мероприятию должна быть на высоте. Статья даёт чёткое проблем и способы их решений.
В статье приводятся интересные примеры, которые помогут сохранить команду BW в кризисные времена. Сохранить команду, обеспечить ей работу и развитие в момент, когда отсутствуют проекты - очень важно!
В статье приводятся примеры, которые легко и просто можно реализовать на практике...
Неплохая статья, но всегда интересно получить обзор практической реализации различных бизнес-кейзов на реальных проектах, типа:
- \"Договор аренды в иностранной валюте\",
- \"Договор аренды в иностранной валюте с договорным курсом\"
- \"Договор в У.Е.\"
- \"Пролонгация договора аренды\"
Комментарий от
Левон Киракосян
| 17 июля 2010, 16:27
Пункт 3 - это понятно, но слишком очевидно чтобы быть дельной рекомендацией.
Пункт 5 - по сути частный случай пункта 3.
Пункты 4, 7 и 8 - рекомендации относительно производительности. Это полезные рекомендации, особенно для тех, кто не имел опыта продуктивных эксплуатаций.
К сожаление не описано ничего касательно именно самой функциональности SNP. Видимо это было за рамками того, что автор хотел описать в статье, но тем не менее - это по сути именно то, ради чего ставят АРО. Систему не ставят чтобы озадачиться ведением основных данных или оптимизацией быстродействия. Основная задача SNP - оптимизация долгосрочного и среднесрочного планирования. А особенности и рекомендации именно применение оптимизационных алгоритмов APO в данной статье не описаны.