Skip to Content

Duet Enterprise recently hosted a Launch Summit showing off some of the ways that Microsoft SharePoint 2010 can utilize SAP’s vital information.

In case you aren’t familiar with Duet Enterprise, here are some highlights:
– SharePoint 2010 can read and update data directly in SAP
– No user plug-ins or downloads required
– Security and technical architecture are provided for integration
– Sample business objects are provided to get started

If the Summit’s popularity (the website stopped responding due to traffic) is any indication of the product’s interest, then we can expect to see loads of companies diving in. While the end-user experience may be incredible, one of the big questions is how complicated and ultimately how costly is the implementation?

Let’s discuss a likely Duet Enterprise implementation:
An SAP customer wants to expose their live inventory view from SAP to employees through SharePoint 2010 without having to login to SAPGUI or use the SAP Portal.

Microsoft SharePoint 2010 uses BCS (Business Connectivity Services) to connect to SAP. This is supposed to simplify the access of line of business systems to Microsoft SharePoint. The problem is that by making the Microsoft integration simpler, the SAP integration became significantly more complex. This would be okay but in my experience SAP resources are far more expensive than Microsoft.

For reference, I’ve followed the fantastic Duet Enterprise Developer Guide available on

The following are some of the high-level implementation steps:

  1. Identify Enterprise Services for both search and read inventory (in SAP they are always separate).
  2. Use the ESR (Enterprise Service Repository – which is installed on CE, or PI) to extend your own custom fields for these Inventory Enterprise Services.
  3. Create proxies in the back-end to implement in ABAP the customizations of these Enterprise Services.
  4. Expose these services to the Service Consumption Layer (SCL) of the Duet Enterprise Middleware (Netweaver 702 ABAP).
  5. In the SCL, create connections to the back-end services via the Back-end Abstraction Layer.
  6. In the ESR for the SCL (getting complicated yet?), create a new simplified and flat web service which combines the read and search of back-end services.
  7. Extend the SCL service to include Duet-specific fields for activities such as session tracking.
  8. Implement the Generic Interface Layer Model
  9. Expose the SCL web service to SharePoint where it can be added as a BCS external list.

Not exactly trivial. But to be fair, Duet Enterprise does provide tools and generators for a lot of this work.

Is there another way?
One of the keys to Duet Enterprise is the security model. There needs to be a way to authenticate a user in SharePoint 2010 and authorize that same user in SAP. The Duet Enterprise middleware, Netweaver 702,  provides SAML2 authentication for this purpose. This works perfectly between SharePoint2010, the identity provider, and Netweaver 702, the service provider.

Ultimately the back-end SAP Enterprise Services can authenticate with one of the following methods:

  • Username and password
  • X.509 ticket
  • SAP Logon Ticket
  • SAML2 (starting with Netweaver 702)

Another option would be to flatten and combine the SAP Enterprise Services for inventory directly in the SAP back-end (or the ESR) and add the SharePoint 2010 specific fields. If this back-end were also upgraded to Netweaver 702 this would avoid the usage of the middleware environment and reduce about 75% of the custom development.

