[PoC] Proxy Mode

[RandomByte]

Work in progress. Possible implementation of a somewhat NetWeaver ABAP / Gateway focused "proxy mode" as part of the standard UI5 Tooling.

Related to SAP/ui5-tooling#41

Note that many custom proxy implementations are already possible using Custom UI5 Server Middleware

Basic Working Principle

1. Normalize request URI
   • Examples:
     • /sap/bc/ui5_ui5/sap/my_app/~D9F8F129E4F10B8324F1751A2A3C583A~5/Component.js becomes
       /Component.js
     • /sap/bc/ui5_ui5/sap/my_lib/~D9F8F129E4F10B8324F1751A2A3C583A~5/library.js becomes
       /resources/my/lib/library.js
2. Try to serve normalized URI from local projects
   • All projects listed when executing ui5 tree will be used
3. If root project defines server.cdnUrl configuration: Try to serve normalized URI from configured CDN
4. Try to serve original URI from configured proxy destination

Possible Scenarios

1. Work on a locally cloned application and library in an ABAP hosted FLP environment
2. Launch an ABAP hosted FLP with a different UI5 version (from CDN or local)
3. ...

Minimal Configuration

specVersion: '1.1a'
metadata:
  name: my.app
type: application
---
specVersion: '1.1a'
kind: extension
type: proxy-configuration
metadata:
  name: abc-proxy
proxy:
  configuration:
    destination:
      origin: https://abc.acme.corp:44300
    insecure: true # obviously: do not send confidential data through the proxy when this is set to true

Full Configuration

specVersion: '1.1a'
metadata:
  name: my.app
type: application
server:
  cdnUrl: https://sapui5.hana.ondemand.com
---
specVersion: '1.1a'
kind: extension
type: proxy-configuration
metadata:
  name: abc-proxy
proxy:
  configuration:
    destination:
      origin: https://abc.acme.corp:44300
      ui5Root: /sap/bc/ui5_ui5/ui2/ushell # required when serving UI5 framework resources from local system or CDN
      ca: # not sure whether this already works, you'll have to use insecure if not
        - ./ca/MyCorpRoot.crt
    insecure: true
    appOnly: true # disables "ui5Root" configuration to enforce proxying UI5 framework resources from configured proxy destination

How to try

In your projects package.json:

  "devDependencies": {
    "@ui5/cli": "SAP/ui5-cli#feature-proxy"
  }

Refrain from using any lockfiles to ensure you always install the latest commits from the referenced feature branches:

echo 'package-lock=false' >> .npmrc

Try it:

ui5 serve --proxy # --verbose for details

Notes

• All application or library projects that shall be served from local system should use specification version 1.1a
• Applications need to define the "sap.platform.abap".uri attribute in their manifest.json (example value /sap/bc/ui5_ui5/sap/my_app)
• Libraries also need to define the "sap.platform.abap".uri attribute. As a fallback to the manifest.json this might be defined in .library at library.appData.manifest."sap.platform.abap".uri (example value /sap/bc/ui5_ui5/sap/my_lib)

Related PRs

• [PoC] ui5 serve: Proxy mode ui5-cli#229
• [PoC] Proxy Configuration Extension ui5-project#209
• [POC] Proxy mode: Read ABAP URI configuration from projects ui5-builder#308

[mlenkeit]

@RandomByte thanks for sharing this PoC. I have a couple of questions and remarks:

Questions:

