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]

@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.