Integraatiot ovat verkkokaupan kasvun näkymätön moottori: kun tilaukset, varastosaldot, tuotteet, hinnastot, asiakasdata ja toimitustiedot liikkuvat oikein järjestelmien välillä, arki rullaa. Kun ne eivät liiku, työ muuttuu käsityöksi ja jatkuvaksi tulipalojen sammutteluksi. Tämä artikkeli kokoaa AI Commerce Cloudin iPaaS-vaihtoehdon periaatteet ja käytännön mallin, jolla integraatiot tehdään nopeammin, joustavammin ja turvallisemmin ilman raskasta “integraatio-UI:ta”.

Miksi iPaaS ei aina ole paras vaihtoehto

Moni yritys päätyy iPaaS-ratkaisuihin, koska ne lupaavat “kaiken yhdellä työkalulla”: valmiita liittimiä, visuaalisen mappaus-UI:n, jonotuksen ja lokituksen. Käytännössä iPaaS on kuitenkin usein:

• Kallis (tyypillisesti kuukausihinnoittelu + transaktiokustannukset; esimerkkitasolla iPaaS voi maksaa noin 2 000 USD/kk)
• Jäykkä (rajattu logiikka, vaikeat poikkeukset ja erikoistapaukset)
• Riippuvuuksia lisäävä (väliportaaseen sidottu arkkitehtuuri ja hinnoittelumalli)
• Operatiivisesti riskialtis (hintamalli tai rajoitteet voivat muuttua, ja integraatioiden “omistajuus” jää epäselväksi)

Lisäksi moni verkkokauppa-alusta integroituu samoihin iPaaS-palveluihin, joten pelkkä iPaaS-integraatio ei tuo kilpailuetua. UI-pohjaisen “oman iPaaS:n” rakentaminen taas on iso projekti, eikä ole välttämättä realistista (varsinkin jos tavoite olisi tehdä kattava UI, jolla “voi tehdä kaiken”).

Ratkaisun ydin: framework + ohut sovelluskerros

AI Commerce Cloudin vaihtoehdon perusidea on:

Tarjotaan valmiiksi turvallinen ja toimintavarma integraatioalusta (framework), jonka päälle tehdään vain ohut, projektikohtainen sovelluskerros. Ohut kerros sisältää liitännän logiikan, mappaukset ja mahdolliset muunnokset. Integraatio syntyy API-kuvausten ja luonnollisen ohjeistuksen avulla, ilman että käyttäjän tarvitsee opetella uutta iPaaS-UI:ta.

Kenelle malli on tarkoitettu

• Yrityksille, joilla on 1–5 kriittistä integraatiota ja tarve tehdä ne oikein ilman iPaaS-kustannuksia
• Kumppaneille (partner agencies), jotka haluavat rakentaa integraatiot nopeasti ja hallitusti
• Organisaatioille, joissa integraatiotarpeet vaihtelevat ja “valmiit liittimet” eivät riitä
• Tiimeille, jotka arvostavat sitä, että integraatio on omassa projektissaan ja täysin hallittavissa

Huomio rooleista: ensisijaiset rakentajat ovat yleensä kumppanitoimistot tai edistyneet adminit. Keskimääräisellä adminilla ei usein ole aikaa tai osaamista tehdä tätä itse, vaikka se olisi mahdollista. JSON- ja XML-perusteiden ymmärrys on hyödyllistä (ainakin tulosten tarkistamiseen), mutta tavoitteena on, että AI-agentilla voidaan ohjata toteutusta myös luonnollisella kielellä.

Mitä kaikkea tällä voi integroida

Koska logiikka ei ole sidottu iPaaS-connector-kirjastoon, käytännössä voi integroida mitä tahansa dokumentoitua rajapintaa. Esimerkkejä:

• ERP-integraatiot: tilaukset, asiakkaat, varasto, hinnat, toimitusstatus (esim. Lemonsoft, Netvisor, Tehden/”Teheden”, SAP, Tisma)
• PIM/tuotehallinta: Akeneo
• Markkinointi ja asiakasdata: Mailchimp
• Hakupalvelut: Algolia
• Enterprise-ympäristöt: SAP (malli tukee yleisiä integraatioperiaatteita ja tarpeisiin räätälöityä logiikkaa)
• Tiedostopohjaiset integraatiot: XML-tiedostot sovitun tallennuspaikan kautta (esim. S3 + SFTP-pääsy ulkopuoliselle osapuolelle)

