cancel
Showing results for 
Search instead for 
Did you mean: 

SAP CAP Compositon to many WITH multiple ON conditions

TobiT
Participant
0 Kudos
2,025

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;
}

Accepted Solutions (0)

Answers (1)

Answers (1)

vansyckel
Advisor
Advisor
0 Kudos

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

TobiT
Participant
0 Kudos

Right, what do I gain by doing this? My goal is using the unique fields Param1 and Param2 as this is more true to the schema I am extending.

TobiT
Participant
0 Kudos

Added the _up to my example, does not run. Remember: I don't want to use managed compositions.

vansyckel
Advisor
Advisor
0 Kudos

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