Łączymy systemy przez REST lub SOAP i synchronizujemy dane
Państwa dane są dziś przenoszone ręcznie między dwoma systemami albo partner wymaga interfejsu API? Łączymy istniejące aplikacje przez REST lub SOAP, synchronizujemy dane między nimi i wysyłamy wiadomości transakcyjne oraz powiadomienia z Państwa procesów.
- Full stack i DevOps od 2012 r.
- Tworzenie API w ColdFusion, Lucee, PHP i Pythonie
- Odpowiedź w ciągu jednego dnia roboczego
Kiedy potrzebny jest interfejs API
Dane są przenoszone ręcznie
Zamówienia, dane klientów lub faktury są eksportowane z jednego systemu i wpisywane w drugim. To kosztuje czas, a literówki wychodzą na jaw dopiero wtedy, gdy klient zapyta.
Partner wymaga interfejsu
Klient, dostawca lub usługodawca chce automatycznie wymieniać dane i przysyła opis swojego interfejsu. Implementujemy interfejs API w Państwa systemie.
Brakuje wiadomości i powiadomień albo przychodzą za późno
Potwierdzenia, faktury lub komunikaty o statusie z Państwa procesów są wysyłane ręcznie albo wcale. Stworzymy API lub podłączymy Państwa system do API dostawcy usługi.
Jeśli stary system ma sam służyć jako usługa, żeby nowe elementy korzystały z jego logiki, właściwym punktem wyjścia jest strona Monolit jako usługa webowa.
Pomagamy też, gdy maile wychodzą, ale trafiają do spamu: Maile trafiają do spamu.
Co podłączamy
- REST z JSON: wywołujemy interfejsy innych systemów albo budujemy własny, który wywołują inne systemy.
- SOAP z XML: podłączamy usługi według ich opisu WSDL, także gdy Państwa własny system jest starszy.
- Synchronizacja danych: między aplikacjami i bazami danych, w stałych odstępach lub przy każdej zmianie, z protokołem przesłanych rekordów.
- Wiadomości transakcyjne i powiadomienia: prosto z Państwa procesów, z SPF, DKIM i DMARC, żeby przechodziły kontrole u odbiorców.
Rozwiązanie techniczne dobieramy do Państwa środowiska, na przykład ColdFusion, Lucee lub PHP. To przykłady, a nie gotowe moduły. Zakres ustalamy na podstawie Państwa przypadku.
Tak powstaje interfejs: od przykładu do eksploatacji
-
Wyjaśnienie przypadku
Na przykładzie opisują Państwo, co wchodzi, co wychodzi, kto wywołuje interfejs i jak często. Na tej podstawie szacujemy nakład pracy.
-
Opis interfejsu
Zapisujemy punkty końcowe lub komunikaty, pola danych, kody błędów oraz przykłady zapytań i odpowiedzi. Państwo i Państwa partner uzgadniają opis, zanim zaczniemy budować.
-
Wdrożenie z testami
Testujemy na fikcyjnych danych, także przypadki błędów: partner nieosiągalny, zdublowane rekordy, nieprawidłowe wartości.
-
Uwierzytelnianie i protokół
Każde wywołanie wymaga uwierzytelnienia i trafia do protokołu. Jak interfejs reaguje na awarie, określa opis.
-
Uruchomienie
Najpierw uruchamiamy interfejs na systemie testowym, jeśli partner go udostępnia, a po Państwa akceptacji na produkcji. Pierwsze przebiegi dokładnie obserwujemy.
-
Przekazanie
Otrzymują Państwo opis, przykładowe wywołania i testy. Kod jest w Państwa repozytorium.
Interfejs, synchronizacja danych czy stary system jako usługa?
| Kryterium | Interfejs między systemami | Regularna synchronizacja danych | Stary system jako usługa |
|---|---|---|---|
| Pasuje, gdy | Dwa systemy mają się nawzajem wywoływać, na przykład przy zamówieniu lub zmianie statusu. | Te same dane są w dwóch systemach i mają być zgodne bez ręcznego przepisywania. | Stary system zawiera logikę, z której mają korzystać nowe aplikacje. |
| Co Państwo dostają | Opisane wywołania w obu kierunkach, z uwierzytelnianiem i protokołem. | Synchronizację w stałych odstępach lub przy każdej zmianie, z protokołem rekordów. | API przed starym systemem i plan budowy nowych elementów obok niego. |
Czego nie obiecujemy
- Interfejs jest tak niezawodny jak systemy na obu końcach. Gdy jeden z nich ulegnie awarii, dane dotrą dopiero wtedy, gdy znów będzie dostępny.
- Synchronizacja nie naprawia błędów w danych źródłowych. Pokazujemy je w protokole, a poprawić muszą je Państwa specjaliści.
- Gdy partner bez zapowiedzi zmieni swój interfejs, połączenie trzeba dostosować. Protokół wcześnie pokazuje takie błędy.
Doświadczenie naszych inżynierów z interfejsami, danymi i pocztą
- Interfejsy
- REST z JSON oraz SOAP z XML
- Bazy danych
- MySQL i MariaDB od 2012 r., do tego Microsoft SQL Server, PostgreSQL i Oracle
- Poczta transakcyjna
- Wysyłka z ColdFusion, Lucee i PHP, łącznie ze zwrotkami i wypisami, SPF, DKIM i DMARC
Jak wdrażamy API
- Na początku pracujemy na dostępach testowych, jeśli partner je udostępnia.
- Kod, dane dostępowe i dokumentacja zostają u Państwa.
- Interfejs zaczyna działać na produkcji dopiero po Państwa akceptacji.
- Mówimy też wprost, gdy własny interfejs się nie opłaca, na przykład dlatego, że wystarczy istniejący eksport.
A co, jeśli u nas ktoś będzie niedostępny? Dokumentację sporządzamy na życzenie. Repozytorium z reguły znajduje się u Państwa. Zastępstwo organizujemy na życzenie.
Interfejsy należą do naszej usługi Rozwój i integracje.
Pytania o interfejsy i synchronizację danych
Czy tworzą i integrują Państwo interfejsy API (REST, SOAP)?
Tak. Tworzymy interfejsy i podłączamy systemy, zarówno przez REST i JSON, jak i przez SOAP i XML, łącznie z synchronizacją danych między aplikacjami. Typowe zastosowania opisujemy na stronie Rozwój i integracje.
Czy da się podłączyć także stary system, który nie ma interfejsu API?
W wielu przypadkach tak. Zależnie od systemu odczytujemy dane z jego bazy danych, wymieniamy pliki albo dodajemy w starym kodzie niewielki interfejs. Która droga się sprawdzi, pokazuje przegląd kodu i bazy danych.
Jeśli stary system ma na stałe służyć jako usługa dla nowych aplikacji, drogę opisuje strona Monolit jako usługa webowa.
Co się dzieje, gdy podłączony system ulegnie awarii?
Interfejs ponawia nieudane wywołania i przechowuje dane w kolejce, dopóki drugi system znów nie będzie dostępny. Każde wywołanie trafia do protokołu, więc da się sprawdzić, co dotarło, a co nie.
Jak często ponawiamy próby, kiedy i kogo powiadamiamy i co dzieje się potem, ustalamy z Państwem wcześniej. Zachowanie przy awariach jest częścią pisemnego opisu interfejsu.
Czy mogą Państwo zagwarantować, że nasze e-maile trafią do skrzynki odbiorczej?
Gwarancja dostarczenia nie jest technicznie możliwa, ponieważ decyduje serwer odbiorcy. Dbamy o poprawne technicznie, zgodne z wytycznymi i monitorowane dostarczanie wiadomości. SPF, DKIM i DMARC są ustawione prawidłowo, reputacja Państwa nadawców jest obserwowana, a wszystkie systemy wysyłające w Państwa imieniu są ujęte w spisie. Następnie mierzymy wynik.
Jaka jest Państwa stawka godzinowa?
To zależy od zakresu, modelu współpracy i pilności. Prosimy krótko opisać Państwa sytuację, a po rozmowie otrzymają Państwo ofertę. Nie trzeba przy tym podawać budżetu. Stałe ceny podajemy przy produktach wejściowych.
Kiedy mogą Państwo zacząć?
Pierwszą odpowiedź otrzymają Państwo w ciągu jednego dnia roboczego. Kiedy zaczniemy pracę, zależy od bieżącego obłożenia i od zakresu. Powiemy to Państwu wiążąco podczas rozmowy wstępnej. Jeśli sprawa jest pilna, Ocena awaryjna w 48 godzin rozpoczyna się z chwilą, gdy uzyskamy dostęp do systemu.
Które systemy mają się ze sobą porozumiewać?
Wystarczy wymienić systemy, których to dotyczy, co ma do nich wchodzić i z nich wychodzić oraz kto wywołuje interfejs. Odpowiadamy w ciągu jednego dnia roboczego.