In either case, SharePoint 2010 offers tremendous capabilities for employees who want to use the vital information in SAP without having to learn to navigate the dark passages of SAP GUI. In my opinion, even if it is difficult, the costs are well worth it to finally give users a pleasant experience with SAP.

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. William van Strien
    Hi Gavin,

    Thanks for you time writing down your experiences with Duet Enterprise. Its very helpful to hear and learn from others that are also implementing Duet Enterprise

    I have some additions to and remarks on your statements:

    – Wrt implementation steps 1 to 4; Duet Enterprise service consumption is not limited to SAP Enterprise Services only. Via the SCL, part of project Gateway, you can also expose lower level SAP BAPI Function Modules and RFCs. In the current state with only a limited set of [useful] SAP Enterprise Services available yet, this will be the more common scenario.

    – Wrt step 6: it is not per se required to have a flattened SCL service interface. It is also possible to expose service interface with a complex data structure. The downside is that the SharePoint ExternalList UI format is limited to row-based / thus flat data structure. In case of a complex data structure, you can consume this in SharePoint via the BCS, but you will need a custom UI and program against the BCS ObjectModel API.

    – Wrt step 7: the Duet Enterprise specific CorrelationID is not mandatory; but without it you loose the benefit of full audit trails throughout the combined SharePoint – SCL – SAP Backend landscape. The Duet Enterprise specific Instance Key is mandatory, for each except the Query/Find operation.

    – Wrt step 9: see above; requirement for this is that the data structure in the consumed Duet Enterprise / SCL service interface as a flat data structure. If not, you can still consume the data in SharePoint context, but it’s not viable to display via ExternalList UI metaphore.

    – Wrt the SharePoint2SAP [SSO] authentication: Duet Enterprise enables this via user mapping, SAML2 is next used for the claims-based authorisation from SharePoint user into SAP backend.

    See also following of my blogposts Development Approach with Duet Enterprise and
    Duet Enterprise lessons learned for custom application scenario

    1. Former Member Post author

      Thank you for your responses. Yes, I see how BAPI’s may help to fill in the gap, but if we are going to commit to an Enterprise Service integration strategy, why not use one of the 2500+ services available, instead of relying on the older integration methods? There is work to extend these services, but this ESR work will be done in this customization process regardless.

      Thanks for your clarification on step 6. I am interested in exploring this connection to the custom UI, and BC ObjectModel API. I would enjoy hearing any experiences with this.

      As for authentication via user mapping, that may make sense with a small number of users, however a large enterprise would likely require an automated system?

      Thanks for your feedback!

      1. William van Strien
        Hi Gavin,

        wrt “There is work to extend these services, but this ESR work will be done in this customization process regardless”; note that even if you have a working SAP Enterprise Service, you will still have to transform it in SCL context to a Duet Enterprise compliant service. Reason for that is that Duet Enterprise imposes specific constraints on the service interface signature. See my blogpost ‘Duet Enterprise lessons learned for custom application scenario’ (Duet Enterprise lessons learned for custom application scenario)

        That same blogpost also exhibits more info, and even code :-), on the custom UI approach.

        Wrt user mapping, Linda Peruzzi published last week a set of blogposts on how to automate the user mapping; see ‘User Mapping in Duet Enterprise 1.0’ (User Mapping in Duet Enterprise 1.0).

        Best regards, William.

  2. Former Member
    As I understand, the objective of Duet (at the end of the day) is to provide Sharepoint a way to consume the business logic (BAPI’s, RFC’s) of SAP by exposing them as Webservices.

    A sharepoint developer can then use these webservices in Sharepoint Designer and Visual Studio to build applications and other webparts and make them available in Sharepoint.

    Chances are, any company thinking about implementing DUET Enterprise already owns a license to ECC….which includes the right to use all the SAP-delivered Web Dynpro applications, both WD4J and WD4A.

    I don’t think any company in there right mind would want to re-write the SAP-delivered Web Dynpro applications that provide the UI to run in a web-browser.

    So does DUET Enterprise provide some mechanism to integrate the SAP Web Dynpro applications into Sharepoint??

    From an application standpoint, why not just keep following SAP’s strategy and build the web-enabled business suite applications using Web Dynpro ABAP (with Floorplan Manager) and expose these applications to Sharepoint?

    What am I missing here?

    1. Former Member Post author

      There’s no reason you can’t simply create a web part in SharePoint and point to the Web DynPro ABAP applications. There is an example here:

      However, the benefit of building integration directly into SharePoint is the usability. Some companies or people just really don’t like Web DynPro. I also don’t think the use case is rebuilding an entire application. Rather, it is giving non-sap users simple access to do periodic tasks in sap. For example: a goods receipt acknowledgement, or the address details of a customer.

      Finally you will still have to figure out the single sign-on in that case without Duet.

      1. William van Strien
        The target of Duet Enterprise is not to replace already available + paid for WebDynpro’s.
        A big advantage of DE is the integration within SharePoint 2010 (and Office 2010; for client and offline access); with all its collaborative, content handling, search, document handling, reporting functionalities. By bringing the SAP process + data into SharePoint, it becomes possible to integrate it within SharePoint context and functionalities.
        In addition, Duet Enterprise V1.0 also provides a number of end-user functionalities + building blocks: Single Sign-On; scheduling + retrieving BW reports into SharePoint document libaries, workflow integration.
        SAP and Microsoft expect that partners will augment this with both horizontal as vertical products; they launched the Unite Program for that.
        Further: from the perspective of SAP; Duet Enterprise is ‘only’ an approach to facilitate integration with Microsoft stack; the underlying Gateway is now released as an individual SAP product, and also enables integration into other directions: IBM Alloy, and the Mobile market.

Leave a Reply