Ups and Downs of Duet Enterprise Implementation

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 sdn.sap.com.

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.

 

If you have an interest in viewing similar content, visit our blog, here. 

View our LinkedIn, here. 

Back To Top