CRS co to jest?

[MK]

Nie zwykłem zakładać tu nowych wątków. Dotychczas jedynie reagowałem na różnego rodzaju sytuację, czasem starałem się pomóc.
Pojawiło się jednak dziś na serwisie zgłoszenie żywcem odnoszące się do pewnej mojej odpowiedzi przy okazji jakiś tu dyskusji. Chodziło o API do systemu SOMED i tajemniczą nazwę CRS. Aby więc wszyscy, być może kiedyś, zainteresowani widzieli o co chodzi.
CRS jest to usługa systemu Windows realizująca skromny wycinek funkcjonalności systemu KS-SOMED. Oczywiście korzysta ona całkowicie z bibliotek systemy KS-SOMED dlatego jest w pełni kompatybilna z systemem. Tak jak wówczas napisałem, jest to pewnego rodzaju API systemu, ale bardzo, ale to bardzo skromny wycinek tego systemu. Nie mniej jednak kilka systemów zewnętrznych (przez to rozumiem również rozwiązania KS nie będące SOMEDem) korzysta z tego rozwiązania i realizuje swoje funkcje, np. MEDIS w taki sposób może wystawiać faktury, które następie w kasie systemu SOMED są widoczne. Rozwiązań jest oczywiście więcej i nie kręcą się one li tylko i wyłącznie wokół kasy. I co ważne, jest to, w miarę potrzeb, rozwijane.
Uwaga jednak podstawowo, jest to zamknięte API. Nikt, nie otrzyma tak po prostu opisu tego API. Nie miałoby to zresztą najmniejszego sensu, gdyż każdy system łączący się z CRS szyfruje komunikaty za pomocą swojego własnego klucza, który oczywiście nie jest wymieniony w dokumencie opisującym API. Więc nawet, gdyby ktoś taki dokument zdobył, raczej podłączenie do CRS by się nie powiodło.
Jak więc wygląda współpraca? Jeśli mają Państwo określone i dobrze sprecyzowane wymagania oraz mają Państwo możliwość ich realizacji, co zwykle oznacza, że jest konkretna firma z własnym rozwiązaniem, które chce się z nami spiąć, lub jest gotowa takie rozwiązanie napisać, wówczas należy dokładnie opisać jaką funkcjonalność Państwo chcą uzyskać i ewentualnie jakie są warunku systemu trzeciego. Analizujemy wówczas, czy jesteśmy je w stanie zrealizować, szlifujemy i precyzujemy wymagania i ostatecznie udostępniamy API z komunikatami realizującymi daną funkcjonalność. Czasem wymaga to z naszej strony dopinania nowych komunikatów, czasem te cegiełki już mamy. Kiedy mamy to już wszystko ustalone udostępniamy API oraz sposób kodowania komunikatów oraz indywidualny, dla danego systemy trzeciego, klucz kodujący komunikację. Przy okazji od razu wyjaśnię, dany system otrzyma dostęp tylko do tych funkcji, które są niezbędne do realizacji danej współpracy, czyli to na co umówiliśmy się. Nie wycinam z opisu API pozostałych komunikatów, niemniej jednak, jeśli nie były one uzgodnione po prostu dany system nie otrzyma do nich dostępu.
Takie rozwiązanie jest przyjęte przede wszystkim ze względów bezpieczeństwa, nie otwieramy systemu na oścież, co zresztą widać w konsekwentnym wprowadzaniu co raz to nowych zabezpieczeń w samym SOMEDzie.
Komunikacja opiera się na wysyłaniu i odbieraniu xml na określony adres i port, gdzie rozgościła się usługa CRS. NIE JEST TO USŁUGA SIECIOWA, tu od razu stopuję. Oczywiście KS ma rozwiązanie (Portal ), które jest normalną usługą sieciową realizującą konkretne funkcje i korzystająca do realizacji niektórych z nich właśnie z CRS, więc da się to zrobić tak, ale to już zadanie właśnie systemu trzeciego.
Celowo nie poruszam tu wątku finansowego. Jestem programistą i takimi tematami po prostu się nie zajmuję. Nie ja podejmuję jakiekolwiek w tym temacie decyzje i, jeśli kiedykolwiek, ktokolwiek, będzie zainteresowany, sprawy finansowe zapewne uzgodni z właściwymi osobami w firmie.

[Michał]

Opisane rozwiązanie przekracza znacząco poziom mojej wiedzy i (pewnie nawet przyszłych) potrzeb. Myślę jednak, że znajdą się wyjadacze, którym ta informacja się przyda, dlatego pozwoliłem sobie przypiąć ten wątek.