MVP-rajauksena: alussa tuetaan REST- ja XML-rajapintoja (ei muita protokollia ensimmäisessä versiossa). Lisäksi on mainittu mahdollisuus rakentaa “läpivientikonnektoreita” (järjestelmästä toiseen ohittaen AI Commercen tietokannan), mutta tämä voidaan rajata aluksi pois, jotta keskitytään integraatioihin, jotka lukevat/kirjoittavat AI Commercen MariaDB:hen.

Ylätason toiminta ja arkkitehtuuriperiaatteet

Projektikohtainen ympäristö

Jokainen integraatio on oma projekti ja oma ympäristö:

• oma koodipohja (ohut sovelluskerros)
• oma ajettava ympäristö (esim. AWS Lambda tai vaihtoehtoisesti Fargate; myös EC2 on mainittu vaihtoehtona “Easy2”-muodossa, mutta ei ensisijaisena)
• omat lokit ja jonot
• omat kustannukset (helppo kohdistaa per tenant / per projekti)
• omat asetukset ja tunnukset

Tämä eroaa monesta iPaaS-mallista: integraatiot eivät asu “yhdessä isossa laatikossa”, vaan ne ovat eristettyjä ja läpinäkyviä.

Framework (vendor) + sovelluskerros (wrapper)

• Framework / vendor (SaaS-toimittaja ylläpitää): jonotus, eräajot, virheiden hallinta, turvarajat, lokitus, integraatioprojektin perusrakenne sekä valmiit työkalut datan muokkaamiseen (XML/JSON), sekä kyvykkyys erilaisille autentikointityypeille (tokenit, API keyt jne.)
• Ohut sovelluskerros (kumppani/asiakas/AI rakentaa): määrittää mitä integroidaan, miten kentät mappautuvat, mitä muunnoksia tehdään ja missä järjestyksessä

Vendor-koodia ei muokata tenant-projekteissa: se tulee riippuvuutena (“vendor dependency”), ja CI voi estää vendor-kansioon kohdistuvat muutokset, jotta AI-agentti ei vahingossa editoi sitä. Tavoite on, että vendor voidaan päivittää taustalla ja sovelluskerros pysyy tarkoituksella “ohuehkona” ja helppona ylläpitää.

AI-ohjattu integraation rakentaminen käytännössä

Keskeinen innovaatio on, että integraatio voidaan toteuttaa AI-ohjatusti. Käytännössä kumppani tai edistyneempi admin:

• syöttää integraatiolle API-dokumentaatiot (ERP/PIM/CRM/markkinointityökalu) ja esimerkkipayloadit (myös PDF voi olla lähtöaineistona)
• antaa ylätason mappauskuvauksen luonnollisella kielellä, esim.:
  • “Tuo kenttä X vastaa meillä kenttää Y”
  • “Jos arvo on tyhjä, käytä oletusta”
  • “Katkaise merkkijono tiettyyn pituuteen”
  • “Tee muunnos ja validointi ennen tallennusta”

AI voi auttaa mappauksissa, muunnosfunktioissa ja reunaehdoissa. Toteutuksen tulee olla agent-agnostinen: kumppani voi käyttää esimerkiksi Codexia, Cursor AI:ta tai muita agentteja (tekstissä mainitaan myös “Google Gravity / Atlas Graviton” esimerkkeinä). Tavoite ei ole sitoa toteutusta yhteen AI-työkaluun tai yhteen käyttöliittymään.

Käyttöönotto käytännössä (asiakas + kumppani)

1. Valitse integraation tavoite
   Määritellään mitä halutaan, esimerkiksi:
   • “Tilaukset ERP:iin”
   • “Varastosaldot takaisin verkkokauppaan”
   • “Tuotteet PIM:stä verkkokauppaan”
   • “Toimitusstatukset ja seurantakoodit”
