К сожалению, картинка не кликабельна, а при имеющемся размере невозможно ничего на ней прочитать.

Касательно последней архитектуры.
 
С одной стороны в тексте прозвучала ключевая фраза: "все доработки и исправления выполняемые в системе BW DEV, параллельно учитываются в системе BW NEW DEV", но на схеме это никак не отражено.
Схема, я считаю, не правильная.
Дело в том, что данная схема предполагала ведение параллельных работ по поддержке существующего решения (исправление ошибок, мелкие доработки) и внедрение новой функциональности (существенные разработки).
Так вот, из предложенной архитектуры мы видим, что все наработки, связанные с исправлением ошибок будут потеряны с выключением "BW DEV", и ландшафт станет неконсистентным, т.е. "BW NEW DEV" не будет равен "BW PRD".
 
Можно поступить след. образом:
- скопировать "BW DEV" в "BW NEW DEV";
- текущие работы по поддержке существующего решения вести в "BW DEV"
- Новая функциональность должна настраиваться в "BW NEW DEV"
- И сам ландшафт должен выглядеть так:
 
(BW NEW DEV)=>(BW DEV)=>(BW QA)=>(BW PRD)
 
таким образом, будет соблюдена консистентонсть систем, и не нужно инсталлировать одну лишнюю инстанцию (BW NEW QA)
 
С уважнием,
Владимир.

Только "сделать выбор на уровне продукта" между VC и CDP (опция configuration on product level) больше нельзя, см. ноту 1511834.

Здравствуйте, Олег.
 
У меня к Вам есть один небольшой вопрос.
Мне нужно добавить три поля в ГФ "CRM_SERVICE_ROB_UI" для экрана "7110".
Скажите, пожалуйста, можно ли используя данную технологию сделать это?
Большое спасибо.

"появляется возможность переносить отдельные элементы логики приложений на уровень базы данных"
 
Я правильно понимаю, что это отход от классической 3-х звенной модели клиент-сервер?
При этом
"По первым прикидкам для оптимальной работы СУБД HANA может потребоваться до трех раз больше процессорных мощностей по сравнению с традиционными базами данных."
 
In-memory технологии - это хорошо, но

Олег, спасибо за Ваш содержательный комментарий.
 
Не очень понятно, что вы подразумеваете под термином документ, но тем не менее.
Если Вы имеете в виду отдельные транзакции, создаваемые пользователями системы, то да, ERP можно с полной уверенностью считать таковой. В данном смысле модель работы SAP ERP системы, существовавшая до появления SAP HANA, в полной мере отвечала такой концепции, поскольку база данных в ней использовалась лишь как хранилище информации.
Напротив, в концепции, в которую включается SAP HANA как база данных, появляется возможность переносить отдельные элементы логики приложений на уровень базы данных и за счет этого повышать производительность транзакций и отчетов..
Если же мы имеем в виду бизнес-логику приложения ERP как таковую, то при миграции на SAP HANA она не изменится. Существует также возможность включать/выключать выполнение оптимизированной на SAP HANA логики стандартных прорамм/транзакций. Стоит также отметить, что в версию ERP для SAP HANA включены дополнительные преднастроенные приложения на базе технологии HTML5 (например, MRP Cockpit). Для процессов, построенных на пользовательских разработках, оптимизацию необходимо будет делать дополнительно.
Таким образом, в случае применения SAP HANA в качестве СУБД для SAP ERP, заказчик получает не только базу данных, позволяющую обрабатывать большие объемы данных с более высокой скоростью, нежели традиционные СУБД, но и платформу для построения новых приложений на основе процессов в ERP, позволяющих анализировать информацию в режиме реального времени. Это позволяет нам говорить о  возвращении к реальному значению термина «Real-time data processing». Причем речь идет не только об ускорении выполнения традиционных отчетов, но и о функциональности, которая считалась нереализуемой ранее из-за проблем с производительностью. Примером может являться сегментация клиентов в CRM приложениях для торговых организаций. Данный процесс в традиционной архитектуре требовал накопления информации и ее переноса в BW, а теперь может выполняться непосредственно в системе CRM.
Говоря про аналитические возможности, я хотел бы отметить, что как минимум в ближайшем обозримом будущем хранилища данных будут по-прежнему строиться на основе SAP BW, теперь использующем SAP HANA в качестве СУБД и платформы для построения real-time отчетности. Связано это в основном с тем, что в настоящее время решение SAP BW предоставляет огромный объем функциональности, позволяющей, к примеру, вести предварительную обработку данных, строить системы бюджетирования и консолидации, реализовывать концепцию data aging с помощью решения NLS. Вероятно, настанет момент, когда данная функциональность будет интегрирована в единую платформу для транзакционных и аналитических систем.
 
Сергей Осин

не сочтите за рекламу, но я вот на один из компьютеров только что установил пакет 2013, включая excel.
Специально после этого разговора решил посмотреть, что сейчас в Excel 2013:
 
после запуска (после win+r -> excel.exe) доступно:
1) обучающие материалы (внутри excel) - которые оказались полезными
 
2) применение защиты, тэгов, экспорта в другие форматы
 
3) возможность облачного хранения
 
4) шаблоны: список дел, календарь, бюджет, расписание, калькулятор, прайс лист и еще какой-то набор.
 
5) моментальный экспресс-анализ таблицы.
 
6) а "откуда есть пошла" сводная таблица?
по-моему развитие анализа электронных таблиц уже отчасти движимо excel.
Так же как развитие бизнес-процессов движимо SAP.
 
+ забыл упомянуть многооконность excel, которая кстати есть в ABAP-редакторе, но ни в одном инструменте для пользователя недоступна.
 

 
что ж... разговор ни о чем вышел в несколько комментариев))))

Для любителей Excel SAP сделал BPC :-)

+ к ALV
динамическое ограничение дат
sapland.ru/articles/spj

Позвольте согласиться только отчасти, там где Вы про горный велосипед говорите.
VLOOKUP является не более чем select в определенной таблице, которая хранится в том же Excel'евском формате. Он далеко не всегда удобнее обычного Select, потому что не позволяет выбирать по комбинации полей, а только по одному полю. Например, попробуйте сделать vlookup по комбинации БЕ + год + номер документа. Придется сначала все значения в одно поле соединять, а потом уже искать. В select это решается одной строкой.
 
"Соединение с сетью" может пропасть и для Excel'евского файла, хранящегося на сервере. При этом непонятно что останется от файла, если сеть пропадет посередине процесса его сохранения.
 
"Ошибки вычисления" могут быть и в Excel, при чем здесь это вообще?
 
Подскажите, как Вы вернете данные в Excel в первоначальный вид после кучи сортировок и фильтров? Многократным Ctrl-Z? Так и в SAP можно снять фильтры и применить первоначальную структуру строк. Только зачем? Данные уже есть в каком-то виде. Чтобы построить на них новый отчет, не обязательно возвращаться к первоначальному виду. Можно изменить существующую структуру данных под нужные фильтры/сортировки.