Jak bezpiecznie i wygodnie łączyć dane z wielu źródeł

Warto połączyć te źródła, których ręczne przepisywanie powoduje opóźnienia, powielanie pracy albo rozbieżności w decyzjach. Typowy przepływ operacyjny obejmuje sklep internetowy, ERP, CRM, system księgowy i narzędzie do raportowania, ale nie każdy system powinien otrzymywać pełną kopię danych.

Dane operacyjne obsługują bieżące zdarzenia, takie jak zamówienie, rezerwacja stanu czy wystawienie dokumentu. Dane raportowe służą do analiz i mogą być aktualizowane z opóźnieniem, jeżeli raport nie steruje bieżącą realizacją zamówień.

Mapę zaczynamy od procesu, a nie listy posiadanych aplikacji. Dla każdego przepływu zapisujemy zdarzenie, nadawcę, odbiorcę, potrzebne pola, częstotliwość, właściciela biznesowego oraz skutek braku danych.

Tabela pokazuje przykładowe źródła danych firmowych i ryzyka, które warto uwzględnić podczas ich łączenia.

Tabela pomaga wskazać, które źródła wymagają przepływu operacyjnego, a które wystarczy zasilać do analiz. Decyzję o zakresie dostępu podejmujemy osobno dla każdego procesu.

Systemem źródła prawdy dla danego pola jest aplikacja, której zatwierdzona wartość ma rozstrzygać konflikt. Nie wybieramy jednego nadrzędnego systemu dla całej firmy, ponieważ sklep może odpowiadać za status zamówienia, a ERP za indeks produktu lub stan magazynowy.

Regułę zapisujemy na poziomie pola, nie tylko obiektu. Produkt może mieć nazwę handlową zarządzaną w ERP, opis marketingowy w sklepie oraz cenę promocyjną wyliczaną przez osobny mechanizm. Integracja musi znać właściciela każdego z tych pól.

Tabela pokazuje przykładowe systemy nadrzędne, odbiorców oraz reguły rozstrzygania konfliktów dla wybranych pól.

Tabela jest wzorem do uzgodnienia, a nie uniwersalną konfiguracją. Właściciele procesu powinni zatwierdzić każdą komórkę przed uruchomieniem synchronizacji.

Gdy dwa systemy mogą zmieniać to samo pole, ustalamy kolejność zdarzeń i warunek nadpisania. Możemy na przykład zaakceptować zmianę tylko wtedy, gdy rekord ma nowszy znacznik czasu i pochodzi z uprawnionego źródła. Z naszych wdrożeń wynika, że brak takiej reguły często ujawnia się dopiero po ręcznej korekcie wykonanej w systemie odbiorczym.

Przy przepływach obejmujących dokumenty sprzedaży i system księgowy warto wcześniej uzgodnić również rolę KSeF oraz ERP. Wdrożenie KSeF w Subiekcie GT może objąć połączenie tych elementów w procesie fakturowania.

Sposób łączenia danych wybieramy według częstotliwości, wolumenu, dostępnych funkcji interfejsów i wymaganej obsługi błędów. API to programowy interfejs wymiany danych, który pozwala systemom wymieniać informacje według zdefiniowanych reguł; gotowy konektor to przygotowany adapter, a automatyzacja no-code pozwala budować przepływy bez pisania większości kodu.

Tabela porównuje sposoby łączenia danych według częstotliwości, obsługi błędów, wymagań technicznych i zastosowania.

API daje większą kontrolę nad walidacją i ponawianiem, jeżeli integracja została tak zaprojektowana. Konektor może skrócić konfigurację, lecz przed wyborem trzeba sprawdzić zakres pól, kierunek przepływu, logi i zachowanie przy błędzie. Google Apps Script ma limity usług i czasu wykonania, a Microsoft Power Automate podlega limitom żądań Power Platform; wartości mogą zależeć od konta lub licencji i zmieniać się w czasie. Google i Microsoft opisują te ograniczenia w oficjalnych materiałach: limity usług Google Apps Script oraz limity żądań Microsoft Power Platform.

Import pliku jest użyteczny przy jednorazowym przenoszeniu danych, ale nie daje sam z siebie kontroli aktualizacji w czasie rzeczywistym. Zalecamy rejestrować datę eksportu, liczbę wierszy, identyfikator partii oraz wynik walidacji. Koszt utrzymania przepływu obejmuje także obsługę wyjątków, zmian API, limitów i ręcznych korekt, a nie tylko samo pierwsze połączenie.

Bezpieczna synchronizacja ogranicza dostęp do niezbędnych pól i używa osobnych, kontrolowanych poświadczeń dla integracji. Konto techniczne to konto wykorzystywane przez proces automatyczny, a nie przez konkretnego pracownika; powinno mieć tylko uprawnienia konieczne do odczytu lub zapisu wyznaczonych danych.

Przed uruchomieniem sprawdzamy:

• czy połączenie korzysta z szyfrowania transportowego, a sekrety nie są umieszczone w adresie URL ani kodzie dostępnym dla nieuprawnionych osób;
• czy zakres danych odpowiada celowi procesu, a dostęp konta technicznego można odebrać bez blokowania innych usług;
• czy logi zapisują identyfikator operacji, czas i wynik bez kopiowania haseł, tokenów ani zbędnych danych osobowych;
• czy kopie robocze, pliki eksportowe i dane testowe mają właściciela oraz określony czas przechowywania;
• czy dostęp do logów i konfiguracji mają wyznaczone osoby.

