cancel
Showing results for 
Search instead for 
Did you mean: 

Query TRex using join index failed: No language specified for attribute;location=04279milq:30103

Former Member
0 Kudos

Hello, Expert

We have custom code to query TRex for Marketing, we are using physical index until now, and things are working well for queries with less than two EXCLUDEs. However if hte query contains two EXCLUDE, TRex returns error: invalid query;index=seg:pc1101_z_bp_datasource_xxx,location=04279milq:30103. SAP looked into this, and mentioned for this type of query we need to use the join index, not the physical index, so I've tried to use the join index ( I guess it is created automatically by TRex when datasource is configured?), however when querying TRex using the join index, i got below error:

No language specified for attribute;location=04279milq:30103

I suppose the Join Index (with suffix _join appending to the name of the physical index) is not created / configured properly, so that the language dependent indies were not created. Any one has clue how to fix this or correct the join index in Trex? (FYI, using the join index, I got the same error while quering with less than two EXCLUDE in the query, so it doesn't work at all, while using the physical index, it works for queries with less than two EXCLUDE)

Thanks for help.

Jayson

Accepted Solutions (0)

Answers (1)

Answers (1)

Former Member
0 Kudos

Anyone can shed some light on this?

former_member217429
Active Contributor
0 Kudos

Hi Jayson,

what's the TREX version you use currently? I suppose that the issue can not be resolved here . May I ask you to create a new one OSS Message on the BC-TRX component.

Best regards,
Mikhail

Former Member
0 Kudos

Hi Mikhail

the version of our TRex is 7.10.55.00

yes, we are creating OSS for that, hopefully SAP can provide some fix / advice.

Do you see anything in this? it looks for me that the join index was not generated properly with language attribute missed or not defined. Since CRM doesn't reallly have control on the TRex index, our hands are tied.

Thanks for help.

Jayson

Former Member
0 Kudos

Hi Mikhail,

we've created OSS 0000380552 2014, including steps and screenshots, are you able to have a look into it?

Thanks

Jayson

former_member217429
Active Contributor
0 Kudos

Hi ,

from my point of view the issue is related to the structure of the search query executed on the Join - here I see two mistakes when building the request:
1) When calling TREX_RFC_SEARCH_DOCUMENTS you fill the internal table REQ_ATTRIBUTES with attributes located in the physical index .However as the search takes a place on Join you need to use the corresponded View Attributes from the Join index. So f.e. you request values of attributes zbpnum, zcontract,zcontractacct . You need to replace these when call mentioned function by the Join attributes obj_11,obj_20 and obj_21.

2) Although the search takes a place in the Join the query parts (table query_entry) contains the data from the physical index seg:pc1101_z_bp_datasource_hvs . It's very unusual structure for the CRM Segment Builder scenario.
I would like to suggest to modify the query on the following way
1) Fill the REQ_ATTRIBUTES table as mentioned above
2) Fill the Query_entry table  using the view attributes in Join. So the query should look like f.e.

obj_72=E AND NOT ( obj_65=X ) OR obj_2<>*

instead of current
seg:pc1101_z_bp_datasource_hvs/zmyaccind=E AND  NOT (seg:pc1101_z_bp_datasource_hvs/zmyaccind=X ) OR seg:pc1101_z_bp_datasource_hvs/z12amount<>*

Best regards,
Mikhail

former_member217429
Active Contributor
0 Kudos

Hi,

the search on the physical index can work with two or more exclusions . However all query parts should belong to the same one index! I mean the following - you run the search against Join seg:pc1101_z_bp_datasource_hvs_join which has two joined physical indexes seg:pc1101_z_bp_datasource_hvs and seg_pc1_101_bpartner . if all attributes from the search query located in the same  index and you want to have the values of attributes returned from the same index - it should work. But if the IndexServer needs to calculate some conditions based on the data from the 2nd index, the search runs into an error. Based on the strucutre of your indexes I suppose that the search in this scenario will not work (other way there was no sence to create Joins at all).

Alternative to the point 2 is a small correction when filling the Query_entry table. Here you can still put the name of the physical index and corresponded attribute  , f.e. INDEX_ID = seg:pc1101_z_bp_datasource_hvs LOCATION=zmyaccind VALUE1=E e.t.c. But additionaly you need to put the language EN into LOC_LANGU field . It should be enough to fix the issue.

Best regards,
Mikhail