Neenotni viri
Različne strukture, identifikatorji, šifranti, kakovost podatkov in pogostost osveževanja.
Izvedeno v praksi
Primeri integracij, pri katerih podatki nadomestijo ročno prepisovanje.
Vsak primer spodaj temelji na izvedenem projektu, vendar so naročniki in tehnični naslovi namenoma anonimizirani. Opisujemo vrsto izziva, izdelano rešitev, dejanski obseg ter praktični rezultat, ne razkrivamo pa zasebnih podatkovnih virov.
Primer 1 · velik spletni katalog
Več kot 30 dobaviteljskih virov in več povezanih sistemov.
Izziv je bil velik katalog z izdelki, dobavitelji, zalogo, cenami in naročili, pri katerem so podatki prihajali iz številnih različno strukturiranih virov. Ročno usklajevanje tako velikega obsega ni bilo smiselno.
Namenska administracija in avtomatizirani uvozi
Preslikave ter redne obdelave izdelkov, cen, zaloge in podatkov za povezane ERP procese.
Dolgoletna nadgradnja
Več kot 15 let razvoja in povezovanja ter več kot 30 dobaviteljskih virov.
Ponovljiv podatkovni proces
Vsak vir ima svoja pravila, podatki pa se pred uporabo obdelajo v enotnem nadzorovanem toku.
Tak projekt ni enkratna skripta. Zaradi novih dobaviteljev, polj in poslovnih zahtev se rešitev razvija modularno.
Primer 2 · ERP in spletna trgovina
Dvosmerna povezava trgovine s SAOP iCenter.
Spletna trgovina in računovodsko zaledje sta morala uporabljati usklajene poslovne podatke. Za vsak sklop je bilo treba določiti smer, glavni vir ter pravila, po katerih se zapis sprejme ali ustavi.
Dva sistema in več tokov
Zaloga, cene, stranke, naročila, računi in statusi niso nastajali na istem mestu.
Individualna SAOP povezava
Namenski moduli so povezali dogovorjene podatke med obstoječo spletno trgovino in SAOP iCenter.
Glavni vir po podatkovnem sklopu
Dvosmerno ni pomenilo prepisovanja vsega v obe smeri, ampak natančna pravila za vsak tok.
Manj ročnih prenosov
Dogovorjeni poslovni podatki se prenašajo po enotnem postopku, napake pa je mogoče iskati po konkretnem zapisu.
Ta primer opisuje obstoječo integracijo lastne PHP trgovine. Ne predstavlja trditve, da je nova Shopify povezava že izvedena.
Primer 3 · 32 dobaviteljev
Dvaintrideset ločenih uvozov v skupen podatkovni proces.
Dobavitelji so posredovali podatke v različnih strukturah, kakovosti in stopnjah popolnosti. Poleg osnovnih artiklov je bilo treba pravilno obravnavati tudi slike, atribute ter tehnično dokumentacijo.
Vsak dobavitelj drugače
Ločena polja, kategorije, zaloge, cene in različna pravila za manjkajoče podatke.
32 namenskih XML uvozov
Uvozi izdelkov, cen, zaloge, slik, atributov, energijskih nalepk in podatkovnih kartic.
Preslikave po viru
Vsak dobavitelj je dobil ločena pravila, preden so se podatki vključili v skupen katalog.
Enoten nadaljnji tok
Različni viri se obdelajo v predvidljivo strukturo, ki jo je mogoče uporabljati v trgovini in drugih kanalih.
Primer 4 · PANTHEON in partnerji
Zaloga in ceniki iz ERP-ja, produktni izvozi za partnerje.
Prodajno okolje je potrebovalo usklajene podatke iz PANTHEON-a ter namenske izhode za zunanje partnerje. Katalog je vključeval tudi različice izdelkov, kar zahteva pravilno povezovanje osnovnega artikla in njegovih izvedenk.
PANTHEON
Dogovorjena zaloga in ceniki so se črpali iz poslovnega sistema.
Katalog različic
Podatki so se povezovali na ustrezne izdelke in njihove različice.
XML za partnerje
Za nadaljnjo uporabo so bili pripravljeni strukturirani izvozi po zahtevani shemi.
Enkrat urejena pravila, več uporab
Isti poslovni podatki so se lahko nadzorovano uporabili v trgovini in partnerskih kanalih.
Primer 5 · tehnični B2B katalog
Dobaviteljski XML, tehnični atributi in B2B ceniki.
Pri tehničnem katalogu osnovni naziv in cena nista dovolj. Pomembni so hierarhija kategorij, tehnični atributi, povezani podartikli ter različni ceniki za poslovne skupine.
Kompleksnejši produkt
Izdelek je bilo treba prikazati z dogovorjenimi tehničnimi podatki in povezanimi artikli.
Dobaviteljski XML feed
Strukturirani podatki so bili osnova za kategorije, atribute in povezave med artikli.
B2B skupine
Ceniki so se obravnavali glede na dogovorjene skupine poslovnih kupcev.
Uporaben prodajni katalog
Tehnični podatki niso ostali v surovem feedu, ampak so bili vključeni v iskanje in predstavitev izdelkov.
Primer 6 · namenski prodajni feed
Priprava produktnega XML izvoza za nadaljnje kanale.
Ciljni kanal je zahteval strukturirane produktne podatke v dogovorjenem formatu. Iz notranjega kataloga je bilo treba izbrati prava polja, jih očistiti, preslikati ter pripraviti ponovljiv izvoz.
Drugačna ciljna shema
Imena polj, obvezne vrednosti in kategorije cilja niso bila enaka notranji strukturi.
Namenski produktni XML
Izvoz je podatke filtriral in oblikoval po pravilih nadaljnjega prodajnega kanala.
Validacija pred oddajo
Manjkajoča obvezna polja ali napačne vrednosti se lahko odkrijejo pred objavo v cilju.
Ponovljiv izvoz
Ko se notranji podatki spremenijo, se lahko osveži tudi strukturirani izhod brez ročnega sestavljanja datoteke.
Kaj je skupno izvedbam
Najprej določimo podatkovni tok, nato napišemo rešitev po meri.
Ne prodajamo enega generičnega vtičnika za vse sisteme. Pri vsakem projektu preverimo dejanske podatke in dostope, določimo glavni vir posameznega polja ter izdelamo samo module, ki jih konkreten poslovni proces potrebuje.
- 01
Viri in cilji
Zapišemo, kje podatek nastane, kam mora priti in kdo ga sme spreminjati.
- 02
Preslikave in kontrole
Določimo identifikatorje, šifrante, obvezna polja, izjeme in vedenje ob neveljavnem zapisu.
- 03
Nadzorovan prenos
Rešitev podatke prebere, po potrebi shrani v vmesno bazo, obdela in prek dovoljenega dostopa zapiše v cilj.
- 04
Zgodovina in odprava napak
Dnevnik pokaže rezultat, pri zahtevnejših povezavah pa kontrolna plošča omogoči iskanje in varen ponovni poskus.
Dosegljiv rezultat je vedno odvisen od kakovosti izvornih podatkov, dejanskih API metod, licenc in pravil, ki jih skupaj potrdimo v specifikaciji.
Pogosta vprašanja
Kaj reference povedo in česa ne?
Možnosti vedno preverimo na konkretnih sistemih, licencah, dostopih in vzorčnih podatkih.
Zakaj imena naročnikov na tej strani niso navedena?
Primeri so anonimizirani, da lahko pokažemo vrsto in obseg dela brez razkrivanja zasebnih tehničnih informacij ali naslovov podatkovnih virov.
Ali lahko enako rešitev samo kopirate v moje okolje?
Praviloma ne. Isti poslovni cilj ima lahko drugačne sisteme, šifrante, licence in izjeme. Izkušnje ter arhitekturne vzorce uporabimo ponovno, podatkovne tokove pa prilagodimo konkretnemu okolju.
Ali primer SAOP pomeni, da je izvedena tudi Shopify povezava?
Ne. Opisani primer se nanaša na obstoječo individualno povezavo SAOP-a z lastno PHP spletno trgovino. Shopify in SAOP sta ločen produkt, ki se pred izvedbo preveri na konkretnih dostopih.
Ali je mogoče začeti z manjšo prvo fazo?
Da. Pogosto je smiselno najprej povezati en zanesljiv tok, na primer zalogo ali nova naročila, ga preizkusiti v praksi in šele nato dodajati druge module.
Kako dokažete, da se je prenos izvedel?
Rešitev beleži čas, vrsto opravila, identifikator zapisa in rezultat. Pri zahtevnejšem obsegu kontrolna plošča omogoča pregled zgodovine, iskanje napak ter nadzorovan ponovni poskus.
Ali lahko obstoječo integracijo pozneje razširite?
Da, če je rešitev zasnovana modularno in ima novi sistem ustrezen dostop. Vsaka razširitev dobi svojo specifikacijo, tehnični predtest in oceno.
Začetni tehnični pregled
Pošljite povpraševanje