TO na pobranie podczas tworzenia TO na rozmieszczenie

[Yeti]

Cześć,
Chciałbym zaimplementować u klienta rozwiązanie, w którym po utworzeniu Zlecenia Przeniesienia na rozmieszczenie lub w trakcie zapisywania, automatycznie wołany jest program albo job do wołania tego programu - na pobranie (zaopatrzenie produkcji do 100). Program do pobrania mamy gotowy ze wszystkimi uwarunkowaniami. Chodzi tylko o trigger tego programu (lub jobu). Jakie rozszerzenie byłoby odpowiednie, żeby tego dokonać, user-exit? Programista z Indii chciał to włożyć do ZXLTOU13, ale odradziłem, wtedy jezcze nie wiadomo czy kwant będzie w docelowym miejscu, to tylko sugestia. Najlepiej byłoby podczas zapisywania TO. Bardzo proszę o sugestie.
Dzięki,
Marcin

[dominik.tylczynski]

ZXLTOU13, czyli MWMTO007, EXIT_SAPML03T_002 to nie jest dobre miejsce na Twoje rozszerzenie. Ten exit jest wywoływany dla zleceń na rozmieszczenie i ustala dane paletyzacji. Natomiast zlecenie przeniesienia nie musi koniecznie zostać zapisane po ustaleniu danych paletyzacji. Zatem może się okazać, że exit zostanie wywołany, uruchomisz swój program do pobrań, a zlecenie na rozmieszczanie nie zostanie utworzone.

Po utworzeniu zlecenia przeniesienia wywoływane jest rozszerzenie MWMTO001, EXIT_SAPLL03T_001. Natomiast myślę, że lepiej jeśli będziesz uruchamiać swój program do pobrań, dopiero po potwierdzeniu zlecenia na rozmieszczenie, bo wtedy jesteś pewien, że zapas znajduje się w docelowej lokalizacji, skąd możesz go pobrać do produkcji. Po potwierdzeniu zlecenia przeniesienia masz rozszerzenie MWMTO002, EXIT_SAPLL03T_002.

Zwróć uwagę, że oba rozszerzenia tj. po utworzeniu i po potwierdzeniu są wywoływane w update task.

[Yeti]

Dzięki Dominik. Czy ma znaczenie, że TO na rozmieszczenie jest automatycznie potwierdzane?

[dominik.tylczynski]

Dzięki Dominik. Czy ma znaczenie, że TO na rozmieszczenie jest automatycznie potwierdzane?

Ma - jeśli zlecenie jest automatycznie potwierdzane podczas tworzenia to wywoływane jest tylko rozszerzenie MWMTO001, a MWMTO002 już nie, bo nie ma tak naprawdę oddzielnego kroku potwierdzenia. To czy zlecenie jest potwierdzane podczas tworzenia widać w MWMTO001.

[Yeti]

Niestety napotkaliśmy program przy procesowaniu naszego programu w backgroundzie przez job w user-exit ZXLTOU01. Nie jest to możliwe wg developera ze względu na fakt, że L_TA_HINZUFUEGEN jest wołany w update tasku i commit jest wywoływany w FB JOB_OPEN. Hm, cokolowiek to znaczy. Próbowaliśmy też BADI WM_ENHANCEMENT, ale dostajemy message: BADI definition WM_WM_ENHANCEMENT is only provided for SAP internal use.
Nie mamy innego pomysłu. Czy da się temu jakoś zaradzić albo jednak wywoływać job w innym miejscu?
BYłbym wdzięczny za pomoc.
Dzięki,
Marcin.

[wojtas7]

Niestety napotkaliśmy program przy procesowaniu naszego programu w backgroundzie przez job w user-exit ZXLTOU01. Nie jest to możliwe wg developera ze względu na fakt, że L_TA_HINZUFUEGEN jest wołany w update tasku i commit jest wywoływany w FB JOB_OPEN. Hm, cokolowiek to znaczy.

a na czym problem polega, w momencie nie macie do dyspozycji jeszcze danych w bazie?

A BADI nazywa się inaczej WM_ENHANCMENT.

