User-centric Development Process for Duet Enterprise projects

In essence, a ‘Duet Enterprise custom scenario’ development project is not different from other application development projects. The customer – either the real end-user, or product management for package software -, has an idea about what to achieve and functional + non-functional (quality) requirements to underline the idea. Often this idea is still vague, and the requirement set far from complete and on aspects also contradictionary. The waterfall approach to yet start with application development (specify, build, test) typically ends up with wrong or failed end-results: the application does not live up to the real customer needs and expectations, and the budget is largely overrun as consequence of responding on the requirements changes. The agile movement came up to improve on this bad practice. Central is the structural involvement of the user (representative) during the full course of the development project. Continous, the user is in the lead about the specifics and the behaviour of the application functionality to be delivered. In Scrum, this responsibility is formalized within the product owner role.

Application mockup

A proven approach to enable the product owner to validate, correct, and ultimately confirm the application functionality is by make it experiencable, ‘touchable’. Provide the product owner with a realistic impression of the application behavour + feature(s) that the project will build: a clickable prototype / mockup.

Based on multiple positive experiences (also within non-Duet Enterprise project, e.g. BI Dashboards), we strongly believe in the added value and power of application mockup. We regard the role of UX / UID expert crucial for customer involvement, and thus for delivering the correct application functionality.

Meeting of 2 worlds

Yet, a Duet Enterprise project also is very much different from ‘normal’ projects. The cause lies with the meeting of 2 very different environments: IT technology, platform concepts, and human nature. The tradional SAP environment is transaction oriented, with focus on structural business process executions. The Microsoft environment, and in particular SharePoint, is far more loose. Ad-hoc processes are the norm, the individual user decides how to perform a specific (business) action. When these 2 worlds + thinking come together in a Duet Enterprise project, the first outcomes are often dramatic. SAP versus SharePoint architects, business analysts and developers do not understand each other (concepts). Both ‘parties’ disagree on how and where (that is, on SAP or on SharePoint side) custom development should be done. The personal preference on how to achieve the SAP+SharePoint integration is influenced by one’s own technology frames and familiair concepts. This has the risk that the user is forgotten: the user interests must be central, deliver an optimal user experience.

Align through Blueprint Duet Enterprise scenario’s

To break through this, we utilize in our Duet Enterprise development process a blueprint step with the focus exclusive on the Duet Enterprise specific scenarios. This blueprint is derived and agreed by a mixed group of SAP and SharePoint representatives. The goal of this step, and its endresult, is to come to a mutual understanding of the solution direction for each of the Duet Enterprise scenario’s. Self-employed constraints are to stick as close to the standards of both the SAP business package and SharePoint platform. Where feasible, we do allow custom development. Here we apply Duet Enterprise integration patterns that we have identified and defined: Consumer-oriented, Provider-oriented, and XML-Funneling pattern.

Of course, the discussion and preferences about where to make custom adjustments still manifest within the Duet Enterprise blueprinting step. However, as it now has the full focus of all involved, mutual agreement is earlier and more effective reached. This is the so-called ‘workshop effect’. Also, in this focussed approach, comparable application situations are easier to recognize. And where so identified, the earlier agreed solution approach can be reused. Starting point for the blueprint derivation is the User Interface Design as validated and confirmed by the product owner.

In the blueprint we derive and define per identified Duet Enterprise scenario the following pieces:

1. Global descripion of the scenario: screenshot of the mockup screen and textual explanation. The purpose is to facilitate on high level a common understanding of the functionality in the scenario. There is no intend to compete with or replace use cases.
2. Derivation, explanation and justification of solution direction. At minimal explanation of the proposed solution direction. But whenever applicable, also the rationale of why an alternative solution direction is dropped.
3. SAP / SharePoint interface
4. SAP Gateway datamodel(s)
5. SAP building blocks: standard RFC’s, BAPIs; identification of needed custom SAP building blocks
6. SharePoint building blocks: standard and custom webparts, SharePoint Service Applications, …

Blueprint validation by Design Authority / Authorities

Justified mantra nowadays within SAP and Microsoft IT departments is to avoid unnecessary or otherwise avoidable custom development. Instead stick close to the standard delivered functionalities of both landscapes.

It is also evident that fully excluding custom development is not feasible when you are developing company custom scenario’s.

We facilitate the consistency and continuity in the Duet Enterprise solution directions by confirming the blueprint to Duet Enterprise Rules, Conventions and Guidelines. The Design Authorities of both SAP and Microsoft IT departments validate the blueprint against these agreements. Derivation can be allowed, but requires the formal approvement of the respective Design Authority (SAP, Microsoft, and in some cases both).

SAP + SharePoint realizations based on the blueprint

With the blueprint accepted and delivered, from here on SAP and SharePoint teams in the project can start with their own development activities for the Duet Enterprise scenario’s. Since representatives of the teams were involved in deriving the blueprint, the concrete software design + development can be done relatively independent of the other party. Of course the data contract details of each SAP / Duet Enterprise interface are input for the SharePoint consumption. Regular sharing the SAP design with the SharePoint developers can achieve this.

Duet Enterprise Development Process

	Step	Responsible	Consulted	Approach	Input
1	Business analysis	Business Analyst	Business representatives	Interviews Workshops	Business vision
2	Mock-Up	UID / UX expert	Business representatives Business Analyst	Sketching Prototyping	Style guide
3	Blueprint	Duet Enterprise Solution Architect	SAP Business Analyst SharePoint lead	Workshop	UID Duet Enterprise Rules, Conventions, Guidelines
4	FoTo’s	SAP Business Analyst	SAP developer SharePoint developer Duet Enterprise Solution Architect		Blueprint Duet Enterprise Rules, Conventions, Guidelines
5	Build	SAP developer			Blueprint FoTo’s SAP Build – Rules, Conventions, Guidelines
		SharePoint developer	Duet Enterprise Solution Architect		UID Blueprint FoTo’s SharePoint Build – Rules, Conventions, Guidelines
6	Integrate	SAP developer + SharePoint developer			Operations – Rules, Conventions, Guidelines,

Duet Enterprise lessons learned for custom application scenario

