Considerations for SAP / Microsoft interoperability approach and technology
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:
- Use a technology ‘connector’ between Microsoft code/platform and SAP platform to consume SAP data into Microsoft context
- 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
Hi William,
thank you -- this is a great overview. I fully agree with you that there are scenarios where it does not make sense to use a product like Duet Enterprise or SAP Gateway for Microsoft. The "one-stop scenario" you mention is very often the first start in a bigger project. Of course it still might not make sense to go with a strategic product, however, I would still follow "some" guidelines/recommendations.
For example instead of using the .Net connector, I would base my new Microsoft/SAP integration project on something like SAP Gateway (and just to mention: for any licensed SAP customer both are “free” for internal usage). Even if it is only a one-stop scenario SAP Gateway (and not the .Net connector) is much, much, much more strategic at SAP right now and also brings more flexibility (e.g. maybe you do not only want to integrate in Microsoft)
Regards,
Holger.
I have seen many customers pose the question of Microsoft and SAP integration and usually the understanding of the scenario is limited but when it comes to delivering outcomes for the end users many complexities arise. For me there is the fundamental question first; do you want to expose data to Office for information or do you want to integrate documents into the business process.
If you want information exposed then this blog has a great summary of the options available.
If you want to integrate documents into the business process and basically organise your documents/knowledge according the business processes organised in SAP then you need a document management system which is deeply integrated with SAP. This allows you to share structure, security, triggers, metadata, relationships etc. To me this represents a more mature way to work with structured and unstructured information to drive business efficiency and accountability.
And note you can have both approaches combined.
Hi Mark, thanks for your thoughts. For a part you make a valid point. However, the field of SAP-Microsoft is much broader as the 2 alternatives you name. I see also business value in operating SAP business transactions in information worker workplaces, which are often positioned into Microsoft domain, and not only Office.
DMS integration is a SAP/MS integration subject on it's own, which I have not addressed in this blog. Nor BI Integration. For DMS integration, integration technologies as SAP ArchiveLink are relevant, and suppliers as OpenText, Gimmal that deliver certified ArchiveLink connectors.
Hi William
You are of course right, I did mean broader Microsoft technologies not just Office. I also agree DMS is a complex topic but its adoption across the modules is inconsistent and as an end user not great to use.
I would like to hear your comments about the ECMLink approach to integrate from SAP to Microsoft via OpenText. I feel that is a 7 lane motorway of integration compared to the 20 year approach of Archivelink which has many limitations.
Hi Mark,
personally I've only limited practical experience with SAP+Microsoft DMS integration; in applying Gimmal's iNet.DM, and none with OpenText. For both suppliers counts that they provide additional value and support on top of the low level ArchiveLink integration, that eases integration scenarios but at the cost of licenses. Whether a viable business case is in fact the same as I stated in my post: is it for a one-shot scenario, or is it enterprise strategical? In the latter OpenText "fast lane" must certainly be considered and evaluated. But bare in mind that OpenText implementations are themselves not easy and time-intensive, and typical require one to hire well-paid OpenText consultants. But again that can be a sensible business investment, it all depends on the specific situation / context.
regards, William
Tend to agree with Mark's statement. There seems to be a massive element of confusion from customers. I think this stems from the fact that people view SharePoint as documents and SAP as data, and the assumption is that people would be attaching documents to SAP transactions, not the other way around.
Hi Athol,
(in addition to my response to Mark); indeed, both SharePoint as SAP are much more as the very limited view you sketch above. Actually, both are business platform, with SharePoint a base to deliver solutions on, and SAP already delivering standard business solutions for the enterprise (SRM, CRM, PLM, ...).
The technical foundation of both business platforms are in full motion, with Office 365 on Microsoft side, and Fiori, S/4 HANA, SAP Gateway and more on SAP side. This also implies that the positioning and business values of integration scenarios are evolving (eg withFiori already providing a much more userfriendly operation as the GUI or WDA, less value to build an alternative UI in Microsoft based UI's), as well as the integration possibilities. Certainly as both suppliers adher to integration standards in new developments: OData, OAuth,