| 1 | = Integracja z zewnętrznymi systemami = |
| 2 | |
| 3 | == Sposób utworzenia połączania z systemem Optima == |
| 4 | |
| 5 | Aby umożliwić synchronizację z systemem Optima należy wykonać poniższe czynności. |
| 6 | |
| 7 | * zmiana stałej w pliku config.inc |
| 8 | * sprawdzenie danych w tabeli wsdl_config_table w systemie eDokumenty |
| 9 | * utworzenie tabeli kolejki w systemie Optima |
| 10 | * założenie triggerów na tabele |
| 11 | * dok!__Dokument |
| 12 | * adr!__Ewid |
| 13 | * kh!__Kontrahent |
| 14 | * założenie widoków (eDokumenty > 2.0 RC15) |
| 15 | * subiekt_export_all_contacts_documents_view.sql |
| 16 | * subiekt_export_all_contacts_view.sql |
| 17 | * subiekt_export_all_queued_contacts_documents_view.sql |
| 18 | * subiekt_export_all_queued_contacts_view.sql |
| 19 | |
| 20 | == Zmiana stałej == |
| 21 | W pliku config.inc należy zmienić stałą "SUBIEKT_DATA_SOURCE_DTSCNM" na |
| 22 | {{{ |
| 23 | define('OPTIMA_DATA_SOURCE_DTSCNM', 'nazwa'); |
| 24 | }}} |
| 25 | gdzie nazwę należy zastąpić nazwą bazy danych systemu Optima |
| 26 | |
| 27 | == Sprawdzenie danych w tabeli == |
| 28 | Jeśli w systemie !eDokumenty tabela wsdl_config_table jest pusta należy wykonać odpowiedni skrypt SQL dla Optima znajduję się on w katalogu |
| 29 | |
| 30 | {{{ |
| 31 | apps\edokumenty\classes\BsConnect\install\data\optima_wsdl_ins.sql |
| 32 | }}} |
| 33 | następnie należy przejść do punktu "Konfiguracja tabeli wsdl_config_table" aby dokonać niezbędnych poprawek oraz ustawień według zaleceń. |
| 34 | |
| 35 | {{{ |
| 36 | #!html |
| 37 | <h1 id="wsdl" style="visibility:hidden"></h1> |
| 38 | }}} |
| 39 | == Ustawienia w tabeli wsdl_config_table == |
| 40 | Następny krok to sprawdzenie tabeli wsdl_config_table oraz czy zawiera dane. W przypadku jeśli jest pusta proszę udać się na stronę z integracją wybranego systemu. Edycję ustawień połączeń możemy dokonać z interfejsu eDokumentów '''Ustawienia -> Systemy zewnętrzne''' |
| 41 | |
| 42 | '''Opis kolumn''' |
| 43 | * Adres - adres pliku (serwera), jeśli w nazwie występuje słowo {host} należy ja zamienić na lokalizacje systemu eDokumenty standardowo jest to localhost, w przypadku vhosta należy podać port (np.: localhost:8080), jeśli system znajduje się katalogu różnym niż public należy dodać nazwę tego katalogu do nazwy (np.: localhost:8080/edokumenty), zmianę tą można dokonać z linii poleceń psql według ustawień instalacji [[br]] |
| 44 | {{{ |
| 45 | UPDATE wsdl_config_table SET wsdl__ = replace(wsdl__, '{host}', 'localhost:8080/edokumenty'); |
| 46 | }}} |
| 47 | * System - wskazuje na nazwę systemu dla którego konfigurowana jest dana metoda(zostawiamy bez zmian) |
| 48 | * Warunek SQL - warunek po jakim będą synchronizowane dane |
| 49 | * dla akcji "Podwiąż kontakt" z lewej strony znaku równości wskazujemy kolumnę z systemu zew. natomiast z prawej w wąsach kolumnę z systemu eDokumenty |
| 50 | {{{ |
| 51 | (np. dla OPT!MY: Knt_Nip='{nip___}' AND Knt_Nazwa1='{name_1}' co oznacza, że będzie |
| 52 | wyszukiwanie kontaktu w systemie OT!MA gdzie kolumna Knt_Nip będzie równa numerowi nip |
| 53 | kontaktu z systemu eDokumenty (token {nip___} jest zamieniany na dane) itd) |
| 54 | }}} |
| 55 | |
| 56 | * dla pozostałych akcji po lewej stronie jest nazwa kolumny z systemu eDokumety a z prawej token z maski(zobacz w katalogu apps\edokumenty\etc\sync) z jakimi zostanie zastąpiony. |
| 57 | |
| 58 | Różnica między tymi metodami polega na tym iż w przypadku szukania kontaktu w systemie zew. należy wykonać zapytanie na zew. bazie dlatego z lewej strony są nazwy kolumn z systemu zew. a z prawej tokeny nazwy kolumn systemu eDokumenty, które zostaną zastąpione danymi wybranego kontaktu. |
| 59 | |
| 60 | Reszta metod służy do porównania danych przychodzących z systemu zew. do systemu eDokumenty. Zapytanie jest wykonywane na bazie eDokumenty dlatego z lewej strony wstawiamy nazwę kolumny z tabeli z bazy eDokumenty natomiast z prawej dane z tablicy "mapy" z systemu zew. |
| 61 | |
| 62 | Tablica (mapa kolumn) ułatwia sparsowanie danych i lepsze rozeznanie przykład |
| 63 | |
| 64 | {{{ |
| 65 | apps\edokumenty\etc\sync\OPTIMA_columns_map.ini |
| 66 | Przykładowa konfiguracja tablicy mapy dla kontaktu dla OPT!MY |
| 67 | [contacts] |
| 68 | Knt_KntID = contid |
| 69 | Knt_Nazwa1 = name_1 |
| 70 | Knt_Nazwa2 = name_2 |
| 71 | Knt_Nazwa3 = name_2 |
| 72 | Knt_Kraj = countr |
| 73 | Knt_Wojewodztwo = woj___ |
| 74 | Knt_Powiat = powiat |
| 75 | Knt_Ulica = street |
| 76 | Knt_NrDomu = bldnum |
| 77 | Knt_NrLokalu = fltnum |
| 78 | Knt_Miasto = city__ |
| 79 | Knt_KodPocztowy = code__ |
| 80 | Knt_Nip = nip___ |
| 81 | }}} |
| 82 | Oznacza to, że do dyspozycji będą dane pod danymi kluczami np.: klucz "nip_!__" będzie zawierał numer nip kontaktu z systemu zew. (w tym przypadku OPT!MA) dlatego warunek zapytania w bazie eDokumeny będzie miało postać |
| 83 | {{{ |
| 84 | nip___='{nip___}' |
| 85 | }}} |
| 86 | Czyli szukamy kontaktu w bazie eDokumenty gdzię nip_!__ (lewa strona) kontaktu z bazy eDokumenty jest równy numerow nip z tabeli - mapy danych jakie otrzymamy z systemu zew. Należy pamiętać aby token w wąsach był dodatkowo w pojedyńczych apostrofach. Ze względu na różny typ danych i sposób w jaki mogą być potraktowane przez SQL (cyfry, liczby nie wymagają apostrofów natomiast litery tak!!) lepiej jest dla każdego typu danych w wąsach stosować apostrofy. |
| 87 | |
| 88 | == Utworzenie tabeli kolejki == |
| 89 | W systemie Optima (w bazie) wykonujemy skrypt z pliku |
| 90 | {{{ |
| 91 | apps\edokumenty\classes\BsConnect\install\sql\optima\optima_export_queue.sql |
| 92 | |
| 93 | }}} |
| 94 | Po wykonaniu tego skryptu w systemie Optima powinna pojawić się dodatkowa tabela o nazwie export_queue. |
| 95 | |
| 96 | == Założenie triggerów == |
| 97 | Triggery mają za zadanie dodawać do kolejki dokumenty i kontaktu które zostały zmodyfikowane bądź dodane do systemu Subiekt. Triggery wykonujemy z załączników bądź w folderze |
| 98 | {{{ |
| 99 | apps\edokumenty\classes\BsConnect\install\sql\optima |
| 100 | }}} |
| 101 | znajdują się pliki oryginalne. Kolejność ich wykonywania nie ma znaczenia. Po ich wykonaniu należy sprawdzić czy tabele dok__Dokument, adr__Ewid oraz Kontrahent posiadają dodatkowe triggery. Można tego dokonać za pomocą narzędzia SQL Manager Lite for SQL Server firmy EMS. (http://www.sqlmanager.net/) |
| 102 | [[BR]]Dla tabeli dokumentów |
| 103 | [[BR]] |
| 104 | [[Image(opDkAd.png, nolink)]] [[BR]] |
| 105 | |
| 106 | Natomiast dla tabeli Kontrahenci [[BR]] |
| 107 | [[Image(opKh.png, nolink)]] [[BR]] |
| 108 | |
| 109 | Możemy przetestować działanie mechanizmy poprzez dodanie do systemu Subiekt dokumentu lub kontrahenta i sprawdzeniu czy w tabeli export_queue pojawiły się wpisy. |
| 110 | |
| 111 | == Założenie widoków == |
| 112 | Począwszy od wersji 2.0 RC16 można decydować jakie dane mają być pobierane z systemu zew. poprzez modyfikacje specjalnych widoków przeznaczonych do synchronizacji. Widoki te są wymagane w celu prawidłowego funkcjonowania. Można je znaleźć w katalogu |
| 113 | {{{ |
| 114 | edokumenty\classes\BsConnect\install\sql\optima\views |
| 115 | }}} |
| 116 | |
| 117 | Można też je pobrać z załączonego niżej katalogu optima.zip. Widoki należy wykonać na bazie Optima (MsSQL). |
| 118 | |
| 119 | ''' Opis widoków ''' |
| 120 | * subiekt_export_all_contacts_documents_view - wyświetla wszystkie dokumenty, które mają kontrahenta |
| 121 | * subiekt_export_all_contacts_view - wyświetla wszystkich kontrahentów |
| 122 | * subiekt_export_all_queued_contacts_documents_view - wyświetla wszystkie dokumenty, które mają kontrahenta oraz zostały zmodyfikowane(dodane do systemu) i znajdują się w tabeli export_queue w systemie zew. |
| 123 | * subiekt_export_all_queued_contacts_view - wyświetla wszystkich kontrahentów którzy zostali zmodyfikowani(dodani do systemu) i znajdują się w tabeli export_queue w systemie zew. |
| 124 | |
| 125 | kolejność wykonywania nie ma znaczenia. |
| 126 | |
| 127 | Widoki te można modyfikować według potrzeb(dodawać kolumny itd) eliminując w ten sposób dodatkową pracę ze strony programisty i aktualizacji w postaci nowej wersji ze zmodyfikowanym widokiem. |
| 128 | Widoki modyfikujemy jeśli klient zażyczy sobie aby z systemu zew. były pobierane dodatkowe dane, których podstawowa definicja nie uwzględniła. Następnie w pliku konfiguracyjnym |
| 129 | {{{ |
| 130 | SUBIEKT_columns_map.ini |
| 131 | }}} |
| 132 | dodajemy kolejny wpis pod odpowiednim indeksem [contacts] - kontakty, [documents] - dokumenty z rzutowaniem danych z dodanej kolumny w widoku na kolumnę w systemie eDokumenty. |
| 133 | |
| 134 | ''' Jaka metoda jaki widok wykorzystuje ''' |
| 135 | * Importuj wszystkie kontakty - subiekt_export_all_contacts_view |
| 136 | * Aktualizuj dane - subiekt_export_all_queued_contacts_view |
| 137 | * Aktualizuj dokumenty - subiekt_export_all_queued_contacts_documents_view |
| 138 | * Aktualizuj dane kontaktów - subiekt_export_all_queued_contacts_view |
| 139 | * Aktualizuj dokumenty kontaktów - subiekt_export_all_queued_contacts_documents_view |
| 140 | * Pobierz wszystkie dokumenty - subiekt_export_all_contacts_documents_view |
| 141 | |
| 142 | == Reset == |
| 143 | Na wypadek gdyby wprowadzone zmiany miały być z jakiegoś względu wycofane z bazy optimy, należy wykonać plik reset_optima.sql który usuwa tabele export_queue, triggery oraz widoki. |
| 144 | |
| 145 | == Raporty z parametrem klienta == |
| 146 | |
| 147 | Aby raportować rozrachunki z klientem, sprzedaż czy cokolwiek z nim związane można do tego użyć raportów ze zdefiniowanym zewnętrznym źródłem danych patrz: [wiki:DeployerGuide/Customization/AdvancedReporting tworzenie raportów SQL] |