Log integracji powinien umożliwiać ustalenie, co się stało, bez ujawniania sekretów. Zapisujemy identyfikator rekordu lub partii, typ błędu, czas, źródło, cel i wynik ponowienia. Szczegółowe zasady bezpiecznego projektowania usług API publikuje OWASP w REST Security Cheat Sheet.

Duplikaty ograniczamy przez stabilny identyfikator, walidację wymaganych pól i jawną regułę scalania rekordów. Stabilny identyfikator to wartość, która rozpoznaje ten sam obiekt w każdym systemie, na przykład uzgodniony numer klienta; sama nazwa, adres e-mail lub nazwa produktu może się zmieniać albo powtarzać.

Normalizujemy formaty przed porównaniem. Dla klienta można ujednolicić wielkość liter w adresie e-mail, odstępy i zapis numeru telefonu, ale nie wolno automatycznie scalać rekordów tylko dlatego, że nazwy firm są podobne.

Przykład: "ABC Serwis" i "ABC-Serwis sp. z o.o." mogą oznaczać ten sam podmiot, ale nazwa nie wystarcza do scalenia. Reguła może wymagać zgodnego identyfikatora podatkowego lub ręcznej akceptacji, jeśli dane są niepełne.

Walidacja powinna zatrzymać rekord, którego brak pola uniemożliwia bezpieczny zapis. Pozostałe rekordy mogą przejść dalej, jeśli integracja zapisze odrzuconą pozycję do kolejki błędów i pokaże ją właścicielowi procesu.

Po błędzie synchronizacji najpierw ustalamy ostatni poprawny etap i zakres rekordów, których dotyczy problem. Ponowienie całej partii bez sprawdzenia może utworzyć duplikaty albo powtórzyć skutki częściowo wykonanej operacji.

Tabela pomaga przypisać typowy objaw do miejsca kontroli, działania naprawczego i właściciela.

Procedura obsługi błędu powinna wskazać etap, właściciela, sposób ponowienia i warunek zamknięcia incydentu. Dla błędu częściowego porównujemy identyfikatory rekordów w źródle i systemie docelowym, a potem ponawiamy tylko brakujące operacje, jeśli integracja obsługuje bezpieczne ponawianie.

Tabela wskazuje kolejność sprawdzania przepływu od systemu źródłowego do raportu.

Ta procedura rozdziela awarię połączenia od błędu danych i błędu prezentacji w raporcie. Właściciel procesu zamyka incydent po potwierdzeniu poprawionych rekordów oraz zapisaniu przyczyny.

Integrację testujemy na reprezentatywnej próbce, obejmującej poprawne rekordy, braki, duplikaty, zmianę statusu i przerwane połączenie. Kryterium odbioru ustalamy przed testem: przykładowo wszystkie rekordy próbki mają znaleźć się w celu z tym samym uzgodnionym identyfikatorem i wartościami pól.

Plan testów obejmuje:

1. Sprawdzenie mapowania wymaganych i opcjonalnych pól.
2. Test rekordu niekompletnego oraz wartości spoza słownika.
3. Ponowienie tego samego zdarzenia i kontrolę, czy nie tworzy duplikatu.
4. Test braku uprawnień konta technicznego do niedozwolonej operacji.
5. Przerwanie połączenia i wznowienie od ostatniego potwierdzonego rekordu.
6. Porównanie liczby rekordów oraz sum wartości przed i po przesyle.
7. Odtworzenie procesu z kopii lub środowiska testowego.

Test odbiorczy podpisuje właściciel procesu, a test techniczny osoba odpowiedzialna za integrację. Microsoft opisuje testy rozwiązania jako część wdrożenia Dynamics 365, w tym określanie zakresu, planu i wyników: wytyczne Microsoft dotyczące testowania Dynamics 365.

Jakość połączonych danych monitorujemy przez opóźnienie, błędy, brakujące rekordy, duplikaty i rozbieżności wartości. Każda miara potrzebuje właściciela, progu reakcji i miejsca, w którym zespół zobaczy alert.

Tabela przedstawia przykładowy plan kontroli jakości połączonych danych i przypisuje odpowiedzialność za reakcję.

Częstotliwość należy dopasować do skutku opóźnienia. Dla raportu zarządczego kontrola okresowa może wystarczyć, a dla zamówień blokujących wysyłkę potrzebny jest alert operacyjny. Perspektywa KC Mobile: podczas wdrożeń sprawdzamy nie tylko, czy integracja zwróciła sukces, lecz także czy odbiorca zapisał oczekiwane wartości i czy raport korzysta z aktualnych danych.

Jeżeli połączenie obejmuje sklep WooCommerce i ERP, integracja Subiekta z WooCommerce może objąć uzgodnienie pól i przepływów między tymi systemami. Gdy proces fakturowania łączy się z KSeF i Subiektem GT, wdrożenie KSeF w Subiekcie GT pozwala omówić zakres takiego przepływu.

• KSeF i CRM: jak przygotować dane oraz procesy firmy do obsługi faktur
• Integracja API KSeF: jak zaplanować połączenie i testy
• Numeracja faktur w KSeF a dotychczasowy system numeracji: jak je pogodzić
• Różnica między BPM a ERP: co wybrać do zarządzania firmą?