Deploy App from own BAS to Custom Cloud Foundry

[Missschaaa]

Hey guys,

Is it possible to deploy an app from our own BAS in our BTP to a Cloud Foundry of a customer?

We created our own app which consumes data from Non-HANA On-Premise Backend System. To deploy the app to our system we added deploy configuration with “npx fiori add deploy-config” and entered our ABAP System which is linked in our BTP via Cloud Connector. This works fine and app gets created as BSP Application in our Backend System so we can use it in our launchpad with SICF node.

Now we want to roll out this app to a customer as MTA Project directly into customer Cloud Foundry and Launchpad Work Zone. Therefor we connected our own BAS to customer Cloud Foundry which worked. Then we overwrote again with “npx fiori add deploy-config” our Deploy Config and this time chose Cloud Foundry. But although we before connected to customer Cloud Foundry system only shows up our own Cloud Foundry Destinations. So we used our own Destination in deploy config and started MTA Project deploy. This leads to wrong xs-app.json entry for the destination.

The app gets created in Customer CF like we wanted it but opening the link does not work because app cannot find metadata, of course due to wrong destination. We can workaround this by copying the destination of customer BTP in our own BTP but sounds wrong for me. So what would be the "standard" way to deploy it? Download it in our BAS and upload it in customer BAS and then deploy it there?

Other question: It looks like deploy config always has to get overwritten. So do we always have to overwrite/switch it when deploying to On-Premise Backend and CF? Is there any way to do it both individual without always overwriting?

Regards

Michael

[jlong]

Hi,

Running the deployment configuration will re-write the ui5-deploy.yaml to reflect the target system i.e. ABAP | Cloud Foundry (CF).

My suggestion would be to create the respective deployment configs per system. Create an ABAP configuration first and rename the ui5-deploy appropiately. CF deployment requires a few more configurations which is why you would create the CF after the ABAP configuration is generated and working. You can then update your scipts as follows;

"deploy-abap": "npm run build && fiori deploy --config ui5-deploy-abap.yaml && rimraf archive.zip",

Technically, the existing CF deployment command doesnt need to change but you can rename it to be consistent. Rememeber, CF deployment is a two step process, step 1 is to generate the archive/zip file and step 2 is to deploy this archive/zip to the sepcific CF instance. Typical build and deploy CF commands;

"build": "rimraf resources mta_archives && mbt build --mtar archive",
"deploy-cf": "cf deploy mta_archives/archive.mtar --retries 1"

When you create the CF deployment configuration, its dependent on an mta.yaml configuration file which will allow you to achieve step 1 which is to generate the archie/zip file.

Your xs-app.json should be configured with a destination and this should NOT be changed, for example;

    {
      "source": "^/northwind/(.*)$",
      "target": "$1",
      "destination": "NorthwindProduct",
      "csrfProtection": false      
    },

https://github.com/SAP-samples/fiori-tools-samples/blob/main/cap/cap-fiori-mta/app/feproject-ui/xs-a...

https://github.com/SAP-samples/fiori-tools-samples/blob/main/neo-migration/fioriapp/xs-app.json

Option1.

Generate a subaccount destination in the respective SAP BTP cockpit accounts, with the same name, however the properties of the destination can be different per subaccount. This can be preconfigured and tested before the Fiori UI app is deployed.

Using this approach, means you dont need to change any configuration within your Fiori UI application.

Now, to successfully deploy this application simply, build the Fiori UI application, login to the respective CF instance and now run the deploy command i.e.

"deploy-cf": "cf deploy mta_archives/archive.mtar --retries 1"

Option2.

Instead of a subaccount destination, you create a destination instance. Here is an example;

https://github.com/SAP-samples/fiori-tools-samples/blob/main/cap/cap-fiori-mta/mta.yaml#L104

How this differs to a subaccount destination is, the destination instance is bound to your MTA ID and any Fiori UI app that is also bound, can consume the destination. If the mta is removed from the CF instance, then the destination instance is also removed. It prevents destinations being shared at a subaccount level.

However, one question when following option 2, what if the properties are different per CF instance? Then you can use an mta extension;

https://help.sap.com/docs/btp/sap-business-technology-platform/defining-mta-extension-descriptors

This would allow you to overwrite/update the destination defined in your mta.yaml per cf instance, for example;

"deploy-cf-customer": "cf deploy mta_archives/archive.mtar -e mta-ext-mycustomer.mtaext --retries 1"
"deploy-cf-local": "cf deploy mta_archives/archive.mtar -e mta-ext-local.mtaext --retries 1"

The *.mtaext can be configured to reflect the different CF instances. An example of a mtaext file;

_schema-version: "3.2"
ID: test-mta-ext
extends: test-mta
version: 1.0.0

resources:
- name: test-destination-service
  parameters:
    config:
      init_data:
        instance:
          destinations:
          - Authentication: NoAuthentication
            Name: NorthwindProduct
            ProxyType: Internet
            Type: HTTP
            HTML5.DynamicDestination: true                       
            WebIDEEnabled: true
            WebIDEUsage: odata_abap
          existing_destinations_policy: update

These properties would need to reflect your security and proxytype per CF instance, this is a CAP based destination instance example;

https://github.com/SAP-samples/fiori-tools-samples/blob/main/cap/cap-fiori-mta/mta.yaml#L104

[Missschaaa]

Thanks jlongie nice comment. I got some questions.

