Introduksjon til Core Components. Øyvind Aassve NorStella



Like dokumenter
Core Components Presentasjon for møte om Norsk Referansekatalog for åpne standarder regi av NorStella InterOp

NorStellas 3 strategiske prosjekter i 2007

UN/CEFACT XML Naming and Design Rules

NorStellas 3 strategiske prosjekter i 2007

EXAM TTM4128 SERVICE AND RESOURCE MANAGEMENT EKSAM I TTM4128 TJENESTE- OG RESSURSADMINISTRASJON

buildingsmart Norge seminar Gardermoen 2. september 2010 IFD sett i sammenheng med BIM og varedata

Kodelister. fortjener større oppmerksomhet. Steinar Høseggen, Geomatikk IKT AS

Bakgrunn. Kurset krever ingen spesielle forkunnskaper om modellering.

Er arketype-metodikken aktuell å benytte på nasjonalt plan i Norge? Jostein Ven, seniorrådgiver, Helsedirektoratet

Semantikkregisteret for Elektronisk Samordning (SERES) Bakgrunn Grunndata Retningslinjer for modellering

NKKN typeforslag versjon Definisjon av grunntypene

Infrastruktur for elektronisk handel. Et prosjekt i regi av Norsk EDIPRO. Møte om oppstart av hovedprosjekt 16 mai EdiSys.

Hvordan komme i gang med ArchiMate? Det første modelleringsspråket som gjør TOGAF Praktisk

Den europeiske byggenæringen blir digital. hva skjer i Europa? Steen Sunesen Oslo,

Elektronisk fakturering mellom bedrifter

Angivelse av EHF profiler og dokumenttyper

A Study of Industrial, Component-Based Development, Ericsson

From a table based Feature Catalogue to GML Application schemas

UDDI norsk katalog for registrering av tjenester (WMS, WFS, WCS, WS) i Norge digitalt

Teknologiforum, Clarion hotel, Gardermoen /27. En introduksjon til SOSI del 1 Regler for UML modellering

Europeiske standarder -- CIM og ENTSO-E CGMES. Svein Harald Olsen, Statnett Fornebu, 11. september 2014

AMS-case forts. Eksemplifisering av modellbasert. tilnærming til design av brukergrensesnitt

SAS FANS NYTT & NYTTIG FRA VERKTØYKASSA TIL SAS 4. MARS 2014, MIKKEL SØRHEIM

Public roadmap for information management, governance and exchange SINTEF

Geomatikkdagene 2018 Stavanger

SERES - status Ressursnettverk for eforvaltning og Norstella Elektronisk Samhandling i Offentlig Sektor 27.august 2009

SOSI standard - versjon Del 1: Regler for navning av geografiske elementer. DEL 1: Regler for navning av geografiske elementer

1. Definisjoner Forholdet mellom SOSI fagområdestandard og SOSI produktspesifikasjon SOSI fagområdestandard... 4

Unit Relational Algebra 1 1. Relational Algebra 1. Unit 3.3

Hva må til for utviklingen av arketyper med klinisk god kvalitet?


MPEG-7. Problemstilling:

Endringer i neste revisjon av EHF / Changes in the next revision of EHF 1. October 2015

ADDML. Archival Data Description Markup Language. Generell del. Versjon PA 0.07 Sist oppdatert: TPD. ADDML_8_2.doc 03/03/2011 1(12)

Conference Centre Portal (CCP)

Semantikk og Informasjonsarkitektur. Geir Myrind, SITS Planlegging Arkitektur

E-faktura. Brukergruppe Norge

EHF Faktura 3.0 og nytt europeisk standardformat

Fra sekvensielt til parallelt

Skaper samhandling. Presentasjon på Efaktura-seminar I Trondheim 9.juni 2009 Are Berg, EdiSys Consulting

Sikkert Drillingnettverk på CAT-D Rig

Hvordan føre reiseregninger i Unit4 Business World Forfatter:

pnvdb Documentation Release Jan Tore Kyrdalen

case forts. Alternativ 1 Alternativer Sammensetning Objekt-interaktor med valg

Hva er terminologi og fagspråk, og hva skal vi med det?

