Witam
Potrzebuję napisać mechanizm integrujący ERP z WMS. WMS narzuca Api w formie komunikatów/plików, które mają być przesyłane pomiędzy ERP a WMS. W pewnym uproszczeniu wygląda to tak że w ERP są zatwierdzane dokumenty i te zdarzenia mają spowodować wysyłanie do WMS komunikatu. Następnie WMS po przyjęciu lub wydaniu towaru odsyła komunikat zwrotny. Na bazie komunikatu z WMS należy zrobić odpowiednie dokumenty w ERP np. WZ , PZ lub przesunięcie MMP itp. ERP posiada swoje API w formie biblioteki dll z której wywołujemy funkcje tworzące dokumenty w ERP. Api ERP-a bywa kapryśne i zdarzy się że wywołana funkcja zawiśnie? Pytanie moje jest takie jak ugryźć temat strukturalnie? Tzn. czy zrobić to w jednej aplikacji, np WinForm? Czy też zrobić np. WindowsSerwices i to może kilka które odpowiadałyby za różne zadania? Mechanizm ma być automatyczny i najlepiej bezawaryjny.
Pomysł jest taki że co jakiś czas np. kilka minut odpali się zadanie, które przeglądnie tabele w ERP i poszuka rekordów na bazie których mają powstać komunikaty do WMS i zrobi wpisy do tabel pomocniczych ze statusem "do wysłania". Kolejny mechanizm na bazie tych wpisów stworzy komunikat do WMS i zmieni status.
Podobnie po stronie wejścia z WMS potrzebny mechanizm który odczyta pliki/komunikaty zwrotne z WMS i np. wrzuci je do tabel pomocniczych. A następnie kolejne zadanie które przetworzy te komunikaty za pomocą API na dok. ERP-a.
wiem że temat jest szeroki ale za wszelkie pomysły i sugestie będę wdzięczny
Robiłem taką integrację (z opisu można podejrzewać, że to nawet te same systemy ;) - jak możesz to napisz co integrujesz).
Ja zrobiłem to w formie osobno działającej aplikacji a nie usługi ponieważ czasem jest potrzeba interakcji z użytkownikiem.
Chodzi o Comarch XL. Co do WMS to powiedzmy że to nie ma znaczenia. Zastanawiam się na połączeniu aplikacji i serwisów. Aplikacja mogłaby służyć np do jakiejś konfiguracji, przeglądnięcia logów itp. a zadania chodziły by w serwisach.
Moim zdaniem to zbędne komplikowanie sobie życia.
Tajny WMS :D
Ile masz tych komunikatów na godzinę? Jak masz i tegracje plikową to bierzesz plik wrzucasz dane gdzie trzeba i przenosisz plik do archiwum jako przetworzone albo jako błędny no i oczywiście jakos log no w bazie żeby łatwo było przeszukiwać. Jak dane nie mogą ulegać zmianie i nie ma konieczności modyfikacji już istniejących danych to ja bym odpuścił tabelki pośrednie. Na upartego możesz do tego wykorzystać Ssis jak mają xl to maj SQL serwera czyli mają też ssis
W moim przypadku wygląda to tak:
WMS komunikuje się za pomocą plików csv (przez FTP).
Po stronie ERP jest API.
Program łączący systemy co jakiś czas
- Sprawdza czy w ERPie pojawiły się dokumenty do eksportu do WMS (taki dokument oznaczany jest w odpowiedni sposób) - jeżeli tak to generuje plik z dokumentem, plus niezbędne dodatkowe pliki (np. kartoteki).
- Sprawdza czy na FTP są nowe pliki, jeżeli tak to przez API dodaj/modyfikuje dokumenty do ERP a plik przenosi do archiwum - tutaj czasami potrzebna jest interakcja użytkownika dlatego działa to jako program.
Komunikatów wyjściowych z ERP na godzinę może być ok. 200. Teoretycznie dane dokumentu nie ulegają zmianie, ale jednak będą wysyłane komunikaty nagłówkowe aktualizujące (np. datę realizacji dostawy). Karty towarowe też mogą być zmodyfikowane np. nazwa i trzeba to wysłać do WMS. Dlatego te tabele wydają się przydatne i rozwiązanie mniej błędorodne jeśli zrobię proste/niezawodne triggery w ERP które w reakcji na zdarzenie w ERP zrobią tylko prostą wrzutkę nowego rekordu w tabeli pomocniczej(nrDok,status) ewentualnie update statusu jeśli już taki dok lub towar był wysyłany.
Zainteresował mnie też pomysł Ssis. Mógłbyś coś więcej napisać jak by to miało działać
Odnośnie tego co pisze hipekk to ja karty będę przenosił automatycznie jak się utworzą w ERP, a nie jak się wysyła dok. I u mnie interakcja jest raczej wykluczona, chyba że w sytuacji awaryjnej gdy coś nie przejdzie tak jak trzeba
Zrób sobie prosty serwis, który tworzy dokumenty jakieś tam ... potestuj bo
API do Twojego systemu ma swoja „specyfikę” .... będziesz dostawać błędy jak je (api) zaczniesz wołać wielowatkowo z webserwisu.
Zobacz tutaj
https://www.spolecznosc.comarch.pl/question/mam-dosc-duzy-problem-z-api-20160-c-17497
Mam sporo do czynienia z tym erp i zrobiłbym aplikację, która sprawdza czy jest coś do roboty i robi lub kończy działanie. Taka job lista, która może powstać z webserwisu. Komunikacja api zapakowałbym to w zaplanowane zadania. O jakich ilosciach dokumentów mówimy? Średnia ilość pozycji na dokumencie?
Wtedy watek powyżej pomijamy.
Mialem problemy z tym w webserwisach.
SQL Server itegration Services to jest narzędziem do integracji. Mają różnego rodzaju konektory i wyjściowym wynikiem jest paczka którą możesz zbudować i odpalić SQL agencie
Jeżeli chodzi o Api XL-a to znam temat wątku clarionowego. Po jego podpięciu funkcją AttachThreadToClarion(int _flag) z reguły jest ok. Aczkolwiek mimo to zdarzy się że funkcja nie zwróci odpowiedzi i serwis wymaga restartu. Trzeba pamiętać że Api Xl-a działa jednowątkowo, logujemy się jako konkretny użytkownik i działamy na przydzielonej sesji w ramach pobranej licencji, czyli coś takiego jak byśmy siedzieli przed interfejsem XL-a. Tu można działać na różne sposoby, przy częstym wołaniu funkcji api można trzymać ID sesji i nie wołać za każdym razem f. logowania, ale należy się zabezpieczyć przed tym że ktoś może np. wyciąć sesje w XL-u, może zabraknąć licencji. Ogólnie z tym Api ciężko zrobić serwis który by nie wymagał restartu przynajmniej raz lub dwa razy w miesiącu
Na pewno nie WinForms.
Webapi na IIS lub Windows service.
Na pewno tzreba zrobić bardzo dokładne logowanie błędów i poprawnych operacji tego co robi XL APi z wygodnym dostępem. Przyda sie.
Ja mam Windows Service z SelfHostedApi i logowanie do 2 tabel operacji tworzenia dokumentów i dodawania pozycji z informacjami i loginów XL, towarach ilościach itp.
Logowanie z NLog.
Trzeba też logować dokładnie co przychodzi z WMSa.
Powiadomienia o błędach to już kwestia projektu.
Mój Windows Service restartuje się raz w nocy i działa bez większych problemów. Błędy jakie się pojawiają wynikają z pomyłek ludzkich, jakieś niepoprawne nazwy, indeksy towarów itp. i po logach operacji widac co sie dzieje.
Pytanie do jacek.placek:
- Jakie argumenty przeciwko WinForms?
- Zastanawiałem się nad WebApi ale nie wiem jak miało by to działać? Mam też napisane restowe API ale tam jest wywoływanie kontrolerów przez aplikację z zewnątrz. A tu musi być serwis który sam inicjuje działanie co kilka minut. Sprawdza czy są pliki z WMS i sprawdza bazę ERPa i ewentualnie podejmuje działanie. Czyli rozumiem że kontrolery byłyby niepotrzebne a podczas startu WebApi w klasie Startup należy zarejestrować jakiś serwis z timerem?
- Bo musiałbyś mieć zawsze otwarte okno z aplikacją. Po restarcie trzeba uruchamiać jako jakiś użytkownik itp.
- No to WinSerwice za pomocą TopShelf (bardzo upraszcza), który sprawdza Timerem albo jakimś Quartzem czy są pliki i jak są to coś robi. Komunikacja HTTP WEB API, jeśli jest potrzebna, może być zaszyta w WinService za pomocą WebApi Self Host (jest paczka nuget). I masz wszystko. Do ogarnięcia to nieszczęsne XL API ale to już wiesz.
No przyznaję że fajnie to wygląda. Znalazłem coś takiego w w necie:
pod likiem: https://luktom.net/pl/e669-topshelf-czyli-uslugi-windows-z-gornej-polki
private static void Main(string[] args)
{
HostFactory.Run(x =>
{
x.SetServiceName("MyService");
x.SetDisplayName("MyService");
x.SetDescription("This is sample service powered by TopShelf.");
x.StartAutomatically();
x.UseNLog();
x.Service(service =>
{
service.ConstructUsing(srv => new MyService());
service.WhenStarted(srv => srv.Start());
service.WhenStopped(srv => srv.Stop());
});
});
Czyli mam prostą apkę konsolową którą mogę łatwo debugować i odpalać do testów oraz jedną komendą instaluję WinService.
Tylko jeszcze gdy bym chciał podzielić te zadania na jakieś wątki, chociażby na dwa żeby wyodrębnić to Api XL-a, np. oddzielić stronę wejściową WMS -> XL oraz wyjściową XL -> WMS to miałbym to zrobić w "MyService" odpalając tam niezależne taski, czy też robić to jako dwa takie serwisy. Z tym że nie wiem czy da się uruchomić dwa serwisy na raz czy też trzeba dwie takie aplikacje?
Napisz sobie worker service w .net CORE który będzie jako usługa windowsowa na serwerze i masz problem rozwiązany.
https://codeburst.io/create-a-windows-service-app-in-net-core-3-0-5ecb29fb5ad0
Pisałem niedawno takie coś i wszystko super śmiga. No i przede wszystkim pamiętaj że API XL'a jest 1-wątkowe.
Dzięki za każde info, myślę że w kwestii hostowania serwisu wszystko jest jasne