2. Luo integraatioprojekti ja ympäristö
   Integraatio saa oman projektinsa ja ympäristön, johon kuuluu valmiit rakenteet: reitit (import/export), mappaukset, lokitus ja jonotus.
3. Syötä API-dokumentaatio ja kuvaa mappaus
   Kumppani toimittaa:
   • API-kuvauksen (dokumentaatio, esimerkkipayloadit)
   • ylätason mappauskuvauksen (mitä kenttää vastaa mikäkin)
4. Testaa hallitusti
   Integraatiot tehdään niin, että:
   • ajot ovat eräajoja ja/tai jonotettuja (kuorma pysyy hallinnassa)
   • virheet lokitetaan ja voidaan toistaa hallitusti
   • onnistumiset ja epäonnistumiset ovat jäljitettävissä
5. Siirry tuotantoon
   Kun integraatio on oikein, se ajetaan automaattisesti sovitulla rytmillä (esim. 5 minuutin välein) ja/tai webhook-pohjaisesti.

Mistä editoidaan

Ohut sovelluskerros

• Integraation projektikohtaisessa Git-repossa (usein GitHub), jossa kumppani/tenant ylläpitää reittejä, mappauksia, funktioita ja business-sääntöjä.
• Suositus on pitää yksi integraatio = yksi repo (esim. “SAP-integraatio” ja “Microsoft-integraatio” erillisinä), jotta ylläpito pysyy selkeänä ja kustannukset voidaan kohdistaa (erilliset Lambdat/Fargate-palvelut).

Framework (vendor)

• Framework toimitetaan riippuvuutena (vendor), jota tenant ei muokkaa.
• CI voi estää vendor-muutokset (guardrail), jotta esimerkiksi AI-agentti ei lähde vahingossa editoimaan framework-tiedostoja.
• Frameworkiin voidaan sisällyttää myös ajon, deployn ja pipelinejen peruspalikat, jotta kumppanin ei tarvitse “opettaa AI:ta” kaikkeen infrastruktuurista (esim. serverless YAML / CDK / CloudFormation -rungot vendorissa).

Asetukset, tunnukset ja salaisuudet

• Salaisuuksia ei kirjoiteta koodiin; ne pidetään GitHub Secrets -hallinnassa ja/tai AWS:ssa (ympäristömuuttujina/secret-viitteinä).
• AI-agentti ei saa nähdä salaisuuksia; kumppani voi tarvittaessa nähdä ja asettaa ne, jos repo on tenantin omistuksessa.

Ajastus ja webhookit

• Ajastukset voidaan hoitaa AWS EventBridge -ajolla (esim. 5 min välein).
• Inbound-webhookit voidaan toteuttaa API Gatewayn tai Lambda Function URL:n kautta, API key -suojauksella.
• Päätepisteiden ei tarvitse olla ihmisten käyttämiä; AWS:n dynaamiset URL-osoitteet riittävät (ei tarvetta omalle domain-proxylle tässä vaiheessa).

Frameworkin “best practises” ja pakotetut turvakaiteet

Jonotus ja eräajo: process_queue

Frameworkin tulee sisältää jonotusmekanismi, jota tenant ei voi ohittaa vahingossa. Perusidea:

• Framework luo DynamoDB-taulun (esim. process_queue) CloudFormation-stackin osana.
• Setupissa kumppani voi valita maksimi-batch-koot per viestityyppi / reitti (esim. “Orders export: 5 kpl/ajo”, “Products import: 100 kpl/ajo”).
• Jos ulkoisesta järjestelmästä tulee 5 000 itemiä, jonotus tallentaa raakadatan (raw payload) ja vapauttaa käsittelyyn esim. 100 kerrallaan seuraavilla processQueue-ajoilla.
• processQueue-endpointia kutsutaan ajastetusti (EventBridge) ja se tasaa piikkejä, jotta MariaDB ei kuormitu ja kustannukset pysyvät hallinnassa.

Jonotuksen “ohitus” ei ole MVP:n tavoite. Käytännössä jonotus toimii turvamekanismina myös silloin, kun kuorma on pieni: jos jonossa on vähemmän itemeitä kuin batch-koko, ne voidaan käsitellä heti.