The Duet Enterprise proposition is multi-faceted. It is a product with ready-to-use functionalities. It is a composition environment for constructing your own solution by composing delivered functional and technical building blocks, e.g. SharePoint Site templates for SAP business objects, SAP reports scheduling and publication into SharePoint, expose SAP workflow decision points as SharePoint tasks. And it is an Integration Foundation for building your own custom application scenario.

In case of that last context, a Duet Enterprise project is a software development project. However, it is not just like any other development project. The application of the Duet Enterprise Integration Foundation in custom SAP / SharePoint application scenarios imposes specific prerequisites to be successful. From experiences with applying Duet Enterprise in custom application scenario, we have learned several lessons.

Starting with Duet Enterprise

Before you are ready to apply Duet Enterprise in a custom application scenario, the project team needs to invest time to get familiar with the product. Get acquainted with the Duet Enterprise concepts, architecture, capabilities, configuration, development approach, constraints and its restrictions. It proofs a steep learning curve to become familiarized with Duet Enterprise and the diverse aspects. This learning experience is made more difficult by the lack yet of concise study material and available reference cases in the open to learn from.

Also you need to install Duet Enterprise in your combined SAP and Microsoft IT landscape. It’s common that this task is performed by the IT operations in your company. Be aware that installation and configuration of Duet Enterprise is more than a simple ‘next-next-OK’ click exercise. Especially on the SAP side, the installation of the Duet Enterprise SAP Add-on consists of configuration steps in diverse parts of the SAP landscape (e.g. SE80, IMG, SOA Manager, …). The total elapse time for installing and configuring Duet Enterprise can easily extend to 5 or more workdays. For the major part the SAP and SharePoint installation and configuration can be done isolated and in parallel. However, there are also multiple moments where it is essential to work together, and exchange system information. From SAP imported into the SharePoint farm, and later on SharePoint security settings required at the SAP NetWeaver / Service Consumption Layer (SCL) side.

Starting within a custom SAP / Microsoft application scenario

This is no different from any SAP / MS integration scenario. Don’t start with the tool, start with the business question! Make sure you understand which problem(s) you are trying to solve. Invest proper time for performing the business and information analysis. Agree with the customer what kind of user experience is asked for. With these demand aspects sufficiently clear, continue with deriving the integration and the software architecture design. In this process both SAP and Microsoft solution architects should be involved. They bring in the insights, knowledge of best and bad practices from the experiences on their own turf. When sketching the integration architecture, continually evaluate whether and where Duet Enterprise can add value, given the Foundation capabilities and the imposed constraints. Don’t make the application of Duet Enterprise your goal; but determine for the application context if and where Duet Enterprise adds value.

Functional system architecture

Input here are the business process, the requested functionalities, the end-user audience, and the workplace characteristics. Decompose the system functionality in use cases. Often not all of the system use cases have the same set of actors. The functional and process architect(s) must carefully decide for which of the use cases there is a business case to expose outside of the SAP boundaries, and for which not. Example of the last is an approval task by a manager or the HR department. They are SAP power users, spending a large part of the day within the SAP GUI. The GUI has no secrets for them, it’s their familiar workplace. The larger workforce in the company is instead a non-casual user of the SAP environment. They are not used to the SAP GUI, and loose valuable time finding out how to operate within the GUI. The financial business case here is reducing the amount of required SAP licenses, and reducing the time spend by this larger set of employees due the unfamiliarity with the SAP UI. A soft business case is that the employee satisfaction is improved by integrating the SAP related work within their common and familiar workplace.

Starting with Development approach

Again, this is no different from other enterprise application integration scenarios. A proven best practice is to start with establishing and defining the contracts via which the application counterparts will communicate. Initially these contracts are defined in abstract format, focusing on the identification and separation of system responsibilities. Microsoft architects recognize this as applying the ‘Contract-First’ approach; SAP architects are more familiar with the term ‘Outside-In’. Do a design time validation on paper or whiteboard that all of the identified functional use cases can be realized by the set of identified interfaces. Augment and tune the interfaces until this design check leaves no more gaps.

Next, model the identified abstract service interfaces in the Duet Enterprise SAP Add-on. The tool for this is the ES Builder, a Java-based modeling environment delivered either as part of SAP PI, or of SAP NetWeaver Composite Environment (CE). In this development step the technology-agnostic service interfaces must be translated into specific SAP service-technology format: data structures, message types, interface operations. Here you also augment the abstract service interfaces with the specific Duet Enterprise requisites: Correlation ID and Business Object Instance Key . These 2 specific parameters are required to enable the Duet Enterprise system monitoring and routing capabilities. Also add here SOAP standards-based fault handling to each service operation. The ES Builder directly supports this via the SAP ESA SOAPFaultException datatype. The SharePoint consumer of the Duet Enterprise service interface can handle the received SOAP Faults in a standard manner through WCF, transparent to any SAP specifics in the fault notification. When all the identified service interfaces are modeled in ES Builder, generate in the ESB the WSDL service description. This W3* standards-based and platform independent service description is utilized and needed on both the SAP service provider and the SharePoint service consumer sides for building the integrated application.

Building the SAP / SharePoint integrated application

With the WSDL service description available, the SAP and SharePoint development teams can each go ahead with the realization of their respective application responsibilities.

At the SAP side the identified service interfaces must be implemented by concrete service realizations. In a Duet Enterprise landscape the term Service Provider refers to the SCL system, and SAP Backend refers to the system that hosts the Business Functionality. SAP Duet Enterprise service implementations are thus positioned in the SCL. The SCL services connect to the SAP Backend to consume the business functionalities and data. Since this SCL-SAP Backend connection is strictly within the SAP environment, it is possible to rely on SAP proprietary connection technology. In fact, between the SCL and the SAP backend it does not add anything additional to connect via web services (BAPI or Enterprise Services). Using web services to connect to the Backend brings some additional performance overhead so RFC-based connection is faster. The development work inside the SCL further consists of mapping the external faced service signatures to the internal SAP processing and data structures. This involves the technical mapping from the W3* standards-based integration handling to the SAP internal invocation model and data structures. And potentially at business process level the composition of multiple SAP actions in the scope of a single Duet Enterprise service operation.

