Monday, January 16, 2012

With the release of Gateway 2.0 as addition to the SAP NetWeaver stack, the question is justifiable whether this on itself is sufficient for SAP / Microsoft interoperability. Stated otherwise: ‘Do you need Duet Enterprise?’ The answer on that depends on your requirements, IT strategy, plans and situation. On level of desired application(s) functionalities as well as the Enterprise Architecture strategy, policy and plans in your company.

Roadmap + ecosystem

Enterprise Architecture

The decision for Duet Enterprise implementation is not made in isolement. It must be considered and fit in the greater area of enterprise architecture. It is evident that Duet Enterprise only makes sense if your ITlandscape contains both SAP and Microsoft. But that alone is not sufficient to justify the purchase and implementation of the product Duet Enterprise. Does EA mandate usage of standards: interoperability protocols, products? And forcommon-of-the-shelf products, prefer strategic suppliers Microsoft and SAP above third-party suppliers? These are just 2 examples of questions on which EA should make a thoughtful decision and statement, resulting in EA guidelines.

Functional requirements

The often required rationale for Duet Enterprise is actually a negativisme of the SAP (G)UI. So it is not so much that the decision is made for Microsoft / SharePoint, but more that it is decided against the 'detested' SAP user interface. But if the only motivation is to get rid of the SAP user interface and replace it by another, there are other possibilities. Build a custom user interface in SAP WebDynpro for instance.

Duet Enterprise starts to shine when you combine the powers of the SharePoint platform with the functionality of the SAP processing. Not merely rebuild the SAP user interface, but design and architect an improved user experience by integrating it within context of the information worker.

Limitations and implications of Duet Enterprise

Duet Enterprise is not a silver bullet for all SAP / Microsoft interoperability occassions. It has limitations, intended or as consequence of architectural desicisions. Also, implementation of Duet Enterprise has its costs.

Limitations of Duet Enterprise

No support of REST protocol

Limited to data-oriented, CRUD+Q service signatures

Design-time tooling support only for inside-out approach; not for outside-in

Full design-time tooling support only for flattened SAP data-structures

Conclusion

The decision for the implementation of Duet Enterprise must be made in perspective of the business requirements and middle-term enterprise architecture. If SAP / SharePoint policy is a fundamental part of the [future] business application and IT landscape, Duet Enterprise might very well be the sensible decision. Better as realizing + maintaining an own SAP / Microsoft interop layer (no matter how smart your IT people are, they will on longer term never win it from the sheer combination of SAP + Microsoft product team). And also better as purchasing + implementing third party products. That will result in more shattering in your IT landscape, while you must assure yourself of the continuity of the product and its supplier. Again here the combination SAP + Microsoft gives on the longer run more trust as that of smaller although dedicated suppliers.

Friday, January 13, 2012

The standard way for a dynamic redirect executed from the browser context is via 'window.location = "<runtime derived url>";'. A side effect of this approach is that you have lost the UrlReferrer information after navigation to the second page. The browser namely treats this approach the same as if the user has explicitly entered the url in the location bar. There is no referrer since referrers are about one page directly referring to another (eg. via a link), not the browser just navigating to another page. If you need the UrlReferrer setting - a typical example is for (re)directing the browser to the first page after action performed on the second page -, a simple javascript trick can be used.

With this code setup, the dynamic derived redirect is added to the context of first page. As result, the UrlReferrer state is repaired and available for inquiry in the (webclient + webserver) context of second page.

Monday, January 9, 2012

Duet Enterprise makes it simpler to bring SAP data into the realm of SharePoint based front-end. At the SharePoint side the SAP data integration is enabled via Business Connectivity Services. The SharePoint platform provides multiple standard controls that hook into BCS Service Application to render external SAP data. XsltListViewWebPart to render a view on ExternalList, BusinessDataDetailsWebPart to display details of a single external SAP BCS entity. These standard controls have a generic ui-process handling. In case the SAP process handling is different, the result may in fact be a lesser user experience as that ‘detested’ SAP UI.

However, within limitations it is possible to extend and adapt the standard SharePoint ui-process handling, while still using and relying on the standard controls.

The standard ExternalList UI-process handling is to display all selected fields in a gridview; and display details of a selected external entity in a popup window.

In case of a relational or hierarchical data model (typical SAP structures), it is more natural to navigate to another portal page with a composite view: display some details of the selected external entity, accompanied with table based overview(s) of related items. This modified UI-process can be achieved with standard SharePoint controls by a number of measures:

Use javascript/jQuery to overload the standard SharePoint client-side handling that is generated for (External)List. This can be done by utilizing the standard ContentEditorWebPart for injecting the jQuery in the SharePoint page, it does not require custom server control development + deployment.

Modify the Xslt-rendering of the standard WebParts to beatify the rendering. Examples of this are applying conditional rendering, other display-formats of data structures, html-layout changes. Also this can be done at SharePoint configuration level, from context of the SharePoint GUI. It does not require custom server controls. Note: Xslt programming is an expertise on its own. Although you can deploy it via SharePoint GUI, it is not something that you can expect the content owner or functional administrator to do.

Use CSS for consistent style of the rendered data displays. Again this can be done via SharePoint GUI; no deployment required to the SharePoint farm.

Readible names for SAP datafields by defining readible names in the BCS resource file per SAP external contenttype. This is something to be done by the SharePoint administrator that has access to BCS Service Application UI.

Build a custom server control to propagate value(s) of the selected SAP external entity as filter(s) to XsltListViewPart that exposes view on ExternalList of related SAP data entity. This does require some custom SharePoint development and a farm deployment. Afterwards this generic server control can be reused in multiple SharePoint pages.

Build a custom server control to provide to standard BusinessDataWebPart the entity identifier of the SAP entity that was selected in XsltListViewWebPart on the referrer page. This server control implements the BCS IEntityInstanceProvider interface. This does require some custom SharePoint development and a farm deployment. Afterwards this generic server control can be reused in multiple SharePoint pages.

The effect of these measures with still usage of OOTB SharePoint controls to display SAP data imported via Duet Enterprise:

User clicks on one of the categories, as result the browser navigates to a second page. On that page some details of the selected category are displayed (via BusinessDataDetailsWebPart, issuing via BCS the Gateway Model Read method), and also data of 2 additional SAP entities (via Gateway Model Query method,with one or more input parameters, the value of these set as BCS filter in ReadList method.

User clicks on one the related SAP entity instance, browser navigates to a third page. On that page some details of the selected instance are displayed (via BusinessDataDetailsWebPart, issuing via BCS the Gateway Model Read method), and again also data of additional SAP entity (via Gateway Model Query method).

Conclusion

Via such SharePoint customizations the UI-process handling for external data can be largely improved. In case the User Interaction Design demands more and deeper adjustments, somewhere the line will be crossed what is sensible possible via SharePoint customization. Then it is more sensible to build custom webparts for exposing the SAP data retrieved via Duet Enterprise. For the SAP side this is transparent, as long as it can deliver the required SAP data structures to compose the SharePoint UI-handling.