Trzy aspekty integracji, czyli kiedy niemożliwe staje się możliwe

Łukasz Kawulok, dyrektor rozwoju obszaru bankowości




Jako ekspert obszaru bankowości, kilka dni temu miałem przyjemność uczestniczyć w spotkaniu dotyczącym budowy systemu kredytowego. Zostałem zaproszony do jednego z banków, który w niedalekiej przyszłości planuje, w ramach swojej instytucji, zinformatyzować procesy kredytowe. Spotkanie dotyczyło pełnego zakresu usług związanych z udzielaniem kredytów: od ofertowania, poprzez wnioskowanie, ocenę, podpisanie umowy, aż po uruchomienie środków i monitoring warunków spłaty. Rozmawialiśmy na temat pełnego portfolio klientów, tj. klientów detalicznych ocenianych wraz z małymi przedsiębiorstwami scoringowo oraz klientów korporacyjnych, ocenianych ratingowo (po szczegółowej analizie klienta i transakcji). W efekcie końcowym dyskusja, która zrodziła się podczas prezentacji dotyczyła integracji. Dlaczego?

Zaczęło się niewinnie w trakcie rozmowy o referencjach. Opowiadaliśmy o wdrożonych przez nas produktach o podobnym zakresie, wspomnieliśmy, iż ostatnie wdrożenie zakończyliśmy kilka tygodni wcześniej. Dotyczyło ono procesu ofertowania i wnioskowania wraz z oceną dla klientów detalicznych. System jest obsługiwany przez kilka tysięcy użytkowników. Analiza i implementacja trwały trzy miesiące, a testy akceptacyjne miesiąc. W ramach tych prac integrowaliśmy się z trzema systemami zewnętrznymi o szerokim zakresie usług i pól danych. „Dla utrudnienia” interfejsy tych systemów zmieniały się w tym samym czasie.

Gospodarz naszego spotkania zapytał: Jakim cudem? Oczywiście wyjaśnił, że rozumie, iż można w niespełna trzy miesiące napisać system lub dostosować gotowy produkt, ale zintegrowanie go z innymi systemami w tym czasie i przy tak krótkich testach uznał już za niewykonalne.

A jednak zrobiliśmy to dzięki zadbaniu o 3 aspekty integracji.

Po pierwsze, możliwość szybkiego wprowadzania zmian w zakresie interfejsu komunikacji. Niezależnie od tego jak ważne są pozostałe aspekty,
o których piszę w dalszej kolejności, to możliwość dodania kolejnego pola, nawet na późnym etapie projektu, jest kluczową kwestią. Bardzo często okazuje się, że to konkretne pole po prostu musi zostać dodane, że jest niezwykle istotne lub że koniecznie trzeba zmienić format, długość czy znaczenie któregoś ze zdefiniowanych pól. Oczywiście można z tym walczyć i jako dostawca bronić się ustaleniami zawartymi w umowie. Chyba, że da się to w prosty, konfiguracyjny sposób wprowadzić i przetestować.

Po drugie, standardy. Jest ich tak naprawdę skończona ilość. Do tego dochodzi iemała ilość sposobów na połączenie systemów, ale jednak także skończona. Nie chodzi o to, żeby je wszystkie wymieniać, jednak: usługi, MQ, komunikaty, kolejki, pliki płaskie, pliki strukturalne, XML i zdefiniowane w XML typy komunikatów itd., a w szczegółach jest jeszcze kilka podtypów, np. pliki klucz-wartość lub specyficzne dla środowiska formaty np. „małponotacja”. Rozwiązanie, z którego skorzystamy musi być zgodne z wybranym standardem lub wspierać je wszystkie.

Jednak to nie zawsze wystarcza. Pracowałem kiedyś przy projekcie, gdzie przy integracji dwóch systemów poprzez webserwisy ustalony został dokładny format komunikatu i sformalizowany w postaci pliku z opisem WSDL. W tej integracji używany był dla wielu pól typ danych dziesiętnych (decimal). System wysyłający, zgodnie ze specyfikacją, przesyłał liczby typu dziesiętnego, jak np.: 3,00; 3; 4,4, a system odbierający miał założoną dodatkową walidację, już po odebraniu komunikatu, na format z dwoma miejscami dziesiętnymi. Oczekiwał zatem danych: 3,00; 3,00; 4,40 i generował wyjątki, mimo poprawnych danych, zgodnych ze standardem dla liczb dziesiętnych WSDL. Mieliśmy tutaj do czynienia z dodatkowymi działaniami poza standardem komunikacji.

Po trzecie, testy, testy, testy. Jeśli chwilę po zaczytaniu definicji integracji jesteśmy w stanie wygenerować atrapę interfejsu i od razu ją udostępnić, w celu przetestowania, to oszczędzimy sobie wielu problemów. Automatyczne dodanie testów sprawdzających wartości, skrajne i gotowe szablony dla testów innego rodzaju, natychmiastowo weryfikuje poprawność techniczną procesu komunikacji. Nie mówimy tutaj o logice biznesowej, tylko o błyskawicznym przetestowaniu całej komunikacji i jej technicznej poprawności. Resztę czasu przewidzianego na realizację projektu możemy przeznaczyć na pisanie funkcji biznesowych.

Podsumowując, platforma VSoft archITekt, którą prezentowaliśmy na wspomnianym spotkaniu zapewnia właśnie te trzy kluczowe elementy integracji. Pozwalają one na efektywną i szybką realizację rozwiązania, a także współpracę miedzy systemami. To dzięki łatwości wprowadzania zmian, obsłudze standardów i gigantycznemu wsparciu dla automatyzacji testów integracji, VSoft archITtekt jest bezkonkurencyjny w tym zakresie. Widzimy to przy każdym wdrożeniu.




Artykuł opisuje korzyści używania naszej autorskiej platformy VSoft archITekt.

W przypadku dodatkowych pytań

napisz do nas na podany adres mailowy