Fra sekvensielt til parallelt

EDIFACT. Electronic Data Interchange for Administration, Commerce and Transport. Kursbeskrivelse utarbeidet for. NorStella. Versjon 1.0.

åpenbim av eksisterende bygg? Produktbiblioteker (i Open BIM) som støtte for FDV dokumentasjon.

Nasjonale aktiviteter. Oslo,

1 User guide for the uioletter package

Modellering av verk Verk og uttrykk i et brukerperspektiv. Litt om modeller/modellering

efaktura bedrifter i mellom. Hva skjer internasjonalt?

Helhetlig integrasjonsplattform. Per Olav Nymo

Elektronisk Samhandling i privat og offentlig virksomhet Teknologi og anvendelser

AvtaleGiro beskrivelse av feilmeldinger for oppdrag og transaksjoner kvitteringsliste L00202 levert i CSV fil

Blockchain 2/22/2019. Hva er Blockchain for Business. IBMs platform & løsninger. Hvordan komme igang? Hva er det og hvordan komme igang?

OptimalJ-kurs UIO Oppsummering av kurset. De ulike modellene egenskaper og formål

Starship SOSI versjon 5?

TDT4117 Information Retrieval - Autumn 2014

Internasjonal standardisering. Erlend Øverby

Referansearkitektur use cases. Kjell Sand SINTEF Energi AS NTNU Institutt for elkraftteknikk

SeaWalk No 1 i Skjolden

FORHOLDET NESUBL OG NORSK REFERANSEKATALOG. Høringsmøte 19. april Arild Haraldsen Adm. dir. NorStella/eForum

CORBA Component Model (CCM)

Smart High-Side Power Switch BTS730

En praktisk anvendelse av ITIL rammeverket

Brukerkrav og use case diagrammer og -tekst 19. januar Agenda. Brukerkrav og use case. Diagrammer Tekst.

Prosjektoppgave: Bildedatabase. TDT4145 Datamodellering og Databasesystemer. Våren 2007

Veilederdokumentenes forankring <UTKAST>

XML enabled database. support for XML in Microsoft SQL Server 2000 & Martin Malý

Tredjeparters tilgang til bankkonti - hva gjør næringen?

Eksamen INF

Metadata for samordning og samhandling

Navngivning av XML elementer

Rollemodell. for. det norske kraftmarkedet

ITGK - H2010, Matlab. Dagens tema : Teori - Databaser

Web Service Registry

NIRF. Hvitvaskingsregelverket og internrevisorer. Advokat Roar Østby

Case 9:12-cv DMM Document 4-5 Entered on FLSD Docket 12/06/2012 Page 1 of 62

EKSAMEN I FAG TDT4180 MMI Mandag 18. mai 2009 Tid: kl

Monitoring water sources.

Information search for the research protocol in IIC/IID

Linked Open Data Kartverkets praktiske erfaringer

Status for arbeidet med Referansemodell for elektronisk samhandling i og med offentlig forvaltning. Rammeverk for interoperabilitet

AvtaleGiro beskrivelse av feilmeldinger for oppdrag og transaksjoner for KID bytte kvitteringsliste L02625 levert i CSV format

Databaser & objektorientering.

INF1000: Forelesning 7

Utfordringer med feil adresser

Gjenopprettingsplan DNBs erfaringer. Roar Hoff Leder av Konsern-ICAAP og Gjenopprettingsplan Oslo, 7. desember 2017

Informasjonsdilemmaet ved vanskelig beslutninger

UML 1. Use case drevet analyse og design Kirsten Ribu

Elektronisk samhandling er viktig!

CSR Harvesting Final Meeting September, 2015 Brest, France. Anne Che-Bohnenstengel & Matthias Pramme, BSH

CORBA Objektmodell (Java RMI)

Standarder for Asset management ISO 55000/55001/55002

Introduksjon til fagfeltet

Vekstkonferansen: Vekst gjennom verdibaserte investeringer. Thina Margrethe Saltvedt, 09 April 2019

Gaute Langeland September 2016

NORSK BRUKERVEILEDNING

Skrankerutine: Låntakerinformasjon

