AI Connector integraatiomallina

AI Connector on ehdotettu integraatiomalli, jossa yhteinen turvallinen sovelluskehys hoitaa jonotuksen, eräajot, lokituksen ja turvarajat, ja jokainen integraatio saa ohuen projektikohtaisen sovelluskerroksen. Malli ei perustu kaiken kattavaan visuaaliseen iPaaS-käyttöliittymään.

> Tila: Tässä artikkelissa kuvataan tavoitemallia ja MVP-rajauksia. Runtime, ohjelmointikieli, jonoratkaisu, lokien säilytys, oletusrajat, repositorion omistus ja tuotantopalvelun kaupalliset ehdot pitää lukita ennen mallin käyttöönottoa.

Miksi AI Connector on vaihtoehto iPaaS:lle

AI Connector -mallin tavoite on pitää tilaukset, asiakkaat, varastosaldot, tuotteet, hinnastot ja toimitustiedot liikkeessä ilman ylimääräistä integraatioväliporrasta. Tyypillinen iPaaS tarjoaa valmiita liittimiä, visuaaliset mappaukset, jonotuksen ja lokituksen, mutta voi samalla tuoda kuukausi- ja transaktiokustannuksia, rajata poikkeuslogiikkaa ja sitoa integraation yhden toimittajan arkkitehtuuriin.

Kustannusesimerkkinä iPaaS-palvelulle on käytetty noin 2 000 USD:n kuukausihintaa transaktiokulujen lisäksi. Tämä ei ole yleinen hinnasto eikä AI Connectorin säästölupaus. Mallin oma kustannus syntyy ajastuksista, kutsuista, datankäsittelystä, tallennuksesta ja ylläpidosta. Pelkkä yhteiseen iPaaS-palveluun liittyminen ei myöskään tuo kilpailuetua, jos kaikki verkkokaupat käyttävät samaa valmisliitintä.

Sovelluskehys ja ohut sovelluskerros

AI Connector -mallissa yhteinen sovelluskehys tarjoaa integraatioille jonotuksen, eräajot, virheiden hallinnan, lokituksen, idempotenssin, kuormarajat, perusrakenteen sekä XML- ja JSON-työkalut. Projektikohtainen sovelluskerros määrittää reitit, kenttämappaukset, muunnokset, validoinnit, rikastukset ja erikoissäännöt.

Tenant-projekti ei muokkaa toimittajan sovelluskehystä. Kehys toimitetaan versionhallittuna riippuvuutena, ja jatkuva integraatio voi estää sen tiedostoihin tehdyt muutokset. Tavoite on päivittää yhteinen kehys erillään ja pitää sovelluskerros niin ohuena, että integraation oma liiketoimintalogiikka on helppo tarkastaa. Malli on tarkoitettu ensisijaisesti yrityksille, joilla on 1–5 kriittistä integraatiota, kumppanitoimistoille ja edistyneille ylläpitäjille.

Mitä rajapintoja malli voi käsitellä

AI Connectorin tavoitemalli voi yhdistää dokumentoituja rajapintoja ERP-, PIM-, CRM-, markkinointi-, haku- ja valmistajatietopalveluihin. Esimerkkijärjestelmiä ovat Lemonsoft, Netvisor, Tehden, SAP, Tisma, Mailchimp ja Algolia. Tiedostopohjainen siirto voi käyttää XML-tiedostoja sovitussa tallennuspaikassa, kuten S3:ssa, johon ulkopuolinen osapuoli pääsee SFTP-yhteydellä.

Ensimmäisen version rajaukseksi on ehdotettu REST- ja XML-rajapintoja. Suora läpivienti ulkoisesta järjestelmästä toiseen ilman AI Commercen MariaDB-tietokantaa voidaan jättää MVP:n ulkopuolelle. Import ja export pidetään erillisinä eikä niiden välistä konfliktinratkaisua rakenneta ensimmäiseen versioon. Mallin mahdollisuus ei vielä tarkoita, että nimettyyn järjestelmään olisi valmis tuotantoliitin.

Projektikohtainen ympäristö ja omistajuus

