Архитектурная проблема, с которой вы сталкиваетесь, заключается в том, что SAP не является источником данных. SAP - это уровень бизнес-логики. Попытка заставить его действовать как простой источник данных, вероятно, вызовет проблемы в будущем.
Так что мой совет - использовать простые сервисы WCF. Или, если вы используете старую версию sap, с нетерпением ждать нового .net-разъема . Сделайте презентационный слой в .net или silverlight. И держи всю логику в соке.
На самом деле есть два возможных сценария, которые вы не указали, какой из них будет использовать ваше приложение.
1. Использование стандартного sap-приложения.
2. Использование пользовательского (Z) sap-приложения.
В первом варианте ясно, что sap выполняет логику. В противном случае ваше приложение будет уязвимо для обновлений в серверной части.
Во втором варианте вы можете выставить CRUD-подобный интерфейс. И попробуйте замаскировать сок как слой данных. Я думаю, что это будет неправильно. Вся эта архитектура не имеет смысла. Но если это навязано вам, не пытайтесь «спасти» его, потому что это только ухудшит его. Делайте логику в sap, а презентации в .net. Я думаю, что повторную реализацию SQL нельзя считать элегантной архитектурой.