Skip to content

Integrating with SAP (WebServices vs BAPI) – Summary Version

by on October 7, 2011

As with any integration project there are many considerations that go into the overall design and solution.  This is specifically true when integrating with SAP (FICO, CRM, etc).  This first posting is just a high-level summary of a couple key integration options, some key advantages/disadvantages, and some key factors to consider in your solution.  I hope for future posts to go into specific implementation details and performance results.  I will also be happy to share my specific client experiences with each of these scenarios offline or answer any questions in the comments of this post.

For purposes of this blog posting, we are going to focus on WebSphere Message Broker (WMB) as the Enterprise Service Bus (ESB) that would be interfaces to SAP (there are other ESB’s or point to point solutions that can be inferred from the same discussion).

Here we are going to focus on 2 of the options for integrating WMB with SAP applications:

1.  SAP Enterprise Web Services

2.  SAP BAPI Integration

There are other integration methods (i.e. leveraging IDOCS), but we will focus on these because of WebSphere Message Broker’s core Web Service capabilities as well as an out of the box solution using SAP Adapter for BAPI integration.

The following lists out some of the high-level advantages and disadvantages:

  1. SAP Enterprise Web Services
    • Advantages
      • Future direction of SAP
      • Flexible and easily support from external applications (i.e. ESB or end application).  This is not tightly coupled to WebSphere Message Broker
      • Supports Web Services Security (although, still immature).
    • Disadvantages
      • Based on feedback from SAP consultants, Web Services currently are wrappers around BAPI’s
      • Transaction control of Web Services and BAPI’s are limited and require custom coding.
      • Requires SAP Application Server environment to be configured (which may not be clients current enterprise standard)
      • Introduces security complexity with Web Services security, SAML tokens.  This has performance implications.
  2. SAP BAPI Integration
    • Advantages
      • Direct integration with BAPI and does not require additional Web Service layer that would potential impact performance. 
      • Ability to easily integration and have transaction coordination of multiple BAPIs.  This is supported by Adapter and also allows you to leverage extensive capabilities of WMB (or other ESB platform) for integration needs.
      • Eliminates requirement for SAP Application Sever use and configuration.
      • IBM recommended integration with SAP from WebSphere Message Broker
    • Disadvantages
      • Use of adapter is tightly coupled to ESB (WebSphere Message Broker)
      • Tied to SAP BAPIs.   There is no reason to believe that BAPI’s will not be part of future architecture, but there is a risk.

As with many architecture decisions, there are advantages and disadvantages to weight.  Following are some key considerations that I hope help drive you in the right direction specific to your environment:

Key Considerations:

  • Performance – There have been bench marks that show BAPI integration performs better.  Your specific SLA’s will need to help drive which solution is best for you (balancing performance, architecture, and cost impacts).
  • ESB Platform and maturity – Many clients have standardized and committed to using IBM’s WebSphere Message Broker as a key component of their SOA architecture.  In this scenario, you are leveraging most of the advantages and reducing the risk of many of the disadvantages.  Your current environment and future direction will help drive what option you choose for integration. 
  • Implementation – regardless of option for integration point with SAP, implementation design should be flexible and reusable.  This will provide flexibility to migrating between these options or other options that are determined necessary in the future.
  • Security – Both of these architectures have security considerations.  These also should be balanced against your current security architecture and standards.
  • Costs – Budget and costs are always a consideration and come in many flavors (cost of licenses, cost of necessary infrastructure upgrades, skill set of resources, cost of resource, implementation costs, etc).

There is no one option that is perfect for every company.  In fact, TransformaTech has implemented both of these solutions at different clients where it made most sense.

As I mentioned at the beginning, this post is just a summary view of a couple options and some key considerations to get you started.   I look forward to any questions or feedback on your particular experiences.

TransformaTech

Advertisements
Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: