Interfejs ODBC i JDBC

Wprowadzenie

ODBC i JDBC to standardy dostępu do źródeł danych, zwykle baz danych, za pośrednictwem znormalizowanego interfejsu w systemie Windows.

Niniejsza dokumentacja opisuje dostęp do baz danych Comarch ERP Enterprise poprzez interfejsy bazodanowe ODBC i JDBC.

Grupa docelowa

Dokument jest skierowany do programistów i konsultantów, którzy chcą tworzyć raporty lub pobierać dane z Comarch ERP Enterprise za pomocą produktów innych firm. Koncentruje się na modelu danych interfejsu bazy danych Comarch ERP Enterprise i jego specjalnych funkcjach. Treść dokumentu jest również podstawą do tworzenia raportów w środowisku systemu Comarch ERP Enterprise.

Definicje

Sterownik ODBC systemu ERP umożliwia dostęp do odczytu danych w różnych bazach danych systemu. Na przykład narzędzia raportujące lub aplikacje pakietu Office mogą z niego korzystać w celu uzyskania dostępu do tych danych. Uprawnienia zdefiniowane w systemie Comarch ERP Enterprise są również brane pod uwagę przy zapytaniach.

Sterownik JDBC systemu ERP umożliwia dostęp do odczytu danych w różnych bazach danych systemu. Narzędzia do raportowania lub aplikacje Office, na przykład, mogą z niego korzystać w celu uzyskania dostępu do tych danych. Uprawnienia zdefiniowane w systemie Comarch ERP Enterprise są również brane pod uwagę przy zapytaniach.

Wymagania wstępne

Aby korzystać z interfejsu ODBC, na komputerze klienta należy zainstalować sterownik ODBC systemu ERP i skonfigurować źródło danych ODBC. Korzystanie z interfejsu JDBC wymaga instalacji sterownika JDBC.

Zakłada się również, że użytkownik:

• Comarch ERP Enterprise zna system z perspektywy użytkownika
• zna podstawy modelowania danych w Comarch ERP Enterprise
• jest zaznajomiony z przygotowywaniem raportów
• posiada wiedzę z zakresu modelowania danych w relacyjnych bazach danych

Obsługiwane systemy innych firm do tworzenia raportów

Interfejs ODBC 32-bitowy został pomyślnie przetestowany z następującymi systemami zewnętrznymi:

• Crystal Reports 2013
• Microsoft Query z pakietu Microsoft Office 2013

Następujące systemy zewnętrzne powinny być zgodne z interfejsem ODBC 32-bitowym, ale nie są już testowane ani obsługiwane przez Comarch:

• Crystal Reports 9, 10, 11, 2008 i 2011
• Cognos Impromptu 7 i Powerplay
• Menedżer danych Cognos 8
• Microsoft Query z pakietu Microsoft Office 2007 lub nowszego

Sterownik ODBC 64-bitowy został pomyślnie przetestowany z następującym systemem zewnętrznym:

• Crystal Reports 2020

Model danych interfejsu bazy danych lokalizacja

Interfejs bazy danych oferuje przygotowany model danych oparty na modelu Comarch ERP Enterprise. Schemat relacyjny bazy danych jest częściowo ukryty. Ułatwia to tworzenie raportów, ponieważ wyświetlane są znane standardowe obiektów biznesowych i ich atrybutów, a niektóre modelowane relacje między obiektami biznesowymi są oceniane automatycznie. Znacząco zmniejsza to liczbę połączeń, które należy zamodelować w raporcie.

W celu przygotowania schematu relacyjnego opisanego poniżej, użytkownik powinien być zaznajomiony z Comarch ERP Enterprise, jego funkcjonalnym modelem danych i najważniejszymi terminami modelowania, takimi jak:

• Business Object, Business Entity, Dependent
• Relacje
• Typy danych, części specjalne
• Klucz podstawowy i klucz biznesowy

Dostęp do interfejsu bazy danych zawsze odbywa się w kontekście tzw. aktywnej organizacji.

Nazwy tabel

Interfejs bazy danych udostępnia tabele zorganizowane w katalogi dla obiektów biznesowych oraz widoków przechowywanych w bazie danych. Główny katalog CISAG zawiera wszystkie tabele zorganizowane w podkatalogi.

Tabela obiektu biznesowego jest klasyfikowana zgodnie z jej typem w jednym z podkatalogów DEPENDENT lub ENTITY. Tabele widoków i widoki OQL zdefiniowane w bazie danych można znaleźć w podkatalogach VIEW i VIEWOQL. Podkatalog VIRTUAL zawiera tabele wirtualne, natomiast podkatalog FUNCTION zawiera funkcje wirtualne.

Jeśli zostały opracowane przez partnera, nowe tabele są włączane do podkatalogów zgodnie z ich przynależnością.

Poniższa tabela ilustruje strukturę:

Nazwa tabeli pochodzi od nazwy odpowiadającego jej obiektu biznesowego lub widoku. Nazwa przestrzeni nazw jest skracana o stałe komponenty, tj. .obj i com., w przypadku obiektów Comarch ERP Enterprise com.cisag., są pomijane. Kropki zastępowane są podkreślnikami.

Tabela może mieć etykietę, która pochodzi z obiektu biznesowego lub widoku jest wyświetlane jako tekst etykiety. Kolumny tabeli są atrybutami obiektu biznesowego, nazwa kolumny jest używana z odpowiedniej nazwy atrybutu. Kolumna może mieć etykietę, która jest zdefiniowana w opisie danych logicznego typu danych należącego do atrybutu. Ustawiony język wyświetlania źródła danych określa język etykiet. Aplikacja raportująca formułuje instrukcje SQL na tych tabelach w celu wygenerowania żądanego raportu.

Nazwy kolumn

Nazwa atrybutu jest używana jako nazwa kolumny. Istnieją specjalne nazwy kolumn i sufiksy, które wskazują na specjalne znaczenie kolumny. Poniższe rozdziały zawierają listę specjalnych nazw kolumn, które programista raportu może wykorzystać do uzyskania informacji o typie lub zawartości bez znajomości konkretnego typu lub zawartości kolumny.

Etykietowanie atrybutów GUID

Identyfikatory GUID (Global Unique IDentifier) są używane do tworzenia unikalnych kluczy dla obiektów biznesowych i odwoływania się do nich. Kolumny oparte na typie danych GUID są zatem najważniejszymi kandydatami do łączenia tabel podczas modelowania danych. Aby podkreślić te kolumny, nazwy kolumn są oznaczone podkreśleniem.

