12 dokumentów oznaczonych z "Obiekt"

Poniżej opis budowania obiektu sprawy jako dowolna definicja XML lub JSON. Postać ta jest wykorzystywana w usługach SOAP (metody z sufiksem XML w nazwie) oraz usługach REST (usługi z sufiksem ExtRest w nazwie).

W niniejszym artykule znajdziemy opis uniwersalnego obiektu MRC wraz z jego komponentami. Jest on wykorzystywany w usługach SOAP oraz REST. W przeciwieństwie do dowolności tworzenia obiektów spraw za pomocą schematów ANY XML i ANY JSON, uniwersalny obiekt MRC jest zdefiniowany w sposób ścisły i i jednoznacznie opisuje dowolny obiekt MRC.

Strona jest w budowie i nie zawiera jeszcze wszystkich informacji. Proszę o cierpliwość.

Strona jest w budowie i nie zawiera jeszcze wszystkich informacji. Proszę o cierpliwość.

W artykule opisano obiekty będące kluczowymi elementami żądań w komunikacji z bazą danych za pośrednictwem usług SOAP i REST. Obiekt Context jest wykorzystywany we wszystkich usługach i jest podstawą do analizy uprawnień użytkownika, jak i formy odpowiedzi. Powszechne wykorzystanie w rozwiązaniu HgDB sprawiło, że zaszła potrzeba wytworzenia pewnego rodzaju standardu komunikacji pomiędzy integrowanymi systemami. Tak powstał projekt Context and Case Request Transportable Objects Open API, który został wykorzystany między innymi do komunikacji pomiędzy Mercury DB (HgDB) 3.0 oraz Iron - POI Excel Serwer.

W artykule opisano obiekt będący kluczowym elementem żądań w komunikacji z bazą danych za pośrednictwem usług SOAP i REST. Nagłówek CaseHeader jest niezbędny do realizacji zadań aktualizacji spraw w bazie danych, wpiera identyfikację i aktualizację definicji typu sprawy. Obiekt ten zawiera predefiniowane pola encji Case, które są wykorzystywane do identyfikacji sprawy, jej statusu oraz innych istotnych informacji. W artykule przedstawiono również przykłady konstrukcji nagłówka sprawy w różnych formatach (XML i JSON) oraz omówiono znaczenie poszczególnych pól.

Opis i przykład realizacji implementacji danych wyjściowych PagedResult, nazywany również wynikiem stronicowanym. Opisany format przesyłanych danych ma zastosowanie wszędzie tam, gdy w odpowiedzi na żądanie zwracane są listy o bardzo dużym wolumenie, których klient nie jest w stanie przetworzyć w jednej operacji, gdzie koniecznością jest podział tych list na strony. PagedResult jest pewnego rodzaju standardem odpowiedzi wykorzystywanym w komunikacji z systemem HgDB. W niniejszym rozdziale opisana została struktura typu w postaci JSON (dla usług REST) oraz XML (dla usług SOAP). Obiekt ma też swoją reprezentację (implementację) w Java i tam jest wykorzystywany w komunikacji RMI.

Mercury DB® jest również nazywany „bazą spraw”. Spróbujmy sobie teraz wyjaśnić czym jest pojęcie „sprawy” w interpretacji systemu. Sprawa to dowolny obiekt opisany przez typ i jego parametry. Długo się zastanawiałem w jaki sposób nazwać podstawową jednostkę definiującą taki obiekt. Słowo Object zarezerwowane jest przez wiele języków programowania stąd też pojawiło się pojęcie Case (sprawa), które w tym przypadku staje się jego synonimem. Pojęcie Case, ma również swoje odniesienie do pojęć biznesowych, które sobą reprezentuje w szeregu zastosowań praktycznych. Sprawa to reprezentacja obiektu umowy, kontrahenta, komputera, samochodu i nieskończonej liczby rzeczy, które nas otaczają, a chcielibyśmy je ewidencjonować w postaci elektronicznej. W dokumencie pojawia się wiele pojęć takie jak „obiekt złożony”, „sprawa zależna”, „sprawa nadrzędna”, „typ”, „parametry typu”, które mogą być różnie interpretowane. W dalszej części postaramy się wyjaśnić na podstawie konkretnego przykładu co te pojęcia oznaczają z punktu widzenia systemu Mercury DB®. Odniesiemy się do przykładu definicji obiektu danych w systemie IBM BPM, w którym posługujemy się pojęciem „Business Object” (BO, obiekt biznesowy).

Strona jest w budowie i nie zawiera jeszcze wszystkich informacji. Proszę o cierpliwość.

Każda usługa zaimplementowana w systemie Mercury DB (HgDB) 3.0 zawiera metodę echo (żądanie wysyłane metodą POST). Pozwala ona na weryfikację poprawności zdefiniowanej komunikacji pomiędzy klientem a serwerem. Przykładem zastosowania metody jest implementacja źródła danych dla systemu Grafana: datasource.ts gdzie w metodzie testDatasource() wykorzystano wywołanie metody echo usługi CaseSearchRest.

W niniejszym artykule opisane zostaną mechanizmy towarzyszące zapisowi sprawy do bazy Mercury DB (HgDB) na poziomie warstwy biznesowej. Pomimo istnienia w systemie metod zapisu spraw w usługach związanych z warstwą logiczną, nie rekomenduje się korzystania z nich. Traktuje się je jako przestarzałe. Ich utrzymywanie jako usługi jawne konieczne jest ze względu na kompatybilność z innymi produktami, które korzystają bezpośrednio z tej warstwy.

Mercury DB to serwer usług (SOAP oraz REST) pozwalający na zarządzanie dowolnymi obiektami, nazywanymi również sprawami. Jego silnik oparty jest o relacyjny model SQL (dane przechowywane są w relacyjnej bazie danych). Połączenie obiektów oraz relacji pozwala na wykorzystanie Mercury DB jako bazy danych obiektów obsługującej transakcje ACID (Atomicity, Consistency, Isolation, Durability czyli niepodzielność, spójność, izolacja, trwałość) jak i również zintegrowanie go z tradycyjnymi systemami BI (Business Intelligence) do analizy biznesowej danych. Łączy świat baz NoSQL (takich jak ElasticSearch, Mongo DB) ze światem baz relacyjnych (Oracle, DB2, PostgreSQL, MySQL).