Forum dyskusyjne SAP

Cześć,

studiuję user exit mojego starszego kolegi i nie mogę zrozumieć co dzieje się w poniżych liniach. Szczególnie chodzi mi o pierwszą linię - co oznacza to przypisanie i dlaczego nazwa programu używanego do tworzenia danych dostawcy jest w nawiasie (dlaczego?); potem odwołanie się do xknvk - struktury ??
Linia 4 - podpięcie do fieldsymbolu ale też zmienna l_fieldname jest w nawiasie ... Proszę o pomoc w "rozkminieniu"

Poprzez field-symbol <XKNVK> można się teraz odwołać do zawartości zmiennej (tabeli wewnętrznej) XKNVK w programie głównym. Taki trick, który pozwala na użycie zmiennych globalnych programu nieprzekazanych w interfejsie user-exita.

Ten sposób przypisywania field-symbol jest opisany na SAP Help: https://help.sap.com/doc/abapdocu_751_index_htm/7.51/en-US/abapassign_mem_area_dynamic_dobj.htm#!ABAP_ALTERNATIVE_1@1@

Zauważ, że choć to bardzo przydatny trick powinien być używany z rozwagą:

SAP Help pisze:For internal use only, the name in name can also have the form "(PROG)DOBJ", where "PROG" is the name of an ABAP program and "DOBJ" the name of a global data object of this program. If the program "PROG" is loaded into the same internal session as the current program when the statement ASSIGN is executed, the data object "DOBJ" is found in this program and the field symbol points to this data object if the assignment was successful.

Internal use oznacza tutaj, że SAP nie zaleca stosowania tej konstrukcji.

To jest tak zwane 'dirty assign' - krótkie wytłumaczenie tutaj:
https://blogs.sap.com/2013/05/30/using- ... valuation/

stosuje się je głównie, żeby dostać się do zmiennych programu głównego, których nie ma w dostępnych bezpośrednio w metodzie/ exicie. W praktyce stosowane przez SAP oficjalnie nie zaleca stosowania tej konstrukcji (są inne metody również na przekazywanie takich zmiennych) ale jak się popatrzy na programowane w standardzie BTE / exity to tam chętnie tego używają metoda w miarę bezpieczna jak się sprawdzi zawsze po assign jaki jest subrc, żeby nie nadziać się na dumpa przy działaniu na field symbol, że nie został przypisany.

Ta inna metoda o której pisałem w nawiasie to możliwość stosowania globalnych zmiennych grupy funkcyjnej - jeżeli masz się gdzieś wpiąć i przekazywać dane przez kilka miejsc procesowania to można stworzyć grupę funkcyjną z 3 modułami:
XXX_SET
XXX_GET
XXX_CLEAR

Zmienne, które chcesz przechowywać deklarujesz w TOP grupy funkcyjnej.

Podczas pierwszej metody wywołujesz zawsze razem: najpierw _CLEAR a potem _SET.

Następnie jak chcesz użyć danych to wywołujesz _GET i masz dostęp do danych w dowolnym momencie procesowania bo grupa funkcyjna je trzyma nawet jak lokalne zmienne z metody wywołania (tam gdzie było _SET) zostały wyczyszczone.

Marek

Dostęp do zmiennych globalnych innych programów przez "dirty assign" jest faktycznie często stosowane w implementacji rozszerzeń (user-exit, badi). Warto zwrócić uwagę, że taki dostęp umożliwia również zmianę tych danych globalnych. Mimo iż jest to technicznie możliwe, lepiej unikać zmieniania - na pewno spowoduje to niespójności.