Reuse Entity Type in different Entity Sets

[former_member182670]

Hi,

Is it possible to reuse entity type in different entity sets?

I can do it in the Service Builder but when calling the service Gateway runtime gets confused.

Sample scenario:

Entity Types:

Request

Person

Entity Sets:

Employees (Person)

Managers (Person)

Requests (Request)

Navigation properties:

Request.Employee

Request.Manager

Associations

Request_Manager Principal Entity: Request, Dependent Person , Cardinality 1:1

Request_EmployeePrincipal Entity: Request, Dependent Person , Cardinality 1:1

Association Sets

Request_ManagerSet Principal Entity Set: Requests, Dependent Set Managers

Request_EmployeeSet Principal Entity Set: Requests, Dependent Set Employees

Call 1:

If I call Requests('123')/Manager MANAGERS_GET_ENTITY is called in DPC which is ok

Call 2:

If I call Requests('123')/Employee still MANAGERS_GET_ENTITY is called instead of EMPLOYEES_GET_ENTITY

Am I missing something?

If I copy Person to Person2 and point EntitySet Employee to Person2 then both calls are routed correctly. But I would like to avoid duplicate Entity Types.

[former_member182670]

I found in one of the model classes following piece of code:

/IWBEP/CL_MGW_ODATA_ASSOCIATN-IWBEP/IF_MGW_ODATA_ASSOC~CREATE_ASSOC_SET

lines 16-18

" again defaulting... by the first entityset which is found for the entity type

   lr_src_entity_set = mo_model->get_eset_by_entity_id( me->mr_association->*-source_entity_id ).

   lr_trg_entity_set = mo_model->get_eset_by_entity_id( me->mr_association->*-target_entity_id ).

So this seems to be a "feature" - first found entity set is always set as target.

I was able to workaround that in my MPC_EXT class by adding following code in redefined DEFINE method:

lo_assoc_set = model->get_association_set( iv_assoc_set_name = 'Request_EmployeeSet' ).

lo_assoc_set->set_right_entityset_id( model->get_entity_set( 'Employees' )->get_id( ) ).

This seems to be working but I would expect this to be correctly generated by the builder.

I leave the question as unanswered for now - maybe someone has found a way to force builder to generate correct model and will reply with solution.

[Former Member]

Hi Tomasz,

Let's break this down into two parts.

1/ Is it possible to reuse entity type in different entity sets? Most cetainly yes.

2/ Although you can, for this use case I'm not sure that you need to.

I'm currently working on an article about this very subject and in my use case I have multiple primary entitysets, i.e. the first addressable set.

In your case, the Requests set is the primary addressable entityset, to which you have assigned two navigation properties. Since the navigation names need to be different, the navigation name acts as your differentiator and the resulting set type can be the same one (persons).

e.g. Requests/Managers  --> Persons (where all persons in result are managers) and Requests.Employees --> Persons (where all persons in result are employees).

The only scenario I can see where I'd want the results to be named as a different set is if the consuming client needs that, but since the client would have made the navigation it would already know the context of the results (it's a manager set or an employee set) and wouldn't need  to be qualified by a feed name.

Maybe that helps you?

Regards

Ron.

[former_member182670]

Hi Ron,

Thanks for your valuable reply. You are right, in my use case I just need one entity set - Persons.

In GET_ENTITY I will check IT_NAVIGATION_PATH and know if request is for Manager or Employee. I didn't think about that in the first place.

I believe there are still some valid use cases where the initial concerns apply.

What is interesting I checked on different (newer) version of Gateway (SAP_GWFND 740 0006) and this problem is no longer there. In MPC association sets are created using  /IWBEP/IF_MGW_ODATA_MODEL-create_association_set which takes entity set types as parameters.

On older version (GW_CORE 200 0007 installed on 7.02) it was created with   /iwbep/if_mgw_odata_assoc-create_assoc_set which uses the defaulting causing the issue.

[Former Member]

Hi Tomasz,

Glad I was able to help.

There were some changes that occurred in SEGW around associations over releases. I noticed that after an upgrade (SP5 or higher?), you did not need to create an association set for an association, i.e. there was one less node on the 'elements' tree. I'm assuming that it defaulted this on a 1:1 basis.

You can still build one, but it wasn't a formal requirement and the navigation worked.

What I have since found; if you have multiple primary entitysets based on one entity, and you have one navigation from that one entity, you need an assoc set for every entityset, even if the navigation doesn't actually apply to all sets. Without that you get a runtime error on some requests about assoc set missing from metadata.

Cheers

Ron.