Rozdzielczość atrybutów tablicy

W przypadku atrybutu tablicowego obiektu biznesowego odpowiednia tabela zawiera wiele kolumn zgodnie z modelem atrybutu. Indeks jest dodawany do nazwy atrybutu jako sufiks.

Specjalna kolumna BusinessKey_text

Jeśli dla obiektu biznesowego spełnione są określone warunki, do jego tabeli dodawana jest kolumna BusinessKey_text. Kolumna ta zawiera ciąg instancji obiektu biznesowego. Podczas oceny żądania serwer aplikacji ładuje powiązaną instancję obiektu biznesowego za pośrednictwem usługi trwałości. Może to prowadzić do dłuższych czasów odpowiedzi w przypadku żądań z dużym zestawem wyników.

Aby kolumna została dodana, muszą być spełnione następujące warunki:

• obiekt biznesowy ma klucz biznesowy
• klucz podstawowy obiektu biznesowego składa się z atrybutu

Ta kolumna może być używana wyłącznie do celów informacyjnych.

Rozwiązanie relacji

W przypadku niektórych relacji obiektu biznesowego klucz biznesowy i opis obiektu docelowego są automatycznie dodawane do tabeli jako kolumny. Aby kolumny zostały dodane do tabeli, relacja musi spełniać określone warunki:

• model relacji musi wynosić 1:1
• docelowy obiekt biznesowy ma dokładnie jeden atrybut typu danych GUID jako klucz podstawowy
• relacja jest zdefiniowana przez dokładnie jeden atrybut, atrybut docelowy jest atrybutem klucza głównego
• obiekty źródłowe i docelowe są zdefiniowane w tej samej bazie danych.
• docelowy obiekt biznesowy ma zdefiniowany klucz biznesowy

Ograniczenia dla wielu relacji na atrybut

Jeśli kilka z tych relacji jest zdefiniowanych dla obiektu biznesowego z tym samym atrybutem źródłowym, ale różnymi atrybutami docelowymi, specjalne kolumny _BK i _text wygenerowane dla kolumny atrybutu źródłowego mogą nie zostać użyte w raporcie. W takim przypadku generowanie metadanych tabeli nie jest deterministyczne. Jedna z relacji jest używana do generowania kolumn specjalnych, pozostałe są ignorowane. W rezultacie możliwe jest, że te specjalne kolumny odnoszą się do innego docelowego obiektu biznesowego niż na przykład podczas tworzenia raportu.

W takim przypadku wymagana relacja musi zostać dodana do raportu ręcznie w celu uzyskania wymaganego klucza biznesowego i ciągu instancji. W tym celu należy otworzyć definicję obiektu biznesowego źródłowego obiektu biznesowego w aplikacji Obiekty deweloperskie. Na zakładce Edytor podzakładka Relacje prezentowane są zdefiniowane relacje z innymi obiektami biznesowymi. Należy zdefiniować wymaganą relację, którą następnie należy dodać ręcznie w raporcie, aby uzyskać wymagany klucz biznesowy i ciąg instancji. Dzięki czemu można połączyć wymaganą tabelę docelowego obiektu biznesowego poprzez kolumnę atrybutu źródłowego i kolumnę atrybutu docelowego z tabelą źródłowego obiektu biznesowego. Aby to zrobić, należy użyć: LEFT OUTER JOIN.

Dodane połączenie musi mieć następującą strukturę:

tabela_źródłowa

LEFT OUTER JOIN tabela_docelowa

ON tabela_źródłowa = tabela_docelowa

Zamiast kolumny _BK w raporcie należy użyć odpowiedniej kolumny w tabeli docelowego obiektu biznesowego, która zawiera klucz biznesowy.

W raporcie należy użyć kolumny Business_Key_text tabeli docelowego obiektu biznesowego zamiast kolumny _text.

Kolumna łańcuchowa instancji z sufiksem _text

Jeśli powyższe warunki są spełnione, kolumna ta jest dodawana. Jej nazwa jest tworzona z nazwy atrybutu źródłowego i przyrostka _text. Jest ona oznaczona etykietą z opisu danych atrybutu źródłowego. Zawartością kolumny jest łańcuch instancji obiektu biznesowego. Podczas oceny żądania serwer aplikacji ładuje powiązaną instancję obiektu biznesowego za pośrednictwem usługi trwałości. Może to prowadzić do dłuższych czasów odpowiedzi w przypadku żądań z dużym zestawem wyników.

Kolumna ta może być używana w raporcie tylko do wyświetlania, ale nie do selekcji po stronie bazy danych (klauzula JOIN/WHERE), grupowania (GROUP BY) i sortowania (klauzula ORDER BY).

Kolumna klucza biznesowego z przyrostkiem _BK (kolumna BK)

Jeśli klucz biznesowy obiektu docelowego ma zostać uwzględniony, spełniony musi być również następujący warunek: Klucz biznesowy obiektu docelowego składa się z dokładnie jednego atrybutu typu String.

Nazwa kolumny jest tworzona z nazwy atrybutu źródłowego i przyrostka _BK. Etykieta jest określana na podstawie opisu danych logicznego typu danych należącego do atrybutu klucza biznesowego.

Optymalizacja instrukcji bazy danych

Należy pamiętać, że kolumny _BK są rozwiązywane w różny sposób w zależności od ustawienia opcji Dostęp ODBC (w aplikacji Panel system -> Typ: Serwer aplikacji). Jeśli kolumny _BK są dostępne przez dane główne, zawartość jest określana albo przez usługę trwałości, albo przez bazę danych. Jeśli pamięć podręczna serwera aplikacji jest wystarczająco duża, obliczenie zawartości przez usługę trwałości jest korzystniejsze niż rozwiązanie przez bazę danych.

Przy ograniczonym dostępie ODBC tylko dane podstawowe o rozmiarach danych S i M są rozwiązywane przez usługę trwałości. Dane podstawowe o rozmiarach danych L, XL i XXL są określane przez bazę danych. Zapobiega to usuwaniu innych obiektów biznesowych z pamięci podręcznej serwera aplikacji podczas ograniczonego dostępu przez ODBC.

