As the name already suggests, the starting point here is your current SAP landscape state. Start with identifying the available functional building blocks in the SAP environment – existing BAPI Function Modules, RFC’s, SAP workflow business objects, and already available SAP webservices. And expose these to outside world, to have the related SAP data and functionality consumed by a non-SAP front-end.
AdvantagesBiggest advantage of this approach is that you have a faster time2market. You can base your SAP / Microsoft.NET interoperability on already existing, and thus also tested, SAP building blocks. The only thing that needs to be done is to put a (web)service interface on them, and then you can integrate with the Microsoft based presentation layer.
DisadvantagesThis can be summarized with the phrase ‘Garbage In – Garbage Out’. If you base your interoperability architecture on the current state of your SAP environment, there is a large likelihood that SAP-proprietary concepts will be visible on the integration surface level. In general, an architecture that originates via this approach will be less pure and transparent. And thus less future-proof.
The essence of the Outside-In approach is to first agree on and define the conceptual contract [interface] between the service provider side [SAP], and the service consumer side [SharePoint]. The idea is to start from the requested application functionalities. Derive and define at a conceptual level the services you require from the SAP backend to deliver the application and system functionalities. Describe the service interfaces in W3*-standards based notation and data structures. From here on, map onto required SAP building blocks: existing if available, new ones otherwise. At SharePoint / presentation side, you can build the consumption layer for the defined service interfaces via wsdl.
Thus start at ‘outside’ with the conceptual, externally visible service interfaces; and continue then for both provider and consumer / SAP and Microsoft sides to the inside with their respective technologies.
AdvantagesBecause you start in this approach with a green field, the resulting interoperability architecture typical has a cleaner interface, which inherently conforms to interoperability standards. And because you start from the required business services, it also has a better chance on being conceptual correct, and future-proof.
DisadvantagesBiggest disadvantage is that this approach requires more investment and time at front in deriving and describing the service interface layer. Also it requires to get both SAP and Microsoft departments representatives on par, to have a common understanding of the applied service concepts. And in case of existing SAP building blocks, a transformation can be required to map the standards-based service interface to the SAP-specifics Function Modules, RFC’s, workflow business objects.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
11 | |
10 | |
7 | |
6 | |
4 | |
4 | |
3 | |
3 | |
3 | |
3 |