Split MTA into backend & frontend – The final piece
Hi all CAP enthusiasts,
I recently posted two blog posts about splitting up your MTA project into a backend and frontend MTA project while keeping them tightly connected. This approach will give you the advantages:
- Separated development artifacts by concerns
- Different lifecycle for each peace
- You can go have more releases for the UI only while updating the backend when needed
- Every developer can focus on his part
- Keep it connected by config in the MTA
- No manual action needed after deployment
In this blog post I would like to provide an overview of the different possibilities. This should help you deciding which approach you use for your situation. With this, I also will throw in a third possibility 😊
This third solution is already explained by Minh Tri Le : https://blogs.sap.com/2020/07/22/how-to-integrate-ui5-with-sap-cap-application-as-the-destination-at-sap-cf-subaccount-level/
It has the benefit that it can be used across different spaces and even subaccounts. Be aware that this comes with additional configuration in case you want use different subaccounts. You will need to configure a trust connection to enable User Propagation between subaccounts. More information on different scenarios are described in sap help:
Based on this third option together with my two previous blog we can put the different solutions in categories:
- Cross-MTA dependencies
- Connect both MTA’s with MTA configuration
- Requires configuration in the MTA of the AppRouter
- MTA generated destination
- Generates a destination from the MTA configuration and dynamically fills in the service url at deployment time
- Manual created destination
- Manually create the destination
- MTA’s are not tightly connected
In my two previous blog posts about this topic, I did not only use different technologies to keep them connected, I also used a different type of AppRouter to access the application in both solutions. In the first one, I used the Managed AppRouter which is part of the portal and launchpad service:
If possible, you should really try to use this one. It will make your life easier!
In the second one, I used the Standealone AppRouter:
You have to use this type of AppRouter in case you have a special requirement which is not available in the Managed AppRouter. It gives you the possibility to extend the AppRouter with custom logic and make it fit to your needs.
The type of AppRouter has nothing to do with the solution for splitting up the MTA into backend and frontend. Although it is an important factor to decide which solution you have to use. Depending on the Approuter not all options will be possible.
I created an overview to have a clear view on when to use which solution:
|Managed AppRouter||Standalone AppRouter||Cross spaces and subaccounts|
|MTA generated destination|
|Manual created destination|
As mentioned earlier, “Cross-MTA dependencies” require a binding to the service in the MTA configuration in the MTA of the AppRouter. It’s not possible to add a binding to the MTA of the Managed AppRouter. This means that this solution cannot be used for the Managed AppRouter.
Generating the destination at deployment time based on MTA configuration should be possible for the Managed as well as the Standalone AppRouter. It doesn’t require any additional configuration in the AppRouter. I haven’t tried this with the Standalone AppRouter but in theory this should work as well.
Creating the destination manually can be used in any scenario but off course comes with manually actions. It has one big added value; it can be used across spaces and subaccounts. This is not the case for the other two solutions. They both require to have a connection to the same xsuaa service instance.
It might be possible to extend the configuration in the MTA to generate the destination the way you would create it manually. This could make the solution “MTA generated destination” work across spaces and subaccounts. I haven’t tried it myself so that’s why I made it gray.
I hope this helps you to get a good view on the different options to split up your MTA. As I haven’t tried all options myself, it would be great to share your experience here in the comments.
Thank you in advance!
Appreciate the insight! I have been looking into ways to separate UIs and services but maintain connections via deployment (rather than maintaining and troubleshooting post-install scripts) and your blogs really helped me understand my options.
One question I have is: how could these strategies be used in a multitenant (cds-mtx) scenario?
My initial thought was to make the following changes to the Standalone Approuter scenario (using git repo names as reference):
Sound about right?
I can’t say for sure. I don’t have much experience with multitenancy. In theory the steps you mention should do the trick.
Please let me know if it worked! Very interesting question!
Would you mind if I forked your repos and posted a follow-up blog of my findings? (Assuming I can get it to work!)
Not at all, please do! Already looking forward to your blog post 🙂