First to be sure that ABAP deploy also works after some deploy to CF is done, we also have to duplicate the "run build" into some "run build-abap", right? As it looks that CF deploy puts some CF commands in build command?

"deploy-abap": "npm run build-abap && fiori deploy --config ui5-deploy-abap.yaml && rimraf archive.zip",

About the two options of customer CF deploy I'm not sure if I understood it correctly. Option 1 would be the way we do it at the moment I think. But in this case the customer destination in our system is only some kind of dummy, right? Without cloud connector and system configuration we canot access customer CF from our own BAS to test with data, right? (it's not needed btw) So putting the customer destination name in our own BTP is just to get it at the drop down when doing CF deploy? We can just put ABC in destination url, it would be no difference?

Option 2 sounds interesting but how can we generate this? Just change the naming in the mta.yaml manually or is there any guided menu to target an instance? What do you mean with when parameters differ? E.g. when we want to deploy one app to three CFs, one is our own and two separate customer CF. This would mean each CF destination would have a separate name and would point to a separate backend system. So in this case we must use extension?

And one last question about the destinations. With Basic Authentification, normally SAP user is given in the destination. It looks like that all user that consume the app then use this destination with the same user, so If you have an app that creates something in backend, it would be always the same sap creator even if in frontend launchpad different user created it?

Regards

Michael

[jlong]

You can manipulate the package.json commands to suit your needs.

deploy:abap is calling;

"deploy:abap": "npm run build && fiori deploy --config ui5-deploy.yaml -f && rimraf archive.zip",

and its only this command that references the build command so you dont need to change it but its your choice.

Lets not confuse local preview which reads your ui5.yaml to determine where to retrieve the OData service. This can be configured to point to any destination.

When deployed to CF then its the xs-app.json that determines where the OData service is retrieved from. So you could have a local preview pointing to your own ABAP backend, validate everything is working then deploy your app to CF but have the xs-app.json routing point to the customers destination, for example;

    {
      "source": "^/northwind/(.*)$",
      "target": "$1",
      "destination": "CustomersDestination"
    },

You can test the customers destination configuration independent of your application so at least you will have some level of confidence it will work when deployed to CF.

Refer to this link

https://ga.support.sap.com/dtp/viewer/index.html#/tree/3046/actions/45995:48363:53594:54336:51208

Just to be clear, there is no way to validate your xs-app.json settings until its deployed to CF which is why you can change the xs-app.json to be any value.

Hope this answers some of your questions.

John

[Missschaaa]

Hey John, sorry for the late answer. Just one question about the build again. You said its not necessary to switch the command to a build-abap command, but in our case package.json looks like

"build": "rimraf resources mta_archives && mbt build --mtar archive",
"deploy-cf": "cf deploy mta_archives/archive.mtar --retries 1", 
"build-abap": "ui5 build --config=ui5.yaml --clean-dest --dest dist",
"deploy": "fiori cfDeploy",
"deploy-abap": "npm run build-abap && fiori deploy --config ui5-deploy-abap.yaml && rimraf archive.zip",
"deploy-config": "fiori add deploy-config",

As you can see the build command is switched to some CF build. We always did first deploy to ABAP then deploy to CF as you said, but it looks like that deploy to CF switches the build command to some CF specific. So we need the special build-abap command right?

Other question after first deploy-abap command we sometimes get error "sh:1: rimraf: not found". Only after first doing the deploy-CF command and then again doing the deploy-abap command rimraf can be executed. So wheres the problem?

And last question again about CF. It looks like that when using the launchpad of Workzone standard edition in CF and sync data with backend that the connection always works about the user that is entered in the BTP destination that was chosen when doing CF deploy. This would lead that all user that use the app create data in backend with this user? How can this be changed? We need user specific creation especially when creating new data in SAP backend system.

Regards Michael

[WouterLemaire]

I think that multitenancy would be the better solutions here. What you are trying to do is providing an application to one or more customers as a cloud solution. Multitenancy is the solution for this, here you have a bit more information: Fundamentals of Multitenancy in SAP BTP | SAP Blogs

[Missschaaa]

Thanks for your answer, that's an interesting blog. If I understand it correctly pre-condition of this would be that we and customer share same infrastructure ressources for SAP Backend System? If so this is the problem which would not work. Customers all have their own SAP systems hosted on Cloud, classical On-Premise Backend, with S/4, without S/4, independent of our infrastructure.

[WouterLemaire]

Normally every customer will have his own BTP subaccount inside the same global account as you. Every customer can subscribe to your application in their subaccount. Inside their subaccount, they need to configure their own destination to their s4 system. In the end, every customer has his own subaccount with its own destination to their own system.

[Missschaaa]

Ok but this means administration, costs and everything that has to do with BTP is done by us? Normally our customers consume only a hand full of Apps from us but use their own BTP space for their own purposes.

[WouterLemaire]

that’s indeed the goal of multitenancy, share resources and lowering the costs. You can include this into the calculation of the monthly fee of your customers.

[junwu]

the deployment configuration is just a yaml file

you can manually add a new one.

Let's say you deploy to onpremise using:

"deploy": "npm run build && fiori deploy --config ui5-deploy.yaml && rimraf archive.zip",

you add another script call it "deployCF", which use another yaml file.

never tried myself, but i think it will work.

[Missschaaa]

Also thought at this and we will try. But it assumes that you always have to manually write the CF destination of customer which is not reachable in our own BTP (because not linked in our Cloud Connector) in the file, right? Or just create a dummy destination in our own CF analogous to the one in the cusomter CF.