Jednym z kluczowych celów projektu, w którym mieliśmy okazję jakiś czas temu brać udział, była zaawansowana integracja systemów OTRS 5 Community Edition i Microsoft Dynamics CRM 2011. W Intalio byliśmy odpowiedzialni za dostarczenie funkcjonalności ze strony systemu ticketowego, oczywiście przy ścisłej współpracy z dedykowanymi osobami ze strony Klienta.
- Naturalnie oba systemy - OTRS i Dynamics - zawierają pewne elementy, które przy odrobinie wysiłku i kilkuset liniach kodu, mogą przetwarzać identyczne zestawy informacji. Potem wystarczy je tylko zmusić do dzielenia ich między sobą...
OTRS i niewszechmogący GenericInterface
Coś, co początkowo wydało nam się niezłym treningiem z wykorzystania modułu GenericInterface, pokazało, że ten element systemu - choć przygotowany z głową i po wielu iteracjach - nie pozwala osiągnąć pełnej synchronizacji obu systemów. Im bardziej zagłębialiśmy się w niuanse protokołów, obiektów i kwestii bezpieczeństwa, zaczęliśmy zdawać sobie sprawę, że czeka nas o wiele więcej pracy, niż początkowo wszyscy zakładaliśmy.
- GenericInterface został stworzony głównie z myślą o zgłoszeniach (obiekty Ticket) i notatkach/wiadomościach e-mail (obiekty Article). My potrzebowaliśmy jeszcze wymiany informacji o Organizacjach (CustomerCompany), ich pracownikach (CustomerUser), usługach (Service) oraz... kontraktach, które dodatkowo będą integralną częścią OTRS na wielu płaszczyznach (m.in. panele z informacjami o klientach oraz ekran AgentTicketZoom, czyli widok szczegółowy zgłoszenia).
Musieliśmy więc rozpocząć od stworzenia całkowicie nowego i nietrywialnego modułu pozwalającego na pełną transparentność czasu i kosztów, które są generowane przez Organizacje i ich pracowników. Dzięki intensywnym testom zarówno po stronie Klienta jak i w Intalio (naturalnie sami również korzystamy z OTRS) udało się doprowadzić ten kolosalny podprojekt do oczekiwanego kształtu. Więcej szczegółów na jego temat można poznać tutaj.
Zdarzenia i żądania
O ile odgrywanie przez OTRS roli serwera informacji nie jest niczym szczególnym, to obsługa zdarzeń dziejących się wewnątrz systemu jest już czymś godnym wzmianki. Niewiele nawet nowoczesnych rozwiązań posiada taki mechanizm, a na pewno nie tej klasy co OTRS. Bez zagłębiania się w szczegóły techniczne napiszę tylko, że jest to raj zarówno dla administratora jak i programisty.
To właśnie umożliwiło nam implementację zwinnego zabezpieczenia, które zawsze dba o pełną integralność danych, nawet tych historycznych, gdyby pojawiły się jakiekolwiek zewnętrzne problemy techniczne z komunikacją OTRS i MS Dynamics.
Kontrolowany przepływ informacji
Napisany w oparciu o nasze doświadczenia z OTRS moduł synchronizacyjny zawsze dba o prawidłową kolejność przesyłanych do CRM informacji. Wszak nie utworzymy obiektu CustomerUser bez uprzedniego stworzenia CustomerCompany. A trzeba pamiętać, że mechanizm integracji pozwala na obsługę całego cyklu życia wszystkich najważniejszych obiektów...
- Klient posiada Kontrakty, w ramach których są mu świadczone Usługi. Usługi są oznaczane w Zgłoszeniach tworzonych przez Użytkowników Klienta. Agenci obsługujący te Zgłoszenia zapisują niezbędne informacje bilingowe, aby później Kontrakt mógł zostać rozliczony.
Tak właśnie zachowuje się to po stronie systemu OTRS i naszego modułu integracyjnego. Prawie tak samo jest po stronie MS Dynamics... Niestety sposób obsługi zdarzeń wewnątrz CRM nie jest tak dopracowany jak w systemie zgłoszeń. Wielokrotne i żmudne testy pozwoliły w końcu określić "prawidłowości", którymi rządzi się Microsoft Dynamics, gdy rozchodzi się o wysyłkę danych "na zewnątrz". Niestety wcale nie oznacza to, że zawsze są one logiczne: rzeczywiście CRM próbuje w OTRS najpierw utworzyć obiekt CustomerUser, a dopiero później CustomerCompany - choć sam u siebie na takie coś nie pozwala (zwyczajnie, technicznie - nie da się). Innym problemem okazały się same obiekty/encje - np. pole "tytuł zgłoszenia" (które w OTRS jest wymagane już na etapie jego tworzenia) CRM "dosyła" w którymś z kolei żądaniu POST...
Wszystkie wspomniane powyżej problemy nie były możliwe do wyeliminowania po stronie systemu Microsoftu. Aby móc doprowadzić projekt do szczęśliwego końca konieczne było obsłużenie tych zachowań w mechanizmach weryfikacyjnych modułu integracji. Potęga open source. :)