[ERROR] cds.compile failed
Urrggh, what terrible beginning of a tutorial...
Today let’s start with an error message. Please read:
Association "<yourServiceName>.<yourExposedEntity><yourAssociationName>" cannot be implicitly redirected
What???
Just a second, the error message continues:
Target "<yourDefinedEntity>" is exposed in service "<yourServiceName>" by multiple projections: "<yourService>.<yourExposedEntity1>", "<yourService>.<yourExposedEntity2>"
I don’t understand a word.
Yes, thank you. That's why you're here.
I don't know why I'm here, I’m losing my time in this cabaret
In this blog we’re going to explain the error
<ironic>oh how great...</ironic>
and provide you with the solution
Ah, great ! <muted> I'll bear the cabaret</muted>
But before we start, here comes the usual necessary link
I know it by heart
for those who don’t know what it is all about: the series of tutorials for new users of SAP Cloud Platform Backend service
Background:
Imagine, you’ve invested lot of effort in order to design a sophisticated model.
Then you happily go to generate an API – but you get the above error message (can be viewed when pressing the “logs” icon)
Of course, you don’t understand a word – we’ve already proven that (see above)
But don’t panic – you’re not alone, you have my blogs.
Experts can jump to the solution
Let’ start from the beginning to explain what this is all about.
No, let’s start from the end: you have a web application.
The web application allows to select animals from your pet shop.
Nice, I chose a cat
Of course, everybody wants a cute kitty
Application layer: the web app
Back to your app
Your web application has 2 lists:
- Normal animals
- Dangerous animals
In order to implement this requirement ( 2 lists of animals), the app can do the following (assuming that the app uses an OData service like PetShopService😞
1. Normal usage of one service collection with filter
2. But there’s another possibility:
This second possibility is more convenient and has probably better performance
But: it has to be implemented by the OData service
Note:
When talking about using an application, we always refer to the runtime.
The app uses a running service to fetch the data
Next layer: the OData service
At runtime, we access an URL, according to the OData service definition.
The URL is composed based on the entity sets, which are exposed by the OData service
As described above, the app has a requirement towards the OData service.
The requirement is:
There should be one data storage for all animals
The service should offer 2 modes of accessing it
More detailed:
The OData service should define 2 entity sets:
<EntitySet Name=”AnimalCollection”/>
<EntitySet Name=”DangerousAnimalCollection”/>
If the app doesn't define a filter, then how do we get the really dangerous animals, like cats?
Correct, such a requirement must be implemented in the service itself, in the java code (up to now always java code) which is running on the server
It is like a hard-coded filter
Do we want that?
Yes, we want the app to be lightweight, only UI, instead, move most of the logic to the java implementation.
Talking about java implementation, there are (again) 2 possibilities how to implement the filter:
1. Fetch all animals from database, then do the filtering in the java code
2. Fetch only dangerous animals from database
The second possibility is again faster, because no useless data is fetched at all
E.g. using a different SQL statement on the database
This leads us to the next layer:
Next layer: database
Ouh - I always heard that Backend service handles the database?
Good point, we don't touch any database, but we define the model which leads to the generation of database tables
Remember what we said above:
"one data storage for all animals"
"2 modes of accessing it"
To express this in CDS:
In the data model, we define one entity
In the service definition, we expose 2 entities as projection on the same datamodel-entity
Going further, we can say that the data model is like defining the designtime artifacts, the names of tables and columns to be generated later, during deployment.
And we can say that in the service definition we express how we want the generated service to behave at runtime.
Again:
In the data model, we define one entity
entity AnimalEntity { . . . }
in the service definition, we expose 2 entities as projection on the same datamodel-entity
entity AnimalCollection as projection on AnimalEntity;
entity DangerousAnimalCollection as projection on AnimalEntity;
Next layer: ...
There's no next layer for us.
Summarizing:
We've learned why it can make sense to define a model that has one entity exposed by 2 projections.
With other words, defining a service exposing 2 entities that are projections on the same datamodel-entity.
We can go ahead and create an API based on this simple CDS model:
Note:
The select statement is explained in the previous tutorial
In order to test, we execute these URLs:
https://.../odatav4/DEFAULT/PETSHOPSERVICE/AnimalCollection
The result: all animals:
If there was no second collection, we would have to do this filter:
https://.../PETSHOPSERVICe/AnimalCollection?$filter=isDangerous EQ true
The result: only dangerous animals:
Last test: the 2nd collection, for convenience:
https://.../PETSHOPSERVICE/DangerousAnimalCollection
As expected, the result payload is the same as in the previous test:
We're done with this chapter.
Have we learned anything new???
Honestly: no, nothing.
But this chapter was necessary to explain the requirement and to understand the difference between designtime artifacts and runtime behavior
This is prerequisite for understanding the initial ERROR message
Again, in this chapter there won’t be anything new.
Again?? Why are we advancing so slowly?
I like to make slow progress, small steps, but have clear understanding
Now we create a new example model: 2 entities with association
We have a list of "Products"
Each "Product" is supplied by a "Supplier"
A "Supplier" is a "BusinessPartner"
Or: a "Supplier" is a concrete term for a generic "BusinessPartner"
We have an association, which allows us at runtime to navigate from a selected "Product" to its "Supplier" (in OData: NavigationProperty)
This is the model, in its first simple stage:
You may test this API if you like.
Would I learn anything new???
Honestly: no, nothing.
...But?
Honestly: no but
Now we add one more aspect to our model:
The "SalesOrder"
The "SalesOrder" is created for a "Customer".
Again, a "Customer" is just a special type of "BusinessPartner"
As such, we don't need a new entity "CustomerEntity" in the data model.
Instead, that’s why the "BusinessPartnerEntity" has property “type”.
The value for this "type" property can be only “Supplier” or ”Customer”, in order to distinguish if the instance at runtime is acting as customer or as supplier.
Note:
This is maybe not the best design, but useful for our tutorial
The "SalesOrder" has an association to the "BusinessPartner" (which is a "Customer") to allow to navigate from the "SalesOrder" to the "Customer" for whom is was created.
So, we add the following entity to our data model:
entity SalesOrderEntity {
key salesOrderId : Integer;
description : String;
linkToCustomer : Association to BusinessPartnerEntity;
}
Anything new?
Be quiet please
Since we are customer-friendly and keeping in mind that there will be application developers using our API, we directly define 2 projections for the runtime:
One for the "Suppliers", another one for the "Customers"
Both point to the same entity, the "BusinessPartnerEntity", both define a filter
entity Customers as select from BusinessPartnerEntity {*}
where type = 'Customer';
entity Suppliers as select from BusinessPartnerEntity {*}
where type = 'Supplier';
...new?
No, the select statement was introduced in this tutorial
OK, looks all good for us.
But ....
But if we attempt to create an API in Backend service, then we get the infamous ERROR above.
Here’s the full (invalid) model, in case you like to try the error:
Explaining the error.
I believe, with what we've learned before, it is easy to understand the error.
At designtime (or modeltime), we define an association from "SalesOrderEntity" to "BusinessPartnerEntity".
At runtime (when running the OData service), we have an instance of "SalesOrders". It is an EntitySet which points to the "SalesOrders" EntityType
According to the association defined above (SalesOrder -> BusinessPartner) , we want to navigate from one instance of "SalesOrders" to an EntitySet which points to "BusinessPartnerEntity".
But there are 2 EntitySets pointing to "BusinessPartnerEntity": "Customers" and "Suppliers".
Which one is the correct one?
As such, at runtime, there would be an error.
The specification of OData has foreseen such cases.
That’s why OData has the concept of <Association> and <AssociationSet> in OData V2.
One is for defining associations between EntityTypes, the other one is to specify the association between EntitySets.
In OData V4 there are <NavigationProperty> and <NavigationPropertyBinding>, respectively
And now it comes:
CDS has foreseen the same.
And it has a solution: the redirected to statement
One of the differences between OData and CDS is the magic:
In OData you have to always define the <AssociationSet> for an <Association>
In CDS, you need the redirected to statement only if it is needed
CDS is intelligent enough to throw a compilation error, if the redirected to statement is required but missing.
And that's the initial ERROR.
Anything new?
OK, thanks, all this is new to me
And now, let's read the error message again:
[ERROR] cds.compile failed:
at petshopModel.cds:22:25-26:
Association "SalesOrderService.Products.linkToSupplier"
cannot be implicitly redirected:
Target "BusinessPartnerEntity" is exposed in service "SalesOrderService" by multiple projections:
"SalesOrderService.Customers", "SalesOrderService.Suppliers"
at petshopModel.cds:22:25-26:
Association "SalesOrderService.Products.linkToSupplier"
must be redirected:
Target "BusinessPartnerEntity" is not exposed
by service "SalesOrderService"
Cool, I understand
This is how it is done:
entity SalesOrders as projection on SalesOrderEntity {
*,
linkToCustomer : redirected to Customers
};
In the projection, we have to declare the association to be redirected to the correct (runtime-) entity.
Moreover, we have to repeat the declaration of all properties, e.g. via asterisk, like done above.
Note:
Don't forget the asterisk, otherwise you'll get an error: no key defined.
Reason is that in this kind of definition, you have to list all properties which you want.
Note:
The CDS-validation in the CDS-editor in Visual Studio Code is intelligent enough to throw an error if we specify a redirected to statement pointing to an invalid entity.
The screenshot below shows it:
I’ve specified the “Products” entity, which is existing, but it doesn’t point to "BustinessPartnerEntity"
This is the meaning of the validation error message.
Here’s the full (correct) model:
We can go ahead and create an API based on the above correct CDS model
This will help us to understand more in depth.
Let’s start with creating a couple of "Suppliers"
{
"id": 111,
"name": "supplier1",
"type": "Supplier"
}
Create some "Customers"
Note that the id must be different from the created supplier
Why? Have you already forgotten that we modelled: "Suppliers" and "Customers" are redirecting to same table ("BusinessPartnerEntity")
{
"id": 222,
"name": "customer1",
"type": "Customer"
}
Create some "Products".
Note that the value of property “linkToSupplier_id” must be valid. It must be the id of an existing "Supplier", created before
{
"productId": 1,
"productName": "product1",
"linkToSupplier_id": 111
}
Create some "SalesOrders" like this:
{
"salesOrderId": 1,
"description": "sold some stuff",
"linkToCustomer_id": 222
}
Afterwards we can
have a look at the 2 entity sets which point to the same (hidden) "BusinessPartnerEntity" table:
https://.../SERVICE/Suppliers
Result:
And:
https://.../SERVICE/Customers
Result:
Now we can try the navigation:
https://.../SERVICE/SalesOrders(1)/linkToCustomer
Result: we’re taken to the "Customer" which we created before.
And the other navigation
https:///SERVICE/Products(1)/linkToSupplier
Result
Let’s view how our CDS model and redirects have been translated to OData.
First, we view the metadata in OData version 4
Interesting to note:
Maybe it is a bit surprising that we have 4 EntityTypes instead of 3.
It would have been possible to have one "BusinessPartnerEntity" EntityType and two EntitySets pointing to it (like realized in CDS)
However, for the OData metadata generation, the only relevant input is the CDS service definition.
There, we have 4 entities.
From this perspective it makes sense.
Respectively, in the OData metadata, 2 EntityTypes are identical, guess which ones?
Yawn...
Furthermore, you can see that the CDS Association has a corresponding NavigationProperty in OData.
And you can see that in OData we have always a NavigationPropertyBinding attached to an EntitySet, not only when needed.
Now let’s have a quick view on the OData V2 metadata.
First thing to note:
the metadata document in V2 is longer than the V4
You can see an additional artifact: the Association, defined on same level like EntityType
The Association connects 2 EntityTypes to each other
The EntityType has in addition a NavigationProperty, which points to the Association
Why the NavigationProperty is needed?
Well, it is used when composing the URL, e.g. https:///SERVICE/Products(1)/linkToSupplier
For the runtime part, there’s the additional artifact AssociationSet, it corresponds to the Association and connects 2 EntitySets to each other
This is the OData-V2-way of solving the redirect-problem
Above, We’ve said that the data for both EntitySets and both EntityTypes is persisted in one table.
When looking at the OData metadata, there’s nowhere any info about one common table for 2 different EntityTypes ("Customers" and "Suppliers")
But what I said is correct.
There's only one database table.
Full stop.
Can you prove it?
Yes, I can: 2 proves.
Prove 1:
In the test section above, we’ve created a "Customer" with id 222 and a "Supplier" with id 111
Now try to create a "Supplier" with id 222
It will fail, because that id already exists.
As such: it is proven that we have only one common database table
You can try…
Yes, I’ve tried, correct... I don’t need a second prove...
Prove 2:
As you know, while generating the API, the Backend service application does a compilation step (you can see it in the API Deployment Logs dialog)
This compilation generates the OData metadata files (resp. edmx files for OData v4 and v2)
But this compilation also generates the descriptor files for the HANA DB (currently the underlying database)
If you could look at these files, you would see that there’s
one entity BUSINESSPARTNERENTITY,
but 2 views SALESORDERSERVICE_CUSTOMERS and SALESORDERSERVICE_SUPPLIERS, both views pointing to the same entity
In total, there are 3 entities and 4 views.
The Java implementation of the OData service works on the views, so everything is fine.
How can I verify this prove?
If you’re lucky, I will show you in a future tutorial how to view these hidden artifacts.
When?
Don't know
Then this prove is not valid
Yes it is
No
Yes
No
Enough, we still have prove 1
OK ok
We know that CDS is powerful and intelligent…
From what we read in the initial ERROR message, we assume that in the normal case, the redirect is done implicitly by CDS
Pure magic
In normal associations, if we don’t define a “redirected to”, then it is still done implicitly by CDS
This means, we should be able to write it, even if not required.
So tet’s try to make it explicit, then see what happens.
This example (based on the example in stage 2) shows it:
Note:
the explicit redirect is not necessary, because:
In the above model, we don't have 2 projections on same entity, involved with association
You can create an API based on this model and you’ll see that it works, it compiles and works exactly same way like the example without explicit redirect. (stage 2)
I like to have an appendix with the full sample model.
So here it is:
Sorry, I forgot to mention that the naming I chose for the CDS elements are not recommendable. I chose those names only for better understanding.
You shouldn't use naming like "linkToAnything" or ending with suffix "...Entity"
I feel like I owe you another appendix with another kitty....
Urrggh, what terrible beginning of a tutorial...
Today let’s start with an error message. Please read:
Association "<yourServiceName>.<yourExposedEntity><yourAssociationName>" cannot be implicitly redirected
What???
Just a second, the error message continues:
Target "<yourDefinedEntity>" is exposed in service "<yourServiceName>" by multiple projections: "<yourService>.<yourExposedEntity1>", "<yourService>.<yourExposedEntity2>"
I don’t understand a word.
Yes, thank you. That's why you're here.
I don't know why I'm here, I’m losing my time in this cabaret
In this blog we’re going to explain the error
<ironic>oh how great...</ironic>
and provide you with the solution
Ah, great ! <muted> I'll bear the cabaret</muted>
But before we start, here comes the usual necessary link
I know it by heart
for those who don’t know what it is all about: the series of tutorials for new users of SAP Cloud Platform Backend service
Background:
Imagine, you’ve invested lot of effort in order to design a sophisticated model.
Then you happily go to generate an API – but you get the above error message (can be viewed when pressing the “logs” icon)
Of course, you don’t understand a word – we’ve already proven that (see above)
But don’t panic – you’re not alone, you have my blogs.
Experts can jump to the solution
Stage 1: Why define 2 entity sets for one entity type?
Let’ start from the beginning to explain what this is all about.
No, let’s start from the end: you have a web application.
The web application allows to select animals from your pet shop.
Nice, I chose a cat
Of course, everybody wants a cute kitty
Application layer: the web app
Back to your app
Your web application has 2 lists:
- Normal animals
- Dangerous animals
In order to implement this requirement ( 2 lists of animals), the app can do the following (assuming that the app uses an OData service like PetShopService😞
1. Normal usage of one service collection with filter
- Call the service for all animals:host.../<service>/animalCollection
- Call the service and filter only dangerous animals:host.../<service>/animalCollection?$filter=isDangerous EQ ‘true’
2. But there’s another possibility:
- Like before, call the same collection to get all animalshost.../<service>/AnimalCollection
- Call a separate collection for only dangerous animalshost.../<service>/DangerousAnimalCollection
This second possibility is more convenient and has probably better performance
But: it has to be implemented by the OData service
Note:
When talking about using an application, we always refer to the runtime.
The app uses a running service to fetch the data
Next layer: the OData service
At runtime, we access an URL, according to the OData service definition.
The URL is composed based on the entity sets, which are exposed by the OData service
As described above, the app has a requirement towards the OData service.
The requirement is:
There should be one data storage for all animals
The service should offer 2 modes of accessing it
More detailed:
The OData service should define 2 entity sets:
<EntitySet Name=”AnimalCollection”/>
<EntitySet Name=”DangerousAnimalCollection”/>
If the app doesn't define a filter, then how do we get the really dangerous animals, like cats?
Correct, such a requirement must be implemented in the service itself, in the java code (up to now always java code) which is running on the server
It is like a hard-coded filter
Do we want that?
Yes, we want the app to be lightweight, only UI, instead, move most of the logic to the java implementation.
Talking about java implementation, there are (again) 2 possibilities how to implement the filter:
1. Fetch all animals from database, then do the filtering in the java code
2. Fetch only dangerous animals from database
The second possibility is again faster, because no useless data is fetched at all
E.g. using a different SQL statement on the database
This leads us to the next layer:
Next layer: database
Ouh - I always heard that Backend service handles the database?
Good point, we don't touch any database, but we define the model which leads to the generation of database tables
Remember what we said above:
"one data storage for all animals"
"2 modes of accessing it"
To express this in CDS:
In the data model, we define one entity
In the service definition, we expose 2 entities as projection on the same datamodel-entity
Going further, we can say that the data model is like defining the designtime artifacts, the names of tables and columns to be generated later, during deployment.
And we can say that in the service definition we express how we want the generated service to behave at runtime.
Again:
In the data model, we define one entity
entity AnimalEntity { . . . }
in the service definition, we expose 2 entities as projection on the same datamodel-entity
entity AnimalCollection as projection on AnimalEntity;
entity DangerousAnimalCollection as projection on AnimalEntity;
Next layer: ...
There's no next layer for us.
Summarizing:
We've learned why it can make sense to define a model that has one entity exposed by 2 projections.
With other words, defining a service exposing 2 entities that are projections on the same datamodel-entity.
Testing the example
We can go ahead and create an API based on this simple CDS model:
entity AnimalEntity {
key id: Integer;
species : String;
isDangerous : Boolean;
}
service PetShopService {
entity AnimalCollection as projection on AnimalEntity;
entity DangerousAnimalCollection as select from AnimalEntity {*}
where isDangerous = true;
}
Note:
The select statement is explained in the previous tutorial
In order to test, we execute these URLs:
https://.../odatav4/DEFAULT/PETSHOPSERVICE/AnimalCollection
The result: all animals:
If there was no second collection, we would have to do this filter:
https://.../PETSHOPSERVICe/AnimalCollection?$filter=isDangerous EQ true
The result: only dangerous animals:
Last test: the 2nd collection, for convenience:
https://.../PETSHOPSERVICE/DangerousAnimalCollection
As expected, the result payload is the same as in the previous test:
We're done with this chapter.
Have we learned anything new???
Honestly: no, nothing.
But this chapter was necessary to explain the requirement and to understand the difference between designtime artifacts and runtime behavior
This is prerequisite for understanding the initial ERROR message
Stage 2: Adding associations
Again, in this chapter there won’t be anything new.
Again?? Why are we advancing so slowly?
I like to make slow progress, small steps, but have clear understanding
Now we create a new example model: 2 entities with association
We have a list of "Products"
Each "Product" is supplied by a "Supplier"
A "Supplier" is a "BusinessPartner"
Or: a "Supplier" is a concrete term for a generic "BusinessPartner"
We have an association, which allows us at runtime to navigate from a selected "Product" to its "Supplier" (in OData: NavigationProperty)
This is the model, in its first simple stage:
entity ProductEntity {
key productId: Integer;
productName : String;
linkToSupplier : Association to BusinessPartnerEntity;
}
entity BusinessPartnerEntity {
key id : Integer;
name : String;
type : String; // value can be "Customer" or "Supplier"
}
service SalesOrderService {
entity Products as projection on ProductEntity;
entity BusinessPartners as projection on BusinessPartnerEntity;
}You may test this API if you like.
Would I learn anything new???
Honestly: no, nothing.
...But?
Honestly: no but
Stage 3: The error
Now we add one more aspect to our model:
The "SalesOrder"
The "SalesOrder" is created for a "Customer".
Again, a "Customer" is just a special type of "BusinessPartner"
As such, we don't need a new entity "CustomerEntity" in the data model.
Instead, that’s why the "BusinessPartnerEntity" has property “type”.
The value for this "type" property can be only “Supplier” or ”Customer”, in order to distinguish if the instance at runtime is acting as customer or as supplier.
Note:
This is maybe not the best design, but useful for our tutorial
The "SalesOrder" has an association to the "BusinessPartner" (which is a "Customer") to allow to navigate from the "SalesOrder" to the "Customer" for whom is was created.
So, we add the following entity to our data model:
entity SalesOrderEntity {
key salesOrderId : Integer;
description : String;
linkToCustomer : Association to BusinessPartnerEntity;
}
Anything new?
Be quiet please
Since we are customer-friendly and keeping in mind that there will be application developers using our API, we directly define 2 projections for the runtime:
One for the "Suppliers", another one for the "Customers"
Both point to the same entity, the "BusinessPartnerEntity", both define a filter
entity Customers as select from BusinessPartnerEntity {*}
where type = 'Customer';
entity Suppliers as select from BusinessPartnerEntity {*}
where type = 'Supplier';
...new?
No, the select statement was introduced in this tutorial
OK, looks all good for us.
But ....
But if we attempt to create an API in Backend service, then we get the infamous ERROR above.
Here’s the full (invalid) model, in case you like to try the error:
entity ProductEntity {
key productId: Integer;
productName : String;
linkToSupplier : Association to BusinessPartnerEntity;
}
entity SalesOrderEntity {
key salesOrderId : Integer;
description : String;
linkToCustomer : Association to BusinessPartnerEntity;
}
entity BusinessPartnerEntity {
key id : Integer;
name : String;
type : String; // value can be "Customer" or "Supplier"
}
service SalesOrderService {
entity Products as projection on ProductEntity ;
entity SalesOrders as projection on SalesOrderEntity;
entity Customers as select from BusinessPartnerEntity {*} where type = 'Customer';
entity Suppliers as select from BusinessPartnerEntity {*} where type = 'Supplier';
}
Explaining the error.
I believe, with what we've learned before, it is easy to understand the error.
At designtime (or modeltime), we define an association from "SalesOrderEntity" to "BusinessPartnerEntity".
At runtime (when running the OData service), we have an instance of "SalesOrders". It is an EntitySet which points to the "SalesOrders" EntityType
According to the association defined above (SalesOrder -> BusinessPartner) , we want to navigate from one instance of "SalesOrders" to an EntitySet which points to "BusinessPartnerEntity".
But there are 2 EntitySets pointing to "BusinessPartnerEntity": "Customers" and "Suppliers".
Which one is the correct one?
As such, at runtime, there would be an error.
The specification of OData has foreseen such cases.
That’s why OData has the concept of <Association> and <AssociationSet> in OData V2.
One is for defining associations between EntityTypes, the other one is to specify the association between EntitySets.
In OData V4 there are <NavigationProperty> and <NavigationPropertyBinding>, respectively
And now it comes:
CDS has foreseen the same.
And it has a solution: the redirected to statement
One of the differences between OData and CDS is the magic:
In OData you have to always define the <AssociationSet> for an <Association>
In CDS, you need the redirected to statement only if it is needed
CDS is intelligent enough to throw a compilation error, if the redirected to statement is required but missing.
And that's the initial ERROR.
Anything new?
OK, thanks, all this is new to me
And now, let's read the error message again:
[ERROR] cds.compile failed:
at petshopModel.cds:22:25-26:
Association "SalesOrderService.Products.linkToSupplier"
cannot be implicitly redirected:
Target "BusinessPartnerEntity" is exposed in service "SalesOrderService" by multiple projections:
"SalesOrderService.Customers", "SalesOrderService.Suppliers"
at petshopModel.cds:22:25-26:
Association "SalesOrderService.Products.linkToSupplier"
must be redirected:
Target "BusinessPartnerEntity" is not exposed
by service "SalesOrderService"
Cool, I understand
Stage 4: The solution: the redirect statement
This is how it is done:
entity SalesOrders as projection on SalesOrderEntity {
*,
linkToCustomer : redirected to Customers
};
In the projection, we have to declare the association to be redirected to the correct (runtime-) entity.
Moreover, we have to repeat the declaration of all properties, e.g. via asterisk, like done above.
Note:
Don't forget the asterisk, otherwise you'll get an error: no key defined.
Reason is that in this kind of definition, you have to list all properties which you want.
Note:
The CDS-validation in the CDS-editor in Visual Studio Code is intelligent enough to throw an error if we specify a redirected to statement pointing to an invalid entity.
The screenshot below shows it:
I’ve specified the “Products” entity, which is existing, but it doesn’t point to "BustinessPartnerEntity"
This is the meaning of the validation error message.
Here’s the full (correct) model:
entity ProductEntity {
key productId: Integer;
productName : String;
linkToSupplier : Association to BusinessPartnerEntity;
}
entity SalesOrderEntity {
key salesOrderId : Integer;
description : String;
linkToCustomer : Association to BusinessPartnerEntity;
}
entity BusinessPartnerEntity {
key id : Integer;
name : String;
type : String; // value can be "Customer" or "Supplier"
}
service SalesOrderService {
entity Products as projection on ProductEntity {
*, // don't forget to add all other properties e.g. via asterisk
linkToSupplier : redirected to Suppliers
};
entity SalesOrders as projection on SalesOrderEntity {
*,
linkToCustomer : redirected to Customers
};
entity Customers as select from BusinessPartnerEntity {*} where type = 'Customer';
entity Suppliers as select from BusinessPartnerEntity {*} where type = 'Supplier';
}Testing the runtime behavior
We can go ahead and create an API based on the above correct CDS model
This will help us to understand more in depth.
Let’s start with creating a couple of "Suppliers"
{
"id": 111,
"name": "supplier1",
"type": "Supplier"
}
Create some "Customers"
Note that the id must be different from the created supplier
Why? Have you already forgotten that we modelled: "Suppliers" and "Customers" are redirecting to same table ("BusinessPartnerEntity")
{
"id": 222,
"name": "customer1",
"type": "Customer"
}
Create some "Products".
Note that the value of property “linkToSupplier_id” must be valid. It must be the id of an existing "Supplier", created before
{
"productId": 1,
"productName": "product1",
"linkToSupplier_id": 111
}
Create some "SalesOrders" like this:
{
"salesOrderId": 1,
"description": "sold some stuff",
"linkToCustomer_id": 222
}
Afterwards we can
have a look at the 2 entity sets which point to the same (hidden) "BusinessPartnerEntity" table:
https://.../SERVICE/Suppliers
Result:
And:
https://.../SERVICE/Customers
Result:
Now we can try the navigation:
https://.../SERVICE/SalesOrders(1)/linkToCustomer
Result: we’re taken to the "Customer" which we created before.
And the other navigation
https:///SERVICE/Products(1)/linkToSupplier
Result
The OData metadata
Let’s view how our CDS model and redirects have been translated to OData.
First, we view the metadata in OData version 4
Interesting to note:
Maybe it is a bit surprising that we have 4 EntityTypes instead of 3.
It would have been possible to have one "BusinessPartnerEntity" EntityType and two EntitySets pointing to it (like realized in CDS)
However, for the OData metadata generation, the only relevant input is the CDS service definition.
There, we have 4 entities.
From this perspective it makes sense.
Respectively, in the OData metadata, 2 EntityTypes are identical, guess which ones?
Yawn...
Furthermore, you can see that the CDS Association has a corresponding NavigationProperty in OData.
And you can see that in OData we have always a NavigationPropertyBinding attached to an EntitySet, not only when needed.
Now let’s have a quick view on the OData V2 metadata.
First thing to note:
the metadata document in V2 is longer than the V4
You can see an additional artifact: the Association, defined on same level like EntityType
The Association connects 2 EntityTypes to each other
The EntityType has in addition a NavigationProperty, which points to the Association
Why the NavigationProperty is needed?
Well, it is used when composing the URL, e.g. https:///SERVICE/Products(1)/linkToSupplier
For the runtime part, there’s the additional artifact AssociationSet, it corresponds to the Association and connects 2 EntitySets to each other
This is the OData-V2-way of solving the redirect-problem
One last note
Above, We’ve said that the data for both EntitySets and both EntityTypes is persisted in one table.
When looking at the OData metadata, there’s nowhere any info about one common table for 2 different EntityTypes ("Customers" and "Suppliers")
But what I said is correct.
There's only one database table.
Full stop.
Can you prove it?
Yes, I can: 2 proves.
Prove 1:
In the test section above, we’ve created a "Customer" with id 222 and a "Supplier" with id 111
Now try to create a "Supplier" with id 222
It will fail, because that id already exists.
As such: it is proven that we have only one common database table
You can try…
Yes, I’ve tried, correct... I don’t need a second prove...
Prove 2:
As you know, while generating the API, the Backend service application does a compilation step (you can see it in the API Deployment Logs dialog)
This compilation generates the OData metadata files (resp. edmx files for OData v4 and v2)
But this compilation also generates the descriptor files for the HANA DB (currently the underlying database)
If you could look at these files, you would see that there’s
one entity BUSINESSPARTNERENTITY,
but 2 views SALESORDERSERVICE_CUSTOMERS and SALESORDERSERVICE_SUPPLIERS, both views pointing to the same entity
In total, there are 3 entities and 4 views.
The Java implementation of the OData service works on the views, so everything is fine.
How can I verify this prove?
If you’re lucky, I will show you in a future tutorial how to view these hidden artifacts.
When?
Don't know
Then this prove is not valid
Yes it is
No
Yes
No
Enough, we still have prove 1
OK ok
One (more) last note
We know that CDS is powerful and intelligent…
From what we read in the initial ERROR message, we assume that in the normal case, the redirect is done implicitly by CDS
Pure magic
In normal associations, if we don’t define a “redirected to”, then it is still done implicitly by CDS
This means, we should be able to write it, even if not required.
So tet’s try to make it explicit, then see what happens.
This example (based on the example in stage 2) shows it:
entity ProductEntity {
key productId: Integer;
productName : String;
linkToSupplier : Association to BusinessPartnerEntity;
}
entity BusinessPartnerEntity {
key id : Integer;
name : String;
type : String;
}
service SalesOrderService {
entity Products as projection on ProductEntity{
*,
linkToSupplier : redirected to BusinessPartners
};
entity BusinessPartners as projection on BusinessPartnerEntity;
}Note:
the explicit redirect is not necessary, because:
In the above model, we don't have 2 projections on same entity, involved with association
You can create an API based on this model and you’ll see that it works, it compiles and works exactly same way like the example without explicit redirect. (stage 2)
Appendix 1: The solution
I like to have an appendix with the full sample model.
So here it is:
entity ProductEntity {
key productId: Integer;
productName : String;
linkToSupplier : Association to BusinessPartnerEntity;
}
entity SalesOrderEntity {
key salesOrderId : Integer;
description : String;
linkToCustomer : Association to BusinessPartnerEntity;
}
entity BusinessPartnerEntity {
key id : Integer;
name : String;
type : String; // value can be "Customer" or "Supplier"
}
service SalesOrderService {
entity Products as projection on ProductEntity {
*, // don't forget to add all other properties
linkToSupplier : redirected to Suppliers
};
entity SalesOrders as projection on SalesOrderEntity {
*,
linkToCustomer : redirected to Customers
};
entity Customers as select from BusinessPartnerEntity {*} where type = 'Customer';
entity Suppliers as select from BusinessPartnerEntity {*} where type = 'Supplier';
}
Appendix 2: The apology
Sorry, I forgot to mention that the naming I chose for the CDS elements are not recommendable. I chose those names only for better understanding.
You shouldn't use naming like "linkToAnything" or ending with suffix "...Entity"
Appendix 3: The pet
I feel like I owe you another appendix with another kitty....
- SAP Managed Tags:
3 Comments