Przy nieograniczonym dostępie ODBC wszystkie dane podstawowe są rozwiązywane za pośrednictwem usługi trwałości. Może to utrudniać działanie innych procesów uruchomionych na serwerze aplikacji, ponieważ dane wymagane przez te procesy są usuwane z pamięci podręcznej. To ustawienie jest zalecane dla serwera aplikacji, który przetwarza głównie dostępy ODBC.

Opcję Dostęp ODBC można ustawić w aplikacji Panel system dla serwera aplikacji.

Wirtualna kolumna relacji

Istnieje możliwość dodania wirtualnej kolumny do tabeli obiektu biznesowego, której zawartość jest obliczana w czasie wykonywania zapytania. Ta wirtualna kolumna jest oparta na relacji między obiektem biznesowym a określonym obiektem biznesowym.

Muszą zostać spełnione następujące warunki:

• model relacji musi 1:1
• docelowy obiekt biznesowy ma dokładnie jeden atrybut typu danych GUID jako klucz podstawowy
• relacja jest zdefiniowana przez dokładnie jeden atrybut, atrybut docelowy jest atrybutem klucza głównego
• obiekty źródłowe i docelowe są zdefiniowane w tej samej bazie danych.

Docelowy obiekt biznesowy nie musi mieć klucza biznesowego lub klucz biznesowy może być wieloczęściowy lub mieć typ inny niż ciąg znaków.

Jeśli taka relacja istnieje dla obiektu biznesowego, a definicja kolumny wirtualnej została zapisana dla docelowego obiektu biznesowego, kolumna wirtualna jest dodawana do tabeli obiektu biznesowego.

Klasa musi być zaimplementowana dla wirtualnej kolumny, która oblicza zawartość kolumny dla każdego wiersza tabeli. Klucz podstawowy odpowiedniej instancji docelowego obiektu biznesowego jest przekazywany jako parametr wejściowy do obliczeń.

Nazwa kolumny wirtualnej jest tworzona z nazwy atrybutu źródłowego z dowolnie wybranym przyrostkiem. Nazwa musi być unikalna w obrębie tabeli rozszerzonej.

Wirtualna kolumna może być używana wyłącznie do celów wyświetlania.

To specjalne rozwiązanie może być wykorzystane do replikacji kolumny _BK, jeśli docelowy obiekt biznesowy nie spełnia warunków dla klucza biznesowego dla automatycznie dodanej kolumny _BK.

Rozdzielczość zestawu wartości atrybutów

Atrybut obiektu biznesowego, którego logiczny typ danych jest oparty na zestawie wartości (ValueSet), jest reprezentowany przez dwie kolumny w źródle danych. Jedna z kolumn jest oznaczona nazwą atrybutu i zawiera wartość zestawu wartości, która odpowiada nazwie stałej. Nazwa drugiej kolumny składa się z nazwy atrybutu i przyrostka _text. Kolumna ta zawiera opis powiązany z wartością ValueSet w języku wyświetlania ustawionym dla źródła danych. Obie kolumny mają przypisaną etykietę przechowywaną w opisie danych należącym do logicznego typu danych atrybutu jako etykietę kolumny.

Jeśli w raporcie zaprogramowano atrybut ValueSet lub określono dla niego selekcje lub warunki, należy zawsze używać stałej nazwy. W ten sposób raport pozostaje niezależny od zmian w nazwie wpisów zestawu wartości i niezależnie od wybranego języka wyświetlania. Parametry raportu, które pochodzą z zestawów wartości, są przesyłane z Comarch ERP Enterprise do aplikacji raportu w tej reprezentacji.

Kolumna _text może być używana wyłącznie do celów wyświetlania.

Wyboru można dokonać tylko w kolumnie stałych z ważnymi stałymi zestawu wartości.

Wartość niezdefiniowana

Kolumny oparte na zestawach wartości mogą być również niezdefiniowane. Aby określić to w raporcie, należy sprawdzić pusty ciąg znaków dla nazwy stałej. W takim przypadku odpowiednie oznaczenie zestawu wartości jest również pustym ciągiem znaków.

Nieprawidłowa wartość

Wartość <invalid> dla oznaczenia zestawu wartości jest przypadkiem specjalnym. Wartość ta jest zawsze zwracana przez źródło danych, jeśli w rekordach danych zostanie znaleziona wartość niezawarta w zestawie wartości. Zazwyczaj wskazuje to na możliwy problem z bazowymi transferami starszych danych. Nie można wybrać nieprawidłowych wartości.

Reprezentacja specjalnych typów danych biznesowych (części specjalne)

Comarch ERP Enterprise oferuje specjalne typy danych, które mają złożone struktury. Najważniejszymi z nich są kwoty i ilości. Są one specjalnie obsługiwane w interfejsie bazy danych.

Rozdzielczość atrybutów typu Foreign Amount

Atrybut oparty na części specjalnej com.cisag.general.obj.ForeignAmount jest reprezentowany przez kilka kolumn w tabeli odpowiadającej obiektowi biznesowemu. Odpowiadają one atrybutom części i innym atrybutom dodanym przez interfejs bazy danych. Nazwy kolumn są tworzone z nazwy atrybutu i odpowiedniego sufiksu. Poniższa tabela zawiera przegląd.

Rozdzielczość atrybutów typu DomesticAmount

Atrybut oparty na części specjalnej com.cisag.general.obj.DomesticAmount jest reprezentowany przez kilka kolumn w tabeli odpowiadającej obiektowi biznesowemu. Nazwy kolumn są tworzone z nazwy atrybutu i odpowiedniego sufiksu.

Użycie kolumn z przyrostkami _amountCorporate i _ amountOrganisation

Podczas korzystania z atrybutu typu Kwota krajowa w raporcie należy wziąć pod uwagę następujące kwestie w związku z wielofirmowścią i wyprowadzaniem kwoty w walucie głównej organizacji:

Pojedyncza witryna: Tworzenie raportu

Kolumna _amountCorporate zawiera kwotę waluty 1, 2 lub 3 kwoty krajowej zgodnie z wiodącym indeksem walutowym klienta. Kolumna _amountOrganisation zawiera te same informacje, co kolumna _amountCorporate.

Wiele lokalizacji: Tworzenie raportu

Kolumna _amountCorporate zawiera kwotę w walucie 1, 2 lub 3 kwoty krajowej zgodnie z indeksem waluty wiodącej aktywnej organizacji. Może to być wartość kwoty odnosząca się do innej waluty, jeśli kwota krajowa, która ma zostać wydana, nie pochodzi od aktywnej organizacji.

