Problem with CAP localized data

[JuanjoGersol]

Dear experts,

We are facing a problem since a couple of weeks in a service that has been running for almost two years now:

We have two services connected via CDS import where I'm exposing one entity to be used locally from the other service:

@readonly
entity Divisions                as projection on MD.Divisions;

Then I'm doing a basic selection:

 const division = await this.run(SELECT.one.from(this.entities.Divisions)
    .where({ division: t.division_division }));

When the framework expand the selection to build the query changes the * by a list of fields that come from the following structure in the cds.entities.Divisions.elements:

The two highlighted properties are the foreign keys of the automatic association localized. They do not belong to the Divisions entity and I have no idea why they are there.

We have a four systems landscape and we are facing this error in two of the system, I aligned package versions and the problem cannot be reproduced:

I checked for errors in the EDMX file we used on the cds import or in the csn.json file that points to these properties without success.

Can anyone support here?

Thanks,

Juanjo

[patricebender]

>The two highlighted properties are the foreign keys of the automatic association localized. They do not belong to the Divisions entity and I have no idea why they are there.

From the screenshot, it looks like the `texts` composition has no on-condition. Instead it looks like it has the `.keys` property, which essentially makes it a managed association. A managed association always materializes as foreign keys in the entity, where the association is defined. Usually, when you define a `localized` string, the cds-compiler creates an composition named "text" with a proper on-condition: 

entity Foo {
    key ID: Integer;
    description: localized String;
}

the above snippet expands to

// generated by cds-compiler version 4.9.1 
entity Foo {
  key ID : Integer;
  description : localized String;
  texts : Composition of many Foo.texts on texts.ID = ID;
  localized : Association to Foo.texts on localized.ID = ID and localized.locale = $user.locale;
};

@odata.draft.enabled : false
entity Foo.texts {
  key locale : String(14);
  @odata.containment.ignore : true
  key ID : Integer;
  description : String;
};

for me it looks like you are trying to define a `texts` composition by yourself. Please provide a sample repository with detailed steps to reproduce your issue, then I will have a look.

[JuanjoGersol · Accepted solution]

Hi @patricebender,

I'm sorry about the misunderstanding, my repository contains two CAP services under the /srv folder. This is required because the problem with the localized data comes from the usage of an external service.

The way to reproduce the problem is as follows:

Clone the repository:

git clone https://github.com/ofunkillo/CapLocalizationSample.git

Install packages in both services (trigger in two different consoles):

cd /srv/MasterData
npm install

cd /srv/BusinessPartner
npm install

 Launch the services (in two different consoles):

cd /srv/MasterData
cds w --port 4007

cd /srv/BusinessPartner
cds w --port 4004

Local access to divisions works as expected:
http://localhost:4007/MasterData/Divisions

Remote access to divisions doesn't work:
http://localhost:4004/BusinessPartner/Divisions

Thank you for your time,

Kind regards,

Juanjo

[patricebender · Accepted solution]

Hi, thanks, I have overseen this details. Oops! I have tried it out locally and came up with a way of getting your example work. With some manual work, the `Divsions_texts` can also be explicitly exposed in your BP service. Please have a look at my PR.

[JuanjoGersol · Accepted solution]

@patricebender thank you for the solution. It's clear now I was over complicating something that is for free thanks to the CDS compiler. For any other having problems with this check the respository and the patch with the small changes.

[JuanjoGersol]

Dear Patrice,

Thank you for your comments, you gave me a hint about what could be the problem.

It turns out that when we started the development of this project, two years ago, maybe at an early stage of the CAP framework, and maybe due to our lack of knowledge, we detected that the localized entities were not autoexposed so we exposed then manually in the service.cds of our CAP application:

entity Divisions_texts            as select from MD.Divisions.texts;

 This was done long time ago and has been working without issues until a couple of weeks ago. I think that removing this will fix the issue.

I'll remove and let you know.

Edit: The reason why the entity is exposed manually is that we have a UI application to maintain the translations. For that reason, autoexposed entities that are by default readonly were not valid so we exposed them manually, it seems the way we are doing it is now causing issues. Keep on investigating. Will update if I find the reason. 

Thank you,

[JuanjoGersol]

@patricebender I have created a demo project in this repository.

To reproduce the specific architecture of my case I have added two separated cap services:

MasterData contains entity division which is a CodeList that contains attributes name and descr that are localized. As we plan to maintain the translations with a UI app we manually expose the entities in the service:

using {MasterDataDb as MD} from '../db/MasterData';

@(path: '/MasterData')

service MasterData {
    entity Divisions as select from MD.Divisions;
    entity Divisions_texts as projection on MD.Divisions.texts;
}

MasterData service should be launched on port 4007 with:

cds w --port 4007

You can access locally to both the Divisions and their texts:

http://localhost:4007/MasterData/Divisions	http://localhost:4007/MasterData/Divisions('1')/texts

On the BusinessPartner service we included the Divisions as external entity to allow the association:

using {
  cuid,  
  managed
} from '@sap/cds/common';

namespace BusinessPartnerDb;

using { MasterData as MD } from '../srv/external/MasterData';

entity BusinessPartners : cuid, managed {
  name: String;
  division : Association to one MD.Divisions;
}

@readonly entity Divisions as projection on MD.Divisions;
@readonly entity Divisions.texts as projection on MD.Divisions_texts;

Pleas note that the maintenance will be done directly on the MD service so on the BP we expose the entities as readonly.

As the expand to an external service is not directly executed by CAP we implemented the ON event handler for the read operation:

module.exports = cds.service.impl(async function businessPartnerService() {
    /**
  * External entities read for masterData service
  */
  this.on('READ', 'Divisions', async (req) => {
    
    // Instance the external service
    const md = await cds.connect.to('MasterData');    
    // Execute the query
    return md.run(req.query);
  });
});

If you trigger the BusinessPartner service with:

cds w --port 4004

And then try to open the Divisions entity from the BP service you will get the error I'm reporting:

As I mentioned earlier, the project has been working fine with this architecture for almost 2 years, and only recently we have started receiving this error, so we think the reason could be related to a package upgrade. We have two system where it's working right now and two systems where it's crashing.

Thank you for support.

Kind regards,

[patricebender]

Hi Juanjo, thanks for your detailed report. I will have a look as soon as possible, we have a lot on our plate right now.

[patricebender]

Hi, I'm sorry, but with your sample repo I was not able to reproduce the issue.

That is not a valid CAP project. Please add a `package.json` and detailed steps to reproduce.