Który program ma bardziej rozbudowane API – Subiekt GT czy Subiekt nexo?

Subiekt nexo ma nowocześniejsze i szersze API (Sfera nexo) niż Subiekt GT, co ułatwia budowę własnych integracji.

Zakres interfejsu Sfera w Subiekcie GT

Subiekt GT udostępnia mechanizm programistyczny Sfera dla Subiekta GT. Jest to biblioteka obiektów przeznaczona do tworzenia rozszerzeń korzystających z wewnętrznych mechanizmów programu. Sfera GT została oparta na technologiach COM i OLE Automation, dlatego integracja zwykle polega na nawiązaniu przez aplikację zewnętrzną połączenia z obiektowym interfejsem programu, pobraniu lub utworzeniu odpowiednich obiektów oraz wywołaniu metod udostępnianych przez bibliotekę. Takie rozwiązanie pozwala automatyzować czynności wykonywane w Subiekcie GT, między innymi pracę z kartotekami, dokumentami sprzedaży i innymi elementami systemu.

Rozbudowanie Sfery GT nie oznacza jednak, że Subiekt GT ma ogólne, niezależne od aplikacji REST API dostępne w typowym modelu usług internetowych. Sfera jest dodatkiem do programu i wymaga zgodności środowiska uruchomieniowego z rozwiązaniem przygotowanym dla GT. Istotny jest także sposób licencjonowania: w przypadku Subiekta GT licencja Sfery jest przypisana do stanowiska, więc korzystanie z rozszerzenia na kolejnych stacjach wymaga odpowiedniej liczby stanowisk Sfery. W praktyce zakres integracji zależy od biblioteki obiektów, wersji programu, użytych komponentów oraz prawidłowego zarejestrowania dodatku.

Sfera nexo i model rozszerzeń Subiekta nexo

Subiekt nexo korzysta z Sfery nexo, która udostępnia środowisko tworzenia rozwiązań opartych na bibliotekach platformy nexo i szczegółowej dokumentacji technicznej SDK. W odróżnieniu od starszego modelu COM i OLE Automation stosowanego w Sferze GT, rozwiązania nexo są projektowane wokół współczesnego środowiska programistycznego oraz typów domenowych opisujących dane i operacje systemu. Programista może pracować z obiektami odpowiadającymi między innymi kartotekom asortymentu, kontrahentom, dokumentom i operacjom handlowym, zamiast ograniczać integrację do bezpośredniego sterowania interfejsem użytkownika.

Sfera nexo pozwala również tworzyć własne operacje widoczne w menu programu, raporty sferyczne oraz rozszerzenia dodające czynności wykonywane z poziomu formatek i serwisów. W praktyce oznacza to możliwość umieszczenia własnej funkcji bezpośrednio w miejscu, w którym użytkownik pracuje z dokumentem albo kartoteką. W ekosystemie nexo występuje także InsERT API przeznaczone do integracji aplikacji webowych firmy InsERT, natomiast jego dostępność i zakres należy sprawdzać osobno dla danego produktu oraz sposobu wdrożenia. Nie należy utożsamiać każdego rozwiązania określanego potocznie jako API z tym samym interfejsem programistycznym.

Dlaczego Subiekt nexo ma bardziej rozbudowane API

Odpowiedź na pytanie z hasła brzmi: bardziej rozbudowane API ma Subiekt nexo, przede wszystkim w postaci Sfery nexo. Wynika to z nowszego modelu rozszerzeń, szerszego SDK i większej liczby mechanizmów przeznaczonych nie tylko do automatyzacji pojedynczych czynności, lecz także do budowy własnych operacji, raportów oraz integracji obejmujących różne obszary pracy programu. Subiekt GT również może być skutecznie integrowany, ale jego Sfera jest starszym interfejsem opartym na COM i OLE Automation oraz wymaga dodatku licencyjnego dla stanowiska.

Różnica nie sprowadza się więc do samej liczby dostępnych metod. Dla integratora ważne są także sposób modelowania danych, możliwość obsługi reguł biznesowych programu, dostępność dokumentacji, obsługa rozszerzeń w interfejsie użytkownika oraz możliwość aktualizowania rozwiązania wraz z kolejnymi wersjami systemu. W Subiekcie nexo rozwiązanie może wykorzystywać obiekty i operacje platformy nexo, a własne funkcje mogą być uruchamiane z menu lub z określonych miejsc programu. W Subiekcie GT podobny cel osiąga się przez obiekty Sfery GT, lecz architektura jest bardziej związana ze starszym mechanizmem automatyzacji. Dlatego przy nowym projekcie integracyjnym nexo zwykle daje szersze możliwości rozwoju, natomiast przy istniejącym wdrożeniu GT znaczenie ma dostępność gotowego dodatku i zgodność z dotychczasowym kodem.

Dobór wersji programu do planowanej integracji

Przed wyborem Subiekta GT albo Subiekta nexo warto opisać integrację jako konkretny przepływ danych. Należy ustalić, czy rozwiązanie ma tylko odczytywać kartoteki, czy także tworzyć dokumenty, modyfikować pozycje, uruchamiać operacje zbiorcze, generować raporty albo dodawać własne polecenia do menu. Trzeba również sprawdzić, czy integracja ma działać lokalnie przy stanowisku z programem, czy ma współpracować z aplikacją webową. Te wymagania wpływają na wybór właściwego interfejsu, licencji, wersji SDK oraz sposobu obsługi błędów.

Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i ich podzespołów, dlatego przy problemach ze stanowiskiem używanym do pracy z Subiektem można rozpocząć od diagnostyki komputera, systemu operacyjnego, dysku, pamięci oraz połączeń urządzeń. Sama diagnoza problemu integracyjnego wymaga jednak rozdzielenia usterki sprzętowej od błędu konfiguracji, licencji albo kodu rozszerzenia. Przykładowo wolne działanie programu nie musi oznaczać awarii komputera, a brak możliwości uruchomienia dodatku może wynikać z niezgodnej wersji Sfery, braku rejestracji lub błędnego środowiska programistycznego. Wniosek pozostaje jednoznaczny: Subiekt nexo oferuje bardziej rozbudowany i nowocześniejszy model API, natomiast Subiekt GT nadal udostępnia użyteczną Sferę dla istniejących integracji.