Wykorzystanie Universal Business Language 2.0 w procesach eCommerce
1. Wstęp
Najważniejszym aspektem wprowadzanych nowych technologii są koszty, nie tylko związane z inwestycją w nowe idee, ale przede wszystkim z oszczędnościami i zyskami jakie mają przynieść. UBL jest darmowym standardem, nie ma potrzeby nabywania licencji, aby wdrażać go w życie. Przykłady środowisk i organizacji, które zainteresowały się tym projektem pokazują, że standaryzując format dokumentów wymienianych drogą elektroniczną można zaoszczędzić sporo pieniędzy. Jednak warunkiem koniecznym oszczędności z używania tego standardu do wymiany danych jest jego powszechność. Nie wystarczy, aby wprowadzić go w kilku organizacjach nawet ściśle ze sobą współpracujących. Po raz pierwszy standard ten zaczął obowiązywać w Danii w sektorze publicznym. Wszystkie firmy i organizacje handlujące i współpracujące z jakimikolwiek publicznymi jednostkami w Danii musiały dostosować się do standardu UBL. Ta powszechność sprawiła, że duński sektor publiczny mógł zaoszczędzić chociażby na kupnie systemów, które zgodne były z jednym standardem. Nie trzeba dla każdej firmy z którą się współpracuje mieć odrębnego systemu, który interpretuje przesyłane dane elektroniczne, wystarczy jeden system przetwarzający dokumenty elektroniczne o strukturze zgodnej ze standardem UBL.
Biblioteka UBL jest oparta na koncepcyjnym modelu Biznesowych Encji Informacyjnych (tzw. Business Information Entities - BIEs) np. adres, towar, płatność. Te komponenty są składane w specyficzne modele dokumentów takich jak zamówienie, czy faktura. Modele dokumentów są następnie przekształcane zgodnie z zasadami nazewnictwa i projektowania UBL do składni schematu W3C XSD. To podejście ułatwia tworzenie typów dokumentów opartych na UBL, które nie zostały ujęte w standardzie. UBL bazuje również na ebXML (Electronic Business XML) i innych systemach e-biznesowych.
Technicznie w uproszczeniu UBL jest zbiorem schematów - plików XML Schema - opisujących zawartość konkretnych dokumentów biznesowych, zawiera także opis w jakich kontekstach biznesowych się je stosuje. Należy zaznaczyć, że biblioteka UBL 2.0 została zaprojektowana tak, by wspomagać budowę szerokiej gamy dokumentów, których nie zawiera, np. przez komponenty. Zakłada się, że organizacje wdrażające UBL 2.0 będą tworzyć swoje własne dokumenty i komponenty (na podstawie standardu), które zostaną dodane do biblioteki w miarę jej rozwoju.
UBL wprowadza przede wszystkim:
- Bibliotekę schematów XML dla danych „wielokrotnego użytku”, np. adres, przedmiot, płatność – wspólne elementy większości biznesowych dokumentów
- Grupę schematów XML dla standardowych dokumentów biznesowych, np. zamówienie, wysyłka, faktura
Zalety biznesowych schematów XML:
- Niskie koszty integracji – ciągłe używanie tych samych struktur danych
- Niskie koszty oprogramowania – oprogramowanie napisane „pod określone tagi” XML jest zacznie łatwiejsze do projektowania i rozwijania
- Niskie koszty wdrażania
- Uproszczony proces uczenia się – określone z góry standardy
- Niedrogie narzędzia do obsługi
2. Symbole i skróty
- ABIE - Aggregate Business Information Entity
- ASBIE - Association Business Information Entity
- BBIE - Basic Business Information Entity
- BIE - Business Information Entity
- CC - Core Component
- CV2 - Credit Card Verification Numbering System
EDI - Electronic Data Interchange
Model montażowy – model ABIE o strukturze drzewa, który może być zaimplementowany jako schemat dokumentu
- Diagram klas – graficzna notacja używana w UML do opisania struktury systemu, zawierająca klasy, ich atrybuty oraz powiązania
- Model arkusza – reprezentacja modelu montażowego w postaci tabeli
- XSD Schema – definicja dokumentu XML zgodnie ze standardami W3C
3. Zastosowanie
Biblioteka UBL 2.0 została zaprojektowana aby wspierać szeroką gamę typów dokumentów. Poniższy diagram przypadków pokazuje przykładowe zastosowanie UBL w procesie powstawania i dostarczania zamówionego produktu:
4. Główne założenia od strony biznesowej
Przedmioty - produkt lub usługa - mogą mieć złożone klasyfikacje - może być częścią innego elementu - może mieć cenę za jednostkę - może odnosić się do dokumentów - może mieć okres ważności - może odnosić się do innych elementów
Identyfikacja przedmiotów. Jeden z podanych identyfikatorów może być użyty do identyfikacji przedmiotu:
- Buyer’s Item Identification – identyfikator klienta - Seller’s Item Identification – identyfikator sprzedawcy - Manufacturer’s Item Identification – identyfikator producenta - Catalogue Item Identification – identyfikator katalogu - Identyfikator ustalany na podstawie standardówProcesy biznesowe: UBL wspiera procesy pomiędzy dwoma głównym aktorami: Klientem oraz Dostawcą, reprezentującymi organizacje lub poszczególne osoby. W procesy mogą być również zaangażowane całe grupy ludzi, wówczas mówimy o różnych „stronach” w procesie.
Na poniższym schemacie przedstawiony jest jeden z procesów – tworzenie katalogu:
Typy dokumentów:
- Catalogue Request – dokument do wysłania żądania katalogu od sprzedawcy
- Catalogue – dokument tworzony podczas zamówienia, opisujący przedmioty i ceny
- Catalogue Deletion – dokument do usuwania katalogu
- Catalogue Item Specification Update –dokument do aktualizowania informacji o przedmiotach w katalogu
- Catalogue Pricing Update – dokument do aktualizowania informacji o cenach
- Request For Quotation – dokument do wysłania żądania wyceny i informacji o dostępności produktów lub usług
- Quotation – dokument do określenia cen i informacji o dostępności produktów lub usług
- Order – dokument zawierający informacje na temat zdarzenia zamówienia produktów
- Order Response – odpowiedĽ na zamówienie ze szczegółami
- Order Response Simple – akceptacja lub odrzucenie zamówienia
- Order Change – zmiana wysłanego już zamówienia
- Order Cancellation – anulowanie zamówienia
- Despatch Advice – powiadomienie o zrealizowaniu dostawy
- Receipt Advice – potwierdzenie odbioru przez klienta
- Invoice – faktura
- Self Billed Invoice – żądanie zapłaty za dostarczone produkty lub usługi zgodnie z ustalonymi warunkami
- Credit Note – zmniejszenie zapłaty, informacja o kredycie
- Debit Note – zmniejszenie zapłaty informacja o zadłuzeniu
- Self Billed Credit Note –żądanie kredytu przez klienta
- Statement – status wykonywanych zadań
- Reminder – żądanie zapłaty
- Remittance Advice – uiszczenie opłaty
- Forwarding Instructions – dokument używany przez zespół, która przekazuje instrukcje do przewozu gotowych podproduktów do innego zespołu
- Packing List – szczegóły pakowania produktów, specyfikacja dystrybucji opakowań
- Freight Invoice – faktura za przewóz towaru
- Certificate of Origin – certyfikat pochodzenia, wymagany przez organy kontrolujące
- Transportation Status – status przesyłki
- Application Response – odpowiedĽ na transakcję
- Attached Document – “koperta” zawierająca cokolwiek (komunikat, dokument)
5. Konstrukcja dokumentu UBL
5.1. Notacja
Słowa kluczowe odzwierciedlają koncepcje konstrukcji, są dane jako prefixy:
- xsd: – reprezentuje XML Schema Definition Language
- xsd: – complexType reprezentuje konstrukcję XSD, typ złożony
- xsd: – SchemaExpression reprezentuje koncept
- ccts: – repretzentuje ISO 15000-5 ebXML Core Components Technical Specification
- ubl: – reprezentuje UBL
5.2. Wymagania na schemat
- oparty o XML
- czytelna struktura z zastosowaniem komponentów Core Comptonents
- wsparcie wielokrotnego użytku
- standardowe „biznesowe” komponenty są różne w różnych kontekstach użycia, np.:
- adresy w różnych krajach (Polska vs. Anglia)
- różne jednostki miar np. dla butów, produktów sypkich, cieczy, itp.
5.3. Związek z ebXML
UBL stosuje metodologie i modele opisane w Core Components Technical Specification. Komponenty kontekstowe są zdefiniowane jako Core Components (ccts:CoreComponents). Są one opisane jako bloki do tworzenia poprawnych semantycznie i ważnych paczek informacji. Zawiera tylko fragmenty informacji niezbędnych do opisania określonych konceptów.
Specyficzne komponenty są zdefiniowane jako Biznesowe Encje Informacyjne (ccts:BusinessInformationEntities). Są one zdefiniowane w CCTS jako fragmenty danych biznesowych lub ich grupy.
UBL składa się z biblioteki ccts:BusinessInformationEntities. BIE może być ccts:AggregateBusinessInformationEntity (ABIE), ccts:BasicBusinessInformationEntity (BBIE) lub ccts:AssociationBusinessInformationEntity (ASBIE).
Prosty przykład słownika danych:
Typy Core Components (CCTs) są wbudowanymi reprezentacjami ograniczeń na podstawowe dane:
- Amount
- Binary Object – grafika, obraz, dĽwięk, video
- Code
- Date Time – lub oddzielnie Date oraz Time
- Identifier
- Indicator
- Measure
- Numeric – oraz Value, Rate, Percent
- Quantity
- Text
Przekształcanie BIE do XML:
Przekształcenie nazewnictwa XML:
- usuń przedziały czasowe
- zamień „Details” na „Type”
- w atrybutach klasy usuń odwołanie do klasy
- usuń nadmiarowe słowa
- usuń „Text” – jest to domyślny typ CCTs
- zamień „Identifier” na „ID”
5.4. Tworzenie UBL
Podstawowy szablon każdego dokumentu UBL wygląda następująco:
<!-- ======= XML Declaration======== --> <?xml version="1.0" encoding="UTF-8"?> <!-- ======= Schema Header ======= --> Document Name: < Document name as indicated in Section 3.6 > Generated On: < Date schema was generated > <!-- ===== xsd:schema Element With Namespaces Declarations ===== --> xsd:deklaracje elementów, atrybutów, przestrzeni nazw i wersji w kolejności: xmlns:xsd Target namespace Default namespace CommonAggregateComponents CommonBasicComponents CoreComponentTypes Unqualified Datatypes Qualified Datatypes Identifier Schemes Code Lists Attribute Declarations – elementFormDefault="qualified" attributeFormDefault="unqualified" Version Attribute <!-- ===== Imports ===== --> CommonAggregateComponents schema module CommonBasicComponents schema module Unqualified Types schema module Qualified Types schema module <!-- ===== Root Element ===== --> Root Element Declaration Root Element Type Definition <!-- ===== Element Declarations ===== --> alphabetized order <!-- ===== Type Definitions ===== --> All type definitions segregated by basic and aggregates as follows <!-- ===== Aggregate Business Information Entity Type Definitions ===== --> alphabetized order of ccts:AggregateBusinessInformationEntity xsd:TypeDefinitions <!-- =====Basic Business Information Entity Type Definitions ===== --> alphabetized order of ccts:BasicBusinessInformationEntities <!-- ===== Copyright Notice ===== --> Required OASIS full copyright notice.
5.4.1. Podstawowe zasady
- Wszystkie elementy dokumentów muszą spełnia standard W3C XML Schema
- Nazwy w języku angielskim
- Dla każdego stworzonego typu złożonego musi istnieć odnoszący się do niego element globalny
- Modułowość, uwzględnianie przestrzeni nazw oraz wersji dokumentu – Modnamver
- W korzeniu znajduje się deklaracja przestrzeni nazw oraz opcjonalnie importowanie innych modułów
- Kompatybilność z wcześniejszymi wersjami dokumentów
5.4.2. Modelowanie
- Organizacja zawartości w komponenty
- identyfikacja funkcjonalnych zależności oraz normalizacja modelu każdego komponentu
- wybór konkretnego schematu hierarchii, na podstawie zależności pomiędzy danymi
- identyfikacja najistotniejszych danych biznesowych
- identyfikacja procesów biznesowych
funkcjonalna zależność – jeśli wartość pewnego komponentu zmienia się pod wpływem zmiany wartości innego (np. powiązanie numeru rejestracji z konkretnym samochodem)
normalizacja – poprawia model, tak by optymalnie opisywał sieć zależności pomiędzy logicznymi grupami komponentów , minimalizując nadmiarowości oraz zapobiegając utratom informacji gdy pewne dane są dodawane lub usuwane
5.4.3. Możliwości organizacji schematu
W zależności od:
- połączenia/rozdzielenia typów z elementami
- dziedziczenia i hierarchii elementów
- zakresu elementów, typów, argumentów – lokalne lub globalne zaproponowano 4 podstawowe opcje: Russian Doll
<xs:schema … > <xs:element name=“Person”> <xs:complexType> _typy złożone zagnieżdżone w elemencie_ <xs:element name=“Name” type=“NameType” /> <xs:element name=“BirthDate” type=“DateType” /> <xs:element name=“ResidenceAddress”> <xs:complexType> <xs:element name=“Street” type=“TextType” /> … </xs:complexType> </xs:element> <xs:element name=“OfficialAddress”> <xs:complexType> … </xs:complexType> </xs:element> </xs:complexType> </xs:element> </xs:schema>
Salami Slice
<xs:schema … > <xs:element name=“Person”> _na najwyższym poziomie są wyłącznie elementy_ <xs:complexType> <xs:element ref=“Name” /> <xs:element ref=“BirthDate” /> <xs:element ref=“ResidenceAddress” /> <xs:element ref=“OfficialAddress” /> </xs:complexType> </xs:element> <xs:element name=“Name” type=“TextType” /> <xs:element name=“BirthDate” type=“DateType” /> <xs:element name=“ResidenceAddress”> <xs:complexType> … </xs:complexType> </xs:element> </xs:schema>
Venetian Blind
<xs:schema … > _główne typy są na najwyższym poziomie_ <xs:element name=“Person” type=“PersonType”> <xs:complexType name=“PersonType”> <xs:element name=“Name” type=“NameType” /> <xs:element name=“BirthDate” type=“DateType” /> <xs:element name=“ResidenceAddress” type=“AddressType”/> <xs:element name=“OfficialAddress” type=“AddressType”/> </xs:complexType> <xs:complexType name=“AddressType”> <xs:element name=“Street” type=“TextType” /> <xs:element name=“PostCode” type=“TextType” /> <xs:element name=“Town” type=“TextType” /> <xs:element name=“CountryID” type=“…” /> </xs:complexType> </xs:schema>
Garden of Eden
<xs:schema targetNamespace=“http://www.example.com/BIEs”… > _wszystko "jest na wierzchu"_ <xs:element name=“Person” type=“PersonType”> <xs:complexType name=“PersonType”> <xs:element ref=“Name” /> <xs:element ref=“BirthDate” /> <xs:element ref=“ResidenceAddress” /> <xs:element ref=“OfficialAddress” /> </xs:complexType> <xs:element name=“Name” type=“TextType” /> <xs:complexType name=“TextType”> … </xs:complexType> … </xs:schema>
Najczęściej używanym schematem jest ten ostatni. Każdy obiekt klasy reprezentowany jest przez typ złożony oraz związany z nim element globalny. Elementy wbudowane w typ złożony używają „ref” zamiast „name”.
Zalety wyboru tego modelu:
- Każdy typ złożony ma powiązany ze sobą element globalny – możliwość szybkiego i bezpośredniego odniesienia się do wszystkich obiektów klas.
- Zagłębione właściwości są równocześnie referencjami do zadeklarowanych elementów.
- Intuicyjne powiązanie struktury ze strukturą klas (typy złożone – obiekty klas).
Przykład użycia typów złożonych:
<xs:complexType name=“AddressType”> _składnia “Address”, szczegółowe dane tej klasy_ … </xs:complexType> <xs:element name=“Address” type=“AddressType” /> _wystąpienie obiektu “Address”_ <xs:complexType name=“PersonType”> <xs:element ref=“Address” /> _pobiera składnię “Address” jako dodatkowe właściwości “PersonType”_ … </xs:complexType>
Źródło: dokumentacje oraz artykuły Organizacji OASIS http://www.oasis-open.org
Aby dodawać komentarze musisz być zalogowany!