W bazie dedykowanej leżą obiekty klienta i jego własne zbiory danych, a w bazie głównej zostają konfiguracja i rejestr ruchów magazynowych. Każde aktywne zapytanie ma zapisane połączenie, więc skrypt terminala woła tylko identyfikator. Skrypty aktualizacji produktu wykonują się wyłącznie na połączeniu głównym.
Tutaj druga baza nie ma żadnego elementu konfiguracji: są w niej obiekty klienta i jego własne zbiory danych, inaczej niż w osobnym artykule o drugiej bazie z dokumentami magazynu zewnętrznego. Artykuł jest przeznaczony dla architekta wdrożenia i administratora, którzy chcą oddzielić dodatki klienta od produktu na poziomie bazy i wiedzieć, co w takim układzie leży w której bazie.
Zapytanie i zestawienie niosą nazwę połączenia, a skrypt na terminalu jej nie zna
W opisywanym wdrożeniu każdy aktywny wiersz zapytań w konfiguracji ma zapisane połączenie, a serwer wykonuje treść zapytania na tym połączeniu. Wiersze zapytań klienta wskazują połączenie główne albo dedykowane, a większość korzysta z głównego. W plikach skryptów ekranów klienta nie ma nazwy bazy ani nazwy połączenia: skrypt woła zapytanie po identyfikatorze i parametrach, na przykład na ekranie zmiany lokalizacji palety. W obrębie jednego ekranu zapytania idą różnymi połączeniami zależnie od tego, czego dotyczą: lokalizacje i stany standardowe przez połączenie główne, a blokady sztuk, czyli obiekt klienta, przez połączenie dedykowane.
Skrypt na terminalu woła zapytanie po identyfikatorze. Na którym połączeniu się wykona, wynika z wpisu w konfiguracji.
Pole źródła danych z nazwą połączenia ma w konfiguracji także zestawienie. Zestawienia klienta korzystają z połączenia głównego i dedykowanego: jedne czytają obiekty bazy dedykowanej, inne bazy głównej. Wpis zapytania pokazuje nazwę połączenia obok treści zapytania, jak na makiecie poniżej. Nowy ekran klienta rejestruje się w słowniku transakcji ścieżką do pliku w katalogu klienta, a pozycja menu wskazuje transakcję po kodzie. Samą konstrukcję połączenia zapisanego przy zapytaniu i odwołań po pełnej nazwie w obie strony opisuje artykuł o drugiej bazie dla magazynu zewnętrznego; tam druga baza trzyma dokumenty magazynu zewnętrznego, a tutaj kod klienta i jego własne zbiory danych.
Obiekty klienta leżą w drugiej bazie i sięgają do głównej po pełnej nazwie
Obiekty bazy dedykowanej sięgają do bazy głównej po pełnej nazwie obiektu, czyli po nazwie obiektu poprzedzonej nazwą bazy i schematu. Widok stanów strefy czyta główny widok stanów i kartotekę lokalizacji, a procedura zapisu przesunięcia czyta konto użytkownika. W drugą stronę zapytanie na połączeniu głównym woła obiekt bazy dedykowanej po pełnej nazwie, na przykład lista proponowanych adresów zbiórki pustych palet i zapis tej zbiórki. Podział zapytań według połączenia nie jest więc regułą bez wyjątków: część zapytań na połączeniu głównym czyta obiekty klienta.
Schemat pokazuje te odwołania jako dwie strzałki między bazami, w przeciwne strony, z podpisem „pełna nazwa obiektu”. U góry stoi skrypt na terminalu, który woła zapytanie, a od zapytania prowadzą strzałki do obu baz.
Własne zbiory danych klienta obsługują wąskie zadania
Własne zbiory danych klienta w bazie dedykowanej obsługują wąskie zadania. Trzy z nich to skany czekające na nośnik przy przyjęciu, blokady sztuk i palet z zapisanym loginem oraz czasem założenia i zdjęcia blokady, a także sztuki dopisane podczas spisu. Pierwszy z tych zbiorów opisuje artykuł o skanach czekających na nośnik.
Cztery elementy konfiguracji leżą w bazie głównej: menu, słowniki, zapisane zapytania i definicje zestawień. Baza dedykowana zawiera widoki i funkcje oraz procedury klienta, a także jego własne zbiory danych, ale nie ma żadnego z elementów konfiguracji. Zestawienie, które ma pokazać dane z obu miejsc, ma więc wpis konfiguracji w bazie głównej i obiekt w bazie dedykowanej.
| Element | Baza główna | Baza dedykowana |
|---|---|---|
| Konfiguracja menu i zapisanych zapytań | tak | nie |
| Definicje zestawień | tak | nie |
| Widoki i funkcje klienta | nie | tak |
| Procedury klienta | nie | tak |
| Własne zbiory danych klienta | nie | tak |
| Rejestr ruchów magazynowych | tak | nie (tylko kopia robocza) |
Co leży w której bazie: układ z opisywanego wdrożenia, ujęcie uproszczone.
Ruchy magazynowe trafiają do głównego rejestru, także z procedur klienta
Procedury klienta zapisują ruchy magazynowe do głównego rejestru ruchów, a nie do własnych zbiorów danych. Dwa punkty rozwijają ten opis:
- Przesunięcie - powstaje jako para wierszy w jednej transakcji procedury.
- Konto użytkownika - ta sama procedura zapisu przesunięcia czyta je w bazie głównej.
Program ERP jest czytany przez serwer połączony z zapytań w konfiguracji
W opisywanym wdrożeniu program ERP jest czytany przez serwer połączony, a zapytania zapisane w konfiguracji wysyłają do niego zapytanie. Z takich zapytań korzystają ekrany opisane w osobnych artykułach:
- Zamówienia - ekran opisany w artykule o zamówieniach z widoku programu ERP.
- Przyjęcie - ekran opisany w artykule o przyjęciu jednym skanem.
Wzorzec odświeżania lokalnej kopii kartoteki ze źródła, które może zwrócić zero wierszy, opisujemy osobno w artykule o odświeżaniu kopii kartoteki.
Skrypty aktualizacji produktu używają połączenia głównego
Skrypty aktualizacji bazy, które produkt wykonuje przy starcie aplikacji, używają w opisywanym wdrożeniu wyłącznie połączenia głównego. Baza dedykowana nie jest celem tego mechanizmu. To zdanie dotyczy wyłącznie mechanizmu skryptów aktualizacji bazy. Inny sposób dostosowania, w którym zmienia się znaczenie istniejącej kolumny zamiast dokładania osobnej bazy, opisuje artykuł o kolumnie z innym znaczeniem.
Przykład (dane wymyślone) w pięciu krokach:
- Kierownik prosi o zestawienie, które łączy stan palet z dodatkową informacją klienta.
- Administrator dopisuje widok w bazie dedykowanej, który czyta stan z bazy głównej po pełnej nazwie obiektu.
- Do konfiguracji dodaje zapytanie i zestawienie z połączeniem dedykowanym, a pozycję menu kieruje na to zestawienie.
- Skrypty na terminalu zostają bez zmian, bo nie znają nazw baz.
- Skrypty aktualizacji produktu wykonują się na połączeniu głównym, więc nowy widok nie jest ich celem.
Pytania do analizy
- Które dodatki klienta powinny leżeć poza bazą produktu, a które w konfiguracji?
- Kto utrzymuje połączenie zapisane przy każdym zapytaniu i co się zmieni, gdy dojdzie trzecia baza?
- Czy skrypty ekranów we wdrożeniu znają nazwy baz i ile miejsc trzeba zmienić przy przeniesieniu bazy?
- Które skrypty aktualizacji muszą dotykać obu baz, a które wystarczy wykonać na jednej?