orkungedik/SAP-basis-dataset huggingface dataset:
## 4.1.4.2.1.2.2.2  Automatic Creation of Destination Configurations
If you use the HTML5 application deployer together with an application router managed by SAP for the Kyma runtime, you can enable that the required destination configurations pointing to the service instances are created automatically.
To enable the automatic creation of destination configurations, add the environment variable SAP\_CLOUD\_SERVICE in the deployment.yaml or Helm chart of the Kyma project and provide the value of the sap.cloud.service property from the manifest.json file of the HTML5 application that you want to deploy. The destination configurations can point to instances of the following services:
- An HTML5 Application Repository service instance of the app-host service plan (mandatory)
- An SAP Authorization and Trust Management (XSUAA) service instance (optional) To create a destination that points to an SAP Authorization and Trust Management (XSUAA) service instance, the SAP Authorization and Trust Management (XSUAA) service instance and a destination service instance must be bound to the HTML5 application deployer.
- A business service instance (optional)
- One or more backend destinations that point to cloud or on-premise backend applications. In addition to the SAP\_CLOUD\_SERVICE environment variable, also add the environment variable BACKEND\_DESTINATIONS to create backend destinations.
##  Note
To enable app-to-app navigation, you also have to add the environment variable IAS\_DEPENDENCY\_NAME and provide the name of the dependency that has been configured for the Identity Authentication token exchange that is required for app-to-app navigation. For more information about how to configure the dependency for app-to-app navigation, see Consume an API from Another Application.
You would typically use the automatic creation of destination configurations in Kubernetes if the HTML5 application deployer application has been previously uploaded as a docker image to Artifactory or Docker Hub. See, for example, this Kubernetes deployment:
<!-- image -->
```
- name: SAP_CLOUD_SERVICE value: "com.sap.test.service" - name: BACKEND_DESTINATIONS value: "[{ \"Name\":\"myapp-backend\", \"Description\":\"My application backend\", \"Type\":\"HTTP\", \"ProxyType\":\"Internet\", \"URL\":\"https://<backendApplicationHost>/\", \"Authentication\":\"NoAuthentication\", \"HTML5.ForwardAuthToken\": true}]" imagePullSecrets: - name: backend-dockersecret volumes: - name: html5-repo-app-host-volume secret: secretName: myapp-app-host-binding - name: xsuaa-volume secret: secretName: myapp-xsuaa-binding - name: destination-volume secret: secretName: myapp-destination-binding
```
## 4.1.4.2.1.2.3  Redeploy Content
You can redeploy changed content to the existing app-host service instance.
After making changes to the static content files of HTML5 applications, you can redeploy the new content to the already existing app-host service instance of the HTML5 application repository. All content referenced by the app-host service instance ID is replaced by the new content. If you want to keep more than one version of your HTML5 application on the repository, you deploy all versions, the new versions and the old versions that you want to keep, to the same app-host service instance ID.
## Example: Deploying two Versions to the Repository
- Application app1 with version 1.0.0 has been deployed to the repository. This app matches a back-end application with version 3.0.0
- For the app, a new back-end version 4.0.0 is available. Therefore, the application with version 2.0.0 is developed that matches the new back-end version.
- As customers may still have a backend with version 3.0.0, app1 with version 1.0.0 cannot be dropped. On the repository, both versions shall be available so the customer can decide which one to use depending on their back-end version.
<!-- image -->
```
xs-app.json
```
```
- app2 ... package.json manifest.yaml
```
## 4.1.4.2.1.2.4  Undeploy Content
To undeploy content you need to delete the content from the repository and delete the app-host service plan instance.
## Procedure
1. Open the Cloud Foundry command line interface (CLI).
2. Undeploy the *.mtar file using the CLI command: cf undeploy and add the --delete-services --delete-service-keys option.
Example: cf undeploy html5.repo.deployer.myHTML5App --delete-services --deleteservice-keys
- Use the -delete-services option, to delete the app-host service plan instance and the application content from HTML5 application repository.
- For the cf undeploy command, you need the mta id . T o get the mta id , do one of the following:
- Call cf mtas .
- Check the mtad.yaml ID .
##  Note
If you do not want to use the -delete-services option, you can delete the app-host service plan instance manually using the CLI command: cf delete-service SERVICE-NAME .
## 4.1.4.2.1.3  Consuming Content
Use the app-runtime service plan to consume HTML5 applications from the HTML5 Application Repository.
## Context
Application router can consume content from the HTML5 Application Repository by binding an HTML5 Application Repository service instance with app-runtime plan to the application router. In addition, the routing to the HTML5 Application Repository service is configured in the xs-app.json file.
## Procedure
1. Create a service instance of app-runtime service plan.
Example: cf create-service html5-apps-repo app-runtime MyHtml5AppsRepoRuntimeInstance
2. Bind the HTML5 Application Repository runtime instance to the application router in the manifest.yaml file.
3. Push the application with the following command: cf push
4. To redirect requests to the HTML5 Application Repository runtime, configure the routing to the HTML5 Application Repository service in your xs-app.json file.
5. HTML5 application content can be consumed from the application router using an URL in the following format: https://&lt;host&gt;.&lt;domain&gt;/&lt;appName&gt;-&lt;appVersion&gt;/&lt;resourcePath&gt;
```
 Sample Code applications: - name: myCRMApp memory: 256M services: - MyHtml5AppsRepoRuntimeInstance
```
```
 Sample Code { "source": "^(/.*)", "target": "$1", "service": "html5-apps-repo-rt", "authenticationType": "xsuaa" }
```
```
 Note appName - the manifest.json app.id without the dots appVersion - the manifest.json applicationVersion.version . The appVersion is optional. If not provided, the latest version will be used.
```
## 4.1.4.2.1.4  Security and Data Privacy Configuration
This section provides information about security and data privacy.
· Identity Provider and Identity Management You can use the User Account and Authentication (UAA) server for user authentication. In Cloud Foundry, a service is created for this configuration. By using the standard service binding mechanism, the content of this configuration is available in the VCAP\_SERVICES environment variable.
As an alternative to the User Account and Authentication (UAA) service , you can also use the Identity Authentication service of the SAP Cloud Identity Services for authentication.
- Authorization Configuration
To obtain the access token to authorize API requests, the client credentials authorization flow is used.
- Data Protection and Data Privacy
The HTML5 application repository service applies the legally required data protection and privacy measures to data that is stored on behalf of customers. These measures include, for example, the need to know principle during support processes, or data isolation between spaces. The HTML5 application repository runtime is a microservice responsible for providing read access to HTML5 applications during runtime. When the HTML5 application is public, the service enables sharing this content with consuming application routers from different spaces.
##  Note
The HTML5 application repository service does not provide the technical capabilities to support the collection, processing, and storage of personal data. The file names used for deploying the HTML5 applications are not intended for personal data.
## 4.1.4.2.1.4.2  Encryption Using Customer-Managed Keys
You can secure your SAP data with your own customer-managed key (CMK) using SAP Data Custodian.
Integrating SAP Data Custodian with the HTML5 Application Repository service allows you to encrypt HTML5 application files and credentials stored in the HTML5 application repository using your own customer-managed key (CMK). For more information about customer-managed keys, see .What is Key Management Service?.
## Enabling CMK Encryption for a New Instance of the HTML5 Application Repository Service
To enable the CMK for the HTML5 Application Repository, include a configuration file (for example, config.json ) with the configuration "enableCmk": true when you create or update an HTML5 Application Repository service instance of the app-host service plan. For example:
```
 Sample Code cf create-service html5-apps-repo app-host -c config.json
```
The config.json file must contain:
```
 Sample Code { "enableCmk": true }
```
## Enabling CMK Encryption for an Existing HTML5 Application Repository Service Instance
To enable CMK for an existing HTML5 Application Repository service instance, update the configuration file for the service instance to include the parameter "enableCmk": true . Then redeploy the application content to the app-host service instance.
## Disabling CMK Encryption for an HTML5 Application Repository Service Instance
To disable the CMK for your HMTL5 Application Repository service instance, set the enableCmk parameter in the instance configuration file to false ( "enableCmk": false ). Then redeploy the application content to the app-host service instance.
## 4.1.4.2.2 Application Router
The application router is the single point-of-entry for an application running in the Cloud Foundry environment on SAP BTP. The application router is used to serve static content, authenticate users, rewrite URLs, and forward or proxy requests to other micro services while propagating user information.
You can set up and run your own application router or you can use the application router that is managed by SAP (for more information see Managed Application Router [page 518]).
We recommend running your own application router only in advanced cases, for example when application router extensibility is required. The application router is available on the following sites:
- As a library on npmjs.com (NPM), see @sap/approuter
- As a container image on Docker Hub, see https:/ /hub.docker.com/r/sapse/approuter
## Related Information
Developing HTML5 Applications in the Cloud Foundry Environment [page 419]
Setting Up Your Own Application Router [page 440]
Resource Files [page 443]
Application Router Configuration [page 444]
Routing Configuration File [page 450]
Application Routes and Destinations [page 481]
Environment Variables [page 494]
Multitenancy [page 511]
Extending the Application Router [page 513]
Extension API of the Application Router [page 516]
## 4.1.4.2.2.2  Resource Files
The routing configuration for an application is defined in one or more destinations.
The application router is used to serve static content, authenticate users, rewrite URLs, and forward or proxy requests to other micro services while propagating user information. The following table lists the resource files used to define routes for multi-target applications:
Application-Router Resource Files Overview
| File                    | Description                                                                                                                                                                                                                                                     | Mandatory   |
|-------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------|
| package.json            | The package descriptor is used by the Node.js package manager ( npm ) to start the application router; in the 'dependencies': {} section                                                                                                                        | Yes         |
| xs-app.json             | The application descriptor contains the configuration used by the application router (for example, destinations for request forwarding)                                                                                                                         | Yes         |
| resources/              | A folder that contains all static resources which should be served by the application router. If no resources/ folder is present, the application router will not serve any static content. However, it still forwards requests to the configured destinations. | No          |
| resources/              |  Tip If you have a static resources folder name in the xs- app.json file, we recommend that you use localDir as default.                                                                                                                                       | No          |
| local-destinations.json | Provides the required destinations information for local devel- opment                                                                                                                                                                                          | No          |
| default-services.json   | Defines the configuration for one or more special User Ac- count and Authentication (UAA) services for local develop- ment                                                                                                                                      | -           |
```
 Sample Code xs-app.json "localDir":"my-static-resources"
```
```
{ "source":"^/web-pages/(.*)$", }
```
## 4.1.4.2.2.4.1  welcomeFile
The Web page served by default if the HTTP request does not include a specific path, for example, index.html .
XS Advanced Application-Router Parameters
| Property    | Type   | Mandatory   | Values                            |
|-------------|--------|-------------|-----------------------------------|
| welcomeFile | String | No          | HTMLpage, for example, index.html |
##  Code Syntax
"welcomeFile": "index.html"
## 4.1.4.2.2.4.2  authenticationMethod
The method used to authenticate user requests, for example: 'route' or 'none' (no authentication).
```
 Code Syntax "authenticationMethod" : "route"
```
| Property             | Type   | Mandatory   | Values                                                                                                                       |
|----------------------|--------|-------------|------------------------------------------------------------------------------------------------------------------------------|
| authenticationMethod | String | No          | • route (default) Authentication type is defined in the routes con- figuration • none Disables authentication for all routes |
##  Caution
If authenticationMethod is set to ' none ', logon with User Account and Authentication (UAA) is disabled.
## 4.1.4.2.2.4.3  sessionTimeout
Define the amount of time (in minutes) for which a session can remain inactive before it closes automatically (times out); the default time out is 15 minutes.
##  Note
We recommend using the environment variable SESSION\_TIMEOUT [page 501] to configure the session timeout.
If the environment variable SESSION\_TIMEOUT [page 501] is set this property will be overwritten.
```
 Sample Code { "sessionTimeout": 40 }
```
With the configuration in the example above, a session timeout will be triggered after 40 minutes and involves central log out.
A session timeout triggers a central log out with the following consequences:
- Deletes the user session
- Requests the log out paths for all your back-end services (if you provided these paths in the destinations and service properties).
##  Note
sessionTimeout can only be configured in the central routing configuration file (xs-app.json) that belongs to the application router, not in an xs-app.json file that is part of an HTML5 application.
## 4.1.4.2.2.4.5  login
A redirect to the application router at a specific endpoint takes place during OAuth2 authentication with the service that you are using for the authentication (User Account and Authentication service (UAA) or Identity Authentication service).
This endpoint can be configured in order to avoid possible collisions, as illustrated in the following example:
```
 Sample Code Application Router 'login' Property "login": { "callbackEndpoint": "/custom/login/callback" }
```
```
 Tip The default endpoint is ' /login/callback '.
```
## 4.1.4.2.2.4.7  destinations
Specify any additional options for your destinations.
The destinations section in xs-app.json extends the destination configuration in the deployment manifest ( manifest.yml ), for example, with some static properties such as a logout path.
```
 Sample Code { "destinations": { "node-backend": { "logoutPath": "/ui5logout", "logoutMethod": "GET" } } }
```
The following syntax rules apply:
Application Router: Destination Properties
| Property   | Type   | Mandatory   | Description                                                                                                                                                                                                                              |
|------------|--------|-------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| logoutPath | String | No          | The log out end point for your destination. The logoutPath will be called when central log out is triggered or a session is deleted due to a time out. The request to logoutPath contains addi- tional headers, including the JWT token. |
| Property     | Type   | Mandatory   | Description                                                                                                                                             |
|--------------|--------|-------------|---------------------------------------------------------------------------------------------------------------------------------------------------------|
| logoutMethod | String | No          | The logoutMethod property specifies the HTTP method with which the logoutPath will be requested, for example, POST, PUT, GET; the default value is POST |
## 4.1.4.2.2.4.8  services
Specify options for a service in your application.
The services section in xs-app.json extends the services configuration in the deployment manifest ( manifest.yml ), for example, with some static properties such as an end point.
```
 Sample Code { "services": { "com.sap.appbasic.country": { "endpoint": "countryservice", "logoutPath": "/countrieslogout", "logoutMethod": "GET" } } }
```
The following syntax rules apply:
Application Router: Services Properties
| Property     | Type   | Mandatory   | Description                                                                                                                                                                                                                              |
|--------------|--------|-------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| endpoint     | String | No          | The name of the attribute in the VCAP_SERVICES that contains the URL of the service.                                                                                                                                                     |
| logoutPath   | String | No          | The log out end point for your destination. The logoutPath will be called when central log out is triggered or a session is deleted due to a time out. The request to logoutPath contains addi- tional headers, including the JWT token. |
| logoutMethod | String | No          | The logoutMethod property specifies the HTTP method with which the logoutPath will be requested, for example, POST, PUT, GET; the default value is POST                                                                                  |
## Related Information
Integration with Business Services [page 489]
## 4.1.4.2.2.4.9  responseHeaders
You can add headers that the application router returns to the client in its responses.
You can add response headers to your application, for example, to comply with security standards.
The responseHeaders property is an array of objects, each object having the following properties:
## Property
Type
## Description
| name   | string   | response header name   |
|--------|----------|------------------------|
| value  | string   | response header value  |
```
{ "responseHeaders" : [ {"name": "header1", "value": "value1"}, {"name": "header2", "value": "value2"} ] }
```
Example:
```
 Sample Code { "responseHeaders" : [ {"name": "Content-Security-Policy", "value": "default-src 'self'"} ] }
```
##  Note
The response headers are added to the list of additional http headers that you have configured in the &lt;httpHeaders&gt; environment variable [page 494]. If the name of a response header configured in the routing configuration is identical with name of an additional http header in the list, the value of the response header overrides the value of the additional http header.
## Related Information
Environment Variables [page 494]
## 4.1.4.2.2.4.10  compression
The compression keyword enables you to define if the application router compresses text resources before sending them.
By default, resources larger than 1KB are compressed. If you need to change the compression size threshold, for example, to '2048 bytes', you can add the optional property 'minSize' : &lt;size\_in\_KB&gt; , as illustrated in the following example.
```
 Sample Code { "compression": { "minSize": 2048 } }
```
You can disable compression in the following ways:
- Global Within the compression section add "enabled": false
- Front end
The client sends a header ' Accept-Encoding ' which does not include ' gzip '.
- Back end
The application sends a header ' Cache-Control ' with the ' no-transform ' directive.
Application Router: Compression Properties
| Property                          | Type    | Mandatory   | Description                                                                                                                    |
|-----------------------------------|---------|-------------|--------------------------------------------------------------------------------------------------------------------------------|
| minSize                           | Number  | No          | Text resources larger than this size will be com- pressed.                                                                     |
| enabled                           | Boolean | No          | Globally disables or enables compression. The de- fault value is true.                                                         |
| compressResponseMix edTypeContent | Boolean | No          | Determines whether response content of the multipart / mixed content type should be com- pressed. The default value is false . |
##  Note
If the &lt;COMPRESSION&gt; environment variable is set it will overwrite any existing values.
## 4.1.4.2.2.4.11  pluginMetadataEndpoint
Adds an endpoint that serves a JSON string representing all configured plugins.
```
 Sample Code { "pluginMetadataEndpoint": "/metadata" }
```
##  Note
If you request the relative path /metadata of your application, a JSON string is returned with the configured plug-ins.
## 4.1.4.2.2.4.12 whitelistService
Enable the allowlist service to help prevent against click-jacking attacks.
Enabling the allowlist service (which is called whitelistService in the code) opens an endpoint accepting GET requests at the relative path configured in the endpoint property, as illustrated in the following example:
```
 Sample Code { "whitelistService": { "endpoint": "/whitelist/service" } }
```
If the allowlist service is enabled in the application router, each time an HTML page needs to be rendered in a frame, the allowlist service is used check if the parent frame is allowed to render the content in a frame.
## Host Names and Domain Names
The allowlist service reads a list of allowed host names and domains defined in the environment variable &lt;CJ\_PROTECT\_WHITELIST&gt; ; the content is a JSON list of objects with the following properties:
Allowlist of Host and Domain Names
| Property   | Type          | Mandatory   | Description                                                                                                    |
|------------|---------------|-------------|----------------------------------------------------------------------------------------------------------------|
| protocol   | String        | No          | URI scheme, for example 'HTTP'.                                                                                |
| host       | String        | Yes         | A valid host name, for example, acme.com.hostname , or a domain name defined with an asterisk (*) *.acme.com . |
| port       | String/Number | No          | Port string or number containing a valid port.                                                                 |
The following snippet shows an example of the resulting JSON array:
```
 Sample Code [ { "protocol": "http", "host": "*.acme.com", "port": 12345 }, { "host": "hostname.acme.com" } ]
```
##  Note
Matching is done against the properties provided. For example, if only host name is provided, the allowlist service returns ' framing: true ' for all, and matching will be for all schemata and protocols.
## Return Value
The allowlist service accepts only GET requests, and returns a JSON object as the response. The allowlist service call uses the parent origin as URI parameter (URL encoded) as follows:
##  Sample Code
GET url/to/whitelist/service?parentOrigin=https://parent.domain.acme.com
The response is a JSON object with the following properties; property 'active' has the value false only if &lt;CJ\_PROTECT\_WHITELIST&gt; is not provided:
```
 Sample Code { "version" : "1.0", "active" : true | false, "origin" : "<same as passed to service>", "framing" : true | false }
```
The 'active' property enables framing control; the 'framing' property specifies if framing should be allowed. By default, the application router ( approuter.js ) sends the X-Frame-Options header with value the SAMEORIGIN .
##  Tip
If the allowlist service is enabled, the header value probably needs to be changed, see the X-Frame-Options header section for details about how to change it.
## 4.1.4.2.2.4.13  websockets
The application router can forward web-socket communication. Web-socket communication must be enabled in the application router configuration.
If the back-end service requires authentication, the upgrade request should contain a valid session cookie. The application router supports the destination schemata " ws ", " wss ", " http ", and " https ".
```
 Sample Code { "websockets": { "enabled": true } }
```
To use web-sockets when the application router is integrated with the HTML5 Application Repository, the websockets property should be added to the xs-app.json of the deployed HTML5 application. When an incoming request for an application in the repository goes through the application router, it retrieves the application's configuration from the repository. If this flag is set, the application router creates a web-socket connection to the back end (the target url of the request) and acts as a proxy which delivers messages on top of the ws protocol from the back end to the user, and vice versa.
##  Restriction
A web-socket ping is not forwarded to the back-end service.
## 4.1.4.2.2.4.14  errorPage
Errors originating in the application router show the HTTP status code of the error. It is possible to display a custom error page using the errorPage property.
The property is an array of objects, each object can have the following properties:
Application Router: errorPage Properties
| Property   | Type         | Mandatory   | Description                                                                |
|------------|--------------|-------------|----------------------------------------------------------------------------|
| status     | Number/Array | Yes         | HTTP status code.                                                          |
| file       | String       | Yes         | File path relative to the work- ing directory of the applica- tion router. |
| path       | String       | Yes         | URL path relative to the HTMLapplication root folder                       |
Here is an example:
```
 Sample Code { "errorPage" : [ {"status": [400,401,402], "file": "./custom-err-40x.html"}, {"status": 501, "file": "./http_resources/custom-err-501.html"} {"status": 403, "path": "/forbidden.html"} ] }
```
In this code example, errors with status code '400', '401' and '402' will show the content of ./customerr-4xx.html . Errors with the status code '501' will display the content of ./http\_resources/customerr-501.html For errors with status code 403, the user is redirected to "/forbidden.html".
To avoid errors when redirecting to an error page that is stored in the HTML5 Application Repository service, define a route without authentication to the error page. For example:
```
 Sample Code { "source": "^/forbidden.html$", "service": "html5-apps-repo-rt", "authenticationType": "none" }
```
##  Note
The contents of the errorPage configuration section have no effect on errors that are not generated by the application router.
## 4.1.4.2.2.5  Headers
## Forwarding Header
The application router sends the following x-forwardingheaders to the route targets:
| Header Name       | Description                                                                            |
|-------------------|----------------------------------------------------------------------------------------|
| x-forwarded-host  | Contains the host header that is sent from the client to the application router.       |
| x-forwarded-proto | Contains the protocol that is used by the client to connect to the application router. |
| x-forwarded-for   | Contains the address of the client that connects to the appli- cation router.          |
| Header Name      | Description                                           |
|------------------|-------------------------------------------------------|
| x-forwarded-path | Contains the original path that the client requested. |
If a client performs a path rewriting, it sends the x-forwarded-proto , x-forwarded-host , and the x-forwarded-path headers to the application router. The values of these headers are forwarded to the route targets without modifications instead of being generated from the application router request URL. The x-forwarded-path header of a request does not impact the source pattern of routes in the xs-app.json .
## Hop-by-Hop Headers
Hop-by-hop headers are only for a single transport-level connection and are not forwarded by the application router. The headers are:
- Connection
- Keep-Alive
- Public
- Proxy-Authenticate
- Transfer-Encoding
- Upgrade
## Custom Header
x-custom-host is used to support the application router behind an external reverse proxy. The x-custom-host header must contain the internal reverse proxy host.
##  Note
EXTERNAL\_REVERSE\_PROXY environment variable is set to true.
In a multi-tenancy landscape, application router can be called from multiple tenants. During the authentication flow, application router uses the tenant ID to fetch the authentication token from XSUAA. Application router extracts the tenant ID from the corresponding host using the tenant host pattern configuration.
In an external reverse proxy flow, the application router uses the x-custom-host to extract the tenant ID using the tenant host pattern configuration.
If the x-custom-host is not provided, the application router uses the host header to extract the tenant ID.
## Authorization Header for Service to Application Router
The x-approuter-authorization header contains the JWT token or Open ID Connect (OIDC) access token to support the service-to-application-router scenario.
The application router can receive a JWT token created by the SAP Authorization and Trust Management service (XSUAA) service or an OIDC access token created by Identity Authentication and use it to access the UI and the data. The JWT token is passed to the application router in the x-approuter-authorization header of a request.
##  Note
The JWT token or the OIDC token are generated with the same SAP Authorization and Trust Management service (XSUAA) service instance or the same Identity Authentication service instance that is bound to the application router.
## 4.1.4.2.2.7  User API Service
The application router exposes a user API that returns the details of the users who are logged in to the application.
You implement the user API by modelling an xs-app.json route [page 455].
The user API supports two endpoints:
- /currentUser returns all details of logged in users.
- /attributes returns the main user properties.
The /currentUser endpoint response has the following format:
```
 Sample Code ``` { "firstname": "John", "lastname": "Doe", "email": "john.doe@sap.com", "name": "john.doe@sap.com", "displayName": "John Doe (john.doe@sap.com)" (The user ID in the identity provider) ,
```
```
"scopes": ["openid","user_attributes","uaa.user"] (Only if the authentication type is 'xsuaa") } ```
```
The /attributes endpoint response has the following format:
```
 Sample Code ``` { "firstname": "John", "lastname": "Doe", "email": "john.doe@sap.com", "name": "john.doe@sap.com" (The user ID in the identity provider) , "scopes": ["openid","user_attributes","uaa.user"] (Only if the authentication type is 'xsuaa") , < user attributes including custom attributes > (Only if the authentication type is 'xsuaa") } ```
```
##  Note
The "name" property is the user ID in the identity provider, which in many cases is also the email address.
##  Note
If you specify 'xsuaa' as the authentication type for the route, the following applies:
- User scopes from the xsuaa access token are added to the response of both endpoints ( / currentUser and /attributes ).
- User attributes from the identity provider (IdP) chosen for the authentication are added to the response of the /attributes endpoint. If a custom IdP is configured for SAP Cloud Identity Services - Identity Authentication, the custom user attributes are also added to the response of the /attributes endpoint. For more information about the definition of user attributes in Identity Authentication, see .User Attributes .
- To get the user attributes from the custom IdP, add the following property to xs-security.json file of the application router: "foreign-scope-references": ["user\_attributes"]
## Configuring the User API Service in the Routing Configuration File
You implement the user API by modelling an xs-app.json route [page 455] using the sap-approuteruserapi service .
The following example handles both endpoints:
```
 Sample Code { "source": "^/user-api(.*)", "target": "$1",
```
```
"service": "sap-approuter-userapi" }
```
The following example uses only the /currentUser endpoint:
```
 Sample Code { "source": "^/user-api/currentUser$", "target": "/currentUser", "service": "sap-approuter-userapi" }
```
## Related Information
routes [page 455]
## 4.1.4.2.2.8  Integration with HTML5 Application Repository
The application router is integrated with the HTML5 Application Repository service, to retrieve all the static content and routes ( xs-app.json ) of the HTML5 applications stored in the repository.
To integrate HTML5 Application Repository with an application router, create an instance of the html5-appsrepo service of the app-runtime plan, and bind it to the application router.
Model the xs-app.json routes that are used to retrieve static content from HTML5 Application Repository in the following way:
```
 Sample Code { "source": "^(/.*)", "target": "$1", "service": "html5-apps-repo-rt", "authenticationType": "xsuaa" }
```
In case the application router needs to serve HTML5 applications not stored in HTML5 Application Repository, it is possible to model that in the xs-app.json file of the application router.
When the application router is bound to HTML5 Application Repository, the following restrictions apply:
- It is not possible to implement the "first" middleware slot to provide routes dynamically.
- Only the workingDir option can be provided in the start of the application router.
- A mixed scenario of modeling part of the static content in a local resources folder and also retrieving static content from HTML5 Application Repository is not supported.
## Related Information
## 4.1.4.2.2.8.1  Processing a Request at Runtime
At runtime, the application router tries to fetch the xs-app.json file from the HTML5 application in the HTML5 Application Repository, and to use it for routing the request.
A valid request to an application router that uses the HTML5 Application Repository must have the following format:
##  Sample Code
https://&lt;tenantId&gt;.&lt;appRouterHost&gt;.&lt;domain&gt;/&lt;bsPrefix&gt;.&lt;appName-appVersion&gt;/ &lt;resourcePath&gt;
For example:
##  Sample Code
https://tenant1.myapprouter.cf.sap.hana.com/comsapappcountry.countrylist/ index.html
<!-- image -->
| Placeholder   | Mandatory   | Description                                                                                                                                                          |
|---------------|-------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| bsPrefix      | No          | Used when the application is provided by a business service bound to this approuter.                                                                                 |
| appName       | Yes         | Used to uniquely identify the application in HTML5 Application Repo- sitory.                                                                                         |
| appVersion    | No          | Used to uniquely identify a specific application version in HTML5 Ap- plication Repository. If no version is provided, the default application version will be used. |
| resourcePath  | Yes         | The path to the file as it was stored in HTML5 Application Repository.                                                                                               |
When processing a request at runtime, the following algorithm is applied:
- If no HTML5 application is found in HTML5 Application Repository for the current request, the central application router xs-app.json will be used for routing.
- If the HTML5 application exists in HTML5 Application Repository but no xs-app.json file is returned, an error message will be issued and the request processing will be stopped.
## 4.1.4.2.2.8.2  Multitenancy of HTML5 Application Repository
The HTML5 Application Repository is a multitenant service. Non-public HTML5 Applications are visible only to the application providers (with provider subaccounts) and the consumers subscribed to the applications (with consumer subaccounts).
When a multitenant application router is subscribed to a subaccount, the HTML5 Application Repository app-runtime instance that is bound to the application router is returned as a dependency, which triggers the subscription to the app-runtime instance. You can also bind HTML5 Application Repository app-host service instances to the application router to enable the subscription of the corresponding HTML5 applications. During runtime, the application router creates an HTML5 Application Repository app-runtime client\_credentials token using the tenant URL that the application router determines from the &lt;TENANT\_HOST\_PATTERN&gt; environment variable.
##  Note
The creation of the token can fail if the app-runtime instance is not subscribed to the subaccount, which happens if, for example, the application router was subscribed to the subaccount before the HTML5 Application Repository became a multitenant service. In this case the application router will create the token using the provider subaccount.
You can trigger the subscription to the HTML5 Application Repository app-runtime instance by using the SAAS Provisioning API: https:/ /api.sap.com/api/APISaasManagerService/resource .
PATCH /saas-manager/v1/application/tenants/{tenantId}/subscriptions
##  Note
If you have an old application router version, the HTML5 Application Repository app-runtime client\_credentials token is created by using HTML5 application provider subaccount.
## Related Information
Developing Multitenant Applications in the Cloud Foundry Environment [page 388]
## 4.1.4.2.2.9.1  Accessing Business Service Data
This section describes how the application router accesses the Business Service data.
To access Business Service data, the xs-app.json file should have a route referencing a specific sap.cloud.service or sap.cloud.service.alias via the service attribute. If an endpoint attribute is also modeled, it will be used to get the service URL; otherwise the fallback URL or URI attribute will be used.
```
 Sample Code "routes": [ { "source": "^/odata/v2/(.*)$", "target": "$1", "service": "com.sap.appbasic.country", "endpoint": "countryservice" },
```
In order to support JWT token exchange, the login JWT token should contain the uaa.user scope. This requires that the xs-security configuration file contain a role template that references the uaa.user scope.
```
 Sample Code { "xsappname"   : "simple-approuter", "tenant-mode" : "shared", "scopes": [ { "name": "uaa.user", "description": "UAA"
```
```
}, { "name": "$XSAPPNAME.simple-approuter.admin", "description": "Simple approuter administrator" } ], "role-templates": [ { "name": "Token_Exchange", "description": "UAA", "scope-references": [ "uaa.user" ] }, { "name": "simple-approuter-admin", "description": "Simple approuter administrator", "scope-references": [ "$XSAPPNAME.simple-approuter.admin" ] } ] }
```
## Related Information
Integration with Business Services [page 489] Accessing Business Service UI [page 493]
## 4.1.4.2.2.9.2  Accessing Business Service UI
This section provides information about accessing Business Services UIs that are stored in HTML5 Application Repository.
Business Service UI's must be stored in HTML5 Application Repository and defined in their manifest.json files as public: true in order to be accessible from an application router application that is typically running in a different space than the Business Service space. In addition, dataSource URIs must be relative to the base URL, which means there is no need for a slash as the first character.
The following is an example manifest.json file of a Business Service:
```
 Sample Code { "sap.app": { "id":"com.sap.appbasic.country.list", "applicationVersion: { "version": "1.0.0" }, "dataSources": { "mainService":{ "uri": "odata/v2/countryservice", "type": "OData" }
```
```
}, "sap.cloud": { "public": true, "service": "com.sap.appbasic.country" } }
```
A Business Service that exposes UI, must provide one or more app-host GUIDs in an html5-apps-repo block in VCAP\_SERVICES credentials.
To access the Business Service UI, the URL request to the application router must contain a business service prefix, as in the following example of a request URL:
## 
```
Sample Code https://tenant1.approuter-repo-examples.cfapps.sap.hana.ondemand.com/ comsapappbasiccountry.comsapappbasicscountrylist/test/flpSandbox.html
```
In this example, comsapappbasiccountry is the business service prefix which matches the sap.cloud.service attribute in the country service VCAP\_SERVICES credentials (without dots). The comsapappbasicscountrylist is the name of the HTML5 application as defined in the app.id attribute in the manifest.json file (without dots).
## Related Information
Integration with Business Services [page 489] Accessing Business Service Data [page 492]
## 4.1.4.2.2.10.1  Performance Statistics
The application router provides performance statistics in an HTTP response header if the HTTP request contains an HTTP query parameter (URL parameter) sap-statistics=true or if the HTTP request contains an HTTP header field sap-statistics:true .
If an HTTP request that contains a header field or query parameter with sap-statistics=true reaches the application router, the application router forwards an sap-statistics header to the corresponding backend. If SAP statistics is implemented for the backend, the backend returns to the application router a response header containing the statistics information from the backend.
The application router returns the following statistics information in an sap-statistics response header:
- total : The time that has passed between the moment when the request entered into the application router and the moment when the application router started writing the response
- ext (in case of destination forwarding): The time spent in the backend
Each backend sub-component can add its own response header with duration measurements when it receives the HTTP header sap-statistics:true .
## 4.1.4.2.2.10.2  Mutual TLS Authentication (mTLS) and Certificates Handling
Mutual TLS (mTLS) is a mutual authentication mechanism. The application router supports the use of certificates for the creation of tokens and an mTLS handshake in backend connections.
To enable the mTLS authentication for backend connections, the following prerequisites must be met:
- The authentication service instance that is bound to the application router, Authorization and Trust Management service (XSUAA) or Identity Authentication (IAS), must provide a certificate chain and a private key in its credentials.
- If the private key isn't provided in the credentials, you can also configure the environment variables XSUAA\_PRIVATE\_KEY (Authorization and Trust Management) and IAS\_PRIVATE\_KEY (Identity Authentication) in the application router to provide the private key.
- The destinations for the backend applications must contain either the HTML5.ForwardAuthCertificate s property in the configuration provided by the destination service (see Application Routes and Destinations [page 481] ) or the forwardAuthCertificate s property in the destinations environment variable (see Environment Variables [page 494]).
- In Cloud Foundry, the client certificate is propagated using the x-forwarded-client-cert header. To enable this, the backend URL must contain a .cert segment in its domain.
The application router gets the XSUAA or IAS tokens that provide the certificates chain and private key. The application router uses the certificates chain and private key from the credentials of the authentication service instance for the following:
- The application router creates the HTTP connection to backend using the private key and a chain of intermediate and client certificates to enable the mTLS handshake. If the FULL\_CERTIFICATE\_CHAIN environment variable is enabled, the application router sends the entire chain of certificates provided in the binding of the authentication service (XSUAA or IAS) to the backend applications. If this environment variable is not enabled, the application router sends only the root and intermediate certificates from the chain.
- When forwarding a request to business services, the application router uses these certificates also to create a client\_credentials token or to exchange the login token.
## 4.1.4.2.3 Managed Application Router
The managed application router enables you to access and run HTML5 applications in a cloud environment without the need to maintain your own runtime infrastructure.
The managed application router is the HTML5 applications runtime capability that is provided by the following products:
- SAP Build Work Zone, standard edition
- SAP Build Work Zone, advanced edition
- SAP Cloud Portal
To use the managed application router, you must be subscribed to one of these services.
For information how to develop HTML5 applications and run them using the managed application router, see the following product-specific guides:
- Developing HTML5 Applications for SAP Build Work Zone, standard edition
- Developing HTML5 Applications for SAP Build Work Zone, advanced edition
- Developing HTML5 Applications for SAP Cloud Portal