Transkript:

Introduksjon til Core Components Øyvind Aassve NorStella

ebxml ebxml globalt prosjekt (FN og OASIS) for å definere et komplett e-business rammeverk for elektronisk samhandling ferdigstilt i 200. Syv spesifikasjoner som til sammen utgjør et komplett rammeverk for elektronisk samhandling (fra prosess- og informasjonsbeskrivelse, grensesnitt og avtaledefinisjoner, meldingsoverføring og register) Også ISO standard (ISO 5000). Core Components Technical Specification (CCTS) spesifikasjonen som adresserer semantisk interoperabilitet - forvaltes av FN (UN/CEFACT), de tekniske ebxml-standardene forvaltes av OASIS.

XML Company A Specifications Scenarios Business Profiles Industry ebxml Registry Company B 4(b) Download ebxml components 4(a) Query about Company A Profile ebxml arkitektur. Request Industry Process 3. Register Implementation Details BPSS/CC CPP Register Company A Profile 2. Build Local Implementation UMM Registry CPP CPA ebxml MS 6. Do Business Transactions 5. Agree on Trading Arrangement

UN/CEFACT organisasjon

Core Components - del av en større UN/CEFACT rammeverk Etablerer et tydelig skille mellom funksjonalitet (modell) og realisering (EDIFACT/XML) Bidrar til harmonisering (felles forståelse mellom ulike domener/bransjer) som en integrert del av en utviklingsprosess

ISO 79 Metadata Registre Hensikt: Standard beskrivelse av data. Felles forståelse av data på internt i og på tvers av organisasjoner. Gjenbruk av data over tid, rom og applikasjoner. Forvaltning av data. Adresserer semantikk, representasjon av data og registrering av data. Registrering: identifikasjon, opprinnelse og monitorering.

Dataelementer Datamodell Entity (type) ISO 79 Data Element Klassifisering Object Class Data Element Concept Property Data Element Attribute (type) Representation Generic Data- Element

Objekt Term Identifiserer ting som kan aksesseres, inspiseres, manipuleres, produseres og arbeides med i forretningsapplikasjoner. Muliggjør logisk gruppering av data (properties) Første navn i det strukturerte navnet for et dataelement. Object Term Person Fornavn: Etternavn: Alder: Navn Navn Numerisk Person.Fornavn.Navn

Property Term Unike attributter som representerer særegne karakteristika om en objektklasse. Gir en finere semantisk beskrivelse av dataelementene. Andre navn i det strukturerte navnet til et dataelement. Konseptuelle dataelementer: Person Fornavn, Person Etternavn, Person Alder. Property Term Person Fornavn: Etternavn: Alder: Navn Navn Numeric Person.Fornavn.Navn

Representation Term Beskriver typer av verdier som er gyldige for et dataelement. Beskriver datatypen for hvert dataelement. Tredje navn i det strukturerte navnet for et dataelement. Person Fornavn: Etternavn: Alder: Navn Navn Numerisk Representation Term Person.Fornavn.Navn

Generiske dataelementer Property + Representation = Generisk dataelement Generiske dataelementer representerer gjenbrukbare konsepter Property Representation Generisk Dataelement Alder Numerisk Alder Numerisk Høyde Mål Høyde Mål Beskrivelse Text Beskrivelse Text Person Alder Numerisk Bygning Alder Numerisk Plante Alder Numerisk Person Høyde Mål Bygning Høyde Mål Plante Høyde Mål

Qualifier Term En kvalifikator legges til for å gjøre et konsept unikt. Objekter, Properties og Representation Terms Spesifiserer den semantiske betydningen mer nøyaktig. Begrenser verdiintervaller, endringer i kardinalitet. Gjør at man for et sett av begreper som kan redusere redundans og øke gjenbruk av data ved å eliminere synonymer.

