Split MTA into backend & frontend – The final piece

[WouterLemaire]

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 triminhle : https://blogs.sap.com/2020/07/22/how-to-integrate-ui5-with-sap-cap-application-as-the-destination-at...

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:

https://help.sap.com/viewer/cca91383641e40ffbe03bdc78f00f681/Cloud/en-US/8ebf60c82a8e4cfc904f441c0c0...

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:

https://blogs.sap.com/2021/03/03/split-mta-into-backend-frontend-managed-approuter/

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:

https://blogs.sap.com/2021/03/10/split-mta-into-backend-frontend-standalone-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
Cross-MTA dependencies
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!