Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member

                I’ve been working on SAP customer projects in cloud-like environments for the past several years. A large portion of these have been BW on HANA in the cloud. Customers will very often point the finger at HANA as the cause of performance issues after moving their BW to HANA and into the cloud, but HANA is rarely the culprit. The same questions always seem to come up, so I decided to jot down some lessons learned.

                We all know that BW by itself doesn’t do much. Referencing the famous picture below, we know that there are multiple interfaces required. We need data sources from which to get the data, whether this SAP or non-SAP sources. Some options to get the data into BW are native BW extractors, SLT or Data Services. Depending on the use case, the implementation could use one or more of these solutions. The open hub services allows the distribution of outbound data, but I don’t have much experience with this. Why would you want to send the data anywhere else if it is sitting on HANA? There must also be a way to consume the data. These can include BEX Analyzer, BEx Web or an integration with BOBJ BI using dashboards, BI Launchpad or Crystal Reports.

(graphic source: SAP documentation)

I would say 90% or more of the BW on HANA projects I have been involved in included a BOBJ BI implementation. The other common systems I see deployed are SLT and Data Services. From experience, it makes sense for some of these systems to sit in the same physical location as the BW on HANA. What can seem like HANA performance issues to the customer are more often latency issues between systems.

On to some of more interesting bits. I’ll assume HANA and the applications are sized and architected properly. We won’t discuss diagnosing HANA or application performance issues, but potential issues with network latency and bandwidth and how to manage these challenges.

I would say an SAP system could be considered a tightly coupled system. What I mean by this is that the database and application tier must sit in the same location and work in concert to ensure smooth operation. On the other hand, I would argue most SAP landscapes can be considered loosely coupled and it is ok to separate the systems by some distance. Although, there are some architecture decisions that need to be made to ensure satisfactory performance in a hybrid cloud environment. When systems are all sitting in the same location connected by a 10G network connection, latency and bandwidth is usually not a concern.

Lessons Learned w/ real world examples


SLT

Disclaimer: This is only an example. These numbers were provided during testing by the customer.  


  • SLT is used for real time replication from varying data sources. A typical use case is replicating data from an on premisis ERP, CRM or a 3rd party DB to the BW on HANA in the cloud.
  • SAP’s recommended network connection for SLT is 1Gbps. It can be expensive for a VPN or MPLS line to have so much bandwidth and it is often overkill.
  • Real world scenario of Fortune 500 company with hybrid cloud implementation; HANA, BOBJ BI and SLT in the cloud replicating from on-premisis ERP
    • Initial data load was a concern, so several iterations of testing were performed over a 100Mbps VPN
      • Before optimization, it took 14 hours to replicate ~350,000,000 records
      • After SLT optimization, 7 hours to replicate ~500,000,000
        • No substitute for well optimized SLT system
    • Initial load peaked at 40Mbps of bandwidth
    • After initial load, VPN bandwidth was throttled down to 15Mbps to sufficiently handle real time replication of ~4 records per second.
    • Sizing depends on scenario, but real world numbers are shown just as an example.
  • SLT should be near the target system
    • RFC traffic is compressed by default
      • In above scenario, network team saw a total of 23.23GBs go through VPN tunnel, but total size of all replicated tables was ~100GBs
      • Since VPN is bottleneck, we want as much compression as possible over the connection
    • The DB connection is not compressed.
  • In the event of a network failure, the replication will be retried until it completes, but will lead to longer execution times and increased resource usage


BOBJ BI w/ BEx

  • Customer had BEx integration with Portal, but portal stayed on premises
    • Users experienced unacceptable response time trying to display reports
    • After much troubleshooting, portal was moved to the cloud next to BW
    • Performance improved dramatically
  • BEx provides a rich web-based reporting interface, but this can come at a cost
    • Common interface from BOBJ to BW is BICS, which is XML that goes through the Java layer for Webi, Crystal, Analysis reports
    • Simple operation such as requesting a list of documents can have 90 individual HTTP requests
    • The bandwidth typically isn’t the issue, but the latency for so much back and forth communication causes delays
    • This is not an issue with low latency connections
  • BEx performance will be best if both the BW and the BOE servers are in the same location
    • This will ensure the best report refresh times
    • Will make latency between BW and BI a non-issue
  • 1733726 - Performance optimization in WAN scenarios with BICS
  • If BEX is integrated with Portal, then portal should sit next to BOBJ BI in the cloud

 

BOBJ Data Services

  • Every implementation that I’ve come across that had BODS in the cloud required a local WTS for BODS Designer
  • There are known issues with Data Services Designer connecting over a WAN
  • BODS development has been aware of this for several versions, but the issue still occurs as of the 1.4 client
  • Only acceptable solution is to put a WTS server with the client tools in the DC where BW and the BODS job server are located
  • May be an option to put BODS on premise, but typically best to put near BW and BOBJ BI

Example architecture




I hope this is helpful. Again, this is my experience over many implementations, but would love to hear any experiences others have had with hybrid cloud scenarios.

Labels in this area