Core Components Technical Specification (CCTS) / ISO 5000-5 (2) Typer byggeklosser Konseptuelle dataelementer Core Components Person, Bedrift, Adresse Gjenbrukbare logiske/ fysiske dataelementer BIEer Postboks_Adresse, Veg_Adresse, Matrikkel_Adresse. Core Data Types Beløp, Kode, Mål, Navn, Antall ++ Forretningsmeldinger Ordre, Faktura, Transportoppdrag Tilrettelegger for semantisk interoperabilitet (applikasjoner og databaser) på tvers av forretningsdomener konsistent bruk av felles semantiske enheter på tvers av kontekst konsistent bruk på tvers av ulike språk

Core Component Aggregate Core Component Simple Characteristic Complex Characteristic Basic Core Component(s) Core Data Type (CDT) Association Core Component(s) With known business semantics Without business semantics CDT Content Component CDT Supplementary Component(s)

Core Data Types (CDT) Grunnmuren for semantisk interoperabilitet CDT definerer rommet for lovlige verdier for en BCC Property. Består av Content Component eller flere Supplementary Components CDT Content Component Simple Characteristic Basic Core Component(s) Core Data Type (CDT) Aggregate Core Component CDT Supplementary Component(s) Complex Characteristic Association Core Component(s) With known business semantics Without business semantics Den primitive typen til en CDT Content Component skal aldri endres. CDT innholder ikke forretningssemantikk. CDT skal være en av 22 godkjente semantiske datatyper.

Core Data Types (semantiske typer) Amount Binary Object Code Date DateTime Duration Graphic Identifier Indicator Measure Name Numeric Percent Picture Quantity Rate Ratio Sound Text Time Value Video

Core Data Types Core Data Type Amount. Type CDT Content Component Amount. Content Value = 2 CDT Supplementary Component(s) Amount Currency. Identification. Identifier Value = EUR Amount.Type har en primitiv av typen decimal. CDT Content Component har verdien 2. Verdien har ingen semantisk betydning i seg selv. CDT Supplementary Component gir verdien mening ved å definere valutaverdien EUR for innholdskomponenten.

Aggregate Core Components Representerer en samling av forretningselementer som tilsammen uttrykker en helhet - a la klassebegrepet i oomodellering. Uttrykker en distinkt forretnings-mening - uavhengig av forretningskontekst. Tilsvarer klassebegrepet i oo-modellering. En ACC skal inkludere en eller flere ACC Properties (enten BCCer eller ASCCer) The Dictionary Entry Name (DEN) av en ACC skal bestå av et semantisk meningsfylt objektnavn fulgt av suffiksen.details. CDT Content Component Simple Characteristic Basic Core Component(s) Core Data Type (CDT) Aggregate Core Component CDT Supplementary Component(s) Complex Characteristic Association Core Component(s) With known business semantics Without business semantics

Aggregate Core Component vs. klasse Aggregate Core Component Klassediagram Financial Account. Details Klasse Financial Account Basic Core Components Financial Account. Type. Code Financial Account. Name Type Name Association Core Components Financial Account. Currency. Code Financial Account. Owner. Party Financial Account. Servicer. Party Financial Account. Information Recipient. Party Attributter Currency Owner Servicer Information Recipient Agent Financial Account. Agent. Party

Basic Core Components (BCC) Representerer en enkelt karakteristikk/attributt av en gitt ACC. Har en unik semantisk definisjon. Innholder en BCC Property som representerer et generisk gjenbrukbart dataelement uahvhengig av en objektklasse. CDT Content Component Simple Characteristic Basic Core Component(s) Core Data Type (CDT) Aggregate Core Component CDT Supplementary Component(s) Complex Characteristic Association Core Component(s) With known business semantics Without business semantics DEN av en BCC skal innholde disse elementene i rekkefølge: objektklassen som eier BBC Property. Property Term til den korresponderende BBC Property. Representation Term som reflekterer den CDT som BCC Propertyen er basert på. BCC Property Ex: Financial Account.Currency.Code OCT PT RT

Association Core Components (ASCC) Uttrykker forholdet mellom to ACC/ objektklasser Har en unik semantisk definisjon DEN består av to ACCer delt av en ASCC CDT Content Component Simple Characteristic Basic Core Component(s) Core Data Type (CDT) Aggregate Core Component CDT Supplementary Component(s) Complex Characteristic Association Core Component(s) With known business semantics Without business semantics Person.Details Name.Name Birth.Date Residence Professional Address.Details Street.Name City.Name Postcode.Code Country.Identifier Person.Bolig.Adresse Person.Jobb.Adresse