Kolumna _amountOrganisation zawiera kwotę w walucie głównej aktywnej organizacji. Została ona obliczona na podstawie waluty 1 (waluta grupy) kwoty krajowej ze współczynnikiem konwersji. Ta wartość jest obliczana i nie może mieć jakości dokładnej wartości.

Podczas tworzenia raportu wewnętrznego organizacji, w którym używane są tylko kwoty krajowe z tymi samymi przypisaniami walut, pole amountCorporate jest zawsze preferowane w stosunku do pola _amountOrganisation, ponieważ zawiera ono wartość z kwoty krajowej i nie jest obliczane na podstawie waluty grupy.

Kolumny globalne tabeli

Jeśli obiekt biznesowy zawiera co najmniej jeden atrybut typu Kwota krajowa, do odpowiedniej tabeli dodawane są następujące kolumny:

Rozdzielczość atrybutów typu Quantity

Atrybut oparty na części specjalnej com.cisag.general.obj.Quantity jest reprezentowany przez kilka kolumn w tabeli odpowiadającej obiektowi biznesowemu. Odpowiadają one atrybutom części i innym atrybutom dodanym przez źródło danych. Nazwy kolumn są tworzone z nazwy atrybutu i odpowiedniego przyrostka.

Specjalna kolumna link_text

Jeśli tabela jest tabelą jednostki biznesowej, która ma dokładnie jeden identyfikator GUID jako klucz podstawowy, do tabeli dodawana jest dodatkowa kolumna o nazwie link_text. Kolumna ta zawiera adres URL, za pomocą którego można otworzyć powiązaną instancję obiektu biznesowego w celu przeglądania/edycji przy użyciu domyślnej aplikacji.

W raporcie wartość pola lub kolumny może być zdefiniowana jako hiperłącze. Oznacza to, że jednostka biznesowa, do której odnosi się hiperłącze, można otworzyć z raportu za pomocą przeglądarki w Comarch ERP Enterprise.

Ta kolumna może być używana wyłącznie do celów wyświetlania.

Obsługa atrybutów obiektów blob

Interfejs bazy danych nie obsługuje atrybutów obiektów biznesowych opartych na typach danych Blob, SBlob i Text. Takie atrybuty nie mają odpowiedniej kolumny w tabeli obiektów biznesowych.

Wyjątki

Domyślnie obsługiwane są jednak atrybuty blob obiektów biznesowych com.cisag.app.general.obj.Text i com.cisag.app.general.obj.LongText. Są one przeznaczone do dołączania tekstów, które są przechowywane w skompresowanej formie w bazie danych. W ten sposób moduł tekstowy może zostać przypisany do obiektu biznesowego poprzez relację.

Atrybuty blob tabel wirtualnych com.cisag.app.general.ItemImage i com.cisag.app.general.PartnerImage są obsługiwane. Zawierają one dane binarne odpowiednich obrazów.

Aby dodać obsługę atrybutu blob dla obiektu biznesowego lub tabeli wirtualnej, należy go zarejestrować. Do tego celu służy hook com.cisag.pgm.appserver.hook.ODBCRegistryHook, który jest zdefiniowany w Hook Contract com.cisag.pgm.appserver.Server. Atrybuty blob mogą być rejestrowane bez konfliktu poprzez oddzielną implementację tego hooka.

Atrybut blob może być używany tylko do wyświetlania. Maksymalny rozmiar obiektu blob wynosi 16 MB.

Rozdzielczość atrybutów daty i znacznika czasu

Comarch ERP Enterprise udostępnia różne typy znaczników czasu i dat. Wszystkie wartości daty i znacznika czasu są zawsze przechowywane w bazie danych jako znacznik czasu odnoszący się do strefy czasowej GMT. Jeśli typ danych zawiera również informacje o strefie czasowej, GUID strefy czasowej jest również przechowywany w bazie danych. Szczegółowe informacje na temat typów znaczników czasu i dat można znaleźć w artykule Typy danych w Comarch ERP Enterprise.

Wartość znacznika czasu lub daty jest wyprowadzana z uwzględnieniem informacji o strefie czasowej. Jeśli wyprowadzana wartość nie ma własnych informacji o strefie czasowej, używana jest strefa czasowa z kontekstu logowania. W interaktywnym trybie ODBC strefa czasowa organizacji określona podczas wprowadzania źródła danych określa, która strefa czasowa jest używana jako kontekst. W środowisku jednostanowiskowym automatycznie używana jest strefa czasowa klienta. Gdy raporty są wysyłane za pośrednictwem SOM, używana jest strefa czasowa organizacji zalogowanego użytkownika. Jeśli nie można określić strefy czasowej organizacji, strefa czasowa systemu Comarch ERP Enterprise jest używana jako rezerwowa.

Interfejs bazy danych zapewnia wszystkie wartości znacznika czasu i daty w strefie czasowej GMT oraz w strefie czasowej kontekstu logowania. Dlatego atrybut oparty na typie znacznika czasu lub daty jest rozwiązywany na kilka kolumn.

Znacznik czasu bez informacji o strefie czasowej

W przypadku atrybutu opartego na podstawowym typie danych TimeStamp do tabeli obiektu biznesowego dodawane są następujące dwie kolumny:

Znacznik czasu lub data z informacją o strefie czasowej

W przypadku atrybutu opartego na specjalnym logicznym typie danych dla znacznika czasu lub daty, do tabeli obiektów biznesowych dodawane są następujące trzy kolumny:

Jeśli atrybut data na fakturze sprzedaży ma wartość 21.05.2025 00:00:00 MSK (czas moskiewski standardowy), a strefa czasowa kontekstu logowania jest inna, np. CET (czas środkowoeuropejski), wówczas interfejs bazy danych przekazuje następujące wartości dla kolumn należących do atrybutu:

Natomiast, jeśli faktura sprzedaży zostanie wystawiona w odniesieniu do strefy czasowej MSK (Moscow Standard Time), interfejs bazy danych przekaże następujące atrybuty:

Zakres wartości znaczników czasu

W interfejsie bazy danych stosowane są następujące wartości dla znaczników czasu i dat:

