For our second interview, we invited Holger Bruchelt, Solution Manager at SAP, to talk about what developers can expect when working with Duet Enterprise. He has worked closely with the Duet Enterprise team in charge of customer management. In addition, he has actively participated as a Duet Enterprise expert at Development Jams in Europe. Holger is currently involved in several Duet Enterprise Feature Pack 1 projects and working on the next version of Duet Enterprise.
The Developer Perspective – Part I
- 1. How does Duet Enterprise enable developers to create applications that connect SAP and Microsoft SharePoint?
- Duet Enterprise provides the framework/platform between the SAP and Microsoft SharePoint worlds; it’s the bridge between these two worlds. It may not sound like much, but the solution enables developers to concentrate solely on the application. This is important because when you are developing an application, there are a lot of ‘other’ things that can get in the way such as security, auditing, supportability, monitoring, etc. Duet Enterprise takes care of all that. So, when you build an application on top of Duet Enterprise, all these ‘other’ things are provided out-of-the-box allowing developers to fully concentrate on the application.
- 2. What kind of tools does Duet Enterprise offer to developers?
- Duet Enterprise, and specifically Feature Pack 1, leverages the infrastructure and development tools of SAP NetWeaver Gateway 2.0. With that, we can use all generator tools that are available through Gateway like the RFC generator, BOR generator, and screen scraping. On top of that, we have a tool called Business Data Connectivity (BDC) browser which completes the development story for the SAP to SharePoint integration. The BDC browser takes a Gateway model created using Gateway tools and generates a BDC file. You can then take that BDC file and upload it to the SharePoint site. In SharePoint, you can leverage all of the Microsoft tools like Visual Studio and SharePoint Designer, and finish the development.
- The BDC browser not only creates a specific BDC file, but it also makes sure that all dependencies between Gateway objects are taken into account. This means that if you have, for example, a CRM account that consists of several ‘connected’ Gateway objects – one for the Account name, one for the different addresses, one for the related contacts – the BDC browser will make sure that all these relationships are also reflected in the created BDC models.
- It can also help with translations (e.g. English, German, etc.) since usually when you have a SharePoint site, you have multiple languages. The BDC browser enables you to make translations directly in the SAP environment. Once you export the BDC file, you have the actual model that is imported into SharePoint with all the required resource files that contain the language dependant objects like English and German.
- We also have an integration in CTS+ (Change und Transport System). With CTS+, we can transport objects not only from the ABAP stack, but also from SharePoint. In the end, when you develop a solution in the development landscape you can have one single transport that brings all the developments both from SharePoint and from the SAP systems into your QA system. Then, you can test in the QA system and later on bring everything, at the same time, in the production system.
- There are two different kinds of so called ‘couplings’ in this CTS+ integration: a loose and a close coupling. Depending on which way you choose, you can either only transport or automate everything on the SharePoint side. You can take the WBS, put it in the transport and deploy this solution automatically in the QA SharePoint server. Or you can do it manually and only add the solution to the QA SharePoint server. Then it is up to the SharePoint Administrator to actually deploy the WBS in the QA landscape.
- On the Microsoft side, we have SharePoint Designer, Visual Studio and Silverlight. We have also notice that a lot of customers are looking into HTML5 to render applications in SharePoint.
- Finally, we also support the development process with supportability functionality. We have debugging functionalities and an end to end trace via Solution Manager where we can trace scenarios to easily find performance bottlenecks or any other development issues.
- 3. What are the steps that developers need to take in order to start creating applications?
- To start, one person on the SAP side has to know the scenario and functions to be exposed so that they can be made available in SharePoint. You can then use the generator tools to simplify the development process. For example, an SAP user who is currently working in SAP/Dynpro screens can use the screen scraping capability to actually scrape the content of the screens that he is working on, use the BDC browser to create a BDC model, import it into SharePoint and continue to beautify the solution with Microsoft tools in the Microsoft environment. This is the simplest scenario where you have Dynpro screens and you can scrape them.
- If you want to go deeper, you can use the BOR generator. In this case, you start on the ABAP side selecting BOR objects/BAPIs, use the BOR generator to generate Gateway models out of these BAPIS, and then follow the same sequence as previously mentioned: Use the BDC browser to create the BDC model, import it into SharePoint, and in SharePoint use Microsoft tools to beautify the application.
- If you don’t have any fitting BAPIs, then there is the RFC generator. With the RFC generator, you can access remote function calls. In this scenario, the developer would have to be familiar with the remote function modules available in the SAP system. The developer story will be very similar, use the RFC generator to retrieve the RFCs, then the BDC browser and finally the Microsoft tools.
- What we’ve seen is that if the RFC generator doesn’t work for some specific RFCs, then the development story is that you adjust the RFC by writing a wrapper RFC and using it in the RFC generator, then you move on to the BDC browser, then the Microsoft tools.
- If you don’t want to use generators, you can use the hand-crafted approach where you generate everything from scratch. It still works but obviously the generator tools speed up the whole development process.
- It is possible for both the SAP and Microsoft developer to start in parallel. While the SAP Admin is using the generator tools or BDC browser, the Microsoft developer can start developing the application on the SharePoint side using Visual Studio or the SharePoint Designer. This is the model that we have seen in our DevJams when we have both teams on site. First, they sit together and define what fields are required from the SAP system (e.g. if we talk about a CRM account, we know that we’ll need a first name, last name, street, etc.). Then, while the SAP developer creates the BDC model, Microsoft starts developing the application with UI and functionalities simulating access to SAP systems. This simulation is done by connecting to a dummy external content type that has the structure that will be available once the BDC model is available in SharePoint.
Continue