The required work at the SharePoint Duet Enterprise consumption side is largely dependent on the operation and data signature of the provided SCL services. At SharePoint side, Duet Enterprise builds on Business Connectivity Services. Implication of this is that the SCL services must exhibit a CRUD+Q operation signature. If not, consumption via BCS is not even possible. If BCS-based consumption of the external SCL services is possible, another aspect is the data structure. SharePoint 2010 out-of-the-box delivers the concept of the External List UI to interoperate with external data. A practical limitation of the External List UI metaphor is that it requires a flat data structure. If not flat, it is not possible to display the external data in a row-based manner. Non-flattened / hierarchical data can still be consumed via BCS in SharePoint, however not via the External List concept. The project will have to build a custom UI to interoperate with hierarchical SAP data structures. The custom UI must connect to the BCS Object Model to interoperate with the external SCL services. Current drawback is that the BCS API only supports a weakly-typed programming model. You have to program per exchanged hierarchical SAP data structure an ORM-based mapping from strong-typed data representation at the SharePoint front-end to the BCS weakly-typed representation.

Debugging Duet Enterprise connection problems

Here is where the application of Duet Enterprise clearly adds additional value. If you obey to the Duet Enterprise constraints; that is if you have per service operation included the Correlation ID parameter; the Duet Enterprise landscape supports the problem analysis via an integral audit trail through the combined SharePoint + SAP systems chain. You look up the Correlation ID value in the SharePoint ULS logs for where the BCS-based connection starts, and follow it through the SCL layer via the SAP system monitoring. Problems can be of infrastructure nature, e.g. SSL certificate at SAP and SharePoint not in sync; SharePoint BCS-SCL service connection level as result of a wrongly chosen SAP proxy endpoint; SAP authentication and/or authorization due incomplete Duet Enterprise user mapping. The Correlation ID based audit trails proofs a big help in tracing where in the integrated SharePoint / SCL / SAP Backend landscape the actual problem cause manifests itself.

Positioning of .NET Connector 3.0 versus Duet Enterprise

In a timeframe of a couple of weeks, SAP independently released 2 products for .NET interoperability: first [December 2010] the next version of the .NET Connector – NCo 3.0; followed a few weeks [Februari 2011] later by the public launch of Duet Enterprise – a combined effort of SAP and Microsoft. These near overlapping release moments may raise questions and uncertainty on the positioning of the 2 .NET interoperability products. Are they competing? Are the successive release moments a symptom of independent products groups within SAP, and will market acceptance determine which one will ‘win’? And what about the SAP ES Explorer? Earlier, SAP spokesman declared the .NET connector outdated in favor of the ES Explorer.

In my thoughts and analysis, the story is differently. NCo3.0 and ES Explorer on one side, and Duet Enterprise all have a distinct positioning. The 3 products are neither competing nor exclusive for .NET interoperability. Each serves a specific and dedicated purpose.

NCo3.0 and ES Explorer

Both NCo3.0 and ES Explorer are in essence .NET Interoperability technologies. Neither of them is positioned as a product. You can not purchase or license it, but instead can download them from SAP Marketplace if you have a valid S-User ID that acknowledges you as a SAP developer. The release of .NET Connector 3.0 passed rather silently, with only an announcement on SDN. It has not received attention from any of the influencing IT business magazines, nor IT Research Analysts. There was a Ramp-Up with selected beta-testers, but with minimal noise ahead and attention during.

• NCO 3.0 is intended as a general purpose technology tool for low level integration plumping. Basically it enables bi-directional interoperability between .NET custom code and SAP RFCs and BAPI Function Modules. Nothing more, nothing less.
• The role of SAP ES Explorer is in essence the same. In the earlier SAP statement, Rima Rudnik-Sirich characterized it as 'It succeeds SAP .NET Connector 2.0 for .NET'. The difference is within the interoperability manner. SAP ES Explorer works at the level of SAP Enterprise Services, W3*-compliant. You apply it as Visual Studio Add-In, to search through all the SAP Enterprise Services available in your landscape; standards ones from SAP, from third parties deployed in your landscape, and your customer-build Enterprise Services. Runtime invocation of the selected Enterprise Services occurs via a generated WCF service proxy.

Duet Enterprise

Duet Enterprise is a whole other story. Both SAP and Microsoft position it as a product that will directly provide business value. The Duet Enterprise release was done at large: a Virtual Launch Event, press releases and articles within the important IT business magazines, analysis reports by Forrester and CITO Research. Application of Duet Enterprise requires a license, the product can be purchased via SAP and Microsoft. (Note: at moment of writing there is no information disclosed on pricing and licensing model). Before reaching General Availability, Duet Enterprise has been evaluated in a combined Ramp-Up / Rapid Deployment Program hosted by SAP and Microsoft together. Participating in the RDP was given substantial noise ahead, and intensive attention during the program course self. (Note: TopForce participated together with a large Dutch insurance company in this RDP).

The role of Duet Enterprise is twofold. It comes out of the box with direct usable functionalities, and capabilities to compose customer-specific solutions. Its second face is what distinguished Duet Enterprise from the previous Duet versions: integration Foundation to build integration + interoperability that is specific for your situation. Also, SAP and Microsoft believe and want ISVs (the ecosystem) to deliver add-ons on the Duet Enterprise products, e.g. for specific vertical markets. To stimulate this, SAP and Microsoft also launched a partner program: Unite Partner Connection Program.

The Duet Enterprise Foundation is also interoperability plumping, but of higher level as NCo 3.0 and ES Explorer. SAP / .NET interoperability occurs via standard W3* services; there is out-of-the-box support for SSO, Authorization, landscape monitoring. All aspects that earlier you typically had to handcraft yourself, and thus also maintain.

Duet Enterprise is bounded to usage from within a SharePoint 2010 context, and via SharePoint 2010 as intermediary layer in Office 2010 clients. Duet Enterprise has no role in other .NET contexts, e.g. SharePoint 2007 or 2003, Silverlight, WinForms or WPF apps, WCF handling, BizTalk.

Implications

