Because of the specifics of a browser environment, some features might be unavailable.
To help you get up and running faster in a browser, we'll outline the main steps and caveats of using SAP Cloud SDK on the frontend.
We will use
Angular to illustrate the usage.
You have a front-end application set up.
For example an Angular application via
ng new myProject.
For most examples, we will use the business partner API.
Add the package
@sap/cloud-sdk-vdm-business-partner-service to your package.json introduce some call via:
For the destination lookup, the SAP Cloud SDK relies on
Node.js functionality like
process.env for example.
However, the request building, execution, and result parsing does not require any
Node.js modules and can be used in the front-end.
Hence you have to create the destination variable
When you run
npm run build your project should compile.
Currently, we are facing compilation errors of the kind
Module not found: Error: Can't resolve 'https' in ...'
Please check out the workaround for these kinds of errors.
As discussed above the
myDest can not be fetched via the destination service.
When you run locally you can simply provide it.
When you execute
npm run serve your project is compiled and hosted on a local server.
When you trigger a request from a browser to the remote system all modern browsers will block this to ensure same origin policy.
One simple way to overcome this issue locally is to disable the web security of your browser temporarily (e.g. --disable-web-security for Chrome).
Alternatively, you can also create a second localhost proxy server that adds the
access-allow-origin-header to the request.
For productive usage, the methods mentioned above for running locally are of course not needed.
You simply configure the
xs-app.json of the used app-router with an entry like this:
and then in your application simply define the destination as:
The created request to
/REMOTE-SYSTEM-IDENTIFIER/sap/opu/odata/sap/API_BUSINESS_PARTNER/A_BusinessPartner will be matched by the app-router and the destination with the given URL and credentials is used.
This approach does not support principal propagation to On-Premise systems. For this you need a JWT and need to include the proper header fields defining the user. See the documentation on On-Premise systems for details.
With webpack it is possible to load resources for local or productive usage. Using such a switch you can easily adjust the value of the destination for the two cases.
Currently, we are facing the issue, that during the compilation from TS to JS the
Node.js parts cause problems even if they are not used.
We hope to resolve these issues in the future but here is a workaround:
- Create a custom webpack configuration named
node-webpack.config.jsand list the following node modules:
- In the
buildtarget to use the custom builder:
- In the
angular.json adjust theserve` target to use the custom builder as well:
- In the package.json exclude the node modules not existing in the browser:
Now the project should build and the run locally.