IBM TRIRIGA Application Platform 3 OSLC

Transkrypt

IBM TRIRIGA Application Platform
Wersja 3 Wydanie 4.1
OSLC — Podręcznik integracji
Uwaga
Przed użyciem niniejszych informacji i produktu, którego one dotyczą, należy zapoznać się z treścią sekcji “Uwagi” na stronie 31.
Niniejsza edycja dotyczy wersji 3, wydania 4, modyfikacji 1 produktu IBM TRIRIGA Application Platform i wszystkich jego
późniejszych wersji i modyfikacji, o ile nie zaznaczono inaczej w nowych wydaniach.
© Copyright IBM Corporation 2014, 2014.
Spis treści
Rozdział 1. Integracja danych przy
użyciu specyfikacji OSLC . . . . . . . 1
Rozdział 2. Integracja w roli konsumenta
OSLC . . . . . . . . . . . . . . . . 3
Komponenty OSLC. . . . . . . . . . . . . 3
Terminologia OSLC . . . . . . . . . . . 3
Dostawcy usług i ich wykrywanie . . . . . . . 4
Przestrzenie nazw OSLC . . . . . . . . . . 5
Operacje i zasoby OSLC . . . . . . . . . . 5
Kształty zasobów . . . . . . . . . . . . 6
Dokumenty kształtów . . . . . . . . . . 7
Znaczniki ETags . . . . . . . . . . . . 10
Identyfikatory URI IBM TRIRIGA dla OSLC . . . 11
Rozdział 3. Praca z zasobami OSLC . . 13
Zapytania dot. zasobów OSLC . . . . . . . . .
Zapytanie z użyciem metod GET lub POST . . . .
Parametry zapytania OSLC . . . . . . . . .
Tworzenie zasobów OSLC . . . . . . . . . .
Tworzenie rekordów zależnych od rekordów głównych
Aktualizacja zasobów OSLC . . . . . . . . .
© Copyright IBM Corp. 2014, 2014
13
13
14
17
18
19
Metoda HTTP PUT . . . . . .
Metoda HTTP PATCH . . . . .
Aktualizowanie dowiązanych zasobów
Usuwanie zasobów OSLC . . . . .
Praca z załącznikami i danymi binarnymi .
Przetwarzanie załączników OSLC . .
Przetwarzanie danych binarnych OSLC
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
19
21
23
23
23
23
25
Rozdział 4. Zarządzanie zasobami OSLC 27
Zabezpieczenia OSLC
Zmiany haseł . .
Nieaktualne hasła .
Rejestrowanie OSLC .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
27
27
28
28
Rozdział 5. Rozwiązywanie problemów
z OSLC . . . . . . . . . . . . . . 29
Objaśnienia kodów HTTP specyfikacji OSLC
.
.
.
. 29
Uwagi . . . . . . . . . . . . . . . 31
Strategia ochrony prywatności .
Znaki towarowe . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 33
. 33
iii
iv
© Copyright IBM Corp. 2014
Rozdział 1. Integracja danych przy użyciu specyfikacji OSLC
Aplikacje produktu i niektóre aplikacje zewnętrzne mogą integrować i udostępniać sobie
nawzajem dane w oparciu o specyfikację integracji Open Services for Lifecycle Collaboration
(OSLC). OSLC ułatwia techniczną współpracę i wymianę danych między narzędziami.
Działając zgodnie z regułami i metodami opisanymi w specyfikacji, aplikacje mogą
wykonywać operacje tworzenia, żądania, aktualizowania i usuwania na zasobach innej
aplikacji.
Społeczność OSLC zrzesza twórców oprogramowania i instytucje współpracujące przy
standaryzacji wymiany danych między narzędziami do zarządzania cyklem życia zasobów.
Do danych tych należą na przykład wymagania, informacje o usterkach, scenariusze tekstowe
i historie zmian. Integracja OSLC aplikacji może odbywać się w oparciu o wersję 2.0
specyfikacji OSLC. Sama specyfikacja wraz z innymi zasobami OSLC dostępna jest w sieci
WWW>
Integracja OSLC realizowana jest między aplikacją konsumencką a zewnętrzną aplikacją
dostawcy. Aplikacja dostawcy OSLC udostępnia dane o swoich zasobach aplikacji
konsumenckiej za pośrednictwem kontenerów nazywanych dostawcami usług. Dzięki
dostępności danych o zasobach aplikacja konsumencka może tworzyć powiązania między
swoimi danymi a danymi zasobów aplikacji dostawcy. Każda aplikacja w produkcie może po
odpowiednim skonfigurowani działać jako aplikacja konsumencka OSLC.
Aplikacje konsumenckie mogą uzyskiwać identyfikatory URI zasobów w aplikacji dostawcy i
na podstawie tych identyfikatorów żądać, na przykład, wyników zapytań. Dostawcy usług
IBM® TRIRIGA są dostępny pod adresem http://twoj_serwer/oslc/sp.
Identyfikatory URI używane w żądaniach OSLC muszą być kodowane jako URL.
1
2
Rozdział 2. Integracja w roli konsumenta OSLC
Aplikacja, konsument OSLC, może być skonfigurowana do obsługi dwóch typów interakcji:
zapytań i tworzenia. Aplikacja konsumencka uzyskuje odsyłacze do zasobów od aplikacji
dostawcy.
Poniższy rysunek przedstawia interakcje między aplikacją konsumencką a aplikacją
dostawcy. Aplikacja konsumencka OSLC może pytać o zasoby lub tworzyć zasoby w
aplikacji dostawcy i zachowywać dla siebie odsyłacze do tych zasobów. Za pośrednictwem
odsyłaczy aplikacja konsumencka może kierować do aplikacji dostawcy żądania zapytań,
aktualizacji lub usuwania zasobów.
Komponenty OSLC
Dostawcy usług, zasoby i znaczniki ETag to informacje potrzebne do konsumowania danych
IBM TRIRIGA za pośrednictwem OSLC.
Terminologia OSLC
W przypadku terminów dotyczących rozwiązania IBM TRIRIGA1 OSLC przedstawione są
definicje.
aplikacja konsumencka
Aplikacja wykorzystująca dane w głównej hurtowni danych do określonych
zastosowań biznesowych.
fabryka tworzenia
Identyfikator URI używany do tworzenia nowych zasobów za pomocą metody
HTTP POST.
aplikacja dostawcy
W kontekście OSLC aplikacja udostępniająca dane o swoich zasobach aplikacji
konsumenckiej za pośrednictwem kontenerów nazywanych dostawcami usług.
Rozwiązanie IBM TRIRIGA jest aplikacją dostawcy dla aplikacji mobilnych the
IBM TRIRIGA Anywhere.
rekord dostawcy
Rekord identyfikujący aplikację dostawcy i zawierający definicje dla co najmniej
jednej interakcji OSLC między aplikacją konsumencką i aplikacją dostawcy.
3
publiczny identyfikator URI
Główny identyfikator URI używany w celu uzyskania dostępu do aplikacji dostawcy
OSLC.
funkcja zapytania
Podstawowy identyfikator URI służący do tworzenia URI zasobów zapytań.
zasób
W kontekście OSLC jest to sieciowy obiekt danych lub usługa, którą można
zidentyfikować za pomocą identyfikatora URI.
Resource Description Framework (RDF)
Struktura reprezentowania informacji w Internecie.
kształt zasobu
Specyfikacja definiująca stałą listę właściwości zasobu, oczekiwane typy danych i
wartości oraz reguły sprawdzania poprawności w przypadku nowych lub
zmienionych zasobów.
typ zasobu
W kontekście OSLC jest to typ danych połączonych między zintegrowanymi
aplikacjami, przykładowo może to być zlecenie zmiany statusu zadania roboczego.
dostawca usług
W kontekście OSLC jest to kontener zasobów zawarty w narzędziu lub produkcie w
celu zapewnienia możliwości korzystania z danego zasobu.
dokument kształtu
Rekord opisujący kształt zasobu i udostępniający go za pomocą identyfikatora URI.
Dostawcy usług i ich wykrywanie
Dostawca usług to kontener lub kolekcja zasobów utrzymywana i udostępniana przez
narzędzie lub produkt. Dostawcy usług są środkiem do grupowania podobnych zasobów,
takich jak defekty lub zadania, które mogą być konfigurowane na potrzeby integracji.
Dostawca usług w aplikacji dostawcy OSLC zawiera dane zasobów, które mogą być
powiązane z danymi aplikacji konsumenckiej poprzez zastosowanie mechanizmów integracji
między aplikacjami. Dane zasobów w programie IBM TRIRIGA mogą mieć postać tekstu w
językach z kodowaniem wielobajtowym. Aby możliwa była integracja między aplikacją
konsumencką a aplikacją dostawcy, konsument musi wykryć lub zidentyfikować dostawców
usług dostępnych w aplikacji dostawcy.
W programie IBM TRIRIGA dostawca usług może być bardzo prostu lub bardzo
skomplikowany, jak np. aplikacja zawierająca wiele modułów i obiektów biznesowych. W
programie IBM TRIRIGA można wykrywać dostawców usług, stosując następujące metody:
v Z menu Narzędzia > Konfiguracja systemu > Integracja > Menedżer OSLC
v Korzystając z identyfikatora URI: http://twoj_serwer/oslc/sp
Każda z tych metod prowadzi do uzyskania listy dostawców usług. W następującym
przykładzie przedstawiono identyfikator URI pracowników: http://twoj_serwer/oslc/sp/
Employee.
Identyfikator URI wskazuje na dokument dostawcy usług zapisany w formacie RDF/XML. W
formacie RDF/XML mogą być zapisane dokumenty kształtów, dostawcy usług, zasoby i dane
zasobów. Aplikacja konsumencka może użyć formularza dostawcy usług do określenia, które
zasoby i usługi są dostępne (np. zapytania, tworzenie).
Dostawca usług OSLC realizuje funkcje fabryki tworzenia OSLC oraz obsługuje zapytania,
udostępniając konsumentom identyfikatory URI służące do tworzenia lub wyszukiwania
4
zasobów obsługiwanych przez dostawcę. Dokument dostawcy usług opisuje dostępne zasoby
i odwzorowania przestrzeni nazw, a także operacje obsługiwane przez dostawcę usług w
odniesieniu do tych zasobów.
W poniższej przykładowej odpowiedzi odwołanie do dostawcy usług OSLC znajduje się we
właściwości rdfs:member. Dokument dostawcy usług dla domeny zawiera identyfikator URI
zadania:
<rdf:RDF>
<rdf:Description rdf:about="http://yourserver/oslc/sp">
<rdfs:member rdf:resource="http://yourserver/oslc/sp/WorkTask">
</rdf:Description>
</rdf:RDF>
Przestrzenie nazw OSLC
W rozwiązaniu OSLC definiowane są ogólne przestrzenie nazw. Właściwość
prefixDefinition zapewnia wyświetlanie wszystkich odwzorowań przedrostków na
przestrzenie nazw używanych przez dostawcę usług do opisywania zarządzanego zasobu.
Przestrzeń nazw właściwości musi się kończyć znakiem # lub /. Przykładowo:
http://yourserver/ns/property#.
W poniższej tabeli przedstawiono przykładowe przestrzenie nazw OSLC:
Przedrostek
Przestrzeń nazw
rdf
http://www.w3.org/1999/02/22-rdf-syntax-ns#
oslc
http://open-services.net/ns/core#
dcterms
http://purl.org/dc/terms/
asset
http://open-services.net/ns#
foaf
http://xmlns.com/foaf/0.1/
rdfs
http://www.w3.org/2000/01/rdf-schema#
rr
http://jazz.net/ns/ism/registry#
spi
http://jazz.net/ns/tririga
Poniższy fragment pochodzący z sekcji usługi w dokumencie dostawcy usług zawiera
przestrzenie nazw OSLC oraz RDF:
<oslc:ServiceProvider rdf:about="http://yourserver/oslc/sp/WorkTask">
<oslc:prefixDefinition>
<oslc:PrefixDefinition>
<oslc:prefixBase rdf:resource="http://open-services.net/ns/core#"/>
<oslc:prefix>oslc</oslc:prefix>
</oslc:PrefixDefinition>
</oslc:prefixDefinition>
<oslc:prefixDefinition>
<oslc:PrefixDefinition>
<oslc:prefixBase rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#"/>
<oslc:prefix>rdf</oslc:prefix>
</oslc:PrefixDefinition>
</oslc:prefixDefinition>
Operacje i zasoby OSLC
Dostawca usług OSLC realizuje operacje fabryki tworzenia oraz obsługuje funkcje zapytania
w przypadku zasobów dostępnych w dokumencie dostawcy usługi. Fabryka tworzenia
zapewnia identyfikator URI pozwalający na utworzenie oslc:creation używanego do
opracowania nowych zasobów za pomocą metody HTTP POST. Za pomocą identyfikatora
5
URI zapytania oslc:queryBase można wybrać zbiór zasobów zarządzany przez dostawcę
usług. Po uzyskaniu zasobu przez zapytanie lub utworzenie zasób można aktualizować lub
usunąć.
Operacja fabryki tworzenia
Jeśli zasób obsługuje tworzenie, może istnieć jedna operacja fabryki tworzenia. Poniższy
fragment pochodzący z dokumentu dostawcy usług zawiera operację fabryki tworzenia, adres
URL kształtu zasobu i URL operacji zasobu tworzenia tworzącej kształt.
<oslc:creationFactory>
<oslc:CreationFactory>
<oslc:resourceType rdf:resource="http://jazz.net/ns/tririga#WorkTask"/>
<oslc:resourceShape rdf:resource="http://yourserver/oslc/shapes/WorkTask"/>
<oslc:creation rdf:resource="http://yourserver/oslc/so/WorkTask"/>
<oslc:label>Create WorkTask</oslc:label>
<dcterms:title>OSLC creation factory for WorkTask</dcterms:title>
</oslc:CreationFactory>
</oslc:creationFactory>
......
Operacja funkcji zapytania
Identyfikator URI zapytania to oslc:queryBase, a w poniższym przykładzie przedstawiono
wyszukiwanie zadania roboczego za pomocą zlecenia: <oslc:queryBase
rdf:resource="http://nazwaserwera/oslc/spq/oslcwodetail"/>:
<oslc:queryCapability>
<oslc:QueryCapability>
<oslc:resourceType rdf:resource="http://jazz.net/ns/tririga#WorkTask"/>
<oslc:queryBase rdf:resource="http://yourserver/oslc/so/WorkTask"/>
<oslc:labelQuery>WorkTask</oslc:label>
<dcterms:taskname>OSLC query capability for WorkTask</dcterms:taskname>
</oslc:QueryCapability>
</oslc:queryCapability>
Po zdefiniowaniu kształtu zasobu OSLC wszystkie zapytania są dostępne poprzez dostawcę
usług. Udostępnianie zapytań odbywa się za pomocą funkcji zapytań OSLC.
Kształt zasobu OSLC można zdefiniować za pomocą raportu opracowywanego w
Menedżerze raportówIBM TRIRIGA. Kształt zasobów używa raportu jako szablonu w celu
zdefiniowania właściwości dostępnych dla zasobu. Te właściwości są zwracane po
uruchomieniu funkcji zapytania.
Każda funkcja zapytania zawiera właściwość o nazwie podstawa zapytania, która jest
używana do stosowania rozszerzonych kryteriów w zasobie. Za pomocą tych kryteriów
można wstępnie zdefiniować filtry dla tego samego kształtu. Pole Podstawa zasobu w
funkcji zapytania zawiera nazwę zapytania zgodną z zapytaniem, na podstawie którego
zdefiniowano zasób. Jeśli to zapytanie jest zdefiniowane, jest ono używane do filtrowania. W
zapytaniu można użyć parametrów TRIRIGA takich jak $$USERID$$, $$RECORDID$$
lub $$PARENT::SECTIONAME::FIELDNAME$$. Podstawa zapytania to lista, a jej
zawartość zmienia się wraz ze zmianami wprowadzanymi w zasobie. Przykładowo: zapytanie
MyWorkTask zwraca listę zadań roboczych, które są przypisane do użytkownika
odpowiadającego za zlecenie zapytanie.
Kształty zasobów
Kształt zasobu to plik w formacie RDF (Resource Description Framework) zawierający opis
typów danych zasobu, jakie mogą być używane w interakcjach. Kształt zawiera listę
atrybutów zasobu.
Plik RDF zasobu można wyświetlić na karcie Podgląd formularza zasobu.
6
Kształt zasobu jest podobny do schematu XML w tym sensie, że definiuje strukturę danych
zasobu.
Dokumenty kształtów
Dokument kształtu w rozwiązaniu OSLC stanowi elektroniczny sposób przedstawienia
zasobu wraz ze wszystkimi zależnościami, atrybutami i właściwościami. Przykładowo:
dokument kształtu zadania roboczego zawiera listę szczegółowych informacji dotyczących
zasobu zadania roboczego.
Dokumenty kształtów obejmują wszystkie zasoby, w tym aktywa, firmy, zamówienia i
zadania robocze. W dokumencie kształtu zawarto również wymagane elementy. Dokument
kształtu zasobu może zawierać połączenia z dokumentami kształtu obiektów podrzędnych.
Dokumenty kształtów są zapisywane w formacie RDF/XML.
Kształt zasobu zawiera właściwości, działania, i zasoby połączone zdefiniowane dla zasobu.
W rozwiązaniu IBM TRIRIGA podczas tworzenia nowego zasobu za pomocą formularza
zasobu OSLC należy określić moduł, obiekt biznesowy i zapytanie dot. obiektu biznesowego.
Można również wybrać moduł i zapytanie o wiele zasobów biznesowych. Na początek w
rozwiązaniu IBM TRIRIGA należy utworzyć zapytanie. W przypadku tworzenia kolumn
wyświetlania w zapytaniu użytkownik definiuje właściwości wstępne. Za pomocą czynności
Importuj wszystkie pola dostępnej w formularzu można zaimportować kolumny
wyświetlania z zapytania w postaci właściwości zasobu. Podczas importowania następuje
próba określenia dla pól IBM TRIRIGA wartości odpowiednich dla OSLC na przykład
wartości tylko do odczytu. Po zaimportowaniu można modyfikować pola oraz usuwać
właściwości. Właściwość dcterms:identifier pozwala na utworzenie ID rekordu podczas
importowania. Pole triRecordIdSY jest wymagane, jeśli użytkownik planuje aktualizowanie
zasobu.
W poniższej tabeli przedstawiono sposób przypisywania pól IBM TRIRIGA do typów
wartości właściwości OSLC:
Typ pola IBM TRIRIGA
Typ wartości właściwości OSLC
Logiczne
OslcPropertyValueType.Boolean
Obiekt biznesowy
OslcPropertyValueType.String
Klasyfikacja
Zestawienie klasyfikacji
OslcPropertyValueType.Decimal
Kolor
Uwaga: identyfikator URI musi być kodowany
jako URL podczas filtrowania pod względem
kolorów pól. Symbol # należy zastąpić za pomocą
ciągu znaków %23.
Numer kontrolny
Data
Data i godzina
Czas trwania
Zestawienie finansowe
Obraz
Tylko etykieta
Lista
Numer
7
Typ pola IBM TRIRIGA
Typ wartości właściwości OSLC
Hasło
Tylko do odczytu - system
Tekst
Czas
UOM
Url
Zasób połączony wskazuje zasób przeznaczony do połączenia. Zapewnia on łańcuchy
powiązania opisujące relację. Poniżej przedstawiono przykładowe łańcuchy powiązania:
Zawiera zasób, Zarządza i Przypisany Do Zasób połączony można dodać do właściwości.
Zasób połączony jest dozwolony i opcjonalny w przypadku pól lokalizatora i sekcji
inteligentnych.
Przykład: dokument kształtu zadania roboczego
Dokument kształtu zadania roboczego zawiera listę wszystkich właściwości, atrybutów i
zależności zadania roboczego. Poniższy kod prezentuje fragment dokumentu kształtu zadania
roboczego o nazwie WorkTask. W tym dokumencie kształtu zasobu są zawarte cztery
właściwości, ale dokument może zawierać wiele właściwości.
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:oslc="http://open-services.net/ns/core#"
xmlns:spi="http://jazz.net/ns/tririga/property#"
xmlns:dcterms="http://purl.org/dc/terms/">
<oslc:ResourceShape rdf:about="http://yourserver/oslc/shapes/WorkTask">
<oslc:property>
<oslc:Property>
<oslc:representation rdf:resource="http://open-services.net/ns/core#Either"/>
<oslc:readOnly>false</oslc:readOnly>
<oslc:occurs rdf:resource="http://open-services.net/ns/core#Exactly-one"/>
<oslc:valueType rdf:resource="http://www.w3.org/2001/XMLSchema#string"/>
<dcterms:title rdf:datatype="http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral"
>ID</dcterms:title>
<oslc:name>RecordInformation.triIdTX>/oslc:name>
<oslc:propertyDefinition rdf:resource="http://jazz.net/ns/tririga/property#triIdTX"/>
</oslc:Property>
</oslc:property>
<oslc:property>
<oslc:Property>
<oslc.readOnly>false</oslc:readOnly>
<oslc:occurs rdf:resource="http://open-services.net/ns/core#Exactly-one"/>
<oslc:valueType rdf:resource="http://www.w3.org/2001/XMLSchema#dateTime"/>
<oslc:defaultValue>TIMESTAMP</oslc:defaultValue>
<dcterms:title rdf:datatype="http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral"
>Planned Start</dcterms:title>
<oslc:name>RecordInformation.triPlannedStartDT</oslc:name>
<oslc:propertyDefinition rdf:resource="http://jazz.net/ns/tririga/property#triPlannedStartDT"/>
</oslc:Property>
</oslc:property>
<oslc:property>
<oslc:Property>
<oslc:readOnly>true</oslc:readOnly>
<oslc:occurs rdf:resource="http//open-services.net/ns/core#Exactly-one"/>
<oslc:valueType rdf:resource="http://www.w3.org/2001/XMLSchema#decimal"/>
<dcterms:title rdf:datatype="http//www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral"
>Actual Total Cost</dcterms:title>
<oslc:name>RecordInformation.triActualTotalCostNU</oslc:name>
<oslc:propertyDefinition rdf:resource="http://jazz.net/ns/tririga/property#triActualTotalCostNU"/>
</oslc:Property>
</oslc:property>
<oslc:property>
<oslc:Property>
<oslc:occurs rdf:resource="http//open-services.net/ns/core#Exactly-one"/>
<oslc:valueType rdf:resource="http://www.w3.org/2001/XMLSchema#string"/>
<dcterms:title rdf:datatype="http//www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral"
>Task Name</dcterms:title>
<oslc:name>RecordInformation.triNameTX</oslc:name>
<oslc:propertyDefinition rdf:resource="http://jazz.net/ns/tririga/property#trNameTX"/>
8
</oslc:Property>
</oslc:property>
<dcterms:title>WorkTask</dcterms:title>
</oslc:ResourceShape>
</rdf:RDF>
Pola numerów:
Atrybut dla skali jest podawany dla pól numerów w OSLC. Skala to liczba cyfr po prawej
stronie miejsca dziesiętnego liczby.
Jeśli numer posiada niestandardową maskę wyświetlania, wartość skali, która jest zwracana
opiera się na niestandardowej masce wyświetlania. Jeśli brakuje maski wyświetlania i nie
istnieje zestaw jednostek miary (JM), domyślnie jest zwracana wartość obydwu. Jeśli istnieje
jeden zestaw JM dla pola numerów i nie ustawiono maski wyświetlania dla pola, zwracana
jest skala maski wyświetlania JM. Znaki 0 i # w masce wyświetlania są uwzględniane
podczas określania skali.
Przykład: skala w polach numerów
Następujący przykład przedstawia zwracane wyniki z wartością skali wynoszącą 3:
<oslc:property>
<oslc:Property>
<spi:scale> 3 </spi:scale>
<oslc:valueType rdf:resource="http://www.w3.org/2001/XMLSchema#decimal"/>
<oslc:occurs rdf:resource="http://open-services.net/ns/core#Zero-or-one" />
<dcterms:title rdf:datatype="http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral">
Cost </dcterms:title>
<oslc:name> triCostNU </oslc:name>
<oslc:propertyDefinition rdf:resource="http://jazz.net/ns/spi#triCostNU" />
</oslc:Property>
</oslc:property>
Właściwości listy i JM:
Można wyświetlić wartości, które są dozwolone w przypadku właściwości listy jednostki
miary.
Właściwość JM lub listy zawiera element oslc:allowedValues, który obejmuje
identyfikator URI zasobu. Identyfikator URI zwraca listę dostępnych wartości, które można
użyć w przypadku właściwości tej listy lub JM.
Przykład
W poniższym przykładzie przedstawiono właściwość z elementem oslc:allowedValues
oraz listę dozwolonych wartości wynikających z identyfikatora URI w elemencie:
<oslc:property>
<oslc:Property>
<oslc:defaultValue>Japan Yen</oslc:defaultValue>
<oslc:valueType rdf:resource="http://www.w3.org/2001/XMLSchema#string" />
<oslc:usage rdf:resource="http://jazz.net/ns/ism/datatypes/
smarter_physical_infrastructure#uom" />
<oslc:occurs rdf:resource="http://open-services.net/ns/core#Zero-or-one" />
<oslc:name>exampleUOM</oslc:name>
<dcterms:title rdf:datatype="http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral">
exampleUOM</dcterms:title>
<oslc:allowedValues rdf:resource="http://yourserver/oslc/system/list/
9
resourceName/spi:exampleUOM" />
<oslc:propertyDefinition rdf:resource="http://jazz.net/ns/spi#exampleUOM" />
</oslc:Property>
</oslc:property>
<rdf:RDF>
<oslc:allowedValues rdf:about="http://yourserver/oslc/system/list/
resourceName/spi:exampleUOM">
<oslc:allowedValues>
<oslc:allowedValues>
<oslc:allowedValue>US Dollars</oslc:allowedValue>
<oslc:allowedValue>Swedish Krona/Kronor</oslc:allowedValue>
<oslc:allowedValue>Brazilian Real</oslc:allowedValue>
<oslc:allowedValue>Russian Ruble</oslc:allowedValue>
<oslc:allowedValue>Norwegian Krone</oslc:allowedValue>
<oslc:allowedValue>New Zealand Dollars</oslc:allowedValue>
<oslc:allowedValue>United Kingdom Pounds</oslc:allowedValue>
<oslc:allowedValue>Thai Baht</oslc:allowedValue>
<oslc:allowedValue>Canadian Dollars</oslc:allowedValue>
<oslc:allowedValue>Egyptian Pound</oslc:allowedValue>
<oslc:allowedValue>Euro</oslc:allowedValue>
<oslc:allowedValue>Polish Zloty</oslc:allowedValue>
<oslc:allowedValue>Korea Won</oslc:allowedValue>
<oslc:allowedValue>Hungarian Forint</oslc:allowedValue>
<oslc:allowedValue>South Africa Rand</oslc:allowedValue>
<oslc:allowedValue>Switzerland Francs</oslc:allowedValue>
<oslc:allowedValue>Japan Yen</oslc:allowedValue>
<oslc:allowedValue>Australia Dollars</oslc:allowedValue>
<oslc:allowedValue>Israeli New Shekel</oslc:allowedValue>
<oslc:allowedValue>Danish Krone</oslc:allowedValue>
<oslc:allowedValue>Indian Rupees</oslc:allowedValue>
<oslc:allowedValue>clIndiaRupee</oslc:allowedValue>
</oslc:allowedValues>
</rdf:RDF>
Znaczniki ETags
Znacznik ETag (znacznik obiektu) to nagłówek HTTP używany do sprawdzania, czy klient
(np. urządzenie mobilne) dysponuje najnowszą wersją rekordu. W przypadku wykonania
zlecenia GET znacznik ETag jest zwracany jako nagłówek odpowiedzi. Znacznik ETag
pozwala również klientowi na wykonanie zleceń warunkowych.
Poza obsługą podstawowych metod aktualizacji HTTP PUT i HTTP PATCH rozwiązanie
OSLC również obsługuje aktualizacje warunkowe. Aktualizacje warunkowe używają
znaczników obiektów HTTP i nagłówków If-Match w celu sprawdzania, czy klienty
dysponują najnowszymi obiektami dla zasobów. Ten proces ten używany do wykrywania
nieprawidłowych aktualizacji warunków śledzenia. Przykładowo: jeśli dwa klienty wczytują
ten sam zasób, rozwiązanie OSLC przesyła nagłówek ETag z odpowiedzią.
Wartością znacznika ETag jest data i godzina ostatniej aktualizacji zasobu. Klient
przechowuje wartość nagłówka ETag i wysyła jako część nagłówka HTTP If-Match dla
kolejnego zlecenia aktualizacji. Serwer ocenia nagłówek If-Match i określa, czy klient
dysponuje starą wersją czy najnowszą wersją zasobu. Jeśli serwer określi, że wersja klienta
jest stara, odsyła odpowiedź HTTP 412 precondition failed. Klient otrzymuje ponownie
zasób i przesyła zlecenie oparte na zaktualizowanym znaczniku ETag. Jeśli jednak serwer
określi, że klient wersja jest najnowszą wersją, aktualizacja jest wdrażana, o ile nie znaleziono
sprawdzenia poprawności biznesowej lub ograniczeń bazy danych.
Klient może również przesłać zlecenie bez nagłówka If-Match lub z wartością nagłówka
If-Match określoną jako * (gwiazdka). Przesłanie takiego zlecenia jest semantycznie
równoznaczne z brakiem nagłówka If-Match w zleceniu aktualizacji. W obu przypadkach
10
aktualizacja jest bezwarunkowa. Jeśli zasób, który jest określony przez identyfikator URI
istnieje i nie znaleziono sprawdzeń biznesowych ani ograniczeń bazy danych, aktualizacja jest
wdrażana.
Identyfikatory URI IBM TRIRIGA dla OSLC
Identyfikatory URI używane w celu nawiązania połączenia IBM TRIRIGA za pomocą OSLC
są niepowtarzalne.
Połączenie z IBM TRIRIGA można uzyskać za pomocą poniższych identyfikatorów URI:
OSLC component
Opis
Strona zasobów systemowych
http://yourserver/oslc
Logowanie
http://yourserver/oslc/login
Wylogowanie
http://yourserver/oslc/logout
Fabryka tworzenia
http://yourserver/oslc/so
Funkcja zapytania
http://yourserver/oslc/spq
Szczegóły zapytania
http://yourserver/oslc/so
Kształt zasobu
http://yourserver/oslc/shapes
Aby uzyskać dostęp do strony kształtu zasobu,
należy wprowadzić adres: http://yourserver/oslc/
shapes/ResourceShapeName
Dostawca usług
http://yourserver/oslc/sp
11
12
Rozdział 3. Praca z zasobami OSLC
Za pomocą metod HTTP można definiować sposoby tworzenia, usuwania aktualizowania
zasobów OSLC przez użytkowników oraz tworzenia zapytań dot. zasobów.
Zabezpieczenia IBM TRIRIGA są stosowane we wszystkich czynnościach dotyczących
danych. Użytkownik nie można utworzyć, zaktualizować, usunąć rekordu ani utworzyć
zapytania dot. rekordu bez odpowiedniego poziomu obsługi zabezpieczeń.
Zapytania dot. zasobów OSLC
Można tworzyć zapytania dot. zasobów OSLC, korzystając z metody HTTP GET lub HTTP
POST. Zmieniając parametry zapytania, można sterować sposobem wyszukiwania zasobów
przez użytkowników. OSLC definiuje prostą składnię zapytania pozwalającą tworzyć
zapytania dot. zasobów opartą na standardzie SPARQL.
Zapytanie z użyciem metod GET lub POST
Podczas opracowywania zapytań dot. zasobów OSLC można użyć metod HTTP GET lub
HTTP POST.
Podczas opracowywania zapytań dot. zasobów OSLC za pomocą metody HTTP GET w
identyfikatorze URI należy określić parametry. Jeśli identyfikator URI jest dłuższy niż 2000
znaków, należy opracować zapytanie za pomocą metody HTTP POST, a nie HTTP GET.
Metody HTTP POST można również użyć, jeśli identyfikator URI jest krótszy niż 2000, ale
nadal długi, lub jeśli użytkownik chce ukryć parametry zapytania, aby nie były wyświetlane w
URI.
W przypadku zapytań z użyciem metody HTTP POST należy określić dla nagłówka HTTP
Content-Type ustawienie application/x-www-form-urlencoded, przesłać identyfikatory URI
bez parametrów i określić parametry zapytania w treści zlecenia HTTP.
Przykład: zapytanie za pomocą metody HTTP GET
Poniżej przedstawiono przykład zapytania za pomocą metody HTTP GET. Wszystkie
parametry zapytania są wyświetlane w identyfikatorze URI.
http://yourserver/oslc/spq/WorkTaskQuery?oslc.select=
spi:triNameTX,spi:RCA{spi:triRCARemedyCL}&oslc.where=
spi:RCA{spi:triRCARemedyCL="Clean"}&oslc.orderBy=%2Bspi:triNameTX
Przykład: zapytanie za pomocą metody HTTP POST
Poniżej przedstawiono przykład tego samego zapytania wykonanego za pomocą metody
HTTP POST. Identyfikator URI zostanie skrócony.
http://yourserver1/oslc/spq/WorkTaskQuery
Treść HTTP
Treść zlecenia HTTP zawiera wszystkie parametry zapytania.
oslc.select=spi:triNameTX,spi:RCA{spi:triRCARemedyCL}&oslc.where=
spi:RCA{spi:triRCARemedyCL="Clean"}&oslc.orderBy=%2Bspi:triNameTX
13
Parametry zapytania OSLC
Parametry zapytania OSLC zapewniają opcje określające sposoby opracowywania zapytań
dot. zasobów OSLC. Przykładowo: parametr oslc.orderBy definiuje kolejności wyników
zapytania. Obsługiwane parametry zapytania HTTP OSLC to: oslc.properties,
oslc.where, oslc.orderBy, oslc.select, oslc.pageSize i pageno.
Jeśli właściwość nie znajduje się w sekcji Ogólne formularza, należy określić nazwę sekcji
właściwości w formacie nazwasekcji#nazwapola. Na przykład triDetails#triTaskTypeCL.
Parametr oslc.properties
Parametr zapytania oslc.properties określa listę właściwości zasobu OSLC. Właściwości
mogą pochodzić z zasobu lub zasobów połączonych. Jest on używany w celu uzyskania
częściowej reprezentacji zasobu. Parametru oslc.properties nie można stosować w
zbiorach zasobów. Kolekcja zasobów to zasób OSLC zawierający inne zasoby OSLC jako
elementy składowe.
Przykład: zlecenia atrybutów
W poniższym przykładowym zleceniu określono, że wartości atrybutów shortTitle i isTask
są zwracane w wynikach:
http://yourserver/oslc/so/WorkTask/
337?oslc.properties=oslc:shortTitle,spi:isTask
Przykład: zlecenia atrybutów z zasobów połączonych
W poniższym zleceniu określono, że wartość nazwy organizacji klienta jest zwracana w
wynikach:
http://yourserver/oslc/so/WorkTask/
13353622?oslc.properties=*,spi:triCustomerOrgTX{spi:triNameTX}
To zlecenie zapewnia utworzenie następujących wyników:
{
spi:triNameTX: "WorkTask"
spi:triStatusCL: "Draft"
spi:triIdTX: "1027019"
-spi:triCustomerOrgTX: {
spi:triNameTX: "Company 01"
rdf:about: "http://yourserver/oslc/so/OrganizationRS/12877121"
}
rdf:about: "http://yourserver/oslc/so/triWorkTaskRS/13353622"
-trira:action: [10]
0: "triDelete"
1: "triInvalidUploadHidden"
2: "triIssue"
3: "triBaseline"
4: "triApplyTemplate"
5: "triCopy"
6: "triPlanHidden"
7: "triSave"
8: "triSaveAndClose"
9: "triTemporaryTemplate"
-prefixes: {
oslc: "http://open-services.net/ns/core#"
rdf: "http://www.w3.org/1999/02/22-rdf-syntax-ns#"
trira: "http://jazz.net/ns/tririga#"
dcterms: "http://purl.org/dc/terms/"
}
}
14
parametr oslc.where
Parametr oslc.where określa klauzulę WHERE filtrowania zestawu wyników zapytania.
Przykładowo: użytkownik chce wyświetlić listę zasobów zadań roboczych OSLC
utworzonych w danym zakresie czasowym i zatwierdzonych przez zarząd. Filtrowanie można
wykonać według zasobów połączonych z zastosowaniem parametru oslc.where.
Przykładowo: użytkownik może chcieć filtrować osoby według nazwiska przełożonego.
Klauzula WHERE OSLC obsługuje następujące, podstawowe operatory porównawcze:
Symbol
Opis
=
Equality
v "wartość" = równe
v "%wartość" = kończy się na
v "wartość%" = rozpoczyna się od
v "%wartość%" = zawiera
Należy zwrócić uwagę, że ręczne wpisanie
identyfikatora URI z symbolem % jako
fragmentem wyszukiwanym wymaga
zakodowania symbolu w następujący sposób:
"%25wartość"
!=
Inequality
<
Less than
>
Greater than
<=
Less than or equal to
>=
Greater than or equal to
Jeśli wymagane jest filtrowanie pod kątem elementów pustych lub innych niż puste, należy
wprowadzić słowo null po symbolu.
Wymogi parametru oslc.where
Daty są wyrażane w formacie ISO 8601. W przypadku typów pól Data i Godzina w
milisekundach przedstawiono, czy wartość pola jest niezerowa.
Specyfikacja OSLC obsługuje operator and jako operator logiczny między wyrażeniami
logicznymi. Operator logiczny or nie jest obsługiwany. W poniższym przykładzie wartość
literału w przypadku statusu jest ujęta w cudzysłów ponieważ właściwość statusu zawiera typ
danych łańcuch. Wartość ilości nie jest ujęta w cudzysłów, ponieważ jest to dziesiętna wartość
danych. Liczby całkowite i wartości logiczne również nie wymagają ujęcia w cudzysłów.
Przykładowo: spi:status="Zamknięty" and spi:quantity>10.5 and spi:active=true gdzie
spi:active zawiera typ danych logicznych.
Specyfikacja OSLC obsługuje operator or niejawnie w ramach pojedynczej właściwości,
używając operatora in. Przykładowo: aby wyświetlić wszystkie zadania robocze o statusie
Wydane lub Aktywne, należy użyć zapytania spi:status in ["Wydane","Aktywne"]
Przykładowo: wyszukiwanie zadań roboczych utworzonych w
danym zakresie czasowym i zatwierdzonych
Użycie poniższej klauzuli powoduje wyświetlenie listy zasobów zadań roboczych
utworzonych w określonym zakresie czasowym:
15
spi:status="Zatwierdzone" and dcterms:created>"2003-07-07T09:50:00-04:00" and
dcterms:created<="2004-07-07T09:50:00-04:00".
Używanie parametru oslc.orderBy w celu określania kolejności
sortowania
Parametr oslc.orderBy umożliwia zdefiniowanie kolejności wyświetlania wyników
zapytania. Przykładowo: listę zadań roboczych można uszeregować wg daty lub ID.
Aby uszeregować zadania robocze rosnąco wg daty utworzenia i szacowanego czasu trwania,
należy użyć następującego parametru oslc.orderBy: +dcterms:created,spi:estimatedDuration. Znak + określa sortowanie rosnące, a znak - sortowanie malejące.
Wartości są rozdzielane przecinkami. Następujący parametr oslc.orderBy jest
nieprawidłowy, ponieważ nie istnieje domyślne sortowanie w składni zapytania OSLC:
dcterms:created,-spi:estimatedDuration. Musi istnieć jawny znak + or - przy nazwie
właściwości. Parametr oslc.orderBy również obsługuje właściwości zagnieżdżone, np.
dcterms:creator{+foaf:name}. W rzeczywistych adresach URL znaki + i - nie działają.
Zamiast nich, w adresie URL należy użyć ciągów %2B i %2D.
Przykład: sortowanie oparte na zasobach połączonych
Pól zasobów połączonych można użyć jako kryteriów kolejności w celu sortowania rekordów
nadrzędnych i zasobów połączonych w rekordach nadrzędnych.
Przykładowo: mogą istnieć dwa główne obiekty, które są nazwane M1 i M2. M1 zawiera dwa
zasoby połączone o nazwach L1 i L3, a M2 zasoby połączone L2 i L4. Jeśli obiekty główne
zostaną posortowane rosnąco bez uwzględniania zasobów połączonych, wynikami będą M1,
M2. Jeśli obiekty główne zostaną posortowane malejąco, wynikami będą M2, M1. Jednak
ponieważ istnieje wiele zasobów połączonych w przypadku obiektów, podczas sortowania
malejącego lub rosnącego zasoby połączone również są sortowane. L1 i L3 są sortowane w
M1, L2, a L4 w M2.
Parametr oslc.select
Parametr oslc.select umożliwia określenie zlecenia dotyczącego częściowej reprezentacji
zbioru zasobów składowych. Parametr oslc.select jest zawsze stosowany do zasobów w
zbiorze. Należy określić listę właściwości uwzględnionych w zleceniu. Wybrane właściwości
mogą pochodzić z zasobu lub zasobów połączonych.
Przykład: zlecenia dot. zasobu częściowego
Parametr oslc.select zapewnia listę kwalifikowanych nazw właściwości rozdzielonych
przecinkami. Parametr oslc.prefix nie jest obsługiwany.
Poniższe zlecenie jest przykładem zlecenia dot. zasobu częściowego:
oslc.select=oslc:shortTitle,dcterms:creator
Przykład: właściwości z zasobów dowiązanych
Dzięki parametrowi oslc.select można wybrać właściwości z zasobów dowiązanych. Aby
pobrać informacje, takie jak nazwa twórcy, należy określić instrukcję SELECT jako
oslc.select= oslc:shortTitle,dcterms:creator{foaf:name}.
16
Zasób foaf:Person jest nazwą osoby określonej w wartości właściwości twórca. Aby uzyskać
wszystkie właściwości z zasobu, można użyć ciągu oslc.select=*. Tej samej składni można
użyć w przypadku parametru oslc.properties podczas wyszukiwania zasobu OSLC.
Przykład: właściwości z zasobów połączonych
Dzięki parametrowi oslc.select można wybrać właściwości z zasobów połączonych. Aby
pobrać informacje, takie jak wartość nazwy organizacji klienta, należy określić instrukcję
SELECT jako
http://yourserver/oslc/spq/WorkTaskQC
?oslc.select=*,spi:triCustomerOrgTX{spi:triNameTX}
&oslc.where=spi:triCustomerOrgTX!="null"
Użycie instrukcji SELECT zapewnia następującą odpowiedź:
{
-rdf:members: [1]
-0: {
spi:triNameTX: "WorkTask"
spi:triStatusCL: "Draft"
spi:triIdTX: "1027019"
-spi:triCustomerOrgTX: {
spi:triNameTX: "Company 01"
rdf:about: "http://yourserver/oslc/so/Organization/12877121"
}
rdf:about: "http://yourserver/oslc/so/WorkTask/13353622"
-trira:action: [10]
0: "triDelete"
1: "triInvalidUploadHidden"
2: "triIssue"
3: "triBaseline"
4: "triApplyTemplate"
5: "triCopy"
6: "triPlanHidden"
7: "triSave"
8: "triSaveAndClose"
9: "triTemporaryTemplate"
}
rdf:about: "http://yourserver/oslc/spq/WorkTask"
-prefixes: {
oslc: "http://open-services.net/ns/core#"
rdf: "http://www.w3.org/1999/02/22-rdf-syntax-ns#"
spi: "http://jazz.net/ns/tririga#"
dcterms: "http://purl.org/dc/terms/"
}
}
Parametr oslc.pageSize
Parametr oslc.pageSize określa liczbę wyników na stronę zwracanych przez serwer.
Przykładowo: oslc.pageSize=20 zapewnia, że zapytanie zwraca 20 wyników na stronę.
Parametr pageno
Parametr pageno określa stronę, którą zwraca serwer. Przykładowo: pageno=3 zapewnia,
że zapytanie zwraca tylko dane z trzeciej strony.
Tworzenie zasobów OSLC
Utworzenie wystąpienia zasobu OSLC wymaga użycia metody HTTP POST. Następnie
można udostępnić zasób innym aplikacjom i zaktualizować go za pomocą metod PUT,
PATCH lub MERGE.
17
O tym zadaniu
Klient OSLC przesyła dokument JSON zgodny z kształtem zasobu opublikowanym w
dokumencie kształtu. Dane są przesyłane do rozwiązaniaOSLC w treści zlecenia HTTP w
formacie JSON, a nagłówek HTTP Content-Type jest określany jako MIME type
application/json. Jeśli zlecenie zostanie przetworzone pomyślnie, klient OSLC otrzymuje
nagłówek lokalizacji HTTP z identyfikatorem URI nowo utworzonego zasobu. Aby
wyświetlić właściwości nowo utworzonego zasobu, można uwzględnić nagłówek właściwości
w zleceniu i określić właściwości, które zostaną wyświetlone. Właściwość nagłówka o nazwie
Właściwości jest zwracana i zawiera określone właściwości.
Podczas tworzenia zlecenia można uwzględnić identyfikator transakcji w nagłówku zlecenia
HTTP. Identyfikator transakcji musi być unikalny w obrębie wszystkich aplikacji klienta.
OSLC zapisuje status identyfikatora transakcji w bazie danych po zakończeniu zlecenia. Jeśli
użytkownik prześle zlecenie z identyfikatorem transakcji, OSLC sprawdza, czy w bazie
danych istnieje transakcja. Jeśli transakcja istnieje, zlecenie w OSLC nie zostaje
uruchomione. Zwracany jest błąd, który wskazuje, że zlecenie nie zostało zakończone z
powodu istnienia identyfikatora transakcji. Poniżej przedstawiono przykładowy nagłówek z
określonym identyfikatorem transakcji:
Accept: application/rdf-xml
transactionid: 6001
Content-Type: application/json;charset=utf-8
Jeśli zlecenie zostanie przetworzone pomyślnie, to klient OSLC otrzyma następującą
odpowiedź:
201 Created
Location: http://yourserver/oslc/so/WorkTask/10269
ETag: 1376596202470
W przypadku przesłania działania musi ono być prawidłowe w kontekście bieżącego stanu
rekordu. Przykładowo: jeśli bieżącym stanem rekordu jest Projekt, działanie zapisu jest często
prawidłowe. Działanie jest wywoływane po utworzeniu rekordu.
Na stronie wyników zapytania (oslc/spq) jeśli parametr oslc.select zawiera symbol
wieloznaczny(*), lub na stronie szczegółów zapytania (oslc/os), jeśli żaden parametr
oslc.properties nie jest dostarczony, wyniki obejmują wszystkie działania, które można
wykonać w przypadku każdego pobranego rekordu. Działanie jest przedstawione w postaci
"tririga:action":["action1","action2",...].
Zlecenia OSLC mogą zakończyć się niepowodzeniem w wielu powodów, np. z powodu
naruszeń biznesowych, uwierzytelnienia lub autoryzacji. Przykładowo: klient OSLC może
otrzymać błąd 400 Bad Request wraz z treścią HTTP zawierającą szczegóły dot. tego błędu.
Tworzenie rekordów zależnych od rekordów głównych
Istnieje możliwość tworzenia zasobów zależnych powiązanych z rekordami głównymi.
O tym zadaniu
Można dodać powiązane rekordy zależne do rekordu głównego. Rodzaj powiązania zależy od
zasobu głównego (nadrzędnego).
Przykład: Tworzenie zamówienia z dwoma wierszami.
Następująca metoda tworzy zasób reprezentujący zamówienie z dwoma zasobami
reprezentujący wiersze. Zasób nadrzędny nosi nazwę HasPOLineItem.
18
{
"spi:action":"Create Draft (triCreateDraft)",
"spi:triNameTX":"oslcPO",
"trirldr:HasPOLineItem":
[
{
"spi:action":"Create (triCreate)",
"spi:triNameTX":"POLineItem1"
},
{
"spi:action":"Create (triCreate)",
"spi:triNameTX":"POLineItem2"
}
]
}
odpowiedź:
201 Created
Location: http://yourserver/oslc/so/PO/10269
ETag: 1376596202470
Aktualizacja zasobów OSLC
Za pomocą metody HTTP PUT można zastąpić zasób OSLC, a metoda HTTP POST z
zastąpieniem PATCH pozwala na częściowe zaktualizowanie zasobu OSLC.
Metoda HTTP PUT w pełni zastępuje dane w zasobie za pomocą właściwości w zleceniu.
Metoda HTTP POST z parametrem x-method-override PATCH w żądaniu treści zastępuje
lokalną właściwość zasobu.
Metoda HTTP POST z parametrem x-method-override PATCH i PATCHTYPE określonym
jako MERGE wyszukuje i dopasowuje elementy zasobu lokalnego ze zlecenia elementami na
serwerze. W zależności, czy dopasowanie zostało znalezione, elementy zasobu lokalnego są
aktualizowane lub wstawiane. Element lokalny nigdy nie jest usuwany z właściwości zasobu
lokalnego.
Przy wysyłaniu żądania aktualizacji w nagłówku żądania HTTP można zawrzeć identyfikator
transakcji. Identyfikator transakcji musi być unikalny w obrębie wszystkich aplikacji klienta.
OSLC zapisuje status identyfikatora transakcji w bazie danych po zakończeniu zlecenia. Jeśli
użytkownik prześle zlecenie z identyfikatorem transakcji, OSLC sprawdza, czy w bazie
danych istnieje transakcja. Jeśli transakcja istnieje, zlecenie w OSLC nie zostaje
uruchomione. Zwracany jest błąd, który wskazuje, że zlecenie nie zostało zakończone z
powodu istnienia identyfikatora transakcji. Poniżej przedstawiono przykładowy nagłówek z
określonym identyfikatorem transakcji:
Accept: application/rdf-xml
transactionid: 6001
Content-Type: application/json;charset=utf-8
Metoda HTTP PUT
Operacja HTTP PUT służy do pełnego zastępowania zasobu OSLC. Metody PUT powoduje
zaktualizowanie właściwości literałów i zasobów lokalnych oraz usuwa wszelkie właściwości
zasobów lokalnych, które nie są uwzględnione w zleceniu.
Podczas korzystania z metody PUT w celu zastępowania zasobów OSLCobowiązują
następujące reguły:
v Wszystkie właściwości literałów określone w dokumencie zlecenia podlegają aktualizacji.
Wszystkie właściwości literałów nieokreślone jako części zlecenia nie są uwzględniane
19
bezpośrednio w tej operacji. Jednak mogą one zostać uwzględnione niejawnie przez logikę
biznesową dołączoną do zasobu. Ta reguła działa analogicznie do użycia metody PATCH
w celu wykonania aktualizacji zasobu.
v All local resource properties are replaced by corresponding property values from the
request. Jeśli właściwość zasobu nie jest uwzględniona w zleceniu, odpowiedni zasób jest
usuwany. Jeżeli właściwość zasobu jest uwzględniona, jego wartość zastępuje wartość na
serwerze.
v Zasobów referencyjnych nie można zaktualizować jawnie. Można jednak zaktualizować
właściwości odnoszące się do zasobów i będą one zgodne z modelem aktualizacji
właściwości literałów. Ta reguła działa analogicznie do użycia metody PATCH w celu
wykonania aktualizacji zasobu.
W poniższych przykładach zasób zadania roboczego zawiera jedną właściwość literału
taskname oraz jedną właściwość zasobu parts. Właściwość parts wskazuje części zasobu
lokalnego i jest powiązana z dwoma rekordami części. Jeśli zlecenie PUT zawiera właściwość
taskname bez właściwości parts, nazwa zadania jest aktualizowana, a dane części są
usuwane.
Przykład: aktualizacja właściwości literału
Poniższa metoda zapewnia aktualizowanie właściwości literału taskname:
PUT http://yourserver/oslc/so/WorkTask/123
{
"dcterms:taskname": "Check-out Leaking – Modified for Test"
}
odpowiedź:
204 No Content
ETag: 1376596202470
Nazwa zadania zostanie zmieniona na Zwróć przecieki – modyfikacje dla testów. Dane
parts nie zostały uwzględnione w metodzie, więc rekordy części są usuwane.
Przykład: aktualizacja właściwości zasobu lokalnego
Poniższa metoda zapewnia aktualizowanie właściwości zasobu lokalnego parts:
PUT http://yourserver/oslc/so/WorkTask/123
{
“spi:parts”: [
{
“spi:partsid": "0000000067",
"spi:quantity": 5
}
]
}
odpowiedź:
204 No Content
ETag: 1376596202470
Wykonywane jest wyszukiwanie rekordów części o ID 0000000067. Jeśli taki rekord części
istnieje, zostanie on zaktualizowany. Jeśli nie, nowy rekord części zostanie utworzony.
Wszystkie pozostałe dane części dla tego zasobu zadania roboczego są usuwane. Właściwość
20
taskname nie została uwzględniona w metodzie, więc nazwa zadania nie jest częścią
zlecenia, a wartość nie ulega zmianie.
Metoda HTTP PATCH
Metoda PATCH służy do częściowego aktualizowania zasobu OSLC. Metoda PATCH nie
usuwa żadnych właściwości zasobów lokalnych nieuwzględnionych w zleceniu. Zlecenie
PATCH jest przesyłane przez metodę POST z nagłówkiem x-method-override, dla którego
określono opcję PATCH.
Podczas korzystania z metody PATCH w celu zastępowania zasobów OSLCobowiązują
następujące reguły:
v Wszystkie właściwości literałów określone w dokumencie zlecenia podlegają aktualizacji.
Wszystkie właściwości literałów nieokreślone jako części zlecenia nie są uwzględniane
bezpośrednio w tej operacji. Jednak mogą one zostać uwzględnione niejawnie przez logikę
biznesową dołączoną do zasobu. Ta reguła działa analogicznie do użycia metody PUT w
celu zastąpienia zasobu.
v Wszystkie właściwości zasobów lokalnych są aktualizowane lub zastępowane przez
odpowiednie wartości właściwości ze zlecenia. Jeśli właściwość zasobu nie jest
uwzględniona w zleceniu, odpowiedni zasób lokalny nie podlega jawnym zmianom. Jeżeli
właściwość zasobu jest uwzględniona, jego wartość zastępuje lub aktualizuje wartość na
serwerze. Inne właściwości zasobów są usuwane przez metodę PATCH, a nie przez
MERGE.
v Zasobów referencyjnych nie można zaktualizować jawnie. Można jednak zaktualizować
właściwości odnoszące się do zasobów i będą one zgodne z modelem aktualizacji
właściwości literałów. Ta reguła działa analogicznie do użycia metody PUT w celu
zastąpienia zasobu.
Przykład: aktualizacja właściwości literału
Poniższa metoda zapewnia aktualizowanie właściwości nazwy zadania w przypadku zadania
roboczego:
POST http://yourserver/oslc/so/WorkTask/123
x-method-override: PATCH
{
"dcterms:taskname": "Check-out Leaking – Modified for Test"
}
W przeciwieństwie do metody PUT ta metoda PATCH nie aktualizuje innych właściwości
zadania roboczego.
Przykład: aktualizacja właściwości zasobu lokalnego
Poniższa metoda zapewnia aktualizowanie określonych rekordów części i usuwanie innych
danych:
{
"dcterms:taskname": "Check-out Leaking – Modified for Test",
“spi:parts”: [
{
“spi:partsid": "0000000067",
"spi:quantity": 5
}
]
}
21
Ta metoda działa podobnie do metody PUT. W systemie wykonywane jest wyszukiwanie
rekordu części o ID 0000000067. Jeśli taki rekord części istnieje, zostanie on
zaktualizowany. Jeśli nie, nowy rekord części zostanie utworzony. Wszystkie pozostałe
rekordy części dla tego zasobu zadania roboczego są usuwane.
Przykład: aktualizacja i scalanie właściwości zasobu lokalnego
Poniższa metoda zapewnia aktualizowanie zasobu, w przypadku którego dla nagłówka
PATCHTYPE wybrano opcję MERGE:
PATCHTYPE: MERGE
{
"dcterms:taskname": "Check-out Leaking – Modified for Test",
“spi:parts”: [
{
“spi:partsid": "0000000067",
"spi:quantity": 5
}
]
}
Wykonywane jest wyszukiwanie rekordów części o ID 0000000067. Jeśli taki rekord części
istnieje, zostanie on zaktualizowany. Jeśli nie, nowy rekord części zostanie utworzony. Dla
nagłówka PATCHTYPE określono opcję MERGE, więc inne rekordy części dla tego zasobu
zadania roboczego nie ulegają zmianie.
Przykład: wykonywanie aktualizacji warunkowej
Poniższa metoda zapewnia aktualizowanie zasobu, jeśli wartością znacznika ETag jest
1376596202470:
if-match: 1376596202470
Jeśli wartością znacznika ETag jest 1376596202470, zasób zadania roboczego jest
aktualizowany i przesyłany jest komunikat HTTP 204.
Jeśli wartością znacznika ETag nie jest 1376596202470, odpowiedzią serwera jest HTTP
412 Precondition failed. Ten komunikat oznacza, że zasób został zaktualizowany przez inny
proces i klient zlecający dysponuje starą kopią zasobów. Klient musi wykonać metodę GET w
zasobie 123 w celu uzyskania nowej kopii zasobu.
W poniższej tabeli przedstawiono zestawienie wyników metod aktualizacji w przypadku
różnych typów zasobów.
22
Metoda
Właściwości literałów
Zasoby lokalne
Zasoby referencyjne
PUT
W przypadku
pominięcia właściwości
dana właściwość nie
ulega zmianie.
W przypadku
dana właściwość jest
usuwana.
W przypadku
ulega zmianie.
PATCH
W przypadku
ulega zmianie.
W przypadku
ulega zmianie.
W przypadku
ulega zmianie.
W poniższej tabeli przedstawiono zestawienie wyników metod aktualizacji w przypadku
różnych typów zasobów.
Metoda
Właściwości literałów
Zasoby lokalne
Zasoby referencyjne
MERGE
W przypadku
ulega zmianie.
W przypadku
ulega zmianie.
W przypadku
ulega zmianie.
Aktualizowanie dowiązanych zasobów
Usuwanie zasobów OSLC
Usunięcie zasobu OSLC wymaga użycia metody HTTP DELETE.
Wprowadź ciąg HTTP DELETE w identyfikatorze URI zasobu. Jeśli obiekt biznesowy
zasobu zawiera zmianę stanu z bieżącego stanu zasobu na stan pusty, to stan obiektu zostaje
zmieniony na pusty.
Jeśli obiekt biznesowy zasobu nie zawiera zmiany stanu z bieżącego stanu zasobu na stan
pusty, to stan obiektu nie ulegnie zmianie. Można zmodyfikować obiekt biznesowy, aby
uwzględniał on zmianę stanu z bieżącego na pusty. Można również zaktualizować rekord za
pomocą metody HTTP PUT lub HTTP PATCH, zamiast HTTP DELETE i przekazać nazwę
czynności w celu uruchomienia operacji usuwania.
Jeśli zasób zawiera rekordy podrzędne, są one usuwane podczas usuwania zasobu. Jeśli zasób
zawiera rekordy powiązane, powiązanie jest usuwane podczas usuwania zasobu, ale
powiązane rekordy nie ulegają zmianie
Praca z załącznikami i danymi binarnymi
Klienty OSLC mogą pobierać, tworzyć i modyfikować załączniki i dane binarne za
pośrednictwem interfejsu API OSLC.
Przetwarzanie załączników OSLC
Przetwarzanie załączników w programie OSLC obejmuje przetwarzanie właściwego
załącznika, będącego dokumentem nieustrukturyzowanym, oraz przetwarzanie metadanych
powiązanych z tym dokumentem.
Metadane opisane są w pliku RDF zasobu AttachmentDescriptor. Zasób
AttachmentDescriptor są zawsze powiązane z załącznikami w relacji 1:1.
Tworzenie załączników OSLC
Załączniki tworzy się, korzystając z metody HTTP POST z treścią binarną. Nie należy
używać wieloczęściowych żądań HTTP POST.
Następujący przykład przedstawia żądanie HTTP tworzące załącznik służący do wyświetlania
obrazu niesprawnej części:
POST http://twoj_serwer/oslc/os/oslcwodetail/_abcd123/attachments
Slug: brokenpart.jpeg
Content-Type: image/jpeg
Content-Length: 18124
23
x-document-description: A broken part
x-document-meta: Attachment
[binary content]
Następujący przykład przedstawia odpowiedź na żądanie:
HTTP/1.1 201 CREATED
Location: http://yourserver/oslc/os/oslcwodetail/_abcd123/attachments/1
Link: <http://yourserver/oslc/os/oslcwodetail/_abcd123/attachments/meta/1>;
rel="describes"
Content-Length: 0
Nagłówek Slug zawiera nazwę pliku. Można użyć nagłówka x-document-description w
charakterze opisu załącznika. Opis ten jest odwzorowywany na właściwość
dcterms:description deskryptora nagłówka. Można użyć nagłówka x-document-meta do
wskazania nazwy folderu, w którym załącznik ma być przechowywany.
Modyfikowanie załączników OSLC
Załączniki OSLC można modyfikować, używając metody HTTP PUT z treścią binarną. Nie
należy używać wieloczęściowych żądań HTTP PUT.
Następujący przykład przedstawia żądanie HTTP modyfikujące załącznik:
PUT http://twoj_serwer/oslc/os/oslcwodetail/_abcd123/attachments/1
Slug: brokenpart2.jpeg
Content-Type: image/jpeg
Content-Length: 18124
x-document-description: A broken part
x-document-meta: Attachment
[binary content]
Następujący przykład przedstawia odpowiedź na żądanie:
HTTP/1.1 204
Content-Length: 0
Aby zmodyfikować wyłącznie opis załącznika, można użyć żądania PATCH względem
identyfikator URI meta, tak jak przedstawiono to w następującym przykładzie:
PATCH http://yourserver/oslc/os/oslcwodetail/_abcd123/attachments/meta/1
Content-Type: application/json
{
“dcterms:description”: “Broken pipe”
}
Wybieranie załączników OSLC
Załączniki zwykle są zasobami powiązanymi z zasobami ustrukturyzowanymi, takimi jak
zlecenia pracy lub zasoby fizyczne. Załączniki mogą być także powiązane z zasobami
podrzędnymi. Podczas pobierania zasobu ustrukturyzowanego domyślnie udostępniany jest
tylko odsyłacz do powiązanej kolekcji załączników. Jeśli konsument oczekuje, że dane
załączników będą włączone bezpośrednio do nadrzędnego zasobu ustrukturyzowanego,
należy użyć następującego formatu zapytania:
/oslc/os/oslcwodetail?oslc.select=res1,res2,spi:attachments{*}
24
Usuwanie załączników OSLC
Do usuwania załączników OSLC służy żądanie:
DELETE <uri załącznika>
Przetwarzanie danych binarnych OSLC
Klienty OSLC mogą pytać o dane binarne i modyfikować dane binarne, korzystając z
interfejsu API OSLC.
OSLC obsługuje następujące typy danych binarnych:
v Dane binarne oprogramowania TRIRIGA przechowywane są w tabeli dm_content. Każdy
element danych ma unikalny identyfikator treści, nazwę pliku i typ MIME określający
sposób wyświetlania danych. Pole binary zawiera identyfikator treści.
v Dane graficzne zapisane są jako pliki obrazów. Pole image zawiera część ścieżki do pliku
obrazu.
Zapytania o dane binarne
Gdy dane binarne są odbierane za pośrednictwem zapytania OSLC lub strony szczegółów
rekordu, wartości prezentowane są w formie identyfikatorów URI. Poniżej przedstawiono
przykładowy identyfikator URI z informacją o danych binarnych:
http://twoj_serwer/oslc/so/supApp/168867/tririga:supBinary
Klient może wykorzystać identyfikator URI do pobrania właściwych danych. W odpowiedzi
HTTP na identyfikator URI treść zawiera zawartość odczytaną z pola content tabeli
dm_content. Nagłówek Content-Type zawiera typ MIME danych binarnych.
Podobnie, gdy dane graficzne są odbierane za pośrednictwem zapytania OSLC lub strony
szczegółów rekordu, wartości prezentowane są w formie identyfikatorów URI. Poniżej
przedstawiono przykładowy identyfikator URI z informacją o danych graficznych
http://twoj_serwer/oslc/so/supApp/168867/tririga:supImage
Klient może wykorzystać identyfikator URI do pobrania właściwego obrazu. W odpowiedzi
HTTP na identyfikator URI treść zawiera obraz odczytany z pliku obrazu. Nagłówek
Content-Type zawiera informację o typie MIME złożoną z łańcucha image/ i rozszerzenia
nazwy pliku obrazu.
Modyfikowanie danych binarnych
Do modyfikowania każdej właściwości binarnej lub graficznej używa się osobnego żądania
HTTP. W Następujący przykład przedstawia format żądania aktualizacji danych binarnych
lub graficznych:
http://localhost:8001/oslc/so/soID/property
W tym przykładzie soID jest identyfikatorem inteligentnego obiektu, do którego należy
właściwość binarna lub graficzna. Właściwość identyfikuje właściwość binarną lub graficzną,
której przypisywana jest wartość. Ma zwykły format właściwości przedrostek:nazwaSekcjinazwaWłaściwości, przy czym nazwaSekcji jest opcjonalna.
Stosowana jest metoda HTTP PUT, a pole content-type nagłówka HTTP zawiera typ MIME
danych, zgodnie z następującym schematem:
v W przypadku właściwości binarnych typ MIME przekazany w nagłówku content-type jest
przyjmowany jako typ MIME danych. Można przekazać nazwę pliku za pośrednictwem
opcjonalnego nagłówka Slug.
25
v W przypadku właściwości graficznych pole content-type musi zawierać typ image. Typ
(type) jest formatem obrazu, takim jak PNG lub JPG. Nazwa pliku jest generowana, a typ
obrazu używany jest jako rozszerzenie nazwy pliku.
26
Rozdział 4. Zarządzanie zasobami OSLC
Uwierzytelnianie i obsługa uwierzytelniania dla usług OSLC są zapewniane za pomocą
zabezpieczeń IBM TRIRIGA. Za pomocą rejestrowania OSLC można debugować i szacować
wydajność.
Zabezpieczenia OSLC
Uwierzytelnianie i obsługa uwierzytelniania dla usług OSLC są zapewniane za pomocą
zabezpieczeń IBM TRIRIGA.
Uwierzytelnianie rodzime
Zlecenie konsumenta może zapewnić wartości user:password kodowane metodą base64 i
znajdujące się we właściwości nagłówka OSLC HTTP.
Jawne logowanie i wylogowywanie
Jeśli aplikacja konsumencka wymaga uruchamiania poleceń jawnego logowania, należy użyć
następującego zlecenia:
GET http://yourserver/oslc/login?USERNAME=username&PASSWORD=password
Jeśli aplikacja konsumencka wymaga uruchamiania poleceń jawnego wylogowywania, należy
użyć następującego zlecenia:
GET http://yourserver/oslc/logout
Uwierzytelnianie
Sterowanie uwierzytelnianiem odbywa się na poziomie obiektu biznesowego zasobu.
Przetwarzanie zabezpieczeń danych zasobu jest wtedy oparte na konfiguracji zabezpieczeń
aplikacji i grupie użytkownika, który wykonał zlecenie. Podczas przetwarzania zasobów
OSLC wszystkie atrybuty obiektów skonfigurowane jako ukryte za pośrednictwem
zabezpieczeń nie są uwzględniane w odpowiedzi na zlecenie OSLC.
Zmiany haseł
Aby użytkownik-klient mógł zmienić hasło, należy utworzyć zasób MyProfile OSLC oparty
na obiekcie biznesowym IBM TRIRIGA Mój profil.
Wykonanie zmiany hasła wymaga utworzenia zasobu MyProfile ze zdefiniowaną co najmniej
właściwością Password. Można również zdefiniować inne właściwości pozwalające na
obsługę innych zmian w profilu.
Zasób MyProfile w OSLC jest dostępny z poziomu identyfikatora URI:
http://yourserver/oslc/so/MyProfile/userId
Ten identyfikator URI zawsze zwraca profil bieżącego użytkownika bez względu na
wprowadzony ID użytkownika, ponieważ użytkownik nie ma możliwości wyświetlenia profili
innych użytkowników. Można określić funkcje zapytania dot. zasobu MyProfile, ale wyniki
zapytania nie zwracają więcej informacji niż jest dostępne w profilu bieżącego użytkownika.
Nie można zdefiniować fabryk tworzenia dla zasobu MyProfile.
27
Nie można tworzyć ani usuwać obiektów MyProfile za pomocą OSLC z poziomu zasobu
MyProfile.
Zmiany w profilu można wprowadzać za pomocą metody PATCH oraz identyfikatora URI.
Zmiana hasła wymaga uwzględnienia poniższego łańcucha JSON w zleceniu:
{..."spi:Password":"password",...}
Hasło jest zapisywane tekstowo - bez szyfrowania; szyfrowanie jest wykonywane
wewnętrznie.
Metody HTTP POST wraz z poniższymi nagłówkami można użyć w zleceniu zmiany hasła:
- x-method-override: PATCH
- PATCHTYPE: CHPWD
ID zasobu reprezentującego Mój profil określono w pliku tririgaweb.properties w
następujący sposób:
OSLC_MYPROFILE_RESOURCE=MyProfile
Nieaktualne hasła
Jeśli okres aktualności hasła ulegnie zakończeniu, w aplikacji konsumenckiej nie można
uzyskać dostępu do żadnych zasobów OSLC poza identyfikatorem URI umożliwiającym
zmianę hasła lub wylogowanie.
Zwracany jest komunikat o błędzie HTTP 403 Forbidden. Jeśli właściwość systemowa
OSLC_MYPROFILE_RESOURCE jest zdefiniowana, zwracany komunikat o błędzie JSON
zawiera identyfikator URI kierujący aplikację konsumencką do URI zawierającego zlecenie
zmiany hasła.
Reguły dezaktualizacji hasła są określone w rozwiązaniu TRIRIGA w opcjach
NarzędziaSystem KonfiguracjaSystemKonfiguracja hasła.
Przykład: nieaktualne hasło - reakcja
{
oslc:Error:
{
spi:user:
{
rdf:resource: "http://yourserver/oslc/so/MyProfile/13417792"
}
oslc:message: "Password Expired"
oslc:statusCode: 403
oslc:extendedError: "OSLC0054"
}
}
Rejestrowanie OSLC
W dziennikach można rejestrować informacje, które mogą być przydatne podczas
debugowania lub szacowania wydajności.
Zarządzanie rejestrowaniem odbywa się za pomocą Konsoli administratora IBM TRIRIGA.
Po zalogowaniu należy wybrać pozycję Rejestrowanie platformy > OSLC. Aby wyłączyć
rejestrowanie, należy odznaczyć pole wyboru OSLC. Więcej informacji zawiera
dokumentacja IBM TRIRIGA Application Platform 3 Administrator Console User Guide.
28
Rozdział 5. Rozwiązywanie problemów z OSLC
Poniższe wskazówki mogą być pomocne podczas rozwiązywania problemów w charakterze
konsumenta OSLC IBM TRIRIGA.
Tabela 1. Wskazówki - rozwiązywanie problemów dot. OSLC.
Zastrzeżenie
Środek naprawczy
Kształt zasobu nie działa po zmianie nazwy
raportu IBM TRIRIGA
W przypadku zmiany nazwy raportu IBM
TRIRIGA zdefiniowanego w kształcie zasobu
kształt zasobu ulega uszkodzeniu, ponieważ
zdefiniowany raport już nie istnieje. Komunikat o
błędzie zostanie wyświetlony podczas
wyświetlania podglądu funkcji zapytania lub
użycia fabryki tworzenia. Zazwyczaj zaleca się
zaktualizowanie kształtu zasobu w przypadku
zmiany nazwy raportu. Ponadto jeśli zmianie
ulega moduł lub obiekt biznesowy w raporcie
IBM TRIRIGA, daną wartość również należy
zaktualizować w kształcie zasobu. Karta Miejsce
stosowania w raporcie umożliwia określenie, który
kształt zasobu korzysta z raportu.
Wymagane są dzienniki w celu debugowania
wdrożenia OSLC
Zarządzanie rejestrowaniem odbywa się za
pomocą Konsoli administratora IBM TRIRIGA.
Po zalogowaniu należy wybrać pozycję
Rejestrowanie platformy > OSLC. Aby
wyłączyć rejestrowanie, należy odznaczyć pole
wyboru OSLC.
Więcej informacji zawiera dokumentacja IBM
TRIRIGA Application Platform 3 Administrator
Console User Guide.
Stos wywołań występuje w przypadku olsc.where
Jeśli w parametrze oslc.where zostaną
zastosowane pojedyncze cudzysłowy, utworzony
zostanie nieprawidłowy adres URL. Wyjątek jest
generowany przez filtr Apache; występuje on,
zanim parametr oslc.where osiągnie servlet OSLC.
Nie podlega to sterowaniu z zastosowaniem IBM
TRIRIGA.
Objaśnienia kodów HTTP specyfikacji OSLC
W rozwiązaniu OSLC stosowane są standardowe kody odpowiedzi HTTP jako komunikaty o
błędach. Przykładowo: odpowiedź HTTP 404 jest standardowo zwracana, gdy strona WWW
nie zostanie znaleziona, a w rozwiązaniu OSLC kod odpowiedzi 404 jest zwracany, gdy
znalezienie zasobu nie jest możliwe.
Niektóre istniejące kody błędów są domyślnie odwzorowywane na kody HTTP domyślnie,
ale można również odwzorować dodatkowe kody.
Poniższe kody odpowiedzi HTTP są wdrożone w rozwiązaniu OSLC:
Kod HTTP
Opis OSLC
200
Powodzenie
29
Kod HTTP
Opis OSLC
201
Powodzenie. Odpowiedź zawiera łącze.
204
Pomyślnie zaktualizowano zasób. Brak obiektu odpowiedzi.
400
Błąd podczas obsługi zlecenia. Przyczyną tego błędu może być zawartość
zlecenia lub URI. Przykładowo: po stronie serwera mógł wystąpić błąd kontroli
poprawności logiki biznesowej.
401
Błąd uwierzytelnienia.
403
Zabroniony. Hasło użytkownika wygasło.
404
Nie można znaleźć zasobu lub wprowadzono nieprawidłowy typ zasobu.
405
Metody HTTP nie można użyć do zasobu.
406
Wymagana reprezentacja nie jest obsługiwana.
410
Stabilna strona zasobów jest nieaktualna.
412
Zasób po stronie klienta jest przestarzały i należy go odświeżyć z poziomu
serwera. Warunkowa aktualizacja nie powiodła się, ponieważ zasób został
zaktualizowany przez innego użytkownika lub proces.
500
Wszystkie pozostałe błędy serwera.
W komunikatach są obsługiwane języki obsługiwane przez IBM TRIRIGA.
30
Uwagi
Niniejsza publikacja została przygotowana z myślą o produktach i usługach oferowanych w
Stanach Zjednoczonych.
IBM może nie oferować w innych krajach produktów, usług lub opcji, omawianych w tej
publikacji. Informacje o produktach i usługach dostępnych w danym kraju można uzyskać od
lokalnego przedstawiciela IBM. Odwołanie do produktu, programu lub usługi IBM nie
oznacza, że można użyć wyłącznie tego produktu, programu lub usługi. Zamiast nich można
zastosować ich odpowiednik funkcjonalny pod warunkiem, że nie narusza to praw własności
intelektualnej IBM. Jednakże cała odpowiedzialność za ocenę przydatności i sprawdzenie
działania produktu, programu lub usługi pochodzących od producenta innego niż IBM
spoczywa na użytkowniku.
IBM może posiadać patenty lub złożone wnioski patentowe na towary i usługi, o których
mowa w niniejszej publikacji. Używanie tego dokumentu nie daje żadnych praw do tych
patentów. Wnioski o przyznanie licencji można zgłaszać na piśmie pod adresem:
IBM Director of Licensing
IBM Corporation
North Castle Drive
Armonk, NY 10504-1785
U.S.A.
Zapytania dotyczące zestawów znaków dwubajtowych (DBCS) należy kierować do lokalnych
działów własności intelektualnej IBM (IBM Intellectual Property Department) lub wysłać je
na piśmie na adres:
Intellectual Property Licensing
Legal and Intellectual Property Law
IBM Japan Ltd.
19-21, Nihonbashi-Hakozakicho, Chuo-ku
Tokyo 103-8510, Japonia
Poniższy akapit nie obowiązuje w Wielkiej Brytanii, a także w innych krajach, w których jego
treść pozostaje w sprzeczności z przepisami prawa miejscowego: FIRMA
INTERNATIONAL BUSINESS MACHINES CORPORATION DOSTARCZA TĘ
PUBLIKACJĘ W TAKIM STANIE, W JAKIM SIĘ ZNAJDUJE, "AS IS", BEZ
UDZIELANIA JAKICHKOLWIEK GWARANCJI (W TYM TAKŻE RĘKOJMI),
WYRAŹNYCH LUB DOMNIEMANYCH, A W SZCZEGÓLNOŚCI DOMNIEMANYCH
GWARANCJI PRZYDATNOŚCI HANDLOWEJ ORAZ PRZYDATNOŚCI DO
OKREŚLONEGO CELU LUB GWARANCJI, ŻE PUBLIKACJA NIE NARUSZA PRAW
OSÓB TRZECICH. Ustawodawstwa niektórych krajów nie dopuszczają zastrzeżeń
dotyczących gwarancji wyraźnych lub domniemanych w odniesieniu do pewnych transakcji;
w takiej sytuacji powyższe zdanie nie ma zastosowania.
Informacje zawarte w niniejszej publikacji mogą zawierać nieścisłości techniczne lub błędy
drukarskie. Informacje te są okresowo aktualizowane, a zmiany te zostaną ujęte w kolejnych
wydaniach tej publikacji. IBM zastrzega sobie prawo do wprowadzania ulepszeń i/lub zmian
w produktach i/lub programach opisanych w tej publikacji w dowolnym czasie, bez
wcześniejszego powiadomienia.
31
Wszelkie wzmianki w tej publikacji na temat stron internetowych innych przedsiębiorstw
zostały wprowadzone wyłącznie dla wygody użytkowników i w żadnym wypadku nie
stanowią zachęty do ich odwiedzania. Materiały dostępne na tych stronach nie są częścią
materiałów opracowanych dla tego produktu IBM, a użytkownik korzysta z nich na własną
odpowiedzialność.
IBM ma prawo do używania i rozpowszechniania informacji przysłanych przez użytkownika
w dowolny sposób, jaki uzna za właściwy, bez żadnych zobowiązań wobec ich autora.
Licencjobiorcy tego programu, którzy chcieliby uzyskać informacje na temat programu w
celu: (i) wdrożenia wymiany informacji między niezależnie utworzonymi programami i
innymi programami (łącznie z tym opisywanym) oraz (ii) wspólnego wykorzystywania
wymienianych informacji, powinni skontaktować się z:
IBM Corporation
2Z4A/101
11400 Burnet Road
Austin, TX 78758 U.S.A.
Informacje takie mogą być udostępnione, o ile spełnione zostaną odpowiednie warunki, w
tym, w niektórych przypadkach, zostanie uiszczona odpowiednia opłata.
Licencjonowany program opisany w niniejszej publikacji oraz wszystkie inne licencjonowane
materiały dostępne dla tego programu są dostarczane przez IBM na warunkach określonych w
Umowie IBM z Klientem, Międzynarodowej Umowie Licencyjnej IBM na Program lub w
innych podobnych umowach zawartych między IBM a użytkownikami.
Informacje dotyczące produktów innych przedsiębiorstw zostały uzyskane od dostawców tych
produktów, z opublikowanych przez nich zapowiedzi lub innych powszechnie dostępnych
źródeł. IBM nie testował tych produktów i nie może potwierdzić dokładności pomiarów
wydajności, kompatybilności ani żadnych innych danych związanych z produktami innymi
niż produkty IBM. Pytania dotyczące możliwości produktów innych przedsiębiorstw należy
kierować do dostawców tych produktów.
Publikacja ta zawiera przykładowe dane i raporty używane w codziennej działalności
biznesowej. W celu kompleksowego ich zilustrowania, podane przykłady zawierają nazwiska
osób prywatnych, nazwy przedsiębiorstw oraz nazwy produktów. Wszystkie te
nazwy/nazwiska są fikcyjne i jakiekolwiek podobieństwo do istniejących nazw/nazwisk i
adresów jest całkowicie przypadkowe.
LICENCJA NA PRAWA AUTORSKIE:
Niniejsza publikacja zawiera przykładowe aplikacje w kodzie źródłowym, ilustrujące techniki
programowania w różnych systemach operacyjnych. Użytkownik może kopiować,
modyfikować i rozpowszechniać te programy przykładowe w dowolnej formie bez uiszczania
opłat na rzecz IBM, w celu rozbudowy, użytkowania, handlowym lub w celu
rozpowszechniania aplikacji zgodnych z aplikacyjnym interfejsem programowym dla tego
systemu operacyjnego, dla którego napisane były programy przykładowe. Programy
przykładowe nie zostały gruntownie przetestowane. IBM nie może zatem gwarantować lub
sugerować niezawodności, użyteczności i funkcjonalności tych programów. Programy
przykładowe są dostarczane w stanie, w jakim się znajdują ("AS IS"), bez jakichkolwiek
gwarancji, w tym także rękojmi. IBM nie ponosi odpowiedzialności za jakiekolwiek szkody
wynikające z używania programów przykładowych.
32
Strategia ochrony prywatności
Produkty programowe IBM, w tym oprogramowanie udostępniane w postaci usług
(„Oprogramowanie”) może używać plików cookie lub innych rozwiązań technicznych do
zbierania informacji o sposobie korzystania z produktu w celu doskonalenia interakcji z
użytkownikiem, dopasowania interakcji do preferencji konkretnego użytkownika lub w
innych celach. W wielu przypadkach Oprogramowanie nie zbiera żadnych informacji
umożliwiających identyfikację tożsamości osób. W niektórym Oprogramowaniu dostępna jest
opcja umożliwiająca użytkownikowi zbieranie takich informacji. Jeśli Oprogramowanie
używa plików cookie do zbierania informacji umożliwiających identyfikację tożsamości, to
konkretne informacje o sposobie wykorzystania plików cookie przez to Oprogramowanie są
podane poniżej.
Niniejsze Oprogramowanie nie używa plików cookie ani innych rozwiązań technicznych do
zbierania informacji umożliwiających identyfikację tożsamości osób.
Jeśli konfiguracje, w jakich to Oprogramowanie zostało wdrożone, umożliwiają klientowi
zbieranie informacji umożliwiających identyfikację tożsamości użytkowników końcowych za
pośrednictwem plików cookie i innych rozwiązań technicznych, to klient powinien zwrócić
się we własnym zakresie o poradę prawną dotyczącą obowiązujących go przepisów
dotyczących zbierania takich danych, w szczególności obowiązków informacyjnych i
konieczności uzyskania zgody użytkowników.
Więcej informacji o stosowaniu różnych rozwiązań technicznych, w tym plików cookie, do
wspomnianych wyżej celów zawiera strategia IBM w zakresie ochrony prywatności dostępna
pod adresem http://www.ibm.com/privacy oraz oświadczenie IBM dotyczące ochrony
prywatności w Internecie, dostępne pod adresem http://www.ibm.com/privacy/details, a w
szczególności jego sekcja zatytułowana „Pliki cookie, sygnalizatory WWW i inne
rozwiązania techniczne”, jak również oświadczenie IBM dotyczące prywatności w
oprogramowaniu, w tym oprogramowaniu udostępnianym w postaci usług, dostępne pod
adresem http://www.ibm.com/software/info/product-privacy/.
Znaki towarowe
IBM, logo IBM i ibm.com są znakami towarowymi lub zastrzeżonymi znakami towarowymi
International Business Machines Corp., zarejestrowanymi w wielu systemach prawnych na
całym świecie. Nazwy innych produktów i usług mogą być znakami towarowymi IBM lub
innych firm. Aktualna lista znaków towarowych IBM jest dostępna w serwisie WWW, w
sekcji “Copyright and trademark information” (Informacje o prawach autorskich i znakach
towarowych), pod adresem www.ibm.com/legal/copytrade.shtml.
Java™ oraz wszystkie znaki towarowe i logo dotyczące języka Java są znakami towarowymi
lub zastrzeżonymi znakami towarowymi Oracle i/lub przedsiębiorstw afiliowanych.
Linux jest znakiem towarowym Linusa Torvaldsa w Stanach Zjednoczonych i/lub innych
krajach.
Microsoft, Windows, Windows NT i logo Windows są znakami towarowymi firmy Microsoft
Corporation w Stanach Zjednoczonych i/lub innych krajach.
UNIX jest zastrzeżonym znakiem towarowym The Open Group w Stanach Zjednoczonych i
innych krajach.
Nazwy innych produktów i usług mogą być znakami towarowymi IBM lub innych firm.
Uwagi
33
34
Drukowane w USA

IBM TRIRIGA Application Platform 3 OSLC

Transkrypt

Podobne dokumenty

Odpady przemysłowe jako źródło paliwa RDF. Analiza

MARTIN Marcin Niewęgłowski IBM Business Partner

certyfikat

Alternatywne paliwo opadowe (RDF) w Polsce – sposób

TECHELON Sp. z o. o. IBM Premier Business Partner

Rafał Czubik IBM Polska sp. z o.o.

VI Forum Sektora Finansowego 23 czerwca 2010 r. Adgar Plaza Ul