The added value of Duet Enterprise [product, foundation] wrt NCo 3.0 and SAP Explorer [basic interoperability technologies] is that it raises the level of SAP - .NET interoperability. In addition to the bi-directional SAP - .NET runtime communication, it also provides interoperability concepts as SSO, Authorization, System Monitoring. And on top, it comes with direct usable functionalities, and capabilities to compose solutions [building blocks].

The limitation is that it only works from a SharePoint 2010 context (and via SharePoint in Office 2010 clients). If you need .NET interoperability from different .NET context, you have to resort to another approach. SAP provides for this both the NCo 3.0 and SAP ES Explorer; which one is usable is dependent on the level of SAP back-end consumption. If SAP Enterprise Services are available; apply SAP ES Explorer; for RFCs and FMs you can use NCo 3.0.

Note: there are also several technologies and products delivered outside SAP to enable .NET interoperability. For instance Microsoft provides the BizTalk WCF LOB Adapter SDK, BizTalk itself; third parties provide product like Sitrion, Ometa, ERP Connect. For the scope of this article they are however not considered.

Development Approach with Duet Enterprise

This blog is, with some minor changes, earlier published on SAP Community Network Blogs

TopForce participated in the 2nd half of 2010 within the Duet Enterprise Rapid Deployment Program. Together with our RDP partner, we followed a well-chosen approach to evaluate this SAP – SharePoint integration product on it’s capabilities and potential.

In the Ramp-Up / RDP I was involved in plotting the Duet Enterprise prerequisites in the company IT infrastructure, selecting the PoC scenario, architecting the integration approach, and configuration + realization of the Duet Enterprise services for the PoC scenario. In this article I highlight the main points of our journey.

Product evaluation via a custom Proof-of-Concept

Both partners in the RDP regarded it as essential to evaluate Duet Enterprise as interoperability product via a custom Proof-of-Concept. Only such we are confronted wih actual experiences and issues in the application and potential of the Duet Enterprise capabilities. We do not suffice with merely a rather simple out-of-the-box scenario provided by Duet Enterprise.

Selection criteria for the PoC scenario

For us the main reason to consider Duet Enterprise is as integration foundation for company-specific SAP / Microsoft interoperability. To best evaluate the product capabilities on this aspect, we defined the selection criteria for the PoC scenario. We weighted the possible scenarios on the following aspects:

1. A real application context, with current and/or future purpose
2. Give input to SAP / Microsoft integration design guidelines

Validation approach

The PoC is intentionally approached as a regular development project. Thus functional specification, architectural and technical design, realization and testing, with ultimate ending in product implementation. In these Agile times, the phases are not necessarily in linear order; especially the integration architecture and realization have had some iterations as results of lessons learned.

Functional specification

In this phase, the application functionality is clearly defined, and agreed plus functional validated with the customer + end-users. Noticeable is that in this phase special attention is / should be given to the UX-factor: the User Experience of the application. This is because the most heard compliant against SAP is typically the lesser user friendliness. And also because nowadays information workers expect no less than a pleasant and familiar workspace, in which one is facilitated and helped to do your daily and also occasional work activities.

Integration and Software Architecture Design

Essential in this phase is close cooperation between the SAP and Microsoft solution architects. Both typically come from different backgrounds (‘different worlds’, almost like Mars versus Venus), yet it is required that they have a sufficient common understanding to architect a proper and future-proof design.

In the architecture itself, a best practice is to apply a layered service integration architecture. Each layer has its own responsibilities. In a nutshell, SharePoint sits at the front-end / presentation layer, SAP at the back-end layer; and Duet Enterprise is the glue as integration layer.

The integration layer is derived from the [use cases of the] functional specification. One of the design principles applied is that the SAP backend is and remains ultimate responsible for correctness of the data. This also implies that business rules are enforced and remain the responsibility of the SAP backend.

Duet Enterprise also imposes some constraints on the service interfaces. At conceptual level this means that Duet Enterprise [currently] only supports data oriented interfaces, operating via CRUD behavior. The explanation is that Duet Enterprise utilizes Business Connectivity Services to exchange data from SAP to and from SharePoint. BCS is a strict data oriented capability, it is not usable for [SAP] process oriented control.

Development Process

Once the service interfaces are derived and defined, the development team can go ahead with implementing the SAP-SharePoint integration via Duet Enterprise. The outline of this development process is as follows:

1. Configure / define the derived interfaces as SAP Enterprise Services in the ESR, using the SAP ES Builder. Hereby you must augment the interfaces as defined with 2 additional parameters required for proper Duet Enterprise handling, namely:
   • Correlation ID; this is used for the end-2-end monitoring of entire runtime flow through the SAP and Microsoft landscapes
   • Business Object Instance Key; this is used as generic identifier in all SCL framework components at runtime and at designtime. It consists of 3 components, Data Value Identier, SCL Business Object Name and the System Alias of the Backend. The key is to be generated in the SCL processing of each SCL service response, in the following structure: <data_value_identifier>_<Business Object Name>_<System Alias Of Backend>. The usage of this key is enable the SCL in subsequent handling to transparently identify the correct backend in a SAP landscape with possible multiple system instances. Notice the implication that if your SAP landscape consists of only a single backend, there is no concrete runtime usage of this field; all your SCL requests will be routed to the single backend. In that case you can simplify the key structure.
2. Export the defined SAP Enterprise Services in WSDL format
3. Hand over the WSDL file to both your SAP developer(s) as SharePoint developer(s). From here, both can in parallel configure and/or build their own side.

SAP NetWeaver 7.02 / Service Consumption Layer

