BAPI - jak to działa

[pabi]

Cześć

Mam system HR i ERP, z HR wysyłąm do ERP typ informacji HRMD_A oraz HRTRPY (koszty podrózy)., natomiast z ERP do HR wysyłam Cosmas i Cremas.

Interesuje mnie BAPI.
Po stronie HR mam w modelu bd64 m.in.
VENDOR.FIND, Vendor.getdetail, generalLedgerAccounts.Getdetail, AccountngEmployeeExpenses.Check itd...
Czyli jestem w modeulu po stronie HR i przeglądam jego BAPI.
Moje pytanie jest takie czy wszystkie BAPI po stronie HR (mój source system) odnoszą się do obiektów po stronie ERP (target system) i na nich operują?

Czy może część tych BAPI robi coś na HR (lokalnie- same coś robią na swoim systemie, source) ?

[dominik.tylczynski]

Model dystrybucji zawsze opracowujesz w systemie źródłowym niezależnie czy w modelu podajesz wprost typ komunikatu ALE, czy metodę obiektu gospodarczego, czyli BAPI. Model informuje jakie komunikaty mają być przesyłane do jakich systemów. Zatem zawsze to co wpiszesz w modelu dystrybucji zostanie przesłane do systemu docelowego w formie IDoc'a i tam wykonane.

[pabi]

Czyli upraszczając typ komunikatu mówi jakie informacje prześlę na system target, natomiast metoda obiektu biznesowego mówi co z tymi wysłanymi informacjami zostanie zrobione również na systemie target? Czyli na systemie source nic nie jest robione(metody obiektów biznesowych nic nie robią na systemie source), system source wystawia tylko paczki danych czyli typy komunikatów.

[dominik.tylczynski]

Obawiam się, że mylisz kilka różnych tematów.

Po kolei zatem.

IDoc Type / Typ IDoc'a - definiujesz w transakcji WE30. Typ IDoc'a definiuje strukturę danych, czyli składnię komunikatu. Natomiast nie definiuje jego znaczenia, czyli semantyki. Ten sam typ IDoc'a np. ORDERS01 jest wykorzystywany do wysyłania zamówień zaopatrzeniowych oraz odbierania zleceń sprzedaży. Zauważ - ta sama struktura komunikatu (typ IDoc'a) ale całkowicie różne znaczenie biznesowe. To znaczenie określa

Message Type / Typ komunikatu ALE - definiujesz go w transakcji WE81. To jest prosty wpis - tylko nazwa i opis komunikatu. Nic więcej tutaj nie ma.

Dalej łączysz typ komunikatu z typami IDoc'ów w transakcji WE82.

Wysyłka IDoc'ów
W systemie źródłowym IDoc jest generowany przez dedykowany program, funkcję czy transakcję np. BD10 dla wysyłania materiałów. Model dystrybucji (transakcja BD64) definiuje jakie typy komunikatów ALE są przesyłane do określonych systemów odbiorczych. Model dystrybucji określa tylko odbiorczy system logiczny, nie mówi nic o tym w jaki sposób komunikat jest przesyłany.

Sposób przesyłania komunikatu definiuje profil partnera - systemu odbiorczego zdefiniowany w systemie źródłowym (transakcja WE20). Tutaj jest określony typ IDoc'a i medium komunikacji, którym zwykle jest RFC destination.

Odbiór IDoc'ów
Teraz przechodzimy do systemu odbiorczego. Tutaj definiujesz profil partnera (znowu transakcja WE20) dla systemu źródłowego. W nim określasz sposób przetwarzania przychodzącego IDoc'a. Zwykle jest to kod procesu, który wskazuje po prostu na funkcję, która odczytuje IDoc, parsuje jego dane i zapisuje w systemie.

Asynchroniczna komunikacja ALE odbywa się zawsze przy pomocy IDoc'ów i najprawdopodobniej taką właśnie komunikację wykorzystujesz w swoim scenariuszu integracji.