https://community.sap.com/t5/applicatio ... -p/5456338

[dominik.tylczynski]

Problem polega na tym, że jak w update task zrobisz commit to poleci dump.

[Yeti]

Problem polega na tym, że jak w update task zrobisz commit to poleci dump.

Tak, dokładnie - mamy dump.

[dominik.tylczynski]

Niestety napotkaliśmy program przy procesowaniu naszego programu w backgroundzie przez job w user-exit ZXLTOU01. Nie jest to możliwe wg developera ze względu na fakt, że L_TA_HINZUFUEGEN jest wołany w update tasku i commit jest wywoływany w FB JOB_OPEN. Hm, cokolowiek to znaczy. Próbowaliśmy też BADI WM_ENHANCEMENT, ale dostajemy message: BADI definition WM_WM_ENHANCEMENT is only provided for SAP internal use.
Nie mamy innego pomysłu. Czy da się temu jakoś zaradzić albo jednak wywoływać job w innym miejscu?
BYłbym wdzięczny za pomoc.
Dzięki,
Marcin.

Miejsce jest dobre. Natomiast faktycznie nie możesz utworzyć zadania w tle funkcją FB_JOB_OPEN będąc w update task'u ze względu na commit w tej funkcji. Dlatego musisz tworzenie job'a wyprowadzić poza update task. Całą logikę/kod ABAP, który teraz masz w ZXLTOU01 do tworzenia job'a przenieś do nowego modułu funkcyjnego, RFC-enabled. Następnie z ZXLTOU01 wywołaj ten nowy moduł przy pomocy CALL FUNCTION func IN BACKGROUND TASK AS SEPARATE UNIT. Wtedy tworzenie job'a zostanie wykonane w oddzielnym LUW. Jakby się coś wysypało w tej funkcji, to błędy znajdziesz w logu RFC, transakcja SM58.

Tak naprawdę to nie musisz nawet za każdym razem tworzyć nowego job'a. Możesz zaplanować jedno zadanie w tle i uruchamiać je przy pomocy zdarzenia wywoływanego z rozszerzenia po utworzeniu zlecenia przeniesienia:

• Events in Background Processing Explained
• Working with Events
• Triggering Events from ABAP Programs

Na początek spróbowałbym z job'em uruchamianym zdarzeniem. Jest to znacznie prostsze do zaimplementowania.

[Yeti]

Bardzo dziękuję za wszystkie podpowiedzi! Próbujemy wszystkiego. Developer entuzjastycznie podszedł do pierwszej z nich dotyczącej LUW. Jednak przed chwilą dostałem info od programisty: The statements COMMIT WORK and ROLLBACK WORK must not be executed within a LUW. In addition, no implicit database commit can be triggered there. To jest z SAP documentation. Nasz program do tworzenia TO na pobranie ma kilka commitów. Czy to ma sens czy też my coś źle robimy, że cały czas mamy problem z tymi commitami?
Druga propozycja wydaje mi się lepsza, ale żadne z nas nie ma z tym doświadczenia. Zaczęliśmy więc od LUW.

Pozdrawiam,
Marcin

[dominik.tylczynski]

Bardzo dziękuję za wszystkie podpowiedzi! Próbujemy wszystkiego. Developer entuzjastycznie podszedł do pierwszej z nich dotyczącej LUW. Jednak przed chwilą dostałem info od programisty: The statements COMMIT WORK and ROLLBACK WORK must not be executed within a LUW. In addition, no implicit database commit can be triggered there. To jest z SAP documentation. Nasz program do tworzenia TO na pobranie ma kilka commitów. Czy to ma sens czy też my coś źle robimy, że cały czas mamy problem z tymi commitami?

Coś musicie robić nie tak z CALL FUNCTION func IN BACKGROUND TASK AS SEPARATE UNIT. Wykorzystywałem to podejście wielokrotnie i działało bez zarzutu. Nie kojarzę ograniczenie w COMMIT WORK w CALL FUNCTION func IN BACKGROUND TASK AS SEPARATE UNIT.