1. In the SCL system, using ABAP Workbench / transaction SPROXY, create service proxy. This generates the skeleton of the provider class that includes the methods specified in the service interface. Later on you will implement the operations which involves some ABAP programming. The explanation of this break-up is that in the construction of the operations you need the GenIL model; and that you do not have yet generated in this stadium.
2. In the SCL system, in transaction se38 create the GenIL model based on the request and response structure of the service proxy. This generates a generic SCL Business Object Model. The reason that it is named ‘generic’ is because it is an intermediate mapping layer between the consumer (SharePoint BCS) specific data structures and the backend (e.g. SAP ECC 6.0) specific part. This enables that the consumer can transparently communicate with different backend systems/versions. That can be simultaneous in case of a distributed SAP landscape, consisting of a multitude of variant backends (e.g. ECC 6.0 for North America, while ECC 4.26 for the Dutch company division). But it is also beneficial when you upgrade your single system SAP environment – the GenIL model shields the client side from such backend environment change. And this also holds in the other direction – via the same GenIL model other clients as SharePoint can in theory also consume the exposed SAP data and functionality. An example is Alloy for IBM WebSphere.
   The GenIL model is actually to be more regarded as a generic Gateway derivative than strict Duet Enterprise specific
3. In the SCL via transaction SIMGH, create per service operation a Backend Operation Proxy that invokes the SAP Backend capability: either a SAP Enterprise Service, BAPI WebService or RFC / Function Module.
4. In the SCL, via transaction se80 create per service operation a Mapper object that implements 2 methods with predefined signatures for inbound and outbond mapping. This involves ABAP code to do the mapping from the GenIL model to the backend specific data format, and vice versa.
5. In the SCL / ABAP Workbench, return to the generated Service Proxy and fill in each of its generated operations. This also involves ABAP code to do the mapping from the received input to the GenIL model, and from the GenIL model to Duet Enterprise service output.
6. In the SCL via transaction SOAMANAGER, create the endpoint for the service proxy.

SharePoint 2010

1. Start SharePoint Designer to generate External ContentType(s) on basis of the imported WSDL from the SAP Enterprise Services.
2. If applicable, generate SharePoint External List as User Interface metaphore. Whether applicable is determined by a) the data structure; External List requires a flat structure (thus no hierarchical / parent-child relationships); b) the User Experience desired by the end-user.
3. if the External List is not applicable, realize in Visual Studio a custom build SharePoint webpart. Hereby you can use the whole richness of available ASP.Net and SharePoint webcontrols – datagrids, calendar, richtextbox, dropdownlist, … Also, SharePoint 2010 allows InfoPath forms for custom UI.
4. Configure the BCS model to connect for this External ContentType to the endpoint in the SCL of the Duet Enterprise specific service.

Conclusion

Introduction and application of Duet Enterprise is not a free ride. It takes time to get familiar with its concepts, and the development approach + tooling add-ons in the ABAP Workbench and SharePoint in the form of BCS Model Generator. It also requires preparation time at front in defining and architecting an application design. But that’s no different from any other software development project. Given that, Duet Enterprise is a noteworthy addition to the SAP / Microsoft interoperability toolbox; and I recommend to consider it for applicability in your specific SAP/MS integration scenario.

Emphasis on Office 2010 hindering Duet Enterprise implementations?

In a blog of Venture Research I read the following rumor: "…about the partnership with Microsoft in Duet Enterprise, which my sources say is not advancing as fast as desired because many organizations are not anxious to upgrade to the latest release of Microsoft Office, which is necessary to derive the true value of Duet. This caution by organizations to update their underlying platform has good reasons in terms of cost and resource constraints, and SAP is not able to do anything about that."

If true, I find this a misconception and incorrect positioning of the Duet Enterprise potential. Surely, it also provides a Microsoft Office 2010 clients connection. But the true strength and potential of Duet Enterprise is that of a standards-based SAP / Microsoft interoperability foundation. It comes out-of-the-box with multiple integration plumping capabilities which you otherwise need(ed) to implement yourself. And being a commercial product, Duet Enterprise is backed-up by both SAP AG and Microsoft Corp as strong and future-proof IT suppliers.

That said, the implementation of Duet Enterprise puts its demands on the software server infrastructure in your company: SharePoint 2010 Enterprise Edition at the Microsoft stack, and NetWeaver 7.02 at the SAP stack. These are minimal necessities, without the availability of the both of them Duet Enterprise is not an option. But Microsoft Office 2010 at the client side is merely a bonus, not a prerequisite.

Participating in Duet Enterprise Ramp-Up / Rapid Deployment Program

This blog is earlier published on SAP Community Network Blogs

In May this year, TopForce applied as IT partner together with an end-user organization for participating in the Duet Enterprise Ramp-Up. Rationale for both organizations to participate in this Rapid Deployment Program is to gain in an early stadium insights and practical experience on the potential and added value of Duet Enterprise.

Our mutual application was accepted by the RDP Program in June. As one of the first activities, both organizations each sent 2 to 3 employees for Duet Enterprise training. Actually this was a requisite for RDP participation. The 5-days training addressed both the infra/operations aspects of Duet Enterprise in the SAP and Microsoft landscapes [3 days], and the development approach in the SAP and Microsoft development suites [2 days].

After this first introduction to the Duet Enterprise product, we received access to the software bits and accompanying documentation. The last mostly in draft versions, understandable as the product is still in Ramp-Up.

Reasons for participating

The mission of TopForce is to deliver the concept of High Performance Workplace for our customers. In essence this means that we aim for ease of use in the daily workspace of the employees, thereby abstracting the nifty details of the total backbone IT landscape. As our background comes from SAP consultancy, at a lot of our customers SAP is [part of] the business back-end. In our HPW vision, one of the means to achieve a pleasant employee workplace is operating the SAP back-end via a SharePoint based front-end (Unlock the value of SAP business processes within a SharePoint based HPW). We defined a conceptual integration architecture for this SAP-backend / MS-frontend interoperability. The architecture is validated via multiple interoperability technologies and products; e.g. WCF to BAPI WebServices, WCF LOB Adapter, Sitrion. Drawback in all was that we still had to develop a lot of the interoperability plumbing ourselves, most noticeable the support for Single Sign-On. Duet Enterprise now promises to be a good (best?) additional alternative for enabling SAP / MS interoperability.

Our partner shares this same goal, but also has a clear additional target. In the recent history several projects have emerged in which SAP / Microsoft integration might be subject for business and IT architectural decision making, and/or in which SAP / Microsoft integration is concrete realized in some aspects. As the role of both SAP as Microsoft server landscapes is gaining importance at this end-user organization, they have the need for consistent design guidance on when and how to achieve SAP / Microsoft interoperability. Duet Enterprise is participated in this context as an important integration technology to consider.

