topic Syntax for mapping to nested field in Application Development and Automation Discussions

Syntax for mapping to nested field

Former Member — Wed, 15 Apr 2015 13:11:07 GMT

Hi,

Consider the following mapping (7.4 SP8):

"define and fill data strucures

BEGIN OF person,

name TYPE string,

BEGIN OF address,

city TYPE string,

zip_code TYPE string, "if I remove this (in this case redundant) line, I get a dump (why?!?)

END OF address,

END OF person,

BEGIN OF employee,

name TYPE string,

city TYPE string,

END OF employee.

DATA(person) = VALUE person(

name = 'John Doe'

address = VALUE #(

city = 'Manassass'

)

"Map from employees to person. This works fine.

DATA(employee) = CORRESPONDING employee( person

MAPPING

city = address-city

"Vice versa does not work out of the box.

DATA(person2) = CORRESPONDING person( employee

MAPPING

name = name

address-city = city "this does not compile.

The syntax checker claims that the red marked "component" does not exist.

Primary question: What is the correct syntaxt to map to the nested "city" element?

Secondary question (came up during the creation of the minimal demo code): Why do I get a core dump if the zip_code line is removed?

Thanks!

Re: Syntax for mapping to nested field

nikolayevstigneev — Thu, 16 Apr 2015 06:42:17 GMT

Hi, Simon!

Here's what the doc says for CORRESPONDING - mapping:

Addition 1

... MAPPING t1 = s1 t2 = s2 ...

Effect

[...] A component of a target object cannot appear more than once in the list after MAPPING and the structure component selector cannot be used to access subcomponents. Neither of these rules apply for components of the source object.

And considering your second question - yep, the dump is reproduced but I can't figure out why two subcomponents for a structure is ok and one is not ok. Let's read the doc together

Re: Syntax for mapping to nested field

Former Member — Tue, 21 Apr 2015 10:01:30 GMT

Hi,

seems I like I missed this limitation, thanks for the pointer.

Too bad it exists, would make certain mappings much easier.

Best Regards,

Simon