• Wartość niezdefiniowana – wartość 01.01.1000 00:00.000 (w odniesieniu do strefy czasowej GMT) reprezentuje niezdefiniowany znacznik czasu. Przykładowo: kolumna updateInfo_deleteTime_gmt zwraca tę wartość, jeśli wskaźnik usunięcia dla obiektu biznesowego nie został ustawiony.
• Wartość minimalna – wartość 31.12.1000 00:00.000 (GMT) reprezentuje najmniejszy znacznik czasu, który może być przetwarzany przez interfejs bazy danych. Wszystkie znaczniki czasu mniejsze niż ta wartość są mapowane na ten znacznik. Wartość niezdefiniowana nie jest uwzględniana w tym zakresie.
• Wartość maksymalna – wartość 31.12.4712 00:00:00.000 (GMT) reprezentuje największy znacznik czasu, który może zostać przetworzony przez interfejs bazy danych.

Znaczniki czasu większe niż ta wartość są mapowane na nią podczas przesyłania do serwera aplikacji.
Jeśli serwer ma zwrócić znacznik czasu większy niż ten, zwracana jest wartość 31.12.9999 00:00.000 (GMT).

Informacje o czasie

Aby możliwe było przetwarzanie czystych wartości czasowych (np. „02:15”), niezależnie od strefy czasowej, w systemie są one zapisywane z datą 01.01.1970 w odniesieniu do strefy czasowej GMT.

Interfejs bazy danych przekazuje takie wartości czasowe wraz z tą datą do Crystal Reports.
Aby poprawnie wykorzystać wartość czasową w szablonie raportu, należy:

• odjąć wartość daty 01.01.1970 od przekazanej wartości lub

• ukryć datę w polu wyjściowym raportu

Przetwarzanie informacji o zmianie obiektu biznesowego

Jeśli dla obiektu biznesowego określono, że system przechowuje informacje o zmianach (opcja Zaloguj użytkownika i czas w aplikacji Obiekty deweloperskie), w tym celu w tabeli obiektów biznesowych znajdują się dedykowane kolumny.

Poniższa tabela zawiera listę kolumn i ich znaczenie:

Obsługa pól zdefiniowanych przez użytkownika

Jeśli pola zdefiniowane przez użytkownika są oparte na rozszerzeniu obiektu, tj. są przechowywane w oddzielnej tabeli bazy danych, a nie w strukturze danych typu blob, można je przeszukiwać za pośrednictwem interfejsu bazy danych. Tabela bazy danych powiązanego obiektu biznesowego jest automatycznie rozszerzana o kolumny dla pól zdefiniowanych przez użytkownika.

Pola zdefiniowane przez użytkownika dla obiektów biznesowych mogą być wyszukiwane i używane w taki sam sposób, jak inne atrybuty za pośrednictwem interfejsu bazy danych. Nazwa kolumny w tabeli odpowiadającej atrybutowi składa się z nazwy atrybutu i przyrostka _ext. Pole zdefiniowane przez użytkownika jest przypisywane do kilku kolumn w tabeli w zależności od typu danych. Rozdzielczość jest analogiczna do zwykłego atrybutu obiektu biznesowego. Etykieta zdefiniowana podczas tworzenia pola zdefiniowanego przez użytkownika jest wyświetlana jako etykieta kolumny.

Typ danych Pole wyboru

Typ danych Pole wyboru dla pola zdefiniowanego przez użytkownika jest rozwiązywany podobnie do typu danych: Valueset.

Obiekty biznesowe zależne od czasu

Niektóre obiekty biznesowe mogą być zależne od czasu (np. obiekt biznesowy com.cisag.app.general.obj.Partner). Podczas odpytywania danych z obiektów biznesowych zależnych od czasu, brane są pod uwagę tylko wersje obowiązujące w bieżącym czasie, jak zwykle w Comarch ERP Enterprise.

Obiekty biznesowe zależne od czasu mają atrybuty validFrom i validUntil. Jeśli atrybuty te są wyraźnie uwzględnione w zapytaniu, tj. używane jako kolumna zwrotna, kryterium wyboru lub sortowania lub do celów grupowania, uwzględniane są wszystkie wersje instancji obiektów biznesowych.

Tabele wirtualne

Tabela wirtualna nie istnieje w bazie danych, ale jest emulowana przez SAS. Zasadniczo dostęp do takiej tabeli można uzyskać w taki sam sposób, jak do tabeli bazy danych. Zawartość tabeli wirtualnej jest obliczana w czasie wykonywania zapytania w odniesieniu do parametrów wejściowych. Wynik może zawierać od 0 do n wierszy. Dodatkowe kolumny można dodać do tego wyniku poprzez sprzężenia z tabelami z innych obiektów biznesowych. Liczba wierszy wyniku jest jednak określana wyłącznie przez tabelę wirtualną. Wyniki dla kolumn z połączonych tabel są określane za pośrednictwem usługi trwałości SAS, a nie bezpośrednio za pomocą instrukcji bazy danych.

Złożoność zapytania podlega znacznym ograniczeniom:

• Dozwolone są tylko typy złączeń LEFT OUTER i RIGHT OUTER. Tabela wirtualna musi zawsze stanowić główną stronę złączenia, tj. lewą stronę w przypadku złączenia LEFT lub prawą stronę w przypadku złączenia RIGHT. Warunek sprzężenia musi być sformułowany przy użyciu klucza podstawowego lub klucza biznesowego obiektu biznesowego należącego do połączonej tabeli. Tylko „=” jest dozwolone jako operator, a wszystkie podwarunki muszą być połączone za pomocą „AND”. Ograniczenia te mają również zastosowanie do złączeń, które pochodzą z tabeli, która jest połączona z tabelą wirtualną. Kolumny z połączonych tabel mogą być używane tylko do celów wyświetlania, co oznacza również, że tabela wirtualna nie może być połączona z inną tabelą wirtualną.
• Tabela widoku lub widoku OQL nie może być połączona z tabelą wirtualną lub być od niej zależna, ponieważ jej zawartość musi być określona w bazie danych.
• Kolumny tabeli wirtualnej mogą być używane wyłącznie do wyświetlania, sortowania i formułowania warunków łączenia. Ponadto kolumny, które są parametrami wejściowymi tabeli wirtualnej, mogą być również używane w klauzuli WHERE do przesyłania parametrów.
• Używanie agregatów i innych funkcji SQL, klauzul GROUP BY i HAVING jest niedozwolone.

Sortowanie wyników

Obsługa sortowania określonego w klauzuli ORDER BY zależy od programisty konkretnej tabeli wirtualnej. Z reguły sortowanie jest definiowane przez programistę, a określona kolejność sortowania jest ignorowana. Szczegóły dotyczące obsługi sortowania można znaleźć w artykule dotyczącej konkretnej tabeli wirtualnej.

