Considerations for SAP / Microsoft interoperability approach and technology

[Former Member]

Over the years since I am focussing on SAP / Microsoft interoperability, I’ve been consulted multiple times from both the international community (USA, South Africa, UK, France, Germany, Israel, The Netherlands, …), and from direct end-organizations to advise on the best approach and integration technology/product to apply. But the answer is not that simple or trivial. What fits in one scenario, may be useless in another. As always, the architectural answerring starts with: “it depends…”

2 mainstream architectural + technology approaches

On the area of SAP / Microsoft interoperability, there are multiple options to choose from. On high level there are 2 basic approaches:

1. Use a technology ‘connector’ between Microsoft code/platform and SAP platform to consume SAP data into Microsoft context
2. Expose the SAP data and functionality as webservices, preferable standards-based

Note: The ‘connector’ approach on itself can also be part of exposing SAP as webservices.

Each of these 2 approaches again has multiple technology options and products to select from. Which option is a best fit in specific (organization and) situation, is influenced by multiple factors; and is per definition thus specific. However, the decision path / design guide has a generic nature.

Questions/factors to address:

1. Is SAP / Microsoft interoperability for an oppurtunistic, one-stop scenario; or is a strategic element of the organization’s enterprise architecture roadmap + vision?

If merely for an one-stop, then keep the investments costs as low as possible. There is no business case to invest in strategic IT enterprise platform for SAP / Microsoft development and support. Try out a basic / simple approach to connect from Microsoft UI context to the required SAP functionality, most likely provided as SAP BAPI’s. If the Microsoft context is from .Net code context (Winform, SharePoint serverside code, WCF service, …) , utilize a SAP/MS connector to connect on SAP proprietary level.  Possible options here are a.o. the (free) SAP .Net Connector 3.0; Gimmal ERP-Link; Theobold Software ERPConnect; SitrionSuite and more. If the Microsoft context is from a webclient (webform, InfoPath, ), it is required to consume SAP via webservices. Basically you have 2 suboptions (that is, if you do not have SAP integration technology / product yet in the IT landscape, SAP NetWeaver Gateway nor PI/PO😞 a) expose the SAP functionality as SAP BAPI webservices; b) expose the SAP functionality as .Net WCF webservice, that itself uses a connector to go into SAP landscape.

If instead the SAP / Microsoft interoperability is part of the strategic enterprise architecture, then…

2. Consume in SharePoint only, or in multiple UI channels (html5, InfoPath,  desktop Apps, native mobile Apps, …)?

If consumption to other channels than SharePoint (alone), do not select an approach that tightly binds to the SharePoint platform and context. Gateway for Microsoft (GWM) in combination with Gateway is likely a better choice in such scenarios.

3. Which integration functions are required? Merely connectivity, for exposing SAP data to Microsoft channels; or also more advanced integration functions adressing SAP workflow, SAP BW Reporting?

If more integration functionalities are requested, it is advisable to look also at a more extended integration suite. Duet Enterprise is momentarily the example of such a suite, delivered and supported by SAP and Microsoft as suppliers. But if an organization has no need for all the integration richness of this suite, there is no business case for the purchase costs of Duet Enterprise licenses.

4. Which landscape monitoring functions are required? Helicopter view to monitor to entire Microsoft – SAP chain; or is it sufficient to have scattered views for the individual Microsoft and SAP landscapes?

If integral monitoring is a requirement, look for an integration product that supports this. Examples are Duet Enterprise and SAP Gateway for Microsoft (GWM). Both products support to hook into SAP Solution Manager to provide end-2-end system audit trails.

5. In case of purchasing a COTS Integration Software Product, the normal questions to evaluate: market presence and references, continuity of the supplier, fit of the product supplier in the organization’s preferred / strategic suppliers, conformance of the product technology to integration standards and IT platforms of the buying organization…

There are multiple smaller suppliers that deliver SAP / Microsoft integration products. What confidence and guarantee do you have in such a supplier that it will still be around in a few years to support the purchased integration product? And is it enabled to maintain and extend the product, to be on par with the latest technology innovations and the market demands plus expectations?

6. What is the technology comfort zone of the organization IT resources? Are they comfortable within the SAP landscape, or instead try to keep as much distance as possible?

If the organization has sufficient capable resources for SAP development and maintenance, it makes sense to realize the integration layer to expose SAP in SAP technology itself. Using SAP NetWeaver Gateway, SAP PI/PO.

If the organization does not have these resources, but instead does have .Net development expertise, it is a better fit to realize the integration layer in Microsoft technology. An example is WCF services that use a connector to invoke available SAP BAPI’s.

7. What security measurements and constraints are in place?

This addresses subquestions on authentication and authorization in the combined Microsoft + SAP landscape; infra related security via reverse proxy, firewalls, DMZ.

8. Are /will the Microsoft based consumption Apps be hosted on-premise, in the cloud or both ?

Current mantra at Microsoft is 'Mobile First, Cloud First'. What does this mean for the own business and IT strategy? If your organization aims to readify itself for the cloud, you must also take this into account when selecting a SAP / Microsoft interoperability approach. The latest version of Gateway for Microsoft supports to consume SAP data and functionality within Microsoft Azure and Office 365 runtime context.

What is already in place / available?

Orthogonal to the above evaluation path, you should also start with inspecting your current IT landscape, and the available components for SAP / Microsoft integration. If your landscape is still a greenfield on this aspect, that is fine. However, if you already have investments (time and material) made, then it is good to consider whether you can feasible reuse that; even if that would not be the preferred approach when you should start from scratch. As example: if you do have SAP PI, then start with examining the options to utilize that to expose SAP for Microsoft consumption; despite that the PI services are not the best choice for consumption in light-weight UI context.

Another example from the consumption side: do you already have SharePoint Enterprise Client Access Licenses (e-Cal’s)? If not, introduction of Duet Enterprise includes the Microsoft license requirement to also purchase per user a SharePoint e-cal license.

Conclusion

Summarized, determining the approach path for SAP Microsoft interoperability has 3 major viewpoints: functional / business context, enterprise architecture, and the already present (or planned) IT landscape (including infra and security constraints).

An organization that is new to SAP / Microsoft interoperability, should consider all of the 3 aspects to make a good choice in interoperability approach.

Further links for information:

SAP Gateway for Microsoft sp3 – from productive App development to Microsoft cloud hosting

Connect SharePoint 2013 to SAP via Gateway for Microsoft

Position of SAP NetWeaver Gateway versus SAP PI

Reasoning for Duet Enterprise in addition to SAP NetWeaver Gateway

Positioning of .NET Connector 3.0 versus Duet Enterprise

Architecture of a cloud-enabled SAP/SharePoint document viewer

Duet Enterprise interoperability versus native WCF service integration