Core Component Metamodel Registry Class + Unique Identifier: String + Version Identifier: String Aggregate Core Component (ACC) ACC Property + Object Class Term: String + Usage Rule: String [0..*]..* + Cardinality: Cardinality + Sequencing Key: String Association Core Component (ASCC) + Association Type: Association Type = aggregation + Usage Rule: String [0..*] 0..* Basic Core Component (BCC) + Usage Rule: String [0..*] 0..* Localized Information + LanguageCode: LanguageCode + Other Language DEN: String + Other Language Definition: String + Other Language Business Term: String [0..*] 0..* 0..* ASCC Property BCC Property Common Information + Property Term: String + Representation Term: Representation Term + Property Term: String 0..* + Dictionary Entry Name (DEN): String + Definition: String + Business Term: String [0..*] Core Data Type (CDT) + Data Type Term: Data Type Term + Usage Rule: String [0..*] CDT Content Component..* CDT Supplementary Component + Property Term: String = Content + Primitive Type: Primitive Type + Usage Rule: String [0..*] + Representation Term: Representation Term + Property Term: String + Primitive Type: Primitive Type + Cardinality: Cardinality + Default Value: String [0..] + Usage Rule: String [0..*]

Core Component Library (CCL) Første versjon av UN/CEFACT bibliotek/ registry med harmoniserte innholdskomponenter ble publisert oktober 2005. Utvides stadig i omfattende prosess på tvers av industrier og geografiske kontinenter. NorStella planlegger i samarbeid med andre å sette i gang prosjekt for etablering av nasjonalt bibliotek/ registry for BIEer med for det norske markedet i løpet av kort tid.

Business Information Entities (BIE) Forskjellen mellom CC og BIEer ligger i konseptet kontekst, en mekanisme for å kvalifisere og forfine en CC til bruk i en spesiell forretningssituasjon. En BIE har en unik semantisk definisjon gitt av konteksten den gitte samhandlingen foregår innen. En BIE kan være en Basic Business Information Entity (BBIE), Association Business Information Entity or an Aggregate Information Entitiy (ABIE).

Hva er kontekst? Den formelle beskrivelsen av forretningsomgivelsene definert ved verdiene til et sett av kontekstkategorier slikt at de ulike forretningsomgivelsene distinkt kan skilles fra hverandre. Uttrykkes i kvalifikatorer som legges til CCene og gjør de semantisk unike. Beskrives i 8 dimensjoner. Finnes bare i logiske/ fysiske modeller.

Kontekstkategorier Context Category Business Process Product Classification Industry Classification Geopolitical Official Constraints business process Role Supporting Role System Capabilities Description The business process name(s) as described using the UN/CEFACT Catalogue of Common business processes as extended by the user. Factors influencing semantics that are the result of the goods or services being exchanged, handled, or paid for, etc. (e.g. the buying of consulting services as opposed to materials) Semantic influences related to the industry or industries of the trading partners (e.g., product identification schemes used in different industries). Geographical factors that influence business semantics (e.g., the structure of an address). Legal and governmental influences on semantics (e.g. hazardous materials information required by law when shipping goods). The actors conducting a particular business process, as identified in the UN/CEFACT Catalogue of Common business processes. Semantic influences related to non-partner roles (e.g., data required by a third-party shipper in an order response going from seller to buyer.) This context category exists to capture the limitations of systems (e.g. an existing back office can only support an address in a certain form).

CC vs. BIE Business Core Assembly Component Adds Extra Information Message Assembly Aggregated In ABIE Specifies Restrictions On ACC Aggregated In Aggregated In ASBIE Specifies Restrictions On Aggregated In Aggregated In ASCC BBIE Specifies Restrictions On BCC Define Values of Business Data Type Specifies Restrictions On Define Values of Core Data Type

