Integracja Subiekta GT z aplikacją webową: co ustalić przed wdrożeniem?
Jeśli zamówienia z aplikacji webowej trzeba przepisywać do Subiekta GT, zacznij od ustalenia, jakie dane mają przechodzić między systemami, kto może je zmieniać i po czym pracownik pozna, że operacja się udała. Dopiero na tej podstawie można wybrać gotowy integrator albo wycenić własne połączenie. Samo przesłanie zamówienia nie rozstrzyga jeszcze, czy powstał właściwy dokument i czy można rozpocząć realizację.
Przed wdrożeniem potrzebne są również zasady działania podczas przerw w komunikacji. Sklep lub portal może nadal przyjmować zamówienia, gdy część obsługująca Subiekta jest niedostępna, ale trzeba ustalić, gdzie zapiszą się zaległe operacje i jak zespół rozpozna opóźnienie. To decyzja o organizacji sprzedaży, a nie tylko o połączeniu dwóch programów.
Czy Subiekt GT ma API do aplikacji webowej?
InsERT udostępnia Sferę dla Subiekta GT: dodatek pozwalający tworzyć rozszerzenia korzystające z mechanizmów programu, między innymi do obsługi zamówień ze sklepu internetowego. Sfera daje wykonawcy dostęp do funkcji Subiekta, ale nie jest gotowym serwisem internetowym, do którego wystarczy wysłać żądanie z przeglądarki.
Dokumentacja techniczna InsERT wskazuje COM i OLE Automation. Są to mechanizmy pozwalające innemu programowi wywoływać funkcje Subiekta. Przy połączeniu z aplikacją webową trzeba więc zaplanować część integracji, która obsłuży Sferę, oraz sposób komunikacji z nią. API webowe może udostępniać gotowy integrator albo oprogramowanie przygotowane przez wykonawcę. W ofercie powinno być jasno wskazane, kto dostarcza ten element i odpowiada za jego aktualizacje.
Subiekt GT Sfera ma wymagania dotyczące Windows i Microsoft SQL Server. Aplikacja webowa może działać w innym środowisku, lecz trzeba uwzględnić utrzymanie części współpracującej z Subiektem. Ustal, na jakim komputerze lub serwerze będzie działała, w jakich godzinach i kto zadba o jej ponowne uruchomienie po awarii.
Jakie dane mają być wspólne i który system może je zmieniać?
Zamiast zlecenia „synchronizujemy wszystko” opisz jeden pełny przebieg zamówienia. Gdzie powstaje, kiedy jest zatwierdzane, jaki dokument ma pojawić się w Subiekcie i jaka informacja wraca do aplikacji? Osobno ustal, co dzieje się po zmianie ilości, anulowaniu lub zwrocie. Wysłanie pierwotnego zamówienia nie załatwia jego późniejszej obsługi.
Każda grupa danych potrzebuje określonego źródła. Jeżeli ceny ustala zespół w Subiekcie, a opisy produktów powstają w sklepie, integracja powinna respektować ten podział. Dwie niezależne edycje tego samego pola wymagają reguły rozstrzygnięcia albo przekazania konfliktu pracownikowi. Sam wybór wartości z późniejszą datą może nadpisać świadomą decyzję drugiej osoby.
Do ustaleń należą również identyfikatory produktów i klientów, jednostki sprzedaży, magazyn, rabaty oraz sposób przekazywania kwot i stawek podatkowych. Przykładowo jedno opakowanie w aplikacji może odpowiadać kilku sztukom w magazynie. Taki przypadek trzeba pokazać na danych testowych, zanim automatyzacja zacznie tworzyć dokumenty.
Stan widoczny w sklepie wymaga osobnej definicji. Ustal, czy ma oznaczać ilość w magazynie, ilość po uwzględnieniu rezerwacji czy inną wartość dostępną do sprzedaży. Określ dopuszczalne opóźnienie aktualizacji i zachowanie przy braku świeżych danych. Okresowe pobieranie stanów samo w sobie nie gwarantuje, że kilku kupujących nie zamówi ostatniej sztuki.
Co zrobić, gdy zamówienie zapisano, ale potwierdzenie nie dotarło?
To ważny scenariusz odbioru integracji: Subiekt zapisał dokument, po czym połączenie zostało przerwane. Aplikacja nie otrzymała odpowiedzi i próbuje wysłać zamówienie ponownie. Bez rozpoznania poprzedniej operacji może powstać duplikat.
Wykonawca powinien pokazać, jak integracja rozpoznaje ponowienie i ustala wynik wcześniejszego zapisu. Stały identyfikator operacji jest jednym z elementów takiego rozwiązania; znaczenie tej zasady opisuje AWS w materiale o bezpiecznym ponawianiu żądań. Samo zapisanie numeru zamówienia w logu nie wystarczy - potrzebny jest sprawdzony sposób powiązania go z dokumentem i rozstrzygnięcia niepewnego wyniku.
Rozdziel także krótką awarię połączenia od błędnych danych, na przykład nieznanego produktu. Zasady ponawiania operacji Microsoft przewidują ponowienia dla problemów przejściowych, z ograniczeniem prób i odpowiednimi odstępami. Błędne dane potrzebują poprawki. Zespół powinien widzieć, które zamówienie czeka, dlaczego oraz kto ma się nim zająć.
Jeżeli pracownik w czasie awarii wprowadzi zamówienie ręcznie, procedura przywrócenia synchronizacji musi to uwzględnić. W przeciwnym razie automat może po powrocie połączenia wykonać już zakończoną pracę ponownie. Uzgodnij, jak oznaczać takie przypadki i sprawdzać zaległości.
Gotowy integrator czy własne połączenie?
Gotowy produkt warto sprawdzić na konkretnym przebiegu zamówienia. Poproś o pokazanie obsługi używanego magazynu, dokumentów, zmian i zwrotów oraz reakcji na przerwane połączenie. Lista obsługiwanych systemów nie mówi jeszcze, czy rozwiązanie odpowiada zasadom pracy Twojej firmy.
Własne połączenie ma uzasadnienie, gdy potrzebnego procesu nie da się obsłużyć dostępnym rozwiązaniem albo jego ograniczenia powodują istotną pracę ręczną. W wycenie powinny znaleźć się również testy, obsługa błędów, dokumentacja i utrzymanie. Odpowiedzialność za tę część pozostaje także po uruchomieniu integracji.
Przed porównaniem ofert sprawdź wersję Subiekta i warunki licencji. InsERT określa Sferę dla Subiekta GT jako licencję jednostanowiskową z możliwością rozszerzenia. Dostawca powinien potwierdzić wymagane licencje dla proponowanej instalacji. Do kosztu wdrożenia dolicz utrzymanie środowiska, opłaty za integrator, jeśli występują, oraz sprawdzanie zgodności po aktualizacjach.
Przy tworzeniu dokumentów oczekuj wykorzystania mechanizmów programu, które uwzględniają jego reguły. Jeśli propozycja obejmuje bezpośrednie operacje na bazie, wykonawca powinien wyjaśnić ich zakres, wpływ na spójność danych i sposób utrzymania po zmianie wersji. Odczyt danych do raportu i zapis dokumentu sprzedaży wymagają odrębnej oceny.
Jak sprawdzić działanie przed uruchomieniem?
W środowisku testowym przeprowadź zamówienie od aplikacji do dokumentu w Subiekcie i potwierdzenia dla zespołu. Porównaj produkt, ilość, cenę, rabat, magazyn oraz uzgodnione skutki operacji. Odbiór powinien obejmować także ponowne wysłanie tego samego zamówienia, brak produktu, zmianę zamówienia i przerwę w komunikacji. Dla każdego przypadku zapisz oczekiwany wynik.
Sprawdź również wznowienie pracy po restarcie części integracyjnej, obsługę zaległości i zachowanie przy spodziewanym szczycie zamówień. Kryterium czasowe powinno dotyczyć ukończenia potrzebnej operacji, a nie samego przyjęcia jej do wysłania. Warto przeprowadzić próbę razem z osobą, która będzie rozwiązywała wyjątki w codziennej pracy.
Dostęp do połączenia webowego powinien wymagać uwierzytelnienia i uprawnień do konkretnych operacji. Zalecenia OWASP dla usług REST obejmują HTTPS oraz ochronę danych dostępowych. Dane dostępowe do Subiekta i poufne klucze integracji pozostają po stronie serwera; nie powinny trafiać do kodu przeglądarki ani adresów URL. W logach potrzebny jest ślad operacji, bez niepotrzebnego kopiowania danych klientów.
Kto odpowiada za integrację po wdrożeniu?
Ustal jedną ścieżkę zgłaszania problemów, nawet jeśli sklep, Subiekta i połączenie utrzymują różne firmy. Powinno być wiadomo, kto sprawdza błąd, kto poprawia dane, kto może ponowić operację i kto potwierdza usunięcie zaległości. Uzgodnij też zakres wsparcia oraz testy po aktualizacji Subiekta, integratora lub aplikacji webowej.
Do wyceny przygotuj wersję i sposób uruchomienia Subiekta, opis używanych dokumentów oraz przykłady zwykłego zamówienia i wyjątków. Pierwszym etapem integracji systemów i API może być ustalenie przepływu danych, ograniczeń i kryteriów odbioru. Taki zakres pozwala porównać oferty według tego, czy usprawnią obsługę zamówień i zapewnią zespołowi kontrolę nad sytuacjami wymagającymi reakcji.