Przypisywanie parametrów wejściowych

Klauzula WHERE może być używana do ustawiania wartości dla możliwych parametrów wejściowych tabeli wirtualnej. Nazwa kolumny, która może być użyta jako parametr wejściowy, zaczyna się od przedrostka in_. Nazwy kolumn muszą być odpowiednio wybrane podczas programowania tabeli wirtualnej. Kilka parametrów wejściowych do ustawienia musi być połączonych za pomocą AND. Tylko = jest dozwolone jako operacja ustawiania wartości parametru.

Klauzula WHERE nie może zawierać żadnych innych warunków.

W celu obsługi Crystal Reports i jego specjalnej funkcji podczas wybierania kolumn TimeStamp (brak obsługi milisekund), istnieje wyjątek dla parametrów wejściowych opartych na typie danych TimeStamp. W takim przypadku interwał jest również dozwolony jako warunek w następującej formie:

in_timeStampAttr >= dateValue1 AND timeStampAttr < dateValue2

Wartość dateValue1 jest przekazywana do tabeli wirtualnej dla parametru wejściowego in_timeStampAttr, inny warunek częściowy jest ignorowany.

Funkcje wirtualne

Funkcja wirtualna to specjalna tabela, która zwraca wiersz wyników dla zestawu wartości wejściowych, który jest obliczany w czasie wykonywania zapytania. Nie istnieje ona w bazie danych, ale jest emulowana przez SAS. Zazwyczaj jest używana do dodawania dodatkowych kolumn do wyniku zapytania.

Funkcja wirtualna jest zwykle łączona z inną tabelą bazy danych za pomocą złączenia LEFT OUTER. Warunek złączenia służy do określenia przypisania wartości dla parametrów wejściowych funkcji wirtualnej. Jeśli zapytanie zawiera JOIN, wynik zapytania jest najpierw określany bez uwzględnienia funkcji wirtualnej w bazie danych. Wartości kolumn funkcji wirtualnej są następnie obliczane dla każdego wiersza wyniku. SAS oblicza wartości kolumn wyjściowych funkcji wirtualnej dla przypisania wartości parametrów wejściowych określonych przez warunek sprzężenia. Kolumna, która może być użyta jako parametr wejściowy, zaczyna się od przedrostka in_. Warunek łączenia nie może zawierać żadnych innych podwarunków.

Funkcja wirtualna może być używana tylko w połączeniach, jak pokazano poniżej:

Tabela bazy danych A LEFT OUTER JOIN funkcja wirtualna VF ON A:columnName1 = VF:columnName1 [AND A:columnName2 = VF:columnName2]*

virtual function VF RIGHT OUTER JOIN database table A ON A:columnName1 = VF:columnName1 [AND A:columnName2 = VF:columnName2]*

Dopuszczalne jest dołączenie kilku funkcji wirtualnych do tabeli bazy danych. Funkcja wirtualna może być również połączona z inną funkcją wirtualną.

Funkcja wirtualna może również stanowić główną stronę JOIN. W takim przypadku obowiązują te same ograniczenia, co w przypadku złączeń z tabelami wirtualnymi.

Możliwe jest również określenie wartości dla parametrów wejściowych funkcji wirtualnej za pomocą klauzuli WHERE (analogicznie do tabeli wirtualnej). Wartość ustawiona w ten sposób zastępuje przypisanie wartości z warunku łączenia. Obowiązują te same zasady przypisywania parametrów, co w przypadku tabeli wirtualnej.

Tabela widoku lub widoku OQL może być używana tylko w sprzężeniu z funkcją wirtualną na stronie głównej sprzężenia, ponieważ jej zawartość musi być określona w bazie danych.

Funkcja wirtualna może być również używana samodzielnie w taki sam sposób jak tabela wirtualna. Zapewnia ona jednak maksymalnie jeden wiersz wyników.

Kolumny funkcji wirtualnej mogą być używane wyłącznie do wyświetlania i formułowania warunków łączenia. Ponadto kolumny, które są parametrami wejściowymi funkcji wirtualnej, mogą być również używane w klauzuli WHERE do przekazywania parametrów.

Automatyczna optymalizacja instrukcji bazy danych

Instrukcje bazy danych wysyłane za pośrednictwem interfejsu bazy danych serwera aplikacji są optymalizowane (w miarę możliwości) przed ich wykonaniem w bazie danych. Celem optymalizacji nie jest odczyt danych, które można założyć, że są buforowane przez serwer aplikacji z bazy danych, ale załadowanie ich z pamięci podręcznej serwera aplikacji. Z tego powodu podejmowana jest próba usunięcia tabel obiektów biznesowych danych podstawowych z instrukcji bazy danych, ponieważ są one przechowywane w pamięci podręcznej. Uproszczona instrukcja bazy danych jest następnie wykonywana w bazie danych. Wymagane dane podstawowe są następnie ładowane za pośrednictwem usługi trwałości, wykorzystując współdzieloną pamięć podręczną i dodawane do wyniku. Przestrzegając pewnych zasad podczas definiowania połączeń między tabelami bazy danych, można zwiększyć szybkość wykonywania raportów i zmniejszyć obciążenie bazy danych.

Tabela obiektu biznesowego jest usuwana z instrukcji bazy danych, jeśli spełnione są następujące warunki:

• Typ danych obiektu biznesowego to:
  • dane podstawowe
  • konfiguracyjne dane podstawowe
  • konfiguracyjne dane podstawowe (tylko do wyświetlania)
• Oczekiwany rozmiar danych obiektu biznesowego to Mały lub Średni. Jeśli serwer aplikacji działa w trybie Nieograniczony dostęp (pole dostępne w aplikacji Panel system -> Typ: Serwer aplikacji), rozmiar danych nie jest brany pod uwagę.
• Warunek łączenia został sformułowany tylko przy użyciu wszystkich atrybutów klucza podstawowego lub klucza biznesowego obiektu biznesowego.
• Kolumny w tabeli są używane tylko do celów informacyjnych.
• W przypadku obiektu biznesowego zależnego od czasu dostępna jest tylko bieżąca wersja.
• Właściwość com.cisag.sys.odbc.DisableJoinOptimisation nie jest aktywna. Ta właściwość służy do wyłączania optymalizacji i nie jest ustawiona domyślnie.

Konfiguracja serwera aplikacji

