SAP Approuter Common Doubts

[former_member877007]

Hi experts,

I'm seeking your insights regarding SAP Router and xs-app.json configurations within standalone approuter approaches in CAPM. I've observed two primary approaches:

1. Approuter within the App Folder:

• No html5-repo-host in mta.yaml
• Fiori apps lack individual xs-app.json files
• Routing seemingly handled entirely by the approuter

2. Approuter in a Separate Folder (<Appname>-approuter):

• Presence of html5-repo-host in mta.yaml
• Individual xs-app.json files for each Fiori app

Questions:

1. Rationale: Could you elaborate on the reasons behind these distinct approaches?
2. xs-app.json Configuration for Approach 2: How should xs-app.json be configured in Approach 2, specifically when a Fiori app resides outside the approuter folder? I've encountered an issue with "localdir: ." not functioning correctly in this configuration.
3. Illustrative Examples: Would you be able to provide concrete examples of each approach, accompanied by explanations for their usage?
   
   Thanks
   Somnath

[sergio_rozenszajn]

Hi Somnath,

See more info here

Indeed there are different implementation options:

1. Standalone approuter with embedded html5 applications (in a local approuter directory)

• This is the old modeling, developed before HTML5 Application Repository service was available. This kind of modeling has some drawbacks:

- If you change the html5 application you have to re-deploy the approuter (which might cause downtime)

- If you have multiple html5 applications all the routes should be configured in the approuter central xs-app.json file, which might be hard to maintain and error prone

2. Standalone approuter using HTML5 Application Repository service

• HTML5 applications can be re-deployed to HTML5 Repo service w/o having to re-start approuter
• Each HTML5 Application contains its own xs-app.json file containing only the routes that are relevant for this app. It is easier to maintain
• HTML5 applications in HTML5 Repo can be also shared as libraries to other apps - for example if you decide to provide a business service

3. SAP Managed Approuter --> recommended SAP approach

• No need to deploy an approuter application
• In this case you need to subscribe to one of the Workzone SaaS Applications, which provides a central approuter support
• With this you avoid the hurdle of running your own approuter application (maintenance, update versions, take care of zero downtime, etc.)
• You can model Workzone sites with it, providing a better user experience
• You can easily integrate other application in the same site
• The only drawback is that you can't code approuter extensions, as it is possible with a standalone approuter

I hope this helps.

Best Regards

Sergio

[former_member877007]

Why does SAP Approuter default to the first approach when created from BAS?

[former_member877007]

Also, I have encountered another peculiar problem. I need a CAP application where I have to consume the same CAP application service and a different CAP application service exposed via a destination. When I add code in the xs-app.json of the app router, it can load two OData services. However, it fails when added to the Fiori app's xs.app.json.

{

"source": "^/diff/(.*)$", "target": "/odata/$1", "destination": "hardAPIs", "authenticationType": "xsuaa", "csrfProtection": false },

This is the xs-app entry, hardAPIs is maintain in destination.
<approuter-link>/diff/hard-data/HardCodedTable working but
<approuter-link>/<fioriapp>/diff/hard-data/HardCodedTable not workingThanks
Somnath