Jokainen AI Connector -integraatio suunnitellaan omaksi projektikseen ja ympäristökseen. Sillä on oma ohut koodipohja, ajettava palvelu, asetukset, tunnukset, lokit, jonot ja kohdistettavat kustannukset. Ensisijaiseksi ajomalliksi on ehdotettu AWS Lambdaa; Fargate voi täydentää pitkäkestoisia ajoja, ja EC2 on mainittu vaihtoehtona mutta ei ensisijaisena mallina.

Suositeltu lähtökohta on yksi integraatio yhtä repositoriota kohti, esimerkiksi SAP- ja Microsoft-integraatiot erillään. EC2:n yhteydessä käytetty työnimi Easy2 ei muuta sitä, että Lambda on ollut ehdotuksen ensisijainen ajomalli. Repositorio voi olla tenantin tai toimittajan omistama, mutta oletusmalli pitää vielä päättää. Projektin eristys tekee kustannuksista ja muutoksista näkyviä eikä sijoita kaikkia integraatioita samaan laatikkoon.

AI-ohjattu integraation rakentaminen

AI Connectorin AI-ohjatussa toteutuksessa kumppani tai edistynyt ylläpitäjä antaa integraatiolle API-dokumentaation, esimerkkipayloadit ja ylätason mappauskuvauksen. Aineisto voi sisältää myös PDF-dokumentaatiota. Ohje voi kuvata esimerkiksi, että kenttä X vastaa kenttää Y, tyhjälle arvolle käytetään oletusta, merkkijono katkaistaan määrättyyn pituuteen tai arvo validoidaan ja muunnetaan ennen tallennusta.

AI-agentti voi auttaa mappausten, muunnosfunktioiden ja reunaehtojen toteutuksessa, mutta ihminen tarkastaa tulokset. Malli ei saa sitoa integraatiota yhteen agenttiin: esimerkkeinä on mainittu Codex, Cursor AI, Google Gravity ja Atlas Graviton. JSON- ja XML-perusteiden ymmärtäminen on hyödyllistä ainakin payloadien ja testitulosten tarkastamisessa.

Käyttöönoton vaiheet

AI Connector -integraation käyttöönotto alkaa täsmällisestä tavoitteesta, kuten tilausten viennistä ERP:hen, varastosaldojen palautuksesta verkkokauppaan, tuotteiden tuonnista PIM-järjestelmästä tai toimitusstatusten ja seurantakoodien päivityksestä. Sen jälkeen luodaan projektikohtainen ympäristö, reitit, mappaukset, lokitus ja jonotus.

Kumppani toimittaa API-kuvauksen, esimerkkipayloadit ja kenttien vastaavuudet. Integraatio testataan jonotettuina tai eräajoina niin, että virheet voidaan toistaa hallitusti ja onnistumiset sekä epäonnistumiset ovat jäljitettävissä. Tuotannossa ajo voi tapahtua sovitulla rytmillä, esimerkiksi viiden minuutin välein, tai webhookista. Viiden minuutin rytmi on esimerkki, ei lukittu palvelutaso.

Missä integraatiota muokataan

Projektikohtaisen integraation reittejä, mappauksia, funktioita ja liiketoimintasääntöjä muokataan integraation omassa Git-repositoriossa, usein GitHubissa. Yhteinen sovelluskehys säilyy riippuvuutena eikä sitä muokata tenant-projektissa. Kehys voi sisältää myös käyttöönoton ja julkaisun perusrakenteet, kuten Serverless YAML-, CDK- tai CloudFormation-määritykset.

Salaisuuksia ei kirjoiteta koodiin. Ne asetetaan esimerkiksi GitHubin salaisuuksien hallinnassa tai AWS:n ympäristömuuttuja- ja salaisuusviitteinä. AI-agentille ei anneta salaisuuksia. Kumppani voi asettaa ne, jos käyttöoikeudet ja repositorion omistus sallivat sen. Ajastukset voidaan toteuttaa EventBridgellä, ja sisään tulevat webhookit API Gatewaylla tai Lambda Function URL -osoitteella API-avaimella suojattuna. MVP:ssä dynaaminen AWS-osoite voi riittää ilman omaa verkkotunnusproxya.

Jonotus ja eräajot