Lokitus ja payloadien tallennus

• RDS/MariaDB on AI Commercen ydintietokanta, eikä sitä käytetä integraation sisäiseen “muistiin” (jonot, lokit, raw payloadit) tai sisäisiin prosesseihin.
• Raw inbound/outbound payloadit voidaan tallentaa DynamoDB:hen (lyhytikäinen, helppo TTL), ja/tai S3:een (myös mahdollinen, erityisesti jos halutaan halpa säilytys XML/JSON-payloadille).
• Virheet voidaan tallentaa DynamoDB:hen TTL:llä (esim. vanhenevat automaattisesti ajan kuluttua).
• Kumppaneille tarvitaan debug-näkymä, jossa nähdään lähetetyt/ vastaanotetut viestit ja niiden lokit. Yksi malli on tallentaa lokit S3:een ja hakea ne käyttöliittymään debug view -näkymää varten.

Turvarajat ja kuormansuoja

• DB-yhteysrajoitus: esimerkkinä 5 yhteyttä per tenant (mainittu tavoiterajana).
• Kutsurajat: esimerkkitasolla 100 pyyntöä/min ja 5 000–10 000 pyyntöä/tunti (tarkat arvot päätetään toteutuksessa).
• Idempotenssi ja toistonsuoja: sama tapahtuma ei saa lähteä vahingossa uudelleen “loputtomasti” (esim. sama tilaus ei saa lähteä 100 kertaa).
• Lisäsuoja tilauksille: jos sovellus kysyy samaa orders-dataa toistuvasti, voidaan hashata vastaus ja jos sama vastaus toistuu esim. 1 tunnin sisällä, framework voi katkaista ajon (kill switch) ja estää vaarallisen loopin.

Huomio: avain (idempotenssin/queue-itemin “job id”) ei ole hardcodattu frameworkiin, vaan se valitaan sovelluskerroksessa viestityypin mukaan (esim. tilauksilla order ID, tuotteilla SKU tai product ID). Tavoite on, että jokaisessa viestityypissä voidaan määrittää yksi keskeinen avain.

In-memory/memoization ohjauksena

• Framework voi ohjata sovelluskerrosta käyttämään in-memory memoizationia, jotta samaa dataa ei haeta silmukassa MariaDB:stä uudelleen ja uudelleen.
• Erillistä cache-palvelua ei välttämättä tarvita MVP:ssä, jos memoization riittää yleisimpiin looppeihin.

VPC, NAT ja IP-whitelist

• Integraatiot ajetaan AI Commercen VPC:ssä (sama perusverkko kuin pääalustalla).
• NAT gatewayt tarjoavat ulospäin kiinteät IP-osoitteet, joita voidaan käyttää kolmansien osapuolten whitelistaukseen.
• VPN-yhteyksiä ei tarvita alussa (mainittu rajauksena), mutta internet-yhteys on käytössä NATin kautta.

Eristys IAM-politiikoilla ja stack-kohtaisilla resursseilla

• Jokaisella integraatioprojektilla on oma CloudFormation-stack, joka luo resurssit (DynamoDB, S3-bucket, jne.).
• Tenantin/partnerin IAM-oikeudet rajataan vain stackin luomiin resursseihin, ei muihin AWS-tilin olemassa oleviin resursseihin.
• Deploy-oikeudet annetaan roolilla tai tunnuksilla; tenant voi omistaa repositorion, mutta ei pääse tekemään mitään “laitonta” IAM-politiikan ohi.

Mappausmalli ilman iPaaS-UI:ta

Mielikuva: rakennetaan “mini-iPaaS ilman UI:ta”, jossa viestityypin mappaus on konfiguroitava ja laajennettavissa funktioilla. Framework tarjoaa rakenteen, sovelluskerros täyttää sisällön.

Viestityypit, reitit ja kansiorakenne

• Framework luo valmiin kansiorakenteen eri viestityypeille / reiteille / “routes”.
• Import ja export erotetaan selkeästi esimerkiksi alihakemistoilla (import/ ja export/), jotta ne ovat decoupled ja ilman konfliktinratkaisua (conflict resolution jätetään MVP:stä pois).

