How to change service-name at deploy time for Cross Container project

[mike_howles4]

Hello all,

I am working on a project where I want one single HDI DB Module that contains common Master Data-like Dimension Calculation Views. My idea is to keep these commonly used views reusable via Cross-container access to more business-specific DB Modules that have reporting Calculation Views of their own but can join against the Master Data Dimension Views. I've got this working somewhat by following this tutorial:

https://developers.sap.com/tutorials/xsa-cross-container-access.html

What I am not clear on is how can I define a service-name for the consumed-db that may have a different name? For instance the example in the tutorial uses the build-time service name which would look like RHOWLES-9skqv35et1oio3vg-SflightExample-hdi_db_sflight however at deploy time, will be hdi_db_sflight. We develop in a DEVELOPMENT space and deploy in a DEPLOY space, so I do not think I will have visibility during development to make reference to hdi_db_sflight.

Sample YAML:

ID: SflightCrossContainerExample
_schema-version: '2.0'
version: 0.0.1

modules:
 - name: db_sflight_cc_example
   type: hdb
   path: db_sflight_cc_example
   requires:
    - name: hdi_db_sflight_cc_example
      properties:
        TARGET_CONTAINER: '~{hdi-container-name}'
    - name: consumed-md-container
      group: SERVICE_REPLACEMENTS
      properties:
        key: consumed-db
        service: '~{consumed-service-name}'

resources:
 - name: hdi_db_sflight_cc_example
   parameters:
      config:
         schema: SFLIGHT_CC_EXAMPLE
   properties:
      hdi-container-name: ${service-name}
   type: com.sap.xs.hdi-container

 - name: consumed-md-container
   type: org.cloudfoundry.existing-service
   parameters:
      service-name: RHOWLES-9skqv35et1oio3vg-SflightExample-hdi_db_sflight
   properties:
      consumed-service-name: '${service-name}'

Is this something I would be able to achieve with xs deploy flags, or something I have to do in a mtad.yaml deployment descriptor?

Thanks for any help.

[thomas_jung · Accepted solution]

>As mentioned, our development build-time is in a DEVELOPMENT space, but our deployed objects are in DEPLOY space.

But that's just a rule you came up with. And one I'd say is wrong. You should deploy you MTAs into the DEVELOPMENT space as well to provide stable versions of containers for other developers to work with.

[mike_howles4 · Accepted solution]

> But that's just a rule you came up with. And one I'd say is wrong.

Noted. We will change our approach as a result. (And stop listening too closely to Max Attention trainers.)

Thank you for your time.

[former_member604919]

Hi, I have not successfully deploy the container to DEV space. I am able to build and run it, but not able to deploy to DEV space. I posted a question here. Thanks for your help!

Regards

Ferry

[thomas_jung]

Why not just take the first suggestion - don't point to the temporary service name at all. Always deploy the foreign container for real in the Dev system and only reference that name. That way you mta.yaml is always consistent. That's the "right" way.

[mike_howles4]

That's a good point but isn't the limitation then that the deployed target container must exist in the same Space as the consuming container? As mentioned, our development build-time is in a DEVELOPMENT space, but our deployed objects are in DEPLOY space. I didn't think that cross-container access could see across spaces?

[chathia]

Thanks for the hint! However, the only concern is the "deploy" action consumes about 5+ minutes (sometimes even more) with the kind of modules in it. Not a quick way to test the changes after the "build", but as you said this would ensure the consistency. Thank you!

[thomas_jung]

You really shouldn't use build time service names in your cross container references. I would imagine the tutorial just does this to keep the scenario simple. Even in development a container should be deployed after it is fully tested so a "Real" version can be used for cross container purposes.

However if you really needed to change such a value at deploy time, you could do it by overriding the value with an mtaext file.

[mike_howles4]

Hey Thomas,

"You really shouldn't use build time service names in your cross container references."

This is precisely what I am trying to avoid. I did run across .mtaext documentation yesterday (https://help.sap.com/viewer/4505d0bdaf4948449b7f7379d24d0f0d/2.0.03/en-US/51ac525c78244282919029d8f5...) , however I was not able to use it successfully because I think of this caveat:

You can use the MTA deployment extension descriptor to add the following information (at deployment time) to an MTA deployment descriptor:

• A property element, for example, a new property or parameter.
• A value for a property that does not already have a valued defined

Since during develop/build time, I am wanting to have it build successfully, I can point to a design-time or its deployed equivalent (assuming that it has also been deployed) but it sounds like the .mtaext requires that I remove the existing service-name parameter from the mta.yaml in order for it to be used? Perhaps if we had Jenkins or some other CI/CD framework in place, it could strip that out from the .mtar for me, but we are in the early adoption phase of XSA so our deploys are currently simple xs cli statements.

Am I missing a way for a mtaext to override an in-place property in mta.yaml? My novice attempt at a .mtaext follows:

_schema-version: '2.0'
ID: SflightCrossContainerExample.config
extends: SflightCrossContainerExample


resources:
 - name: consumed-md-container
   properties:
      consumed-service-name: db_sflight
<br>

And another slightly different attempt that failed:

_schema-version: '2.0'
ID: SflightCrossContainerExample.config
extends: SflightCrossContainerExample


resources:
 - name: consumed-md-container
   parameters:
      service-name: db_sflight
   properties:
      consumed-service-name: '${service-name}'

Even with xs deploy file.mtar -e extension.mtaext, it still is picking up the service referenced in mta.yaml instead.