Project team

Our RDP project team consists of the following roles / persons:

From the end-user organization

1. Project lead
2. SAP solution architect
3. Microsoft solution architect
4. SAP business analyst
5. SAP infra/operations
6. SharePoint infra/operations
7. SharePoint developer
8. SAP NetWeaver solution architect / consultant

From TopForce as IT partner

1. SAP / SharePoint interoperability consultant (my participation in this Ramp-Up)
2. ABAP developer [only temporarily required]

From the combined SAP / Microsoft RDP support team

1. SAP NetWeaver consultant [from SAP AG]
2. SharePoint consultant [from Microsoft Services]
3. Whenever applicable, supplemented with SAP and Microsoft consultants with varying expertise’s; dependent on nature of discussions and encountered issues

Validation approach and activities

The potential of Duet Enterprise is twofold. On one side it delivers directly usable out-of-the-box functionalities, customizable in some degrees to your situation. Second to that, and this is where it strongly differentiates from the original DUET proposition, it provides a SAP / SharePoint interoperability foundation. Although the first is certainly interesting, our main combined focus for now is evaluating Duet Enterprise for the added value on interoperability plumping aspects. This validation is done by means of a real-life custom-developed application. The following activities are executed by the RDP team:

• Attend the Duet Enterprise training to get acquainted with the infra and development aspects
• Install and configure Duet Enterprise in the SAP NetWeaver 7.02 and SharePoint 2010 landscape
• Derive and define the Software Architecture Design for the selected real-life application
• Discuss the Software Architecture Design with RDP consultants, from SAP AG and Microsoft Corp.
• Model, compose and [only] where required custom-develop the interoperability + integration between SAP backend environment, and SharePoint 2010 based front-end
• Derive and define the Design Guide for SAP / Microsoft integration decision making at business and IT architecture level

Where do we stand / Results so far

In this near-end phase of the Ramp-Up program, approaching the General Availability of Duet Enterprise, it is not viable to go into product details. This will be addressed later, after the successful conclusion of our Ramp-Up participation.

Results and findings that I can share now are:

• Getting acquainted with the design and development approach for Duet Enterprise application has an initial steep learning curve. Mind you, this will be less after General Availability when the accompanying documentation will be more complete and mature.
• Installation and configuration of Duet Enterprise takes its time. This is mainly due the complexity of any typical SAP landscape anno 2010 (aka ECC, NetWeaver, Solution Manager, SLD, ESS and MSS, …), and not so much to direct back to Duet Enterprise specifically. On SharePoint 2010 side the work is much less, although also here it depends on the characteristics (complexities) of the SharePoint farm.
• This RDP project is an evidence for the added value of a mixed SAP / Microsoft development team (Build Your Interoperability Team as 1 of the Steps HowTo begin with SAP / MS interoperability)
• It pays out if the SAP and Microsoft solution architects are on a general level familiar with the ‘opposite’ platform stack. E.g. what’s the positioning of SAP PI versus Microsoft BizTalk; what is the concept and support of SAP Enterprise Services;
• It pays out to have at least one team member aboard that has knowledge and practical experience on the SAP / MS interoperability area; knowledge of both technology stacks, interoperability technologies and approaches.
• And final remark: SAP / MS interoperability is and remains interesting stuff; from business and IT architectural point of views…

Duet Enterprise is approaching the General Availability date. If you are considering its application for SAP / Microsoft interoperability, I like to share ideas and actions.

SAP project "Gateway" and Duet Enterprise

Project "Gateway" was prominent on the agenda of this years SAP TechEd. In an interview with SearchSAP.com, SAP’s Chief Technology Officer Vishal Sikka got into more detail on the role and proposition of Gateway, and the relation it has with the Duet Enterprise product.

Some remarkable statements, and messages derived from this interview:

• Gateway is the bridge from the existing system, e.g. [SAP ERP] 4.6c application with all customizations, to the new world – SharePoint, Facebook, Twitter; without requiring your SAP customers to upgrade to a new version which is inherently service enabled.
• Gateway is a mechanism to enable an existing SAP system that is dark to the outside world, and to put windows on it.
• SAP Enterprise Services are usually large, and they are designed for process consumption, not for UIs.
• The Gateway, think of it as a protocol adapter, that you can attach to a legacy SAP system and have it speak to the world outside.
• Duet Enterprise is a product we have built with Microsoft that has the Gateway inside it that has the abilities to connect the world of SharePoint.

Duet Enterprise Overview presentation at SAP TechEd 2010

Virtual SAP TechEd 2010 presents the recorded 1-hour session CD109 - Duet Enterprise Overview: Consume and Extend SAP Applications Through Microsoft SharePoint and Office. The presenters were from SAP AG, Microsoft Corp and CapGemini. In this session the business goals of Duet Enterprise are outlined, at high-level the advantages it brings for companies doing or considering SAP / Microsoft interoperability, discussion of the architecture and runtime flow, and the development toolset + process. Accompanied by (life and pre-recorded) demo's.

Some of the take-aways of this presentation:

• Duet [Enterprise] Service Consumption Layer is the first version of SAP's project "Gateway", embedded in Duet. The aim of project "Gateway" is provide simplified access to SAP:
  SCL, internally referred to as 'Gateway Layer'

  
  Framework built as an NetWeaver ABAP add-on, enabling simplified access to SAP software from any device or environment using standard market protocols


• Primarily, Duet Enterprise is working as an Add-On on both sides; NetWeaver stack and SharePoint stack
• [SAP service-enabling] Business entities from SAP available as Web Services; [SAP consumption] Discover SAP information as External Content Types in BCS, and connect to SharePoint/Office.
• The ready to use Duet Enterprise capabilities, are also building blocks that you can use and even build upon in your custom solutions
• SharePoint Duet Enterprise front-end development distincts 3 Solution Types:
  1. Simple - by end-user; within the SharePoint GUI
  2. Intermediate - by Power User; via SharePoint designer
  3. Advanced - by a .NET developer; via Visual Studio


