Aloita asiakkaan tietovirrasta

AI Commerce -integraation valinta alkaa asiakkaan tietovirrasta, ei integraation nimestä. Kuvaa ensin järjestelmät, siirrettävät tietokohteet, suunta, käynnistystapa, viivevaatimus, tietojen omistajuus ja virhetilanteen palautuminen.

Valitse natiivi integraatio, jos AI Commercen nykyinen integraatiorekisteri kattaa tarvittavan järjestelmän ja toiminnot. Valitse räätälöity toteutus vasta, kun todistettu vaatimus ei mahdu natiivin integraation sopimukseen. Älä lupaa toimitusaikaa, hintaa, jatkuvaa osuutta tai palvelutasoa yleisen tietopankkiartikkelin perusteella; ne vahvistetaan tarjouksesta, tilauksesta ja palveluliitteistä.

Tarkista natiivi integraatio

Tarkista AI Commercen natiivi integraatio avaamalla ylläpidossa Asetukset → Integraatiot tai /configuration/integrations. Nykyinen työtila kokoaa ERP-, PIM-, haku-, tekoäly-, mainonta-, sähköposti-, tuki-, toimitus-, maksu-, tunnistautumis-, kartta-, viestintä- ja sisällönhallintaintegraatioita.

Etsi asiakkaan järjestelmä ja avaa sen tiedot. Tarkista ainakin:

• onko integraatio käytössä ja mikä asetus aktivoi sen
• mitä tunnisteita, osoitteita ja muita asetuksia se tarvitsee
• mitkä arvot ovat salaisuuksia ja näkyvät peitettyinä
• mitä tietoalueita toteutus todella lukee tai kirjoittaa
• onko suunta tuonti, vienti vai erikseen määritetty molempiin suuntiin
• käynnistyykö toiminto käyttäjän toimesta, tapahtumasta vai ajastuksesta
• miten virhe, uusintayritys ja duplikaatin esto toimivat.

Integraationäkymä on nykyisin ensisijaisesti asetusten tarkistus- ja näkyvyyspinta. Se, että toimittajan kortti on rekisterissä, ei vielä todista asiakkaan tarvitsemien toimintojen, kirjoituspolun tai kauppakohtaisen konfiguraation olevan valmis.

Tee natiivin integraation soveltuvuusarvio

Tee natiivin integraation soveltuvuusarvio yhdellä hyväksytyllä testitapauksella jokaista tarvittavaa tietovirtaa kohti. Käytä tuotantoa vastaavaa testiympäristöä ja yksilöiviä testitunnisteita. Varmista lähdejärjestelmästä kohdejärjestelmään ainakin avainkentät, kieli, valuutta, verot, tila, aikaleima ja ulkoiset ID:t.

Kokeile lisäksi puuttuva pakollinen tieto, tuntematon koodi, tilapäinen rajapintavirhe, sama tapahtuma kahdesti ja viestin uudelleenkäsittely. Hyväksy natiivi vaihtoehto vasta, kun omistaja pystyy näyttämään, että epäonnistuminen on havaittava, korjattava ja turvallisesti uusittava ilman kaksoiskirjauksia.

Kirjaa soveltuvuusarvioon tuetut ja rajatut toiminnot. Esimerkiksi natiivi ERP-kortti voi sisältää asiakas- ja tilaussynkronoinnin asetuksia, mutta se ei tarkoita automaattisesti tuote-, saldo-, hinta-, lasku- tai palautusvirtaa.

Tunnista räätälöidyn integraation tarve

Räätälöity integraatio voi olla tarpeen, kun asiakkaalla on järjestelmä, jota rekisteri ei tue, tai kun natiivin integraation tietomalli, työnkulku, viive tai virheenkäsittely ei täytä hyväksyttyä vaatimusta. Tyypillisiä kohteita voivat olla ERP-, WMS- tai tilausjärjestelmät ja poikkeavat liiketoimintaprosessit.

Rajaa ero kirjallisesti ennen kehitystä. Älä valitse räätälöintiä vain siksi, että asiakkaan terminologia poikkeaa natiivista mallista. Älä myöskään pakota vaatimusta natiiviin integraatioon, jos se rikkoo tietojen omistajuutta, jättää tapahtumia havaitsematta tai edellyttää manuaalista tietokantakorjausta.

Ymmärrä /rest/*-reitin rajat

AI Commercen /rest/*-reittien rajat määräytyvät storefrontin palvelinpuolisesta reitittimestä. Reitit eivät ole yleinen ylläpidosta luotava kauppiaskohtainen API-avain tai vapaa GraphQL-välityspalvelu. Jokainen reitti vastaa ennalta toteutettua ja julkaistua palvelumoduulia; tuntematon reitti palauttaa 404:n ja väärä HTTP-metodi 405:n.

Storefrontin sisäinen GraphQL-kuljetus käyttää palvelinsalaisuuksia. Julkiseksi tarkoitettu kyselykerros sallii vain erikseen luetellut juurikentät ja kentät, vain lukukyselyt ja enintään 8 000 merkin kyselyn. Se estää muun muassa mutaatiot, tilaukset, introspektion, fragmentit ja aliakset. Näitä rajoja ei saa kiertää räätälöidyn integraation vuoksi.

Uusi /rest/*-palvelu on siis koodimuutos, joka tarvitsee nimetyn omistajan, sopimuksen, turvallisuuskatselmoinnin, versionoinnin, tietojen minimoinnin, kuormarajan, lokituksen, testauksen, käyttöönoton ja palautuksen. Älä julkaise palvelinsalaisuuksia partnerille tai selaimeen.

Sovi vastuunjako ennen toteutusta

Sovi integraation vastuunjako nimeämällä asiakkaalle, partnerille ja AI Commercelle vastuut vähintään seuraavista:

Partneri rajaa oman toteutuksensa ja kokoaa toistettavan teknisen todisteen. Jos havainto osoittaa AI Commercen ydintoiminnon virheen, se eskaloidaan virallisen tukipyynnön kautta. P1–P4-prioriteetti, vaste, ylläpito ja mahdollinen bugipalkkio määräytyvät voimassa olevan sopimuksen tai erillisen ohjelmaehdon mukaan, eivät tämän artikkelin perusteella.

Tee käyttöönottopäätös

Tee integraation käyttöönottopäätös vasta, kun seuraavat todisteet ovat valmiit:

1. Tietovirta ja omistava järjestelmä on kuvattu kenttätasolla.
2. Natiivin vaihtoehdon soveltuvuus ja rajat on testattu.
3. Räätälöinnin tarve on yksilöity eikä samaa kyvykkyyttä jo omisteta muualla.
4. Autentikointi, oikeudet, salaisuudet ja henkilötiedot on katselmoitu.
5. Idempotenssi, virheenkäsittely, seuranta ja palautus on todistettu.
6. Versiointi, ylläpito ja käytöstä poisto on omistettu.
7. Asiakas, partneri ja AI Commerce ovat hyväksyneet vastuunjaon ja kaupalliset ehdot.

Jos todiste puuttuu, pidä päätös avoimena ja kirjaa puute. Älä muuta epävarmaa integraatiota myyntilupaukseksi tai tuotantoasetukseksi.