Łączenie dwóch systemów: co sprawdzić, zanim obieca się integrację

„Czy te dwa systemy się ze sobą komunikują?” to pytanie, na które nie da się odpowiedzieć. Komunikują się, żeby zrobić co: jakie dane, w jakim kierunku, z jaką częstotliwością i kto ma rację, gdy oba systemy mówią co innego. Ten przewodnik pomaga odpowiedzieć na te pytania, zanim podejmie się zobowiązanie, ponieważ obiecana, ale niezweryfikowana integracja zamienia projekt w nieustanne utrzymanie.

Niemal wszystkie nieudane integracje mają tę samą historię: w testach działało, potem pojawił się nieprzewidziany przypadek — anulowane zamówienie, klient z dwiema kartotekami, usunięty produkt — i nikt nie zauważył, że od trzech dni nic już nie przechodzi.

Jeden wiersz na każdą daną

Punktem wyjścia jest lista: jeden wiersz na daną, cztery kolumny. Jeśli nie udaje się jej wypełnić, nie jest to jeszcze moment na przyglądanie się specyfikacjom technicznym.

Ostatnia kolumna to ta, która pozwala uniknąć sporów. Jeśli cena produktu różni się w obu systemach, który wygrywa? Jeśli odpowiedź brzmi „to zależy”, integracja będzie generować niespójne dane niezależnie od zastosowanej technologii.

Dane, które zmieniają właściciela po drodze

Niektóre dane zmieniają właściciela i to najbardziej delikatny przypadek. Zamówienie należy do strony, dopóki nie zostanie przyjęte; od tego momentu prawda znajduje się w systemie do zarządzania firmą, a strona pokazuje jedynie jej kopię. Jeśli oba systemy mogą je modyfikować, prędzej czy później dwie zmiany się zderzą i wygra ta, która przyszła jako ostatnia, co niekoniecznie oznacza tę właściwą.

Praktyczna zasada jest jedna: dla każdej danej, w każdej chwili, tylko jeden system może ją zapisywać. Pozostałe tylko odczytują.

Czego interfejsy nie mówią na pierwszej stronie

• Uprawnienia. Udostępnione Państwu dane dostępowe mogą nie obejmować wszystkich potrzebnych pól, a autoryzacja może wygasać lub wymagać okresowego odnawiania, o czym ktoś musi pamiętać.
• Limity. Ile zapytań na minutę lub na dzień, ile rekordów na jedno żądanie. Duży katalog może nie mieścić się w tych limitach przy potrzebnej częstotliwości, a to zmienia projekt, nie tylko kod.
• Pola faktycznie dostępne. Dokumentacja wymienia obiekty, ale nie zawsze mówi, czy Państwa niestandardowe pola są udostępnione: trzeba to sprawdzić na własnych danych, a nie na przykładzie.
• Środowisko testowe. Jeśli nie istnieje, każda weryfikacja odbywa się na rzeczywistych danych, ze wszystkimi tego konsekwencjami. To ograniczenie trzeba wziąć pod uwagę wcześniej, a nie odkryć później.
• Warunki dostawcy. Co jest dozwolone, w jakim planie, i czy dostęp do wymiany danych jest wliczony, czy stanowi osobny koszt.

Karta integracji: zamówienie, które przychodzi dwa razy

Przypadkiem, który trzeba zaprojektować, nie jest ten normalny, lecz ten nieczysty. Zamówienie zostaje wysłane do systemu do zarządzania firmą, odpowiedź nie przychodzi z powodu problemu z siecią, system ponawia próbę i zamówienie trafia do systemu dwa razy. To najczęstsza ze wszystkich usterek.

1. Każda wiadomość niesie stały identyfikator, ustalony przez nadawcę: numer zamówienia ze strony, a nie kolejny numer generowany w momencie wysyłki.
2. Odbiorca sprawdza, czy dany identyfikator został już przetworzony. Jeśli tak, nic nie powtarza i odpowiada, że sprawa jest już załatwiona. To właśnie ta właściwość sprawia, że ponawianie prób jest bezpieczne.
3. Próby powtarza się w rosnących odstępach czasu i przez określoną liczbę razy; potem wiadomość trafia do kolejki błędów, którą przegląda człowiek. Nieskończone ponawianie prób ukrywa problem, zamiast go rozwiązywać.
4. W regularnych odstępach porównuje się oba systemy za dany okres: ile zamówień po jednej stronie, ile po drugiej, których brakuje. To uzgadnianie danych i jest to jedyna rzecz, która naprawdę pokazuje, czy integracja działa.
5. Naprawa sytuacji to spisana procedura: kto usuwa duplikat i w którym systemie, co dzieje się z dokumentem, jeśli został już wystawiony, kto powiadamia klienta, jeśli otrzymał dwa potwierdzenia.

Taką samą kartę należy wypełnić dla kartoteki klienta, gdzie typowa usterka jest inna: dwie kartoteki dla tej samej firmy, utworzone z numerem VAT zapisanym na dwa różne sposoby. Potrzebna jest wcześniej ustalona reguła rozpoznawania oraz miejsce, do którego trafiają wątpliwe przypadki, zanim przejrzy je człowiek.

Kto zauważa, gdy integracja się zatrzymuje

Integracja prędzej czy później zawsze się zatrzymuje: dostawca wprowadza aktualizację, hasło wygasa, certyfikat nie zostaje odnowiony, pole zmienia format. Pytanie nie brzmi, czy to się wydarzy, lecz ile czasu minie, zanim ktoś to zauważy.

• Kontrola, która sprawdza niedawny przepływ danych i ostrzega, gdy się on przerywa, zamiast czekać na telefon od klienta.
• Konkretny odbiorca, z imieniem i nazwiskiem, dla tego powiadomienia, oraz drugi, na wypadek gdy pierwszego nie ma.
• Rejestr wymian danych, który można sprawdzić bez dzwonienia do programisty: gdy zamówienie nie dociera, pierwsze pytanie zawsze brzmi „czy zostało wysłane?”.
• Jasno określona odpowiedzialność za utrzymanie, z terminami ważności danych dostępowych i certyfikatów zapisanymi w miejscu, które ktoś regularnie sprawdza.

Czego ten przewodnik nie obejmuje

Tutaj projektuje się wymianę danych między dwoma systemami, które mają ze sobą współistnieć. Przeniesienie danych historycznych — ze starego systemu do zarządzania firmą albo z arkuszy kalkulacyjnych — to inne zadanie, z problemami czyszczenia danych i kontroli wyniku, i ma swój własny przewodnik. Osobno omówiony jest także konkretny przypadek połączenia sklepu internetowego z magazynem.