Rework required for Fiori apps exposed in SAP Workzone containing calls to external data sources?

[fvdlangenberg1]

Dear community,
I have this problem with a Fiori app exposed in SAP Workzone. The app contains a call to an archive server to fetch image data (of a scanned invoice). The app works fine when the user is logged in to the company intranet, but is not able to retrieve the image when logged on only to SAP Workzone, because the user's browser cannot reach the archive server (which is not exposed to Internet).

It seems to me that the only way to make the app work in SAP Workzone is to replace the client-side call to the external data source with a server-side call. That way the SAP Back-end would execute the call, fetch the data and push it to the SAP Workzone user.

In general this code rework should be done for all Fiori apps that use external (not part of the back-end) data sources. 
Or am I wrong here?
 

[FabioPagoti]

Hello @fvdlangenberg1 ! I see you are relatively new here so welcome to the SAP Community.

Some parts of your question are a little bit confusing but let me focus on the core of your question.

If you have an app in BTP (used in SAP BUILD WorkZone or not) which relies on an external source in a local network which is not exposed to the internet, you need the SAP cloud connector installed in some server on your local network connected with the BTP subaccount you are using. On that same BTP subaccount you'll need a destination which will be used inside your app (both in files xs-app.json to redirect some calls to it and likely in some ui5.yaml files that are needed if you run your app locally/in BAS.

SAP Cloud connector allows you to connect with non-SAP systems, which might be the case of your archive server. So in theory you wouldn't need an API to proxy those calls for you. Assuming you don't need an authentication which is not supported by Cloud Connector, I don't see any issues with having a destination pointing to your archive server via Cloud Connector.

Now it's confusing if you also need this app deployed in your local network or you only use it when developing locally. It's worth sharing here your manifest.json file containing the data sources as well as how are you fetching this files in your controllers. Sharing your ui5.yaml files and your xs-app.json might be helpful as well.

[fvdlangenberg1]

Hi Fabio, Thanks for your response. The app concerned is an existing 3rd party app from OpenText. The archive server in this case is setup as a external Content Repository (CR) on the SAP Backend with transaction OAC0. The URL inside that CR definition is retrieved somewhere in the logic and used as part of the URL to the actual image.Then the image URL is called by the browser of the Workzone user. I can expose the content server via the SAP Cloud connector, but cannot change the logic that constructs the image URL and calls it.

[fvdlangenberg1]

Maybe I should generalize my question a bit more.

We use the SAP Workzone to supply generalized, Internet based, access to Fiori applications of several SAP landscapes. If such a Fiori app contains references to external data sources (such as SAP content repository) then the app must be modified to work in 2 situations:

1. when the user is connected to the company on-premise network only
2. when the user is connected to SAP Workzone only.

In situation 1 we have no problems. The user is able to reach the content repository which is located on-premise. 
In situation 2, the SAP workzone browser tries to reach the content repository, but can only do that when:

a) it is exposed via SCC and the calling application uses the SCC destination OR
b) when the client-side (browser) call in the Fiori is replaced by a server-side call (in which case the SAP backend does the call to the content server).

[FabioPagoti]

Yes, from my understanding you did not have cloud connector in place already. So I am not sure what is still open in your question. Situation 2 a and b are the only way possible based on your conditions. Actually item 'b' will also rely on the cloud connector assuming this server is not exposed in the internet as well.

[fvdlangenberg1]

The point is that when the Fiori app is used on-premise the calling method to the Content Repository is directly done by the browser, which is the current standard. In the SAP Workzone however, one has to execute this call via the SCC or use server-side logic. For this, the standard code needs to be changed.

[FabioPagoti]

It's worth sharing here your manifest.json file containing the data sources as well as how are you fetching this files in your controllers. Sharing your ui5.yaml files and your xs-app.json might be helpful as well.

[fvdlangenberg1]

Hi Fabio, I'm not a developer. This is just a Fiori App from OpenText for invoice management. But I can imagine some Fiori apps exist that use client-side code for connecting to external data sources (as Content Repositories). If these are offered via SAP Workzone, code must be modified somehow to keep these connections working.

[FabioPagoti]

Thanks for the clarification. Your assumption might not be correct. Client side can only connect with the remote source by the usage of HTTP APIs, and in that sense CORS or Cross-Site Scripting could be an issue (which could happen in the cloud but on on premise). If that is the case I'd expect the OpenText solution has some sort of Admin/configuration panel to address that.

I saw something like this in 3051989 - "This content cannot be displayed in a frame" error if Business Workspace is opened from S...) but I wonder if this is part of the same solution you are using (it is under component XX-PART-OPT-ECM-CLD)

To solve this problem:

1. open Content Server admin page
2. go to "Configure Security Parameters"
3. unselect the option: "Frame Embedding: Prevent request handlers from being embedded in external frames"

There are different means by exposing an app in WorkZone. The app could be deployed in BTP or in the on-premise server and exposed via Content Federation (aka Content Exposure). WorkZone uses an iframe to embed some apps, which could also indicate a reason for not reaching the server.

That iFrame is the reason some HTTPs calls when done in SAPUI5 do not work in WorkZone unless you adapt the source code a little bit - but this is not always the case.

The easier way of understanding how this communication works, I highly suggest you doing it is my tracing the HTTP calls while you use the Fiori app in the browser by using the browser Developer Tools (any Fiori/front end developer can help you to do this in case you need support). In Chrome or Edge, just press F12 while having the app opened an check the "Network" tab.

I suggest to repeat this process both when executing the app in the local network and in work zone. If the call in workzone really fails, it should be even easier to identify in the Network tab as it will return some 4xx or 5xx error (despite being read).

Please attach those snapshots here. You can check the Headers >> General section for that request to see the URL being called and compare both scenarios.

The "Console" tab is also useful in case of CORS, Cross-Site Scripting issues.