Odpowiednie ustawienia dostępu za pośrednictwem interfejsu bazy danych można wprowadzić w konfiguracji serwera aplikacji w Panel system. Ponieważ dostęp do interfejsu bazy danych za pośrednictwem JDBC jest nowszy, opcje konfiguracji są oznaczone jako ODBC. Mają one jednak również zastosowanie do dostępu JDBC.

Dostęp ODBC

Za pomocą pola Dostęp ODBC można określić, czy dany serwer aplikacyjny ma obsługiwać zapytania poprzez interfejs bazy danych, a jeśli tak – w jakim trybie dostępu ma pracować.
Dostępne są dwa tryby: Nieograniczony oraz Ograniczony.

Tryby te wpływają na zachowanie serwera aplikacyjnego w kontekście:

• liczby zajmowanych połączeń z bazą danych

• oraz zużycia pamięci operacyjnej podczas automatycznej optymalizacji instrukcji bazodanowych przesyłanych przez interfejs ODBC

Serwer aplikacyjny, którego głównym zadaniem jest obsługa zapytań przez interfejs bazy danych, powinien pracować w trybie Nieograniczonym.

Ograniczenie liczby używanych połączeń do bazy danych

Liczba połączeń z bazą danych używanych jednocześnie w celu uzyskania dostępu do interfejsu bazy danych może być ograniczona.

W trybie:

• Ograniczonym maksymalnie 50% możliwych połączeń z bazą danych dla dostępu do interfejsu bazy danych jest używanych jednocześnie. Zapewnia to, że inni użytkownicy mogą pracować interaktywnie z serwerem aplikacji.
• Nieograniczonym wszystkie dostępne połączenia z bazą danych są w razie potrzeby wykorzystywane do dostępu do interfejsu bazy danych. W rezultacie użytkownicy mogą nie być w stanie pracować interaktywnie.

Konfiguracja hiperłączy dla jednostek biznesowych

W przypadku jednostek biznesowych do odpowiedniej tabeli dodawana jest specjalna kolumna link_text. Zawiera ona adres URL do wyświetlenia jednostki biznesowej w Comarch ERP Enterprise. Aby wygenerować adres URL, serwer aplikacji przetwarzający żądanie interfejsu bazy danych musi być odpowiednio skonfigurowany.

W  aplikacji Panel system po wybraniu typu Serwer aplikacji, w polu Docelowy serwer dla atrybutów linka należy określić serwer aplikacji, na którym domyślna aplikacja ma zostać otwarta z instancją obiektu biznesowego jako parametrem. Może to być inny serwer aplikacji niż ten, który przetwarza żądanie interfejsu bazy danych. Musi on jednak mieć dostęp do tej samej bazy danych.

Uprawnienia

Uprawnienia do dostępu za pośrednictwem interfejsu bazy danych mogą być definiowane na poziomie użytkownika i jednostki biznesowej.

Uprawnieninia na poziomie użytkownika

Dostępne są następujące opcje umożliwiające lub uniemożliwiające użytkownikowi korzystanie z interfejsu bazy danych:

Autoryzacja na poziomie jednostki biznesowej

Oprócz możliwości, uprawnienia na poziomie jednostki biznesowej są również oceniane podczas uzyskiwania dostępu za pośrednictwem interfejsu bazy danych. Tabele jednostek biznesowych i ich zależności, do których zalogowany użytkownik nie ma uprawnień dostępu za pośrednictwem interfejsu bazy danych, nie są dla niego widoczne. Tabele wirtualne i funkcje wirtualne są zwykle przypisane do jednostki biznesowej i dlatego dziedziczą jej uprawnienia.

Uwagi dotyczące modelowania

W dalszej części przekazane są wskazówki w jaki sposób odtworzyć modele danych w Comarch ERP Enterprise i jak uniknąć błędów w modelowaniu.

Konwencje nazewnictwa źródeł danych

Raporty standardowe są powiązane ze standardowymi źródłami danych określonymi w tabeli:

W związku z tym powiązane źródła danych muszą zostać skonfigurowane na komputerze klienckim. Alternatywnie, źródło danych, które ma być używane w raporcie, można zmienić w aplikacji raportu. Szczegółowe informacje na temat aplikacji Raporty można znaleźć w artykule Raporty.

Ograniczenia podczas odpytywania wielu baz danych OLTP

Ze względów technicznych, w przypadku interaktywnego dostępu ODBC, tj. w aplikacji zewnętrznej, takiej jak Crystal Reports, po wybraniu źródła danych systemu ERP dla bazy danych OLTP nie można go zmienić. Oznacza to, że w przypadku zapytania do innej bazy danych OLTP, aplikacja raportująca musi zostać zamknięta i uruchomiona ponownie. Alternatywnie można otworzyć drugą instancję aplikacji.

Raport nie może zatem wysyłać zapytań do wielu baz danych OLTP, gdy jest wykonywany za pośrednictwem interaktywnego sterownika ODBC systemu ERP. Raport może jednak jednocześnie odpytywać bazę danych OLTP, repozytorium, konfiguracyjną oraz bazę danych OLAP należącą do bazy danych OLTP.

Ograniczenie to dotyczy tylko dostępu interaktywnego, ale nie danych wyjściowych raportu przy użyciu Menedżera danych wyjściowych systemu ERP (SOM).

Wizualizacja modelu danych

Aby uzyskać informacje o modelu danych dla danego obiektu biznesowego, pomocne jest sprawdzenie jego metadanych w aplikacji Obiekty deweloperskie. Alternatywnym sposobem wyświetlenia metadanych obiektu biznesowego jest użycie menu kontekstowego pola typu Entity – poprzez opcję Obiekt deweloperski.

Metadane zawierają informacje o atrybutach, typach danych, indeksach, relacjach i innych właściwościach obiektu biznesowego.

Aplikacja Diagramy modelu danych może być używana do uzyskania graficznej reprezentacji modelu danych dla zestawu obiektów biznesowych. Szczegółowe informacje można znaleźć w artykule Diagramy modelu danych.

Model danych raportu

