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.
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.
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
- Two SAP BTP subaccounts preferably in different regions
- Amazon Route 53 with access to a custom domain
- Configure SAP Build Work Zone service in one of the SAP BTP accounts with all the necessary tiles, groups, access rules, and destinations
- 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.
- 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.
- 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.
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
Thank you for sharing! Do you know is it is possible to keep personalisation in sync between both Launchpad’s?
hi Wouter, thanks for your comment. Unfortunately, such a feature does not exist today. But I'll keep you posted.
Some of the biggest complaints I hear from customers about BTP (besides the pricing) are
Yes, having a failover strategy is crucial! I've been implementing failover strategies using Akamai so far, and it went just well. What are the benefits of using Route 53? Is it more flexible, reliable, or cheaper than Akamai? Or just the preferred option for Amazon devs?
Failover or regional redundancy is important. It comes at some monetary costs, but also with additional effort if not to call it overhead. Let's say you wanna have 20 "cloned" FLPs worldwide... means you'll have to deploy changes 20 times and keep things 20 times in sync. A lot of that you can automate. But what about services that you use in your FLPs, i.e. the WorkFlow Service? Would you have it 20 times as well? What if a user rejects a workflow... will the other Workflow Service instances be informed? Rhetorical question 😉
Here is my wishlist:
that are great ideas. Can you please file them as influencing requests in the opportunity: SAP Application Development - Digital Experience. That way they do not get lost in this comment.
Thanks for the suggestion, and I think it would be a good idea.
Problem: I still don't have an S-User, and SAP seems not to want P-Users to "influence".
I'm afraid to ask you, but is there a chance you could add this?
what's about applying for the SAP PartnerEdge Open Ecosystem – Build Partnership? There you get an S-User and use it with the BTP Fee Tier.
Also a good idea - thank you again for being so helpful!
The last time I tried it didn't work out because of some bug on the website. Now this time when pressing the apply button, which redirects to https://www.sap.com/germany/partners/partner-program/build/apply.html, I'm getting a page not found error. I think SAP simply doesn't want me... 🙂
Page not found error when applying for sap partner edge
As already replied on Twitter the link for the partnership application is: Apply for Partnership or Membership