on 2021 Aug 05 8:18 AM
Dear community,
i face the following challenge:
I have a database with parties and people (see below). I expose it with cap and use fiori elements as the UI.
My customer wants to look up parties and assign them individual people right in the party UI.
The solution was to use a composition to many and a table connecting these two entities.
While using an ID type UUID for the on condition everything is going well in draft mode. But truth be told: There is no party and no people. I am extending a ERP ECC data model.
I gave up on using the same keys (multiple) for my entities, as draft mode won't comply. But i was hoping to at least take the key fields present in the backend and make them unique on my entities (PARAM1, PARAM2).
Worked like a charm until i tried to join my people to my parties. It looks like if it is not a single UUID joining the two entities the CAP framework does not auto fill it on CREATE to PARTY/PARTY_TO_PEOPLE.
Alright... custom service.js it is. If a new CREATE request hits the PARTY/PARTY_TO_PEOPLE i determine the "unqiue" fields (PARAM1, PARAM2) on PARTY and enrich the request data. All newly created PARTY_PEOPLE will contain the data of PARTY.(PARAM1, PARAM2) and my UI will display the assigned PARTY_PEOPLE (note that the assignment of a real person is independent from this)... Yeah party!
Until i click the "edit" button a second time. The before assigned PARTY_PEOPLE is no longer visible in draft view. And creating another assignment leads to a weird error.
So my assumption is that DRAFT mode is not able to receive the assignments if it is not connected via UUID. Even if it would be it somehow screws up more assignments than one.
Any ideas?
PS: I just noticed that we could have ignored the PERSON entity for this as the issues is already and only with Composition of many. But maybe you have a totally different solution for my little problem over here 🙂
Thanks and Cheers!
Data model for reference:
@assert.unique : {PARTY_UNIQUE : [
PARAM1,
PARAM2
]}
entity PARTY {
key ID : UUID;
PARAM1 : String;
PARAM2 : String;
PARTY_PEOPLE : Composition of many PARTY_PEOPLE
on PARTY_PEOPLE.PARAM1 = PARAM1
and PARTY_PEOPLE.PARAM2 = PARAM2;
}
entity PARTY_PEOPLE {
ID : UUID;
PARAM1 : String;
PARAM2 : String;
PERSON_ID : UUID;
PERSON : Association to PERSON
on PERSON.ID = PERSON_ID;
}
entity PERSON {
key ID : UUID;
NAME : String;
}
Request clarification before answering.
Hi Tobias,
Your PARTY_PEOPLE don't have a so-called "backlink" to your PARTY, i.e., an association telling the runtime to which PARTY these PARTY_PEOPLE belong. See our Orders with Order Items example.
Best,
Sebastian
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Tobias,
How did you add it? Or better, could you please share a minimal example? Reproducing such issues is pretty cumbersome.
Also, why don't you want to use managed compositions? I understand that PARTY and PEOPLE are artifacts of a different system, but why can't PARTY_PEOPLE be a standard composition of many? Having PARAM1 and PARAM2 in both entities is unnecessary redundancy, no?
@assert.unique : {PARTY_UNIQUE : [
PARAM1,
PARAM2
]}
entity PARTY {
key ID : UUID;
PARAM1 : String;
PARAM2 : String;
PARTY_PEOPLE : Composition of many PARTY_PEOPLE on PARTY_PEOPLE.PARTY = $self;
}
entity PARTY_PEOPLE {
ID : UUID;
PARTY : Association to PARTY;
PERSON : Association to PERSON;
}
entity PERSON {
key ID : UUID;
NAME : String;
}
Best,
Sebastian
User | Count |
---|---|
74 | |
20 | |
9 | |
8 | |
7 | |
5 | |
5 | |
4 | |
4 | |
3 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.