XML/JSON-valinta ja työkalut

• Jokaisessa reitissä voidaan valita, käsitelläänkö XML:ää vai JSON:ia.
• Framework tarjoaa valmiit työkalut XML/JSON-parsintaan, muunnoksiin ja validaatioon.

Esimerkkimappaus (kenttä → funktio → kohdekenttä)

Yksi käytännöllinen malli on mappauslista per viestityyppi, jossa jokainen rivi sisältää:

• lähdekentän polku (esim. XML:ssä tuote.tuotekoodi)
• muunnosfunktion nimi (esim. convertSku())
• kohdekenttä (esim. MariaDB-taulu.sarake: products.products_model)

Esimerkki muodossa:

{ ['tuote.tuotekoodi', 'convertSku()', 'products.products_model'], [...] }

• tuote.tuotekoodi = avain XML:n tuote-objektista
• convertSku() = funktio, jonka Codex/devit ylläpitävät sovelluskerroksessa
• products.products_model = kohdekenttä AI Commercen MariaDB-skeemassa

convertSku()-funktion esimerkkikäytös: trimmataan whitespace ja katkaistaan merkkijono siihen pituuteen, jonka MariaDB-skeeman varchar() sallii kyseisessä sarakkeessa. Tämä on tyypillinen “iPaaS-tyylinen” muunnos, mutta ilman UI:ta.

MariaDB-skeema näkyviin sovelluskerrokselle (vendor)

• Frameworkin vendor-osaan voidaan sisällyttää AI Commercen tietokantaskeema “odotettuna mallina” puhtaana SQL:nä.
• Skeema pidetään ajan tasalla vendorin @latest-versiossa, jotta AI-agentti tai kehittäjä näkee odotetut taulut, sarakkeet ja datatyypit ilman runtime-introspektiota.
• Vendor-päivitykset pyritään tekemään ilman breaking changes; jos breaking change olisi pakko tehdä, kumppaneille ilmoitetaan ja annetaan aikajana tehdä tarvittavat muutokset omiin repoihin ennen pakollista siirtymää.

Julkaisu, ylläpito ja versiointi (CI/CD)

• Versionhallinta: GitHub (tai vastaava), jotta rollback ja auditointi onnistuvat (commiteista näkee kuka teki mitä).
• Deploy: GitHub Actions, joka ajaa lintit ja perustestit ennen deployta.
• Toimintamalli: “push/merge → automaattinen deploy” ilman erillisiä hyväksyntöjä (tenant voi halutessaan vaatia partner review’n, mutta oletus voi olla auto-deploy).
• Rollback: MVP:ssä manuaalinen (Git revert / checkout aiempaan tagiin), ei automaattista rollbackia, mutta perustaa voidaan valmistella myöhempää automaatiota varten.
• Vendor-koskemattomuus: CI voi estää vendor-muutokset, jotta “hard guardrails” säilyvät.

Runtime-päivitykset ja pitkäikäisyys: tekstissä nostetaan esiin, että Lambda voi deprekoida vanhoja runtime-versioita. Siksi wrapper-kerros pidetään tarkoituksella hyvin ohuena ja perussyntaksilla, jotta se ei vanhene nopeasti. Ajatuksena on myös, että tulevaisuudessa AI-agentti pystyy päivittämään wrapperin uuteen runtimeen (esim. “Node.js version 35” mainitaan hypoteettisena esimerkkinä) helposti, mutta MVP:ssä kannattaa silti valita vakaa kieli ja minimimuutoksilla toimiva malli.

Tekniset rajaukset ja oletukset (MVP)

• Ei konfliktinratkaisua (import/export ovat erillisiä, eivät tietoisia toisistaan).
• Ei tarvetta rinnakkaisille invokaatioille tässä vaiheessa.
• Ei VPN:ää; outbound toimii NAT gatewayn kautta ja mahdollistaa IP-whitelistauksen.
• Ei “superraskaiden” ulkoisesta järjestelmästä toiseen -connectorien tukea MVP:ssä (esim. Akeneo → ERP ohittaen AI Commercen DB), vaikka malli voi teoriassa tukea myöhemmin.
• Kuorma oletuksena pieni (esimerkkitasolla max ~5 tilausta per tunti), mutta arkkitehtuuri ei saa estää myöhempää reaaliaikaisuutta (webhookit) tai suurempia datamääriä.
• MariaDB on AI Commercen ydintietokanta; integraation sisäinen jono ja lokit eivät asu MariaDB:ssä.

