It is very interesting to observe a product adapt itself to changes in technology, customer requirements and marketing metaphors (Ahem...). At the end of the day it is all about making life bearable at the business place. Enabling R/3 functionalities with a webdynpro UI is a true example.
Having worked in a project involved in using webdynpro to create PM and Purchasing functionalities, there are some pain points from a development perspective.
I have listed some of the realisations below: 1. Availability of BAPIs/RFCs is one of them - this is a very important task. When a requirement is visible then this is the first thing that needs to be done. If there is no BAPI/RFC available then effort and expertise needs to be considered for the same. 2. Quality of the RFC Function - Selected RFC function need not address all the requirements. Workarounds have to be devised. In this process a more generic approach with a vision for future enhancements is a must. 3. If the BAPI/RFC Function does not seem to work well, then try testing in your other systems. This could just be because of patch level differences. Atleast within SAP with so many systems available this exercise is very valuable. 4. Reusability - This is probable proposition. Imagine getting a repository with all the main R/3 functionalities - (eg Purchase Order creation/Updation/Deletion).And assume you just have deploy the webdynpro application and then configure a couple of properties file so that the application starts working. Remember every customer will have a different system landscape - and if there is this one repository the solution provider has then he can implement business requirements at lightning speeds. All these are definitely logical, but then to make sure that it is definitely part of every webdynpro developer's checklist is the intention.
