Route Multi-Region Traffic to SAP Build Work Zone, standard edition, using Amazon Route 53

The need for Business Continuity

The requirement for the business continuity of a modern-day tool is implicit and very essential. Nowadays, customers have zero tolerance for downtime. For business-critical applications, a failure, even of the tiniest amount, could have adverse effects. One such service that could be adversely affected by an outage is SAP Build Work Zone, standard edition. The Build Work Zone, standard edition service, being the end users’ central point of entry for all the applications, is expected to be highly available and responsive. 

SAP’s promise 

The SAP Build Work Zone service in SAP Business Technology Platform promises an easy-to-configure, role-based solution to act as a gateway into all applications, by displaying them in different tiles arranged in different groups. The availability of this service is limited by SAP BTP’s limitation of a subaccount to act as a single host located in a single region. This means we need a way to better prepare for and handle failure. So, instead of having a single work zone service in a single SAP BTP subaccount, we can have a clone running in a different subaccount that is hosted in a different region. That leaves us just with the task of redirecting the traffic to the right destination. 

Amazon’s Route 53 

Route 53 is Amazon’s highly available and scalable Domain name System (DNS) web service featuring easy-to-configure traffic policies and health checks to redirect the traffic to the right target. Route 53 fits our requirements perfectly and can act as the entry point; triage the traffic, and increase the availability of the SAP Build Work Zone service. 

Architecture

The data flow for this scenario begins with the request from the end user’s domain or the URL of the SAP Build Work Zone service. The flow then takes us to Route 53, which will check the health of the underlying systems and redirect the users to the right available target. 

High-Level Realization Steps 

 Prerequisites: 

• Two SAP BTP subaccounts preferably in different regions 
• Amazon Route 53 with access to a custom domain 

Steps 

1. Configure SAP Build Work Zone service in one of the SAP BTP accounts with all the necessary tiles, groups, access rules, and destinations 
2. Transport the Work Zone service from this first SAP BTP subaccount to the other SAP BTP subaccount in a different region with the help of SAP Cloud Transport Management service. 
3. Map the custom domain routes by using the Custom Domain Plugin of SAP BTP. This step must be done manually, once for each SAP BTP subaccount. This will ensure the establishment of trust between Amazon Route 53 and SAP BTP subaccounts. As a final task, an SAP service ticket must be created to accept the domain as a valid authentication and redirection URL. 
4. The next step is to create a traffic policy in Amazon Route 53 and configure the right rules to redirect the traffic. This step also includes the task of creating the health check policies and the hosted zone records. Optionally, on top of the health check, the traffic policy rule can also be based on the geographic location which can help reduce the network latency. 

For more details, you can check out the git hub repo here 

Potential Business Use Cases and Value 

Employee Self-Serve Portal 

The reliability and availability of a company’s employee portal with important services like personal info, paycheck, and vacation calendar are very critical. Making such a portal highly available with the above architecture will really make a positive impact on the employees. 

Service Industry – Field Portal 

Employees of a service industry who are out on the field attending to customer issues need to have a reliable single source of truth about their business at their fingertips. The information that is provided to them, apart from being always available, can also be made location specific with reduced latency to help them serve better. 

Other Points to Consider 

 The other points a customer might consider before adopting this architecture: 

• The effect on the Stateful Apps: The state of the applications will not be retained when the users’ traffic gets redirected to the other launchpad and this might force the user to refresh his page because when the switch happens, the data could be served from a different App Server which might not know of the current state.
• Extra Cost: The cost associated with setting up the extra sub-account and the associated subscription fee
• Manual Maintenance: The effort to maintain and keep both copies of the SAP Build Work Zone in sync. Because a change made in one instance might have to be manually replicated or would have to be transported to the other instance and further propagated to the production instance.

Conclusion and Next Steps 

 As all business trends indicate, cloud adoption and in particular multi-region cloud solutions are becoming more and more common to attain high availability and high resiliency. SAP customers can realize the potential of these services and increase the availability of their solutions by adopting the above-detailed approach. 

At SAP, we will continue collaborating with all the hyperscalers and release many more joint reference architectures, tackling different scenarios and solutions. Do let us know if you have any service or design scenario that you would like for us to focus on first. And meanwhile, please share the post and comment below if you have any questions. 

Credits

The above reference architecture is the results of teamwork and contributions from both SAP and AWS. I would like to thank the following SAP team members for their efforts: Mahesh Kumar Palavalli, Shanthakumar Krishnaswamy and Sandesh Shinde. And Sivakumar N, Martin Frick, Uwe Klasing and Anirban Majumdar for their support and guidance.

And special thanks to the following AWS team members for their inputs and support: Sunny Patwari, Sabari Radhakrishnan, Renga Sridharan and Soulat Khan