Model danych Comarch ERP Enterprise jest złożony i zgodny z zasadami projektowania obiektowo-relacyjnego. W związku z tym, podczas tworzenia raportów, programista szybko staje przed koniecznością pracy z dużą liczbą tabel, do których raport uzyskuje dostęp. Oprócz braku przejrzystości, może to również prowadzić do problemów z wydajnością, ponieważ operacja łączenia między tabelami jest kosztowną operacją bazy danych. Złożoność raportu powinna być zatem zminimalizowana. Ponadto należy zadbać o to, aby złączenia między tabelami były sformułowane w taki sposób, aby automatyczna optymalizacja złączeń upraszczała wynikową instrukcję SQL, a w rezultacie można było wykorzystać pamięć podręczną serwera aplikacji.

Korzystanie ze specjalnych kolumn

W przypadku użycia wszystkich wymaganych tabel do sformułowania zapytania, mogłoby to szybko doprowadzić do złożonego modelu 10-15 tabel. Na przykład baza zamówień sprzedaży (CISAG^@ ENTITY.app_sales_SalesOrder) zawiera około 90 odwołań do innych tabel. Większość tych odniesień wskazuje na powszechnie używane obiekty biznesowe, takie jak waluty, typy zamówień, jednostki itp. W tym miejscu należy zawsze sprawdzić, czy kolumny dodane do tabeli przez interfejs bazy danych dla opisów (sufiksy _txt lub _BK) mogą być używane w raporcie zamiast formułowania JOIN z odpowiednią tabelą.

Zdenormalizowany obiekt biznesowy

Comarch ERP Enterprise w niektórych miejscach denormalizuje model danych, tj. zachowuje kopie. Powodem tego jest wydajność w dostępie do danych oraz archiwizacja danych transakcyjnych (np. dane podstawowe klientów w bazie zamówień).

Komunikaty o błędach

Błędy występujące podczas dostępu za pośrednictwem interfejsu bazy danych są rejestrowane za pomocą komunikatów o błędach. Może się to zdarzyć w różnych punktach i ma miejsce w trybie SOM oraz gdy interfejs bazy danych jest używany interaktywnie.

Błędy, które wystąpiły w serwerze aplikacji, są zapisywane w dzienniku systemowym serwera aplikacji, który wykonuje dostęp do interfejsu bazy danych i należą do klasy komunikatów ODS. Można je przeglądać za pomocą aplikacji Rejestr komunikatów.

SAS wysyła również wszystkie komunikaty o błędach do interfejsu bazy danych. Sterownik ODBC systemu ERP wprowadza do dziennika zdarzeń systemu Windows komunikaty otrzymane od SAS, a także komunikaty o błędach, które wystąpiły w samym sterowniku. Błędy występujące w sterowniku to zwykle komunikaty wskazujące na błędy komunikacji z serwerem ODBC. Sterownik JDBC generuje błędy w postaci wyjątków SQL.

W trybie SOM komunikaty o błędach są również wprowadzane do komunikatów o stanie powiązanego żądania wyjściowego, dzięki czemu wskazanie przyczyny błędu jest widoczne bezpośrednio na żądaniu wyjściowym. Powinien to być pierwszy punkt kontaktu w celu określenia przyczyny błędu.

W trybie interaktywnym komunikaty o błędach są udostępniane aplikacji ODBC (np. Crystal Reports) za pośrednictwem interfejsu API ODBC, dzięki czemu można je wyświetlać bezpośrednio w aplikacji za pomocą okien dialogowych.

Najczęstsze przyczyny błędów

Wiele błędów występuje z powodu nieudanej lub anulowanej komunikacji między zaangażowanymi serwerami. Przyczyny tego są często następujące: system został nieprawidłowo skonfigurowany, serwer aplikacji nie działa lub został ponownie uruchomiony podczas generowania raportu lub certyfikat jest nieprawidłowy. W przypadku pracy interaktywnej możliwą przyczyną są również nieaktualne źródła danych ODBC. Komunikaty o błędach komunikacji nie są rejestrowane w dziennikach komunikatów ODBC-SAS, ponieważ w momencie wystąpienia błędu nie ma połączenia.

Inne błędy są spowodowane brakiem uprawnień ODBC użytkownika używanego do dostępu ODBC lub dostęp ODBC nie jest dozwolony na serwerze aplikacji używanym do dostępu ODBC.

Wiele komunikatów o błędach pojawiających się podczas tworzenia raportów dotyczy ograniczeń opisanych w tym dokumencie dotyczących korzystania ze specjalnych kolumn obiektów biznesowych i typów danych, a także tabel/funkcji wirtualnych.

Sterownik JDBC

Oprócz sterownika ODBC, sterownik JDBC jest kolejnym interfejsem do baz danych systemu Comarch ERP Enterprise. Sterownik JDBC oferuje ten sam model danych co sterownik ODBC, który również jest przeznaczony tylko do odczytu. Wszystkie ustawienia skonfigurowane w aplikacji Panel system dla dostępu ODBC dotyczą również dostępu JDBC.

Instalacja sterownika JDBC

Sterownik JDBC jest dostarczany i aktualizowany jako plik instalacyjny com.cisag.sys.delivery.Install-JDBC-Driver w postaci pliku zip. Plik files/install/jdbc/jdbc-driver.zip należy rozpakować odpowiednim programem archiwizującym z folderu serwera plików systemu Comarch ERP Enterprise. Wszystkie rozpakowane pliki jar muszą znajdować się w ścieżce klas. Implementacja sterownika JDBC znajduje się w pliku semiramisjdbc.jar.

Konfiguracja połączenia JDBC

Sterownik JDBC komunikuje się z serwerem aplikacji za pośrednictwem protokołu HTTPS. Aby sterownik JDBC mógł nawiązać połączenie, należy utworzyć plik magazynu kluczy zawierający następujące informacje:

• klucz publiczny Comarch ERP Enterprise (główny urząd certyfikacji)
• certyfikat użytkownika

Plik magazynu kluczy można utworzyć za pomocą narzędzia wiersza poleceń Java keytool lub za pomocą aplikacji kreatora, takiej jak KeyStore Explorer, i musi być typu JKS.

Interfejs Java do nawiązywania połączenia JDBC (java.sql.Connection) oczekuje dwóch szczegółów: adresu URL połączenia i specyfikacji właściwości.

Adres URL połączenia musi zaczynać się od prefiksu protokołu jdbc:semiramis:, po którym następuje adres URL do SAS. Adres URL jest taki sam, jak adres używany do konfigurowania źródła danych ODBC. Można go zatem skopiować z okna dialogowego tworzenia źródła danych ODBC.

Właściwości są parami klucz-wartość dla wymaganych informacji konfiguracyjnych. Sterownik JDBC rozpoznaje następujące właściwości: