Hello,
Sorry i don't have a roadmap to check against. I can, however, give you a few pointers to look at :
For the application structure : isolation between components and abstraction are the main concern. Is the application sufficiently decoupled to allow insertion of new DAO or BO :
If you separated the access object(s) from the others, the objects manipulated by your application could come from a SAP system, a web service or a database. With sufficent abstraction, (and if the subject allows this), you could get objects from a variety of sources. (Real life exemple : getting objects from a SAP system and a web service at the same time, and completing these objects by calling a database. no component except the acces component knew where the objects "came" from).
If your application does anything other than displaying the objects to the user, then this become a little bit complicated, as you have to ask yourself if the manipulation will be done by you application, or in the SAP system itself, or any other system. Once more it goes back to abstracting your operations to make sure you can get any implementation you wish for.
Last, make sure your object are compatible with the SAP version. You model classes should at least contains the id of the SAP object as a member.
Making sure your application can call sap is no different than making sure it can call others data source / external processor.
Others things that comes into play are the autorisations : are all users equals in what they can do (operations), or on what they can manipulate (data) ? Does sap enforce those limitations ?
-
If users are equals, you can use only one user, with connection pooling, and put the connection information in a property file.
-
Otherwise you have (again) several possibilities. One solution is to perform a mapping between you users and their login/password for SAP (if several users are equals, you can still use a connection pooling for them), with SAP perfoming the control for the datas ( standard autorizations). If the function you're calling are not standard, and/or can be modified, then you can add an information on the user, and perform the control yourself in the function.
Real life exemple : the function called whas getting the employee Id, and returned the team working with this employee depending on the enterprise structure. in this case, SAP could not do the limitation, so a single connection was prefered)
Regards,
Guillaume