• Study on the effort it takes to develop SAP/SharePoint integration learns that without Duet Enterprise it costs 6 times
• Create solutions very fast to address business (needs) very quickly. Not create very big applications, but small ones and do it fast
• SAP services are fairly complicated, with nested and complex structures. SAP WSDL's kinda have their own definition, slightly away from the WS*-standards
• Duet Enterprise can either map SharePoint users to SAP users through the Duet Enterprise User Mapping component, or connect to a LDAP that this mapping.

See also slides of the presenation

Steps HowTo begin with SAP / MS interoperability

Important aspect of applying SAP-Microsoft interoperability within a company IT landscape, is how to start. Almost always the Microsoft and SAP departments form their own community in the company, with only limited contacts and co-operation between them, and no clear understanding of each others platforms, technologies and capabilities. See also earlier posts of Kristian Kalsing [1] and of myself [2] addressing this issue.

Raymond Smith [Microsoft Corporation] published an interesting article on this: Building an SAP/Microsoft Interoperability Team. In his article he distinguishes and details on the following aspects:

Aspects of Building an SAP/Microsoft Interoperability Team

1. Build a SAP Interoperability Lab
2. Determine a Proof of Concept Business Process
3. Build Your Interoperability Team
4. Cross Train Developers
5. SAP Interoperability Training
6. Determine Architecture
   • Security
   • SAP Architecture
   • SharePoint/.NET Architecture
7. POC Development

I recognize [most of] these steps from own experiences with SAP / MS interoperability implementations. For the details, I strongly advice to read Raymond's article.

Duet Enterprise - Technical Overview presentation

Upon searching on 'Duet Enterprise', I came accross this posted presentation with technical overview. Next to the expected high-level on the Duet Enterprise proposition, this powerpoint also contains some more in-depth explanatory visualizations of the technical and system flow in capabilities like authorization and single sign-on, SAP role based authorization, workflow, monitoring.

Note, the presentation is [declared] prelimary; in awaiting of RTM.

What about the competition - new roadmap for SAP NetWeaver Portal

As a SharePoint adept, I don't really consider the SAP Enterprise Portal as competition. Let's face it, the typical UI is horrible, and it lacks many of the capabilities the SharePoint platform brings. But moreover, the impression [within the market] is that SAP has stopped with actual new major developments in this product (Web2.0, content management, social media). SAP is putting it's intellectual resources and budget mainly on the business capabilities, and less on fancy user interaction. Fair enough, as it leaves room for integration and interoperability via foreign UIs, as SharePoint.

Contradicting the above, it's knownable that at SAPPHIRE some new additions for SAP NetWeaver Portal were announced. Most notable the concept of 'Enterprise Workspaces'. Read and see more of this in SAP NetWeaver Portal – SAPPHIRE NOW Summary.

It aims to provide SAP users with an iGoogle- or myYahoo-type experience within SAP, allowing them to build their own pages with structured and unstructured assets -- reports, RSS feeds and so on. It applies a self-service approach within defined roles and security. [SAP NetWeaver Portal roadmap includes 'Workspaces,' easier third-party integration]

Well, the UI impressions and the self-service concepts are rather impressive and promising. I do hold on to my opinion that SharePoint is a better overall portal platform. But it looks as if SAP could be making a new step forward in its own portal product.

Standards-Based Interoperability between SAP NetWeaver 7.0 and Microsoft .NET 3.5/4.0

Microsoft opened a new interoperability area within MSDN on Web Service Interoperability between the major web services vendors. Amongst these naturally also SAP. The site contains an extensive (75 pages) Demonstration Scenario of the Collaboration Technology Support Center addressing information about how to set up standards-based Web services communication between Microsoft .NET Framework applications and SAP Application Server ABAP-based consumers and providers.

Portal Embedding of SAP UWL into SharePoint

There are multiple alternatives for utilizing SharePoint as presentation layer to SAP functionality. The most basic is portal launch, next comes portal embedding. Portal embedding has some advantages (mainly being rapidly to achieve: you only visually integrate the 2 [SAP, Microsoft] environments, without any direct systems/applications integration and interoperability), but remains a rather poor man's approach to portal integration. The typical SAP UI / Look and Feel is very different from the SharePoint UI (standard or company-customized), and the SAP Portal pages exhibit themselves browser navigation in addition to the SharePoint navigation.

Andre Fischer a.o. from SAP recently published the whitepaper Integration of SAP Universal Worklist into Microsoft Office SharePoint. This paper contains an example of the portal embedding approach, while also addressing the double navigation issue. In particular it describes an approach to integrating the SAP Universal Worklist into SharePoint context. Basically it comes down at making sure at the SAP Portal side that the portal pages are rendered headerless, without the portal navigation. The elegance of the sketched approach is that it is limited to SAP Portal configuration and customization work, there is no custom development required at either SAP nor SharePoint side.

Duet® Enterprise on stage at SAPPHIRE 2010

Duet® Enterprise is now clearly gaining momentum in the marketspace. It was also on the agenda of the SAPPHIRE 2010 Conference. Watch the session presented by Pascal Gilbert (Microsoft). In this presentation Pascal discusses at a conceptual level the business proposition of Duet® Enterprise, enlists in what aspects it is an improvement of the previous Duet versions, and gives a real life example of how Duet Enterprise can be put in sensible action applying strictly the OOTB provided capabilities.

Duet® Enterprise on stage at seminar 'SAP and Microsoft BI'

Recently I attended the Microsoft seminar 'SAP and Microsoft BI'. The focus of this seminar, and the audience, was evidently on Business Intelligence in a heterogenous SAP + MS IT landscape. But within this scope, also the forthcoming DUET Enterprise receives it's role. Juergen Grebe of the SAP / MS Alliance team had a good session on the interoperability architecture and the provided capabilities of DUET Enterprise.

White paper discussing the promise of Duet® Enterprise

CITO Research has published The Business Value of Duet Enterprise, a research white paper sponsored by Microsoft. Such sponsorship always contains the risk of the result being more of an advertorial instead of an independent and thorough analysis + evaluation. This paper at locations certainly qualifies as unconditional product promotion, but it also presents several useful insights and details on the mission and capabilities of Duet Enterprise.

