cancel
Showing results for 
Search instead for 
Did you mean: 

Mapping restrictions with composite provider

michael_simon4
Participant
0 Kudos

Hi all,

we are upgrading to BW on HANA 7.40 and plan to use the new objects (ADSO & Composite Provider) in our new developments.

We have the requirements (from business side & due to our authorization concept) to map InfoObjects/Navigational attributes different for the participating Infoproviders. We are doing this in our current Multiproviders quite often. Example:

  • Multiprovider field: 0COSTCENTER__0COMP_CODE Mapped from:
    • Participating Infocube 1: Characteristic 0COMP_CODE
    • Participating Infocube 2: Navigational attribute 0COSTCENTER__0COMP_CODE

I am not able to model this with the new objects (ADSOs & Composite Providers) - Because navigational attributes cannot be enabled in the ADSOs & the composite provider doesn't give me the option to map the enabled navigational attributes different for each participating InfoProvider (also not possible if I use the old Cubes within the Composite). I also tried to create 1 Composite per ADSO to enable the navigational attributes and then put another Composite provider on top - but then I also lack the option to map Navigational attributes from the source to another characteristic.

Has anyone the same problem or already found a solution for it?

Thank you and best regards,

Michael

Accepted Solutions (0)

Answers (5)

Answers (5)

Former Member
0 Kudos

Hi Michael

Below is a workaround / solution for your issue.

1. Create an Open ODS View on top of your ADSO.

2. Enable the navigational attribute in your Open ODS View. (In my example I did it with fields, but it works for both, fields and InfoObjects):

3. Add this Open ODS View to your CompositeProvider.

(Do not forget to display of the navigational attributes in the source part provider)

4. Now, you can map navigational attributes and characteristics to any other characteristic.

Hope this helps

Best regards

Peter

michael_simon4
Participant
0 Kudos

Hi Peter,

thank you for your solution. But if I understand it correctly, it solves only the problem to map a characteristic and/or navigational attribute to a characteristic in the composite provider. The other part of my problem is to map a characteristic to a navigational attribute of the HCPR - and this is also with your workaround not possible, right?

Best regards,

Michael

Former Member
0 Kudos

Dear Michael

I created a little example implementation for your requirement (sorry for the German texts in the screen shots).

Try to map the navigational attribute to the target.

The target is a field with the name of the 0COMP_CODE InfoObject (unfortunately not 0PLANT__0COMP_CODE). Map also the other InfoObjects to this field.

Now you can rename the target field e.g. into "NAV_BUKRS" (respect the limitation of 12 characters and only one consecutive underscore "_").

If you like, you may add another 0COMP_CODE field with other mappings to your target.

After that, you associate the two fields to the InfoObject 0COMP_CODE in the "display" tab.

Theoretically, the analysis authorization identifies both fields with 0COMP_CODE due to the associations and applies the corresponding authorizations.

At least, I'm able to restrict the "navigational attribute" field with an authorization variable in the BEx Query Designer:

Comment:

  1. Hopefully, the workaround above solves your issue. Are you able to test it with your analysis authorization?
  2. The target does not allow field names with the same naming convention as used for the navigational attributes in MultiProviders.
    => Agree, here we have some space for further improvements.
  3. IMHO, if you map your navigational attribute like in my example above, you can reproduce the reporting behavior in your CompositeProvider as you had it in your MultiProvider. The only restriction is a different field name for the navigational attribute.


Best regards

Peter.


michael_simon4
Participant
0 Kudos

Hi Peter,

thank you for your detailed description. We will test this in our system I will get back to you as soon as we have a result.

Best regards,

Michael

former_member93896
Active Contributor
0 Kudos

Hi Michael,

why don't you use 0COMP_CODE in the CompositeProvider target?

Best,
Marc
Product Management SAP HANA DW

michael_simon4
Participant
0 Kudos

Hi Marc,

thank you for your answer. Yes, this covers one part of my requirement (as Björn List also pointed out to me) - the problem how to map an ADSO navigational attribute to an characteristic in the HCPR. But the other way round (how to map a characteristic from an ADSO to an navigational attribute in the HCPR) is not covered. And this is necessary, because we have authorization relevant navigational attributes and need to have them in the HCPR, but not all underlying ADSOs have these navigational attributes and need therefore a different mapping.

Best regards,

Michael

former_member93896
Active Contributor
0 Kudos

Understood. Thanks for the feedback, Michael. Our backlog is pretty full but we will see when we can implement this again.

Best,
Marc
Product Management SAP HANA DW

Former Member
0 Kudos

Hi Michael,

Can you solve the issue?

Regards

Eduardo.

michael_simon4
Participant
0 Kudos

Hi Eduardo,

as far as I know there is no solution for my issue at the moment - even with workarounds.

Best regards,

Michael

Former Member
0 Kudos

Dear Community,

please vote for both ideas:

Composite Provider missing feature: Reference characteristic / navigational attribute mapping

Composite Provider missing feature: Characteristic / navigational attribute mapping

