In EventHubMessagingService, the value of ce-source is build by appending the current "tenant" when using the multi-tenant plan of the service (see method emitTopicMessage). This tenant is retrieved from UserInfo.getTenant() which (at least when using XSUAA) corresponds to the zid claim.
There is also some fallback logic, but this usually is not applicable. See https://github.com/cap-java/cds-feature-event-hub/blob/main/cds-feature-event-hub/src/main/java/com/sap/cds/feature/messaging/eventhub/service/EventHubMessagingService.java#L155
On the other hand, from what we heard. the suffix of ce-source must correspond to the system ID in the Global Account systems list of the corresponding SaaS app subscription. Which for BTP is defaulted to the subaccountId (which is sometimes different from the tenantId). What should we do if this is not the case?
In EventHubMessagingService, the value of ce-source is build by appending the current "tenant" when using the multi-tenant plan of the service (see method emitTopicMessage). This tenant is retrieved from UserInfo.getTenant() which (at least when using XSUAA) corresponds to the zid claim.
There is also some fallback logic, but this usually is not applicable. See https://github.com/cap-java/cds-feature-event-hub/blob/main/cds-feature-event-hub/src/main/java/com/sap/cds/feature/messaging/eventhub/service/EventHubMessagingService.java#L155
On the other hand, from what we heard. the suffix of ce-source must correspond to the system ID in the Global Account systems list of the corresponding SaaS app subscription. Which for BTP is defaulted to the subaccountId (which is sometimes different from the tenantId). What should we do if this is not the case?