The paper discussions the mission and values of Duet® Enterprise from different viewpoints and angles:

• [as it should be] Starts with the business vision; the why
• the architecture and interoperability approach; the how at high level
• examples of what can be achieved; use cases
• the components of the Duet Enterprise foundation; it's building blocks for composing applications that surface SAP line-of-business content and processes in user interface formats tailored to the needs of the nowadays Information Workers
• the personality of composites that are best realized via either Duet Enterprise, Business Connectivity Services, or rather BizTalk; choosing the right interop tool for the task/scenario at hand

Some of the most noticable points to take from the paper are:

1. The statement that although Duet® Enterprise relies on SAP NetWeaver 7.02; it can handle scenario's where a company's SAP environment consists of many generations of SAP applications. From SAP R3 4.6C to SAP ERP 6.0 and beyond.
2. Duet® Enterprise is SAP / MS interoperability foundation; for rapid development and construction of custom applications
3. Duet® Enterprise enables the rapid development approach by providing the needed interop plumping
4. Duet® Enterprise builds on existing investments in SAP [business applications + architecture] and Microsoft [Information Worker] software.
5. Duet® Enterprise fits in with existing modern IT management, development processes and environment/technologies.
6. Duet® Enterprise is one way for realizing the vision of Office Business Applications when it concerns connecting with SAP line-of-business.

Missing in the paper is a thorough consideration of the strengths versus weaknesses; of the product and of the proposition itself. With respect to that, Duet® Enterprise could be seen as a threat to some of the SAP business. Although it's promise is to extend the reach of SAP business capabilities beyond its traditional usage and departments, it does so via Microsoft instead of SAP software. It will be interesting to watch hows this develops, and what it will mean for the business of both SAP as Microsoft. Ideally, both will prospher from it. Only then, the combined effort will truly deliver, and have a future.

A compact overview of SSO Technologies supported by SAP NetWeaver for surfacing from .NET based clients

Earlier I blogged some about the area of Single Sign-On in a mixed SAP NetWeaver – Microsoft .NET world. Yesterday Andre Fischer from SAP AG published an up-to-date compact overview on this topic. Recommended reading for those interested in SAP / MS interoperability.

SAP Influencer Summit '09 exhibits evidence of the Microsoft connection

Source: The Clear Path Forward for the SAP Super Tanker...

Above blog reports on the SAP Influencer Summit held last week in Boston. At this summit, the mid-term future directions of SAP as IT and solutions company where presented to the audience of 275 analysts and IT influencers.

Noticable in the context of SAP / Microsoft interoperability are the following observations:

• Silverlight was formally named as the user interface surface of choice over Adobe’s Flex, and Sharepoint & Office interoperability is clearly seen as the path forward over that horizon. The dev environment is similarly on the .net side of the ocean.
• Excel and Crystal Reports (and SAP’s Xcelsius) are similarly foundational components to analytics reporting and dashboarding.

Makes me wonder: is SAP finally making a renewed stand on the integration and interoperability of the SAP and Microsoft platforms + products? The fact that noise and attention from SAP on the recently by Microsoft announced DUET Enterprise is yet effectively non-present, is at least confusing with the messages made at the summit. I guess we'll still have to wait and see whether and in which direction(s) the 2 companies will interoperate and partner.

Interesting sessions on SAP/MS interop at the SAP TechEd's 2009

In the coming weeks the SAP TechEd 2009 will be held, at various locations worldwide. The series starts in Phoenix (USA), following Vienna (EMEA market), Shanghai (China) and ends in Bangalore (India).

The SAP TechEd is filled with lots of interesting sessions, divided within 7 tracks. From the perspective of SAP / MS platforms interoperability, the tracks SOA Middleware, Security and Identity Management and Custom Development appear the most interesting ones. And within them especially the following sessions

• Duet Best Practices: Fast-Track Your Duet 1.5 Operations with Duet Admin Tools
• Customizing Alloy: Exposing SAP Workflows to Lotus Notes
• Interoperability Between SAP NetWeaver Portal and Microsoft SharePoint Technologies
• Integrating SAP with Office 2010 and SharePoint 2010
• Creating Online and Offline Form Processing Scenarios with Adobe Forms and Web Dynpro for ABAP
• Architecture Guidelines for Composite Applications
• Standards-Based Interoperability between SAP NetWeaver PI and Microsoft .NET
• SAP NetWeaver Process Integration 7.1: SAML Implementation
• Enterprise Services Repository in Complex Customer Landscapes
• SAP and Microsoft: Interoperability and Beyond
• Tactical SOA Governance in SAP Environment
• Business Process Management and Security – Inextricably Intertwined
• Service-Based Single Sign-On in an SAP and Microsoft Combined Environment

I'm pleasently surprised by the attention SAP gives to the field of platforms-interoperability in general, and that of SAP/Microsoft in particular. Although I self are not able to join this conference (I'm instead scheduled for the soon coming Microsoft SharePoint Conference 2009), a TopForce colleague will attend. So I hope and expect to receive the details via him.

Tags: SAP NetWeaver Microsoft SharePoint integration interoperability SSO

The Quest for searching thorough advice on best-practices SAP / SharePoint interoperability

What started out as a rather simple inquiry question on the SDN forum SAP NetWeaver .NET Technologies, is now transforming in a more in-breadth discussion on getting best approaches to apply within SAP / SharePoint interoperability. André Fischer, SAP employee, posted a direction to the whitepaper Interoperability between SAP NetWeaver Portal and Microsoft SharePoint Technologies. Although a good overview document of the possible approaches, that is also its shortcoming: it's an overview, but it does not give the reader solid advice on best approaches to apply in specific situations. Not strange, that is not the purpose of this whitepaper. And also, the answer on such questions is for a major part influenced by the particular enterprise situation, thus difficult to generalize. But when involved in such a concrete enterprise situation, you are in need of such guidelines and advice.

So we try to 'challenge' André to come up with more concrete advice. If you're interested, follow the forum-thread to see whether he accepts and responds to this...

Tags: SAP NetWeaver Microsoft SharePoint integration interoperability architecture guidelines roadmap