AI Connector -sovelluskehyksen jonon tarkoitus on estää kuormapiikit ja hallitsemattomat toistot. Ehdotetussa mallissa CloudFormation-pino luo DynamoDB:n process_queue-taulun. Kumppani määrittää viestityypin tai reitin eräkoon, esimerkiksi viisi tilausta vientiajoa kohti tai 100 tuotetta tuontiajoa kohti.

Jos ulkoinen järjestelmä palauttaa 5 000 kohdetta, jono tallentaa raakapayloadin ja vapauttaa esimerkiksi 100 kohdetta kerrallaan seuraaville processQueue-ajoille. EventBridge kutsuu käsittelyä ajastetusti. Jonoa ei ole tarkoitus ohittaa MVP:ssä: jos kohteita on eräkokoa vähemmän, ne voidaan käsitellä heti jonon kautta. Jonon tarkka palvelu, taulurakenne ja käsittelytakuu ovat vielä toteutuspäätöksiä.

Lokit ja payloadien säilytys

AI Connectorissa AI Commercen RDS/MariaDB on liiketoimintadatan ydintietokanta, eikä integraation sisäisiä jonoja, lokeja tai raakapayloadeja ole tarkoitus tallentaa sinne. Lyhytikäiset sisään ja ulos kulkevat payloadit sekä virheet voidaan tallentaa DynamoDB:hen TTL-vanhenemisella. Suuret tai pidempään säilytettävät XML- ja JSON-payloadit voidaan tallentaa S3:een.

Kumppaneille tarvitaan debug-näkymä, jossa näkyvät lähetetyt ja vastaanotetut viestit, virheet ja lokit. Yksi ehdotettu malli lukee näkymän tiedot S3-lokeista. Säilytysaika, henkilötietojen käsittely, salaisuuksien peittäminen, käyttöoikeudet ja poistokäytäntö on päätettävä ennen tuotantokäyttöä.

Turvarajat ja toistonsuoja

AI Connectorin ehdotettuja tavoiterajoja ovat enintään viisi tietokantayhteyttä tenantia kohti, 100 pyyntöä minuutissa ja 5 000–10 000 pyyntöä tunnissa. Nämä ovat esimerkkejä, eivät tuotannon lukittuja rajoja. Jokaisen viestityypin idempotenssiavain määritetään sovelluskerroksessa: tilauksella se voi olla tilaus-ID ja tuotteella SKU tai tuote-ID.

Sama tapahtuma ei saa kiertää loputtomasti. Lisäsuojana toistuvan tilaushakuvastauksen voi tiivistää hashiksi ja katkaista ajon, jos sama sisältö toistuu esimerkiksi tunnin eli 1h sisällä. Sovelluskehys voi myös ohjata käyttämään muistinsisäistä memoisaatiota, jotta samaa MariaDB-tietoa ei haeta silmukassa uudelleen. Erillistä välimuistipalvelua ei välttämättä tarvita MVP:ssä, jos memoisaatio kattaa yleiset toistot.

Verkko- ja käyttöoikeuseristys

AI Connector -integraatioiden on ehdotettu toimivan AI Commercen VPC:ssä. NAT-yhdyskäytävä tarjoaa ulospäin kiinteän IP-osoitteen kolmannen osapuolen sallittujen osoitteiden listaa varten. MVP:ssä ei oleteta VPN-yhteyttä, vaan ulospäin suuntautuva liikenne kulkee NATin kautta.

Jokaisella integraatioprojektilla on oma CloudFormation-pino, joka luo esimerkiksi DynamoDB-taulun ja S3-bucket-resurssin. Tenantin tai kumppanin IAM-oikeudet rajataan vain kyseisen pinon resursseihin. Julkaisuoikeus annetaan erillisellä roolilla tai tunnuksilla. Repositorion omistaminen ei anna oikeutta ohittaa AWS-tilin IAM-rajoja.

Mappaus ilman visuaalista iPaaS-käyttöliittymää

AI Connectorin mappausmallissa sovelluskehys tarjoaa viestityypeille ja reiteille kansiorakenteen. Import ja export erotetaan omiin hakemistoihinsa. Tätä on kuvattu myös mini-iPaaS-malliksi ilman raskasta käyttöliittymää. Jokainen reitti valitsee XML/JSON-käsittelyn ja käyttää yhteisiä parsinta-, muunnos- ja validointityökaluja.

