Skip to Content

OData Channel (ODC) development now preferred for new Duet Enterprise scenarios

As of Duet Enterprise FP1 SP3, the Duet Enterprise product team now clearly positions OData Channel as the recommended approach for new developments of custom Duet Enterprise scenarios:
Feature Pack 1 for Duet Enterprise 1.0 Development Introduction
Generic Channel remains supported, also within Duet Enterprise 2.0; but will not be enhanced with new features and capabilities. Message: OData is the way to go. Main reason is that OData has much more potential for consumption outside the SAP Business Suite boundaries, and therefore the Duet Enterprise team is focusing its resources on supporting that more prospective channel.

Consequence for Duet Enterprise custom development: learn new approach + tools

Although one thus still has the option to utilize the Generic Channel development approach, the signal send by Duet Enterprise team is clear. OData development has the momentum and the future. Consequence for custom Duet Enterprise development is that on SAP side the programmer must transition to develop Gateway OData Services instead of GSDO types. The concepts and steps of the 2 are somewhat comparable, but the tools and execution + coding are different. For GSDO the ABAP programmer uses SE80 and /IWFND/GWO_GEN; OData development is performed mainly within the new Service Builder (SEGW). Within both approaches you have the options to generate the data provider class through mapping to RFC and BOR, or to manual handcraft it. Once the data provider class is ready (OData DPC or Generic Channel GSDO), you expose it as SharePoint 2010 callable entity. For OData DPC, the BDC Browser tool is extended with the capability to convert OData Services into Gateway SOAP web service. At runtime, Gateway applies for this the Duet Enterprise FP1 SP3 OData-SOAP Bridge. The existence of the OData-SOAP Bridge is transparent for the SAP Duet Enterprise developer. One simple utilizes the BDC Browser as before for GSDO type, to now expose the OData Service for consumption within SharePoint 2010.
Noticeable is that for SharePoint 2010 development side, nothing changes. You still import the BDC model generated via BDC Browser containing one or more External Content Types that refer to Gateway SOAP webservice(s). And next utilize the out-of-the-box Business Data UI-controls, and/or the BCS API to develop a custom UI.
See also:
Duet Enterprise FP1 Developer Guide - OData Channel.jpg
Duet Enterprise FP1 Developer Guide - OData Channel.jpg
You must be Logged on to comment or reply to a post.
  • Hi

    What is the business benefit for the customer to  to develop Gateway OData Services instead of GSDO types?

    What is an impact of the OData-SOAP Bridge on the gateway performance ?



    • Hi Adi,

      The most significant business benefit is that same GW OData service can be reused for multiple front-end channels: SharePoint for [internal] portals, Mobile Apps, PHP, …

      2nd business benefit is that OData request is more mobile-friendly; the message-size is typically up to 50% or more smaller as SOAP-based requests. This is good for transfer throughput, and thus for user-experience.

      An IT benefit is that in case of need for CUSTOM GW service development; OData is a lot simpler as compared with custom GSDO channel development. You only need to develop 2 classes: a Data Provider and a Model Provider.

      With GSDO your are forced to do also a lot of lower level ‘plumping’; data conversion and so on.

      Regards, William.