Forum ERP XL

Witam,
Napisałem aplikacje w ASP.NET 5, której jednym z zadań jest wystawianie WZ w XL.
Podpiąłem bibliotekę z api i napisałem funkcję, która ma otworzyć XL w trybie interaktywnym z nowym dokumentem. Tryb ma być interaktywny żeby użytkownik mógł sprawdzić od ręki poprawność dokumentu.
Podpiąłem funkcję z API pod button i się zaczęła zabawa. Jak odpalam aplikację z poziomu visual studio wszystko działa prawidłowo, tworzy się nowy dokument i jest opcja pracy na nim. Jednak po wrzuceniu projektu na IIS i próbie wywołania funkcji do XL nie dzieje się nic.
Program nie zwraca błędu, nie otwiera XL, wisi na kliknięciu buttona.
Przekopałem chyba całe forum w tej sprawie ale nie mogę znaleźć rozwiązania żeby zaczęło to działać.
Spotkał się może ktoś z takim problemem i jest w stanie nakierować gdzie może leżeć problem.

A co widać przy próbie debugowania z VS aplikacji uruchomionej pod IIS ?
Ja do tej pory kompilowałem wszystkie dodatki do XL pod .Net 4.
Podejrzewam problemy identyfikacji np. bazy danych ERPXL z wpisów w rejestrze przez użytkownika przypisanego do ISS.
Czy użytkownik ISS ma dostęp do instancji CDNXL ustawionej w zmiennej path ?

Przy debugowaniu z VS pod IIS wszystko działa prawidłowo.
Dopiero po opublikowaniu i wrzuceniu na serwer IIS przestaje działać.

IIS_IUSRS ma dostęp do ścieżki gdzie jest zainstalowany XL, która jest w PATH. Bazy podpięte są dla wszystkich użytkowników systemu. Włączone w IIS obsługa 32bitowych aplikacji. Nie wiem czy coś jeszcze pominąłem?
Tak myślę, w samej bazie jest potrzebny dodatkowy użytkownik pod aplikację? Jeżeli tak to gdzie w momencie wywołania API ten użytkownik musi być ewentualnie przypisany.

Czy na serwerze IIS może Pan debugować aplikację za pomocą Remote Tools for Visual Studio ?
Zaczynając sesję od api.XLLogin(loginInfo, ref session), możemy w loginInfo podać m.in. usera ERPXL i jego hasło.

Żaden ze mnie Pan .
Przy debugowaniu jedno razowo otrzymałem błąd

unhandled win32 exception in w3wp.exe

A do samego logowania mimo podania danych nawet nie dochodzę. Wydaje mi się, że problem leży wyłącznie po stronie IIS.
Uruchomiłem na serwerze plik exe z projektem, zalogowałem się na stronę po przypisanym porcie 5000, i wtedy api również zadziałało prawidłowo.
Po wejściu na stronę przez IIS zero reakcji. W logach pusto, zwracam do pliku kody błędów api i tam tez pusto. Dlatego tak ciężko mi się czegoś złapać.

Cześć,

Zobacz w Event Viewer (Podgląd zdarzeń) co jest w logach systemowych. To powinien być pierwszy krok do diagnozy i naprawy problemu.

Przerobiłem kilka tematów z IIS pod CDN XL, ogólnie nie polecam

Zgadzam się z kolegą.
Strzelanie do api XL z poziomu przeglądarki może przyprawić o sporo siwych włosów. Wieczna walka z wątkami. W starych Formsach jeszcze dało się jako tako to wymusić, ale MVC .NET to była już jazda (customowy HttpHandler, RouteHandler). A i tak nie było pełnej niezawodności. Wydaje się że najlepszym rozwiązaniem jest buforowanie zadań z aplikacji web (czy to w bazie czy np. w jakiejś kolejce typu RabbitMQ) i odczytywanie ich za pomocą usługi współpracującej z XL API działającej po stronie serwera.

Dzięki panowie za odpowiedź .
Szczerze jestem na 4 dniu walki i zaczynam myśleć czy tego właśnie w jakiś sposób nie obejść. IIS zaczyna mi się śnić po nocach.

Koordak - dzięki za pomysł z podglądem zdarzeń, nie wiem czemu na to nie wpadłem.
Więc sytuacja wygląda tak, po ogarnięciu chyba z 4 błędów, które były w podglądzie zdarzeń i debugowaniu z poziomu serwera stanąłem na kolejnym problemie. Mianowicie debuger nie przechodzi za linię

cdn_api.cdn_api.XLLogin(Logowanie, ref SesjaID);

Dzieje się tak przy próbie wywołania logowania w trybie interaktywnym tak by pobrała się licencja użytkownika, który się zaloguje i otworzy się formatka dokumentu. W tym momencie visual studio zwraca

Exception thrown: 'System.OperationCanceledException' in System.Private.CoreLib.dll

W przypadku wywołania trybu wsadowego logowanie przechodzi prawidłowo i cały program dalej się wykonuje, nawet zapisują się logi (to dla mnie nowość, dotychczas logi miałem czyste od strony XL).
Niestety nie daje mi to efektu, który chcę osiągnąć i zaczynam się zastanawiać czy to możliwe żeby wywoływać to logowanie interaktywne (w dokumentacji też comrach poleca tryb wsadowy, który mimo wszystko trochę mnie ogranicza przez chociażby to, że zawsze będzie jeden operator przypisany do wszystkich dokumentów).
Wątki niby ma mi ogarnąć

[DllImport("ClaRUN.dll")]
static extern void AttachThreadToClarion(int _flag);

ale jak to w praktyce działa jeszcze nie testowałem. Tzn czy zadziała kilka razy i stwierdzi, że czas się wykrzaczyć, a wtedy zostaje odnowienie puli aplikacji.

Zapamiętaj że API jest jednowątkowe.

Dlatego też stawianie aplikacji na IIS jest problematyczne bo ciężko bardzo zarządzać sesjami itp.

Tak jak kolega wyżej napisał Twoja architektura powinna wyglądać tak:

Client 1 <------> API ---> CDN XL
Client 2 <------>

Całe myk polega na tym że API powinno procesować jeden request na raz który wykonuje operacje na CDN XL.

Można to rozwiązać na kilka sposobów:

- Piszesz windows service, .net core worker service, który czyta wiadomości z MQ kolejek
- Piszesz REST API serwis na IIS lub jako hostowany windows service który metody z API procesuje pojedynczo na jednym Thread LOCK'ująć requesty.


IIS odradzam z tego powodu że mimo iż mam napisany REST API który jest na IIS to czasami DLL z Comarcha wysypuje się i trzeba resestować cały IIS aby uruchomić na nowo api.

Dlatego z mojej praktyki najlepszym rozwiązaniem jest obecnie windows serwis, który działa w inifnity loop i w razie W może też się sam restartować jeżlei jest uzywany health check.

Ogólnie jakbyś chciał to napisz do mnie na priv chętnie pro bono podzielę się doświadczeniami + mam mały deal do zrobienia też więc może jakaś synergia w tym temacie się fajna urodzi.

Pozdrawiam.