Teraz najciekawszy temat, czyli relacja IDoc-BAPI
Wcześniej napisałem, że w systemie docelowym IDoc przychodzący jest przetwarzany przez dedykowaną funkcją. Tą funkcją może być jedna z funkcji BAPI. Wtedy dla takiej funkcji generuje się w transakcji BDBG interfejs BAPI-IDoc. Transakcja BDBG generuje segmenty IDoc'a, sam typ IDoc'a na podstawie definicji funkcji BAPI; generuje także funkcje, które tłumaczą strukturę wygenerowane typu IDoc'a na interfejs funkcji BAPI.
Jeśli w komunikacji asynchronicznej wykorzystujesz przetwarzanie IDoc'ów przez funkcje BAPI to w modelu dystrybucji nie podajesz samego typu IDoc'a tylko obiekt gospodarczy i jego metodę, czyli w sumie właśnie BAPI, które jest implementacją tej metody.

Mam nadzieję, że w miarę jasno to opisałem i po 2-3 krotnym przeczytaniu będzie to zrozumiałe.

[pabi]

Bardzo dziękuje, bardzo dobrze napisane, nie jest to proste więc krok po kroku to przejdę.
Jeszcze jedno mam nadzieję, że już ostatnie pytanie z serii ALE, przyznam, że trochę się w tym zagmatwałem ale może uda mi się opisać ok.

Po stronie HR mam Jednostkę gospodarczą 2000, ORK1, konta symboliczne.
Po stronie ERP mam Jednostę Gospodarczą FIRMA1, ORK2, konta symboliczne, konta KG.
Regułami konwersi w IDOC wszystko konwertuję tak jak potrzebuję z 2000 na FIRMA1 itd.

I podstawowe pytanie - czy aby zaksięgować płace programem np. PC00_M99_CIPE uruchamianym po stronie HR na konta KG po stronie ERP jednak nie muszę utworzyć fikcyjnej jednostki gospodarczej 2000 w ERP z obszarem ORK1 i kontami symbolicznymi ? Program po stronie HR nie widzi reguł konwersji ALE - nie znajdzie na ERP JG = 2000, ORK1, kont KG przypisanych do kont symbolicznych b- będzie szukał po JG/ORK i tu już stanie bo po stronie ERPa nie znajdzie JG=2000 jesli mu nie założę fikcyjnej jednostki - wyświetli info o braku JG 2000.

Konwersja ALE załatwiła mi zamianę jg w IDOC, BAPI to przetworzy jednak program do księgowania płac uruchamiamy po stronie HR i on będzie szukał jednostki 2000 po stronie ERP i obszaru ORK1 oraz kont symbolicznych.
Czy w takiej sytuacji utworzenie takiej jednostki fikcyjnej jest niezbędne czy jednak nie, czy można to rozwiązać bez twortzenia fikcyjnych jednostek gospodarczych ?

[dominik.tylczynski]

O ile dobrze pamiętam, a mogę mieć już zamazane szczegóły, bo robiłem to lata temu, standardowo integracja HR-ERP działa tak, że program księgujący płace odpytuje synchronicznie przez BAPI system ERP i sprawdza czy wszystkie dane (konta, jednostka gospodarcza) zgadzają się między HR i ERP. Natomiast to sprawdzenie nie jest wymagane. W przypadku z przed lat system HR nie był fizycznie połączony z ERP, po prostu nie było między nimi komunikacji, więc żadne BAPI nie mogły być wywoływane między tymi systemami. System HR generował IDoc'i z księgowaniem listy płac. Te IDoc'i były zapisywane do pliku, przenoszone do ERP i tam przetwarzane i księgowane w FI.
Stąd wnioskuję, że nie musisz w ERP tworzyć jednostki gospodarczej 2000 i nie musisz wykonywać tych synchronicznych weryfikacji.