In my previous article, I called ABAP on-premise system functions using Java+SAP Cloud Platform +SAP Cloud Connector to introduce how to consume ABAP with SAP Cloud Connector in Neo environment of SAP Cloud platform On-premise a function in the system. In the Java code of the demo application in that article, we are actually using JCO(Java Connector) to call functions On the ABAP on-premise system remotely.

For a change today, let’s try the CloudFoundry environment for SAP cloud platform.

We also tried a different way to consume services from the ABAP on-premise system. Let’s develop a Web application that displays the product list and price information from the ABAP on-premise system through OData.

The example is shown below.

The steps required to implement the same requirements in a CloudFoundry environment are a little more complex than consuming ABAP on-premise functions in the Neo environment of the SAP cloud platform mentioned in the previous article.

The most significant architectural difference in a CloudFoundry environment compared to Neo deployment is the addition of an App Router. Why is this required in a CloudFoundry environment? My colleague Beining Li elaborated in his article: SCP Application Router Introduction.

To complete this example, we need to deploy two applications to the SAP cloud platform’s CloudFoundry environment, the App Router and the Web application itself. The full code for two examples is on my Github:

Github.com/i042416/Clo…

A brief description of the interaction between modules in the figure above:

1. The App Router serves as the portal for users to access Web applications.

2. The App Router redirects the request to the XSUAA instance. The login page is displayed. This instance is responsible for completing login authentication and will be created later. Below is the effect of the login interface opened on my phone.

3. After the login, the App Router redirects requests to the Web application.

4. The Web application makes two parallel requests to XSUAA, as shown in Figure 4A and 4b, to obtain the JSON Web Token used to access steps 5 and 6.

5. The Web application accesses the Destination instance to obtain the configuration information.

6. The Web application sends requests to the Connectivity instance.

7. The Connectivity instance forwards the request to the Cloud Connector via Secure Tunnel.

8. Cloud Connector and on-premise systems are located in the Corporate Network and directly invoke their services.

Ok, so let’s do that with Jerry.

1. In my previous article, I used Java+SAP Cloud Platform +SAP Cloud Connector to call functions in ABAP on-premise system to introduce the download and installation of Cloud Connector. So now we can reuse the previously installed Cloud Connector.

Click the Add Subaccount button to create a new configuration based on the CloudFoundry Subaccount:

The most important thing is to maintain the CloudFoundry Subaccount ID and username (login mailbox).

Create a mapping from Virtual Host to Internal Host. The name of Virtual Host can be maintained at will. I maintain my-Backend. Remember this name for future use. I maintain the Host name and port number of on-premise system that provides OData services. Click the Check button to ensure that the Cloud Connector can successfully connect to the on-premise system with the status Reachable.

Expose the following four ICF service paths for on-Premise systems:

  • /sap/bc/lrep
  • /sap/iwbep
  • /sap/opu/odata
  • /sap/public

The configuration on the Cloud Connector is now complete.

2. Reviewing the module interaction diagram we described earlier, configurations on Cloud Connector cannot be directly deployed for application consumption on CloudFoundry. We also need to create three different types of instances on the SAP cloud platform.

Create a new Destination in SAP Cockpit. The URL field points to the Virtual Host created in the previous step. The name of the Destination should also be written down for later use.

Enter the Service Marketplace and create a new instance of XSUAA:

The connectivity- Jerry-Demo is the name of the Web application I will deploy to the SAP cloud platform later.

Create XSUAA instance:

Connectivity and Destination instances are created in the same way and will not be described again. Below is a snapshot of the state of the three different types of instances created to complete the scenario described in this article.

So far, the configuration on SAP cloud platform is complete.

3. Now start developing the Web application. Xs-app. json: the entry file for the App Router is index. HTML.

Go to App

/app/ : dest-to-app: /app/ : dest-to-app: /app/ : dest-to-app: /app/

The actual URL for this destination is maintained in the manifest.yml file of the App Router. You also need to maintain the XSUAA instance created in the previous step in the services field of the yML file:

Look again at the Manifest.yml file for the Web application: the three types of instance names created in the previous step need to be maintained as shown below:

Next we need to develop the UI5 part of the Web application and specify which OData service the data source of the product list is based on. In the CONTROLLER file of UI5, specify the path of OData model as the relative path data-eu.

For this relative path data-eu, a route is defined in neo-app.json that is redirected to the on-premise system’s standard OData service EPM_REF_APPS_SHOP_SRV. Which on-premise system to redirect to is determined by the target field of the route. In my case it is Jerry-Abap-Backend, which is the Destination we created in THE SAP cloud platform Cockpit.

The Destination URL field points to the Cloud Connector’s Virtual host, which maps to the on-premise system’s host name and port number. The configuration on SAP Cloud Connector, App Router, Web application, connectivity, XSUAA and Destination instances on SAP Cloud platform, these models work together like parts on a machine. The access scenario from Internet Network to Corporate Network is realized.

Deploy the two applications to the SAP Cloud platform’s CloudFoundry environment and click on the App Router as the entry point to see the product list page at the beginning of this article.

In addition, the network request path observed in Chrome Developer tools only contains the route data-eu configured in the neo app.json of UI5 application mentioned above, while the host name and port number of on-premise system are not exposed to the Cloud environment.

Of course, to run this demo, you need to specify a backend system for the standard OData service EPM_REF_APPS_SHOP_SRV On on-premise system using transaction code/iWfnd /maint_service. In my example below, THE backend implementation of the service is AG3.

Print the actual url in Java code, found at http://my-backend:80/sap/opu/odata/sap/EPM_REF_APPS_SHOP_SRV/$metadata.

My-backend :80 in this URL is replaced by the Cloud Connector with the actual on-premise system address and sent to the on-premise system.

For more of Jerry’s original technical articles, please follow the public account “Wang Zixi” or scan the following QR code: