Optima, COM, IIS - błąd inicjowania

Odpowiedz Nowy wątek
2019-05-09 17:53
0

Siemka
Niestety, zacząłem pisać nieco kodu wykorzystującego API Optimy (COM) i mam problem.

1.IIS
Aplikacja to .Net Web API na IIS.

Jak uruchamiam z poziomu VS na IIS Express to jest OK (VS uruchomione jako admin).
Jak uruchamiam w Local IIS (i na serwerze testowy w IIS) to linia

Login = Application.LockApp(1, 5000, null, null, null, null);

wywala Błąd inicjowania aplikacji.

Pewnie chodzi o jakieś dziwne uprawnienia.
Dodałem uprawnienia IIS AppPool.NET 4.5 (na tym działa api) do folderu instalacji Optimy.

  1. Console app
    Jak przerzuciłem API na console app + self hosting to nawet działa lokalnie na testowej Optimie. Dodają się kartoteki towarów i jakieś dokumenty.
    Problem jest gdy wrzucę to na serwer klienta. console app z web api jest na serwerze 1 a serwer kluczy Optimy na serwerze 2. W konfiguracji połączenia API (COM) Optimy nie wiedzę żadnych parametrów do ustawienia serwera klucza Optimy. Jest tylko konfiguracja połączenia do bazy danych firmy.
    Efekt jest taki, ze dostaję cały czas info, że nie mogę nic zapisywać w Optimie.

Wiecie coś na ten temat? @AdamWox, możesz coś pomóc? Grzebiesz chyba w tym mocno.

Pozostało 580 znaków

2019-05-09 18:07
0

Zmień sposób logowania. Też miałem z tym problem i niestety odpowiedzi co powoduje kłopot inicjowania aplikacja nie mam. Chyba nawet sam Comarch nie wie, ale...
Możesz skorzystać z drugiego sposobu logowania, który nie wymaga korzystania z Application.LockApp()

static AdoSession Logowanie()
{
    Environment.CurrentDirectory = @"C:\Program Files (x86)\Comarch ERP Optima";
    LoginService login = new LoginService();
    ModuleCollection mc = new ModuleCollection() { Module.KasaBank, Module.Handel };
    login.Login("OPERATOR", "HASLO", "FIRMA", mc);

    return login.LoginInfo.CreateSession();
}

Pozostało 580 znaków

2019-05-09 18:12
0

Dzięki, a LoginService to skąd masz?
i ModuleCollection?

edytowany 1x, ostatnio: jacek.placek, 2019-05-09 18:15

Pozostało 580 znaków

2019-05-09 18:17
1

Potrzebujesz Common.dll i Common.Logic.dll z folderu z Optimą. Do tego dwa usingi

using Optima.Common;
using Optima.Common.Logic.Services;
Testing... :) - jacek.placek 2019-05-09 18:22

Pozostało 580 znaków

2019-05-09 18:43
0

Ja mam Optimę na d:. Skopiowałem sobie te 2 dllki do swojego folderu i podpiąłem
Mimo ustawienia
Environment.CurrentDirectory = @"D:\Program Files (x86)\Comarch ERP Optima";

Krzyczy mi, ze nie może odnaleźć plików. Najpierw Comman.DataAccess (skopiowałem) potem log4net (dodałem), a teraz ERP. U siebie dodałem i działa a na serwerze nie może znaleźć assembly (teraz ERP.dll jak skopiowałem do swojego fodleru Common, Common.Login, log4net i Comon.DataAccess).

Ty w swoich rozwiązaniach kopiujesz te assembly do własnego folderu czy dołączasz z c:\program fiels...?

Pozostało 580 znaków

2019-05-09 18:47
1

Aaaaa, wybacz, zapomniałem o najważniejszym... Aplikacja pisana pod obiekty COM Optimy musi znajdować się w głównym katalogu Optimy. Comarch mi milion razy pisał, że wystarczy Environment.CurrentDirectory, ale niestety nic to nie daje.
Może jakbyś zrobił odwrotnie i skopiował zawartość Optimy do folderu z API to da radę?

Ja piszę apki głównie okienkowe, więc totalnie wszystko pakuje do folderu z Optimą i się nie przejmuje.

edytowany 1x, ostatnio: AdamWox, 2019-05-09 18:48

Pozostało 580 znaków

2019-05-09 18:58
0

Pamiętaj że obiekty COM Optimy są 32-bitowe , w application pool trzeba włączyć zgodność. Ja kopiuje jeszcze same obiekty Clarionowe (te z katalogu C:\Program Files (x86)\Comarch ERP Optima\Interop ) do BIN aplikacji.

Pozostało 580 znaków

2019-05-09 20:22
0

@krzycht: To włączyłem od razu po doświadczeniach z XL-em. Na razie mam konsolowego exe-ka. Jak dopracuję to się pobawię z iisem albo Windows service.

Pozostało 580 znaków

2019-05-09 20:25
0

@AdamWox: u mnie to ma być web śpi więc skopiowanie do folderu Optimy jest raczej możliwe bo tylko na serwerze. W druga strone nie chcialbym kopiować, żeby mieć czysty instalator do aktualizacji.

Pozostało 580 znaków

2019-05-09 20:30
0

Problem niestety jest w tym, że to powinno działać w API, które jest w .NET Framework, ponieważ Optima jest w tym pisana. Comarch niestety nie planuje przejścia na Core, co mnie troszkę martwi, bo trzeba kombinować na dziwne sposoby, aby korzystać z obiektów COM. Pozytyw w .NET Core jest taki, że takie API, albo nawet cała aplikacja webowa może być usługą windows, nie trzeba żadnych IISów, nie trzeba żadnych Kestrelów (domyślam się, że jakoś to jest hostowane) i wiem, że to działa, bo już to robiłem. Tak jak wspomniałem wcześniej, trzeba dziwnie kombinować.

Pozostało 580 znaków

2019-05-15 13:50
0

Już dawno się tym nie zajmowałem, ale z tego co pamiętam to aby aplikacja webowa mogła używać obiektów COM należało:

  • zainstalować na serwerze (tam gdzie jest IIS na którym apka będzie stała) Optimę,
  • stworzyć użytkownika windows, na którym będzie można uruchomić Optimę, spróbować ręcznie się zalogować czy jest dostęp,
  • pula aplikacji przypisana do apki - ustawiamy logowanie (identity) na stworzonego użytkownika (zamiast domyślnego logowania na AppPool identity)
  • na puli właczamy obsługę 32-bitowych aplikacji
    I to chyba wszystko, bez problemu działało. Logowanie mniej więcej chyba tak jak wskazał AdamWox.
    Cała sprawa z nowym użytkownikiem polegała na tym, że ma on wymagane wpisy w zmiennych środowiskowych wskazujące lokalną instalację Optimy.

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0