ABAP Mesh Performances

[Former Member]

Dear Experts,

I am currently investigating on features added on 7.4 version.

One of them is the Mesh allowing to create associations between structures/tables. This feature is quite interesting for developper's needs but as far as I could see the performances are quite bad when working on 10.000+ entries.

The fact is when calling a code line such as:

DATA(ls_line) = mesh-po_header\my_items[ gs_ebeln ]

[ gs_ebeln ] : This notation is not reserved to the mesh. It came out with 7.4 as well.

It is calling a read table without binary search and therefore the performance are really close to it.

Is there a way to make it use the binary search?

If not, might there be a workaround to work with mesh with great performances?

Thanks for your answers

[Former Member]

I found part of the answer in SAP documentation:

• Unlike the statement READ TABLE with a free key specified, no binary searches can be forced for a table expression and it is not possible to specify explicit table key for optimizing searches using secondary keys.

But the question remains: is there a way to use mesh with great performances

[retired_member]

Provide an appropriate (secondary) table key and use key access in the square brackets.

KEY keyname [COMPONENTS] ...

(instead of free key).

Many think it is not possible, but why take the deviation of using the free key if a normal key specification is possible.

[Former Member]

Hello Horst and thanks for your answer.

I am discovering this feature and tried it but with this is not working.

Here is my sample code:

________________________________________

TYPES: BEGIN OF ty_bkpf,
belnr TYPE belnr_d,
bukrs TYPE bukrs,
END OF ty_bkpf,

BEGIN OF ty_bseg,
belnr TYPE belnr_d,
buzei TYPE buzei,
END OF ty_bseg,

ty_t_bkpf TYPE SORTED TABLE OF ty_bkpf WITH UNIQUE KEY belnr
WITH NON-UNIQUE SORTED KEY cle_belnr COMPONENTS belnr ,
ty_t_bseg TYPE TABLE OF ty_bseg WITH NON-UNIQUE KEY belnr buzei,

BEGIN OF MESH ty_mesh,

head TYPE ty_t_bkpf
ASSOCIATION my_items TO item ON belnr = belnr,
item TYPE ty_t_bseg
ASSOCIATION my_header TO head ON belnr = belnr,
END OF MESH ty_mesh.

DATA: mesh TYPE ty_mesh.

SELECT belnr bukrs
FROM bkpf
INTO TABLE gm_po-head.

SELECT belnr buzei
FROM bseg
INTO TABLE gm_po-item.

DATA(ls_mesh) = gm_po-po_head\my_items[ key key_belnr COMPONENTS belnr = 10000000 ].

_____________________________________________________________

And on this last statement, I get the following error (translated) during activation:

Field "KEY" unknown. It does not exist in the table nor is it defined in a data statement

I can make it work on a simple table expression but not inside this mesh.

[retired_member]

Zut alors, should've look it up before answering.

[retired_member]

Maybe using the workaround

[USING KEY key] [WHERE log_exp]

in a loop can help.

[Former Member]

I finally found out a workaround.

It seems like the association can as well be specified a key. The call will be done based on the key of a structure gs_bkpf in my case.

____________________________________________________

BEGIN OF MESH tm_po,
header TYPE ty_t_bkpf
ASSOCIATION my_items TO items ON bukrs = bukrs and belnr = belnr and gjahr = gjahr USING KEY primary_key,
items TYPE ty_t_bseg
ASSOCIATION my_header TO header ON bukrs = bukrs and belnr = belnr and gjahr = gjahr USING KEY primary_key,
END OF MESH tm_po.

DATA: gm_po TYPE tm_po.

gs_bkpf-bukrs = 'XXXX'.
gs_bkpf-belnr = 1000000000.
gs_bkpf-gjahr = '2017'.

LOOP AT gm_po-header\my_items[ gs_bkpf ] INTO DATA(ls_item).
CLEAR sy-subrc.
ENDLOOP.

__________________________________________________

This means secondary keys can't be used on meshs but since each assocation has its own key, this is not much of a problem.

Thanks again Horst for your advice