I was going to write a piece on Sharepoint and SAP webparts that I had written, however I doubt I could do the topic justice when there is already a guide to doing this out there
This is an excellent document and covers off everything you might need to know about making SAP web parts (and what I believe are flaws especially coming from an MS background).
The key thing to remember before you start is that you need (list for sharepoint people really)
1. A SAP system to connect to
2. A SAP Market place user and password (cannot download tools without this)
3. The SAP .NET Connector, version 2 of this was really easy (ish) to use.
4. An SAP developer key, without which you are not licensed to develop, it won’t prompt for it but you should have it.
5. A Sharepoint dev system
I did not follow the guide though, I referenced it but not having SAP experience I stuck to existing BAPI’s and very simple, if somewhat useless functionality, its a demo after all.
So to start with, as a sharepoint developer I suggest you leave SAP alone to start with.
Get the SSO working, if you’ve not done this then it might present some problems. In the guide it stores the SSO credentials in SSO but also in WebPart properties, this is not something I recommend, If you have secure data store it only in credentials.
I believe it was most likely done this way as Custom ToolParts can be scary, but using a custom part can ensure better security by not storing that SSO information outside of the secure SSO components. Also because you are using a toolpart you can add validation, something I achieved by calling the ExistenceCheck method on the User BOR (BAPI_USER_EXISTENCE_CHECK), this might not be the correct SAP way but it appeared to work. Examine your SSO definitions do you need group login or user login. *Update: Whilst I still think using WebPart properties as in the example is wrong, Just as bad is the toolpart, both methods end up posting the credentials over port 80 which is bad. The correct and only way is to call the GetCredentialEntryUrl() method and ensure that SSL is configured for your SSO. This does not give you the ability to validate your settings as my toolpart did but it guarentees security. If your not fussed about the very few times that those credentials are passed over http then the toolpart method I described is a better solution and the credentials are not accessible via the web part properties, whilst I havent tried to find them in the database they were not designed to be secure like credentials.
Once you have the web part working and the SSO working, work on a web service for the web part to get its data from, Displaying the data in the web parts is easy for any sharepoint developer now, just pass the credentials over the web service via SSL.
As I said earlier instead of using the guide’s example try your own. I decided to do a webpart that searched vendors (BAPI_VENDOR_FIND), this is an existing BAPI and once you understand the basics of BAPI calling (it is kinda weird MS guys) you can then just struggle getting the data out and in a sensible format and deal with errors etc in an MS way for your webpart to handle.
This post is not meant to be a guide so comes with no code, its a pointer to the guide and to hopefully point out what I think is an error in the guide regarding SSO but mainly to give you a hint of don’t blindly follow that guide as you will need ABAP skills to create the custom RFC ZIBF_OPEN_PO_NEW, stick to something already there.
However here are some videos showing the parts I wrote in operation, the data is IDES and obviously copyright of SAP
VideoOne : A web part that searches for vendors via a postback then uses AJAX and sharepoint to display the Vendor and list of PO’s
VideoTwo : Two connected web parts that searches for vendors via a postback then passes the vendor ID to the second to display the vendor and PO’s then allowed a drilldown to PO items