intranett integrasjon for departemente - lars marius garshol
TRANSCRIPT
Datanavet
2
1. Hvordan funker boksen i midten?
2. Hvordan kommer dataene seg dit?
Intranett
Sharepoint
Arkiv
Fagsystem #1
Fagsystem #2
Hermetikkboksen
3
RDF
4
• Datanavet er egentlig en RDF-database – RDF = Resource Description Framework – en W3C-standard for data – også utvekslingsformat og spørrespråk (SPARQL)
• Implementert i en lang rekke produkter – gir oss mange alternativer å velge mellom
• Flere enn Bouvet som har kompetanse på dette – bøker, spesifikasjoner og kurs finnes der ute
Hvordan RDF virker
5
ID NAME EMAIL
1 Stian Danenbarger stian.danenbarger@
2 Lars Marius Garshol [email protected]
3 Axel Borge axel.borge@bouvet
SUBJECT PROPERTY OBJECT
http://example.com/person/1 rdf:type ex:Person
http://example.com/person/1 ex:name Stian Danenbarger
http://example.com/person/1 ex:email stian.danenbarger@
http://example.com/person/2 rdf:type Person
http://example.com/person/2 ex:name Lars Marius Garshol
... ... ...
Tabellen ‘PERSON’
RDF-iserte data
Plug-and-play
6
• Integrasjonene med kilder er “connectorer” – trenger man en til plugger man
den på, og pøser inn data fra kilden
• RDF-databasen er skjemaløs – trenger ikke opprette tabeller
osv på forhånd
• Ingen felles datamodell – transformerer ikke data for å
integrere dem
Fagsystem #1
Fagsystem #2
Produktkø
• At datakildene bare “plugges på” gjør at vi kan styre prosjektene med en produktkø
• Denne består av nye kilder og data-elementer
• Disse utredes av oss – for å vurdere omfang og arbeidsmengde – og for å vurdere hvordan helheten passer sammen
• Deretter kan kunden avgjøre hvilke oppgaver som skal plukkes fra køen
7
Datastrukturen
8
Datanavet
Sharepoint
CRM
Arkiv
ERP
sameAs
sameAs
Kobling av data fra ulike system
9
• Hos DSS finnes brukerdata i to ulike system – IDM har grunndata, men – Active Directory har tilgangene
• Samme brukernavn i begge system – dermed kan vi samle inn data fra
begge, – koble dataene sammen, og – enkelt hente ut det vi trenger
=
sameAs
Kobling uten felles ID
Customers
Companies
Customers
CRM
Customers
Billing
RDF Duke
Field Record 1 Record 2 Probability
Name acme inc acme inc 0.9
Assoc no 177477707 0.5
Zip code 9161 9161 0.6
Country norway norway 0.51
Address 1 mb 113 mailbox 113 0.49
Address 2 0.5
http://code.google.com/p/duke/
sameAs
SDshare
ERP Suppliers
Uavhengighet av kilden
• Vi ønsker løsninger som er uavhengige av detaljer i kilden – enten vi sync-er data ut, eller – kjører spørringer for å hente data
• Uavhengighet er viktig fordi det isolerer løsningen fra endringer i kildene – kildene kan komme og gå – kildene kan endre form
• Merk dog at total uavhengighet er ikke mulig – er strukturene for forskjellige blir ting vanskelig – men forbausende ofte er de ikke det
11
Uavhengighet av kilde #1
12
Kjernemodell
core: Person
core: Project
core:participant
idm: Person
idm: Project
sp: Person
sp: Project
sp:member-of idm:has-member
IDM Sharepoint
Uavhengighet av kilde #2
13
• “Facebook-strømmer” krever spørringer på tvers av datakilder – hver datakilde har sin representasjon
• Vi kan utjevne forskjellene med annotering – dvs: beskrive dataene i RDF
• Dermed kan nye typer data plugges inn, uten at spørringen må endres
sp:doc-created a dss:StreamEvent; rdfs:label "opprettet"; dss:time-property sp:Created; dss:user-property sp:Author. sp:doc-updated a dss:StreamEvent; rdfs:label "endret"; dss:time-property sp:Modified; dss:user-property sp:Editor.
idm:ny-ansatt a dss:StreamEvent; rdfs:label "ble ansatt i"; dss:time-property idm:ftAnsattFra .
Pilene
14
Ikke dytt!
• IT-folk flest vil helst “dytte” data – avsender kaller tjenester hos mottager
• Dette gir høy kompleksitet – begge systemene har nå avhengighet til hverandre – må implementere kode og logikk i fagsystemet – egne triggere/tråder i fagsystemet – mange bevegelige deler
15
Fagsystem #1
Men dra!
• Vi velger å la mottager dra – og bruker alltid samme protokoll og samme format
• “Pakker inn” kilden – innpakningen må støtte 3 enkle funksjoner
• Gir en helt annen løsning – kun mottager som er avhengig av kilde – i mange tilfeller null kode – innpakningen er tynn og tilstandsløs – selve dataflyttingen gjøres av kode som er felles for
alle integrasjonene
16
Fagsystem #1
Web part-en
• Viser data gitt – en spørring – et XSLT-stilsett
• Kan kjøres hvor som helst – standard protokoll til
databasen
• Lett å inkludere i andre systemer også
17
Virtuoso RDF DB
EPiServer Sharepoint
Novell IDM
Active Directory
Regjeringen.no
Web
part
Web
part
SPARQL SDShare SDShare
SDShare SDShare
SDShare
Dataflyt (forenklet)
18
Virtuoso RDF DB
Novell IDM
Ansatte Org-struktur
Sharepoint Org-struktur
EPiServer
Tema Sidestruktur
Tema
Arbeidsrom Dokumenter Lister
Avslutning
19
Gjennomføring
20
• Kunden ba om oppstart 15. august, leveranse 1. januar – kilder: EPiServer, Sharepoint, IDM
• Vi tilbød fastpris, leveranse 1. november • Leverte 20. oktober
– integrerte også med ActiveDirectory (nødvendig) – la til integrasjon med Regjeringen.no for å gi mer
verdi
• Integrasjon med ACOS Websak – har blitt utredet og planlagt – men ikke gjennomført
Datakildene
21
Kilde Connector
Active Directory LDAP
IDM LDAP
Intranett EPiServer
Regjeringen.no EPiServer
Sharepoint Sharepoint
Konklusjon
22
• Dette lot seg gjennomføre så lett og raskt på grunn av – at arkitekturen er riktig – at vi har mange komponenter som kan gjenbrukes – og arkitekturen gjør det mulig å bruke de samme
komponentene i veldig ulike settinger
• Gitt dataene er funksjonalitet som regel lett – det er å innhente dataene som er vanskelig
Mens vi venter på lunsj...
23
RDF description of the data set, using Dublin Core and VOID
http://sws.ifi.uio.no/npd/page/LinkedOpenNPDFactPages
29
How hard would it be to use?
30
• We loaded the data locally in a few minutes • We already have the ability to display
arbitrary data from RDF • All that’s missing is connections from
existing data – organization numbers is one way – statistical analysis is another