It's unbelievable how this functionality could have been forgotton to be implemented in the "premium alternative" of Multiproviders

Thanks, Martin

bjoern_list2
Explorer
0 Kudos

Just put your HCPR in a second HCPR, if possible (only unions)!

In the second HCPR you can map both fields to one field.

http://service.sap.com/sap/support/notes/2215947

michael_simon4
Participant
0 Kudos

Hi Björn,

thank you for your answer. The mentioned solution solves the problem how to map an ADSO navigational attribute to an characteristic in the HCPR. But the other way round (how to map a characteristic from an ADSO to an navigational attribute in the HCPR) is not covered. I fear this is currently not even with workarounds possible.

Best regards,

Michael

Former Member
0 Kudos

Hi Michael,

did you find a way for your second Scenario "how to map a characteristic from an ADSO to a navigational Attribute in the HCPR"?

This functionality seems to be missing in the CompositeProvider.

Kind regards,

Tobias

michael_simon4
Participant
0 Kudos

Hi Tobias,

no, we didn't found a solution, but my colleague created an idea at the Ideaplace:

https://ideas.sap.com/D34674?status_id_filter=335897B6-05D7-4568-8804-3F55E3B39025&current_tab=Recen...

Please feel free to vote.

Best regards,

Michael

former_member194957
Active Participant
0 Kudos

Hi Michael ,

                   The navigational attributes can be added to the HANA composite provider . Please follow this discussion Navigational attributes in Advanced DSO (BW 7.4... | SCN. Hope this helps. You get an option to check the navigational attributes which are available to the fields added in the underlying ADSO as part provider to the HCPR.

Regards

Tharun.

michael_simon4
Participant
0 Kudos

Hi Tharun,

I checked your link. I am aware how I can activate navigational attributes in HCPR. This works fine, if I have a HCPR with 2 participating ADSOs and I activate e.g. 0COSTCENTER__0COMP_CODE in my HCPR: Then for both 2 ADSOs 0COSTCENTER__0COMP_CODE is used.

My problem is that I want different mappings for the participating ADSOs (or Cubes): From one ADSO I want 0COSTCENTER__0COMP_CODE mapped, for the second I want directly the characteristic 0COMP_CODE mapped (not the navigational attribute). This was easily possible with MPROs.

Best regards,

Michael

former_member194957
Active Participant
0 Kudos

Hi Michael,

                I have tried out the same scenario. Here i have created two adsos having the following infoobjects

1.ZTK_ADSO1 - having only 0COSTCENTER infoobject and compounding attributes 0CO_AREA  is added automatically

(Note : 0COSTCENTER has 2 navigational attributes - 0PROFIT_CENTER and 0RT_LOCATIO )

2.ZTK_ADSO3 : having 0RT_LOCATIO infoobject .

i created a HCPR with these 2 adsos as part provider and i have mapped as shown in the screen shot (0COSTCENTER from first adso and 0RT_LOCATIO from second adso)

later click on the "output" tab and right click 0COSTCENTER and chose "Navigation attributes"

you can choose the 0RT_LOCATIO which is nav attribute mapped from the 0COSTCENTER in the first ADSO.

Now you can see that

0COSTCENTER_0RT_LOCATIO is mapped from first adso and

0RT_LOCATIO is mapped from second adso.

Hope this was your scenario too.

Regards

Tharun

michael_simon4
Participant
0 Kudos

Hi Tharun,

thank you for your efforts. If I understand your example correctly, it is possible to use in the reporting 0COSTCENTER__0RT_LOCATIO from one ADSO and 0RT_LOCATIO from the other.

My scenario is, that the user filters 0COSTCENTER__0COMP_CODE in the HCPR and this affects 0COSTCENTER__0COMP_CODE in ADSO 1 and 0COMP_CODE in ADSO 2.

Screenshots from an old MPRO example:

DSO 1:

DSO 2:

MPRO:

Identification for 0COSTCENTER__0COMPCODE in the MPRO:

This is different from your example, or am I wrong?

Best regards,

Michael

former_member194957
Active Participant
0 Kudos

Hi Michael,

                 This the same scenario as mentioned by you . Even though the last screenshot in your reply displays two options for 0COSTCENTER__0COMP_CODE, the values for navigational attribute is to be mapped from first DSO and the 0COMP_CODE infoobject values are to be mapped from second DSO.

The way the fields are assigned are different in UI screens , but the concept is the same.

In MPRO you have a seperate option to assign the mappings. In HCPR you can do the assignment and mappings in the initial screen itself.

Regards

Tharun.

michael_simon4
Participant
0 Kudos

Hi Tharun,

but in your example I have two fields in the query - one for ADSO 1 and one for ADSO 2. What I need is only 1 field in the query - when I filter on this field it should affect ADSO 1 & 2 (in my example I want to filter on the MPRO field 0COSTCENTER__0COMP_CODE and this is handed over to 0COMPCODE for Inforpov 1 and 0COSTCENTER__0COMPCODE for Infoprov 2).

Best regards,

Michael