Yksi ehdotettu mappausrivi sisältää alkukentän polun, muunnosfunktion ja kohdekentän, esimerkiksi ['tuote.tuotekoodi', 'convertSku()', 'products.products_model']. Tässä tuote.tuotekoodi on XML-objektin avain, convertSku() on sovelluskerroksen funktio ja products.products_model MariaDB:n kohdesarake. Funktio voi poistaa ylimääräiset välilyönnit ja katkaista arvon skeeman varchar-pituuteen. Mappaus on tarkistettava todellista API-sopimusta ja tietokantaskeemaa vasten.

Tietokantaskeema ja versiointi

AI Connectorin tietokantaskeema- ja versiointimallissa toimittajariippuvuuteen voidaan sisällyttää AI Commercen odotettu MariaDB-skeema puhtaana SQL-tiedostona. Tällöin agentti ja kehittäjä näkevät taulut, sarakkeet ja tietotyypit ilman tuotantokannan runtime-introspektiota. Skeema pidetään ajan tasalla riippuvuuden uusimmassa versiossa.

Päivitysten tavoitteena on välttää rikkovia muutoksia. Jos sellainen on pakollinen, kumppaneille ilmoitetaan ja annetaan siirtymäaika. Git-versionhallinta säilyttää auditoinnin ja palautuksen. GitHub Actions voi ajaa CI/CD-putkessa linttauksen ja perustestit ennen julkaisua, minkä jälkeen push tai merge voi julkaista automaattisesti. Tenant voi vaatia kumppanikatselmoinnin. MVP:n palautus tehdään käsin Git-revertillä tai aiempaan tagiin palaamalla.

Runtime pidetään vakaana ja sovelluskerros yksinkertaisena, jotta vanheneva Lambda-runtime voidaan vaihtaa hallitusti. Esimerkkiviittaus tulevaan ”Node.js 35” -versioon on hypoteettinen eikä tekninen valinta.

MVP:n rajat

AI Connectorin ehdotettu MVP ei ratkaise importin ja exportin konflikteja, ei tarvitse rinnakkaisia invokaatioita eikä käytä VPN:ää. Se ei myöskään tue raskaita ulkoisen järjestelmän läpivientejä, jotka ohittavat AI Commercen tietokannan. Sisäinen jono ja lokit pidetään MariaDB:n ulkopuolella.

Alkuperäinen kuorma-arvio on pieni, enintään noin viisi tilausta tunnissa, mutta arkkitehtuuri ei saa estää myöhempiä webhookeja tai suurempia datamääriä. MVP tukee REST- ja XML-rajapintoja. Nämä rajat ovat suunnitteluoletuksia, jotka pitää vahvistaa ensimmäisen tuotantointegraation todellisella kuormalla ja sopimuksilla.

Päätä nämä ennen toteutusta

AI Connectorin toteutussuunnitelmaa ei pidä lukita ennen seuraavia päätöksiä:

• Ajetaanko ensisijaisesti AWS Lambdalla vai Fargatella, ja missä toinen täydentää ensimmäistä?
• Valitaanko toteutuskieleksi Go vai Python?
• Tallennetaanko jonot ja raakapayloadit DynamoDB:hen, S3:een vai hybridimalliin?
• Omistaako repositorion oletuksena tenant vai toimittaja?
• Mitkä ovat pyyntö-, tietokantayhteys- ja toistosuojan oletusrajat?
• Miten idempotenssiavain määritetään jokaiselle viestityypille?
• Mitä kumppanin debug-näkymä näyttää lähetetyistä ja vastaanotetuista viesteistä?
• Miten toimittajariippuvuuden rikkova päivitys julkaistaan ja kuinka pitkä siirtymäaika annetaan?

Kun päätökset on tehty, ensimmäiset Lemonsoft-, Netvisor-, Tehden-, SAP- tai Tisma-mallit voidaan määritellä tuotantovalmiuden arviointia varten. Valmiiksi liittimiksi niitä ei pidä kutsua ennen toteutusta, testituloksia, valvontaa ja hyväksyttyä käyttöönottoprosessia.