Ennen toteutussuunnitelman lukitsemista: tärkeimmät kysymykset

Tässä mallissa ei kannata “lukita designia” ennen kuin nämä peruskysymykset on päätetty. Pidä lista tarkoituksella lyhyenä ja päätöksentekoon ohjaavana:

• Runtime-valinta: onko ensisijainen ajomalli AWS Lambda (cold start tärkeä) vai Fargate (pitkäkestoisempi), ja missä kohdissa toinen täydentää toista?
• Kielivalinta: mennäänkö Go:lla vai Pythonilla (molemmat mainittu ok), ja mikä valinta minimoi breaking change -riskin ja helpottaa AI-agenttien luotettavaa muokkausta?
• Queue ja payload storage: tallennetaanko raw inbound/outbound payloadit ensisijaisesti DynamoDB:hen, S3:een vai hybridinä (esim. DynamoDB + TTL virheille, S3 pitkille payload-lokeille)?
• Repo-omistusmalli: tuetaanko sekä vendor-omisteista että tenant-omisteista repo-mallia, ja mikä on oletus (fokus B: tenant omistaa repo, SaaS rajaa IAM-oikeudet)?
• Turvarajojen oletusarvot: mitkä ovat järkevät per-minute/per-hour limitit, DB-connection limitit ja loopin tunnistusrajat (esim. sama orders-hash 1h sisällä → kill switch)?
• Idempotenssiavain per viesti: miten avain määritellään per viestityyppi (order ID, SKU, product ID), ja miten estetään vahingossa tehty “sama viesti uudelleen” -looppi?
• Debug-näkymä Hallintapaneelissa: mikä on minimitaso, jolla partner näkee lähetetyt viestit, virheet ja payloadit (esim. S3-lokeista listaus)?
• Vendor-päivitysstrategia: miten varmistetaan “ei breaking changes”, ja millä prosessilla/ajalla kumppanit päivittävät wrapperin, jos breaking change olisi pakollinen?

Yhteenveto ja suositeltu seuraava askel

AI Commerce Cloudin integraatiotyökalu toimii “mini-iPaaS”-mallina ilman raskasta UI:ta: framework tuo jonotuksen, lokituksen, turvarajat ja toimintavarmuuden, ja ohut sovelluskerros (kumppani/tenant/AI-agentti) toteuttaa mappaukset ja logiikan. Malli pitää kustannukset ennustettavina, tekee erikoistapauksista mahdollisia ja vähentää riippuvuutta välikäden hinnoittelusta. Seuraavaksi kannattaa päättää vähintään runtime + kieli + queue/payload storage -linjaukset sekä turvarajojen oletusarvot, jotta ensimmäiset ERP-template-versiot (esim. Lemonsoft/Netvisor/Tehden/SAP/Tisma) voidaan viedä tuotantovalmiiksi.

Sanasto

• Akeneo: PIM-järjestelmä (tuotehallinta), josta voidaan tuoda tuotteet ja attribuutit verkkokauppaan.
• Hallintapaneeli: AI Commercen ylläpitäjien käyttöliittymä, johon voidaan tuoda esim. debug-näkymä integraatioiden seurantaan.
• AI Commerce: verkkokauppa-alusta ja sen tietokantaydin (MariaDB), jota integraatiot lukevat ja päivittävät.
• Builderio: AI Commerceen liitettävä sisällönrakennustyökalu (mainitaan alustasanastossa).

Avainsanat

• AI Commerce Cloud integraatiot
• iPaaS vaihtoehto
• integraatio framework
• ohut sovelluskerros
• DynamoDB process_queue
• AWS Lambda VPC
• GitHub Actions deploy
• XML JSON mappaus
• ERP integraatio (Lemonsoft, Netvisor, Tehden, SAP, Tisma)
• Akeneo PIM integraatio