CC/BIE relasjon Det kan skapes mange ABIEr fra en ACC. Ex: Adress.Details (ACC) > Shipping_Adress.Details (ABIE) Mailing Adress.Details (ABIE) Det kan skapes mange BBIEr fra en BCC. Ex: Organization.Name.Text (BCC) > Supplier_Organization.Name.Text (BBIE) Supplier_Organization.Department_Name.Text (BBIE)

Eksempel ABIE ACC Financial Account. Details Financial Account. Type. Code Financial Account. Name Financial Account. Currency. Identifier Financial Account. Owner. Party Financial Account. Servicer. Party Financial Account. Information Recipient. Party Financial Account. Agent. Party Context ABIE Credit _ Financial Account. Details Credit _ Financial Account. Business _ Type. Code Credit _ Financial Account. Name Credit _ Financial Account. Primary _ Owner. Party Credit _ Financial Account. Direct _ Servicer. Party En ABIE trenger ikke inneholde alle attributtene til en BBIE > Extension by restriction. En ABIE er en samling av relaterte biter av forretningsinformasjon som til sammen uttrykker en bestemt forretningsmening i en gitt forretningskontekst.

Business Data Types (BDT) En BDT er en avledet fra en CDT En ukvalifisert BDTer kan brukes meget vidt og inneholder ikke spesifikk forretningssemantikk. Behov for BDTer som gjelder for et smalere forretningsdomene En kvalifisert BDT (QBDT) er en ukvalifisert BDT som har restriksjoner på BDT ContentComponent eller BDT SupplementaryComponent. QBDT inneholder forretningssemantikk ex Product_Identifier.Type

BDT Metamodell Business Data Type (BDT) + Data Type Qualifier: String [0..*] + Data Type Term: Data Type Term..* +basis Core Data Type (CDT) + Data Type Term: Data Type Term..* BDT Content Component + Primitive Type: Primitive Type +basis CDT Content Component + Primitive Type: Primitive Type 0..* Component Restriction + Expression Type: String [0..] + Expression Type Language: String [0..] + Restriction Type: Restriction Type [0..] + Restriction Value: String [0..] Common Information + Business Term: String [0..*] + Definition: String + Dictionary Entry Name: String + Possible Value: String [0..*] + Usage Rule: String [0..*] 0..*..* BDT Supplementary Component + Cardinality: Cardinality + Primitive Type: Primitive Type +basis CDT Supplementary Component + Cardinality: Cardinality + Primitive Type: Primitive Type

Interoperabilitet Kontekstnøytrale CCer er grunnlaget for det konseptuelle modelleringsnivået. Kontekstspesfikke (spesfikk for gitt domene) BIEer er grunnlaget for det logiske/ fysiske modelleringsnivået. XSD-skjema basert på UN NDR er grunnlaget for syntax-spesfikke instansieringer. Tett integrasjon mellom disse tre lagene sikrer interoperabilitet på tvers av domenemodeller og databaser.

Bruk i dag (og i fremtiden) Fokus på grunnleggende forretningsinformasjon som typisk må utveksles uavhengig av bransjer og over landegrenser (Ordre, faktura, transportdoks etc). Standardorganisasjoner: UBL, Rosettanet, OAG, SWIFT, GS (EAN)... SAP, (Oracle) intern datadefinisjonsmetodikk Seres-prosjektet i Brønnøysund delvis basert på CC RTV trygdedata som skal utveksles med Europa. TransportXML oppgradering til full kompabilitet vha ShortSeaXML.

Spørsmål?

Core Components Technical Specification (CCTS) / ISO 5000-5 Beskriver en metodikk for utvikling av et omforent sett av semantiske byggeklosser som representerer de generelle typene forretningsdata i bruk i dag uavhengig av bransje og dokumentstandard. støtter utvikling av nye forretningsvokabular og restrukturering av eksisterende vokabular. basert på semantiske definisjoner klare regler for hvordan definere hva et element betyr. bruker en kontekstmekanisme som styrer hvordan datakomponenter varierer avhengig av konteksten de brukes i (ex. Forretningsprosess, bransje, geografisk område etc.) ikke knyttet til meldingssyntax modeller kan uttrykkes i XML Schema, UML diagram, Java klasser, SQL baserte databaser, EDI etc.