1. Under Possible Scenarios, you say Work on a locally cloned application and library in an ABAP hosted FLP environment. I don't understand that sentence (nor the scenario). Could you please clarify that you mean by that?
2. Can you elaborate the purpose of the ui5Root in conjunction with appOnly? From the comments in the example, it seems that they are somehow contradicting.
3. Can I use this to proxy Gateway requests themselves? If so, could you share a sample configuration for this?
4. Why do I need the "sap.platform.abap".uri parameter in my manifest.json? Not sure if this parameter already exists today. Does it have to be the same as a specific proxy config parameter? Anyway, a disadvantage that I see of making this parameter mandatory or reading this without allowing to overwrite is that if I switch destinations (e.g. a different server), I might have to adjust the manifest.json (it it's deployed there under a different path). I think proxies should generally allow me to run my app against any destination without making any changes to it.

Remarks:

This PR seems to be very much focused on serving UI5 resources from a different location (i.e. remote server, the "sap.platform.abap".uri parameter, etc.). I still feel like this is not the most urgent feature from an app development perspective as mentioned in my comment on #41.

[RandomByte]

Thanks, sure!

1. Under Possible Scenarios, you say Work on a locally cloned application and library in an ABAP hosted FLP environment. I don't understand that sentence (nor the scenario). Could you please clarify that you mean by that?

Basically, all resources of the application and library are served from your local disk. Everything else from a NetWeaver ABAP or -Gateway system.

2. Can you elaborate the purpose of the ui5Root in conjunction with appOnly? From the comments in the example, it seems that they are somehow contradicting.

They are contradicting. And I'm looking for a better solution to this for a final implementation. Setting appOnly basically disables the effect of ui5Root. Setting appOnly has the same result as not setting ui5Root.

3. Can I use this to proxy Gateway requests themselves? If so, could you share a sample configuration for this?
   Do you mean OData requests or something else?

4. Why do I need the "sap.platform.abap".uri parameter in my manifest.json? Not sure if this parameter already exists today. Does it have to be the same as a specific proxy config parameter? Anyway, a disadvantage that I see of making this parameter mandatory or reading this without allowing to overwrite is that if I switch destinations (e.g. a different server), I might have to adjust the manifest.json (it it's deployed there under a different path). I think proxies should generally allow me to run my app against any destination without making any changes to it.

This parameter already exists today and is widely used among SAP owned applications: https://ui5.sap.com/#/topic/3a9babace121497abea8f0ea66e156d9

In my tests, the use of this parameter made it very simple clone a UI5 project and use it as part of a proxy setup without much changes to the projects configuration. An option to overwrite this parameter in the ui5.yaml would definitely make sense. Although I'm wondering whether it should be part of the projects- or the proxy-configuration.

Remarks:

This PR seems to be very much focused on serving UI5 resources from a different location (i.e. remote server, the "sap.platform.abap".uri parameter, etc.). I still feel like this is not the most urgent feature from an app development perspective as mentioned in my comment on #41.

Sorry that we missed to reply to that comment of yours!

We simply haven't done enough research into this direction. The neo-app.json or xs-app.json files are probably good alternatives for the "sap.platform.abap".uri parameter used in this PoC.

We would be happy for any contributions (comments and/or code) to integrate this as well.

This PoC focuses a lot on the handling of "special" UI5 requests, like app-cache-buster URLs and unbundling preload- or custom bundles. I think these are elements that should come from the UI5 team. Also since they can change frequently.

The actual rewrite logic can be exchanged or even better made pluggable if that helps to support more scenarios.

[petermuessig]

As we cannot support all proxy variants for ABAP, CF, Neo CP, ... - I would not integrate a proxy solution into our tooling. We can never make everyone happy and this will just produce requirements. Being open and pluggable should be sufficient IMO. Hence, I would close the PR.

[mlenkeit]

@petermuessig thanks for sharing your view on this and I can fully understand it. While the new UI5 tooling already supports plugging in your own middlewares (and thus proxies), it still requires a lot of verbose config. I think a plug-and-play (or "install-as-dependency-and-play") mechanism would help a lot here.

[petermuessig]

@mlenkeit - yes exactly - if a NPM package would also be able to transport the UI5 tooling configuration this would be also a nice option, something like this:

specVersion: "2.0"
metadata:
  name: my-custom-config
type: configuration
builder:
  customTasks:
  - name: ui5-task-transpile
    afterTask: replaceVersion
    configuration:
      debug: true
      removeConsoleStatements: true
      excludePatterns:
      - "lib/"
      - "another/dir/in/webapp"
      - "yet/another/dir"
server:
  customMiddleware:
  - name: ui5-middleware-simpleproxy
    mountPath: /srv/
    afterMiddleware: compression
    configuration:
      baseUri: https://services.odata.org/V2/Northwind/Northwind.svc/

Also the dependencies to the builders and tasks could be defined in the package.json of such a configuration module. Another thing is to define and forward the ui5 > dependencies section when the configuration package is used as a devDependency.

[RandomByte]

As we cannot support all proxy variants for ABAP, CF, Neo CP,

Why do you think we can't?

---

I think the majority of UI5 applications require a proxy in their development setup. It would be only reasonable to work out a good solution for those.

With the current state of middleware extensibility, a solution that is as easy to use as this PoC tries to demonstrate it, is not possible. Even though this PoC is currently focused on ABAP environments, the idea of having a proxy-configuration entity might make sense in all scenarios.

Anyways, I think it would be in the interest of many developers if the UI5 Tooling would be aligned with the SAP Business Application Studio in regards to proxying.

In summary: Even if we don't write the proxy middleware ourselves, we need to put work into figuring out how anybody could write them. And first of all we need to get an overview of the requirements.

[petermuessig]

In summary: Even if we don't write the proxy middleware ourselves, we need to put work into figuring out how anybody could write them. And first of all we need to get an overview of the requirements.

This is what I agree with - but I am pretty sure - we cannot do it right for everyone and thus to save the work for us I am a bit more defensive here. Even today, with the extensibility we have ~4 variants of the proxy for different scenarios. In BAS - the AppRouter is being used - so maybe we just integrate the AppRouter which is not based on the express middleware - might be also challenging, IMO.

[d3xter666]

This is now removed officially from UI5 Tooling since version 3: #550