Tervetuloa lukemaan kattavaa ohjeartikkelia AI Commercen uudesta Serverless-ratkaisusta, joka mahdollistaa partnerien kehittää omaa logiikkaa ja laajennuksia AICommercen ytimeen ilman, että heidän tarvitsee muokata varsinaista pää-backendiä. Tämän artikkelin tarkoitus on toimia syväluotaavana oppaana: kerromme taustalla olevasta arkkitehtuurista, miksi tämä malli on hyödyllinen, kuinka asennus sekä käyttöönotto tehdään ja mitä kaikkea kumppanit voivat sen avulla toteuttaa.

1. Taustaa: Composable Commerce ja miksi se on tärkeää

Composable Commerce -ajattelumallissa jokainen osa-alue (kuten tuotehallinta, asiakashallinta, tilausten käsittely, hakutoiminto, jne.) voidaan toteuttaa erillisinä “palikoina” eli micro serviceinä. Nämä micro servicet kommunikoivat keskenään API-rajapintojen kautta. Perinteisen monoliittisen arkkitehtuurin sijaan Composable Commerce -malli tarjoaa:

• Joustavuutta: Uusia ominaisuuksia voi luoda nopeammin, kun jokaista osaa voidaan kehittää ja testata toisistaan riippumatta.
• Laajennettavuutta: Voit lisätä kolmansien osapuolien palveluita (esim. uusia maksuratkaisuja, haku- tai ERP-integraatioita) helpommin, ilman massiivisia muutoksia ydinjärjestelmään.
• Nopeampaa tuotekehitystä: Kumppanit voivat kehittää ja julkaista omia laajennuksiaan itsenäisesti, ja AI Commerce-hallinnoi turvallisuuden ja infrastruktuurin.

2. Ratkaisun ydin: AI Commercen Serverless Lamda -ympäristö

Olemme luoneet partnerikäyttöön erillisen palvelittoman (serverless) ympäristön, joka sijaitsee samassa virtuaalisessa VPC:ssä kuin AI Commercen ydinkoodi. Tällä tavoin tietoliikenneyhteydet ovat erittäin nopeita, eikä eri pilviympäristöjen välillä tarvitse siirtää dataa internetin kautta.

2.1 Mitä tämä tarkoittaa kumppaneille?

Pääsy laajennettuun infrastruktuuriin

• Kumppanit voivat ottaa käyttöönsä AWS Lambda -pohjaisia mikropalveluja (funktioita), joilla on suora, turvallinen yhteys AI Commercen pää-backendiin (tai sen tietokantaan RDS:ssä).

Itsehallittu koodi ja deployment

• Kumppanit saavat omat AWS CLI -avaimet, joilla he voivat lähettää koodinsa suoraan AI Commercen hallinnoimaan ympäristöön. Näin he voivat kehittää ja päivittää laajennuksiaan joustavasti, ilman että AI Commercen tiimin täytyy joka kerta puuttua prosessiin.

Yksi GitHub-repositorio per asiakas

• Kullakin kumppanin asiakkaalla (esim. “Airbus” tai “Boeing”) on oma GitHub-repositorio: extensions-airbus, extensions-boeing jne. Sinne kumppani ylläpitää ja puskee koodinsa.
• AICommerce huolehtii peruskonfiguraatiosta sekä resurssien alustamisesta, joten kumppani voi keskittyä vain bisneslogiikkaan.

Yhteinen domain ja CloudFront

• AI Commerce konfiguroi ympäristön siten, että loppuasiakkaan domainin (esim. boeing.com) taustalla on CloudFront, josta ohjataan pyynnöt API Gatewaylle ja edelleen Lambda-funktioille.
• Näin partnerien palvelut näyttäytyvät yhtenäisenä osana AICommercen järjestelmää, mutta toimivat kuitenkin fyysisesti erillisinä mikropalveluina.

3. Käyttökohteet: Milloin partneri tarvitsee omaa serveritöntä backendiä?

• ERP-integraatiot: Jos asiakkaalla on jo käytössä oleva ERP-järjestelmä, voidaan AI Commercen tilaukset tai tuotetiedot synkronoida sinne helposti oman Lambda-funktion kautta.
• Haku- ja suodatinpalvelut: Jos AI Commercen natiivi haku tai hakupartnerit eivät riitä, voi kumppani tuoda oman hakumoottorin (esim. Elasticsearch, Solr tms.) ja korvata tai laajentaa sillä AICommercen hakutoimintoja.
• Uudet ominaisuudet: Kumppani voi laajentaa tilaus-, asiakas- tai tuotekäsittelyä kustomoiduilla reitityksillä (webhookit, validoinnit, lisälogiikka) säilyttäen kuitenkin täyden yhteensopivuuden ydintietorakenteiden kanssa.

4. Hinnoittelu ja resurssirajoitukset

Lambda-funktioiden muistirajoitus

• Oletuksena rajoitamme Lambda-funktioiden muistin 2 GB:hen (2048 MB). Isommat tarpeet vaativat erikoishinnoittelua ja erillisen sopimuksen AI Commercen kanssa.

API Gateway -käytön rajoitukset

• Voimme asettaa rajoja kutsujen määrälle (esim. throttling, rate limit), jotta estetään ylikuormitus. Korkeammat kutsumäärät hoidetaan tapauskohtaisesti.

Kumppanin oma AWS-ympäristö

• Jos asiakas tarvitsee laajempaa hallintaa tai merkittävästi isompaa kapasiteettia, voidaan “alikäyttäjänä” luoda erillinen AWS-tili, josta on silti suora VPC-yhteys AI Commerceen.

5. Tekninen toteutus: Palvelittomat laajennukset käytännössä

Alla on esitetty esimerkinomainen projektirakenne extensions-clientName -nimiselle repositoriolle (vaihda clientName haluamaasi nimeen). Projektin tarkoituksena on tarjota yksi tai useampi Lambda-funktio API Gatewayn takana.

5.1 Runtimet

Tuemme uutta AWS Lambda -ympäristöä, johon voi valita useita eri runtimeja:

• .NET 8 (C#, F#, PowerShell)
• Java 21
• Node.js 22.x
• Python 3.13
• Ruby 3.3
• Amazon Linux 2023 (Go, Rust, C++, custom)

Lisäksi tuemme muita vielä AWS:n tarjoamia vanhempia runtimeja, kuten Java 8 - Amazon Linux 2, Node.js 18.x, Python 3.9, jne. Voit valita serverless-konfiguraatiossa minkä tahansa näistä runtimeista.

5.2 Projektin folderirakenne

Tyypillinen rakenne Java-esimerkillä (Node.js, Python, .NET vastaavat samankaltaista mallia, vain build-työkalut ja hakemistojen nimet vaihtelevat):

extensions-clientName/
 ├─ pom.xml                  # Maven-konfiguraatio (Java)
 ├─ serverless.yml           # Serverless Frameworkin pääkonfiguraatio
 └─ src/
     └─ main/
         └─ java/
             └─ com/
                 └─ clientName/
                     └─ Handler.java  # Päälogiikka

5.3 Asennus ja käyttöönotto

Kloonaa repositorio

git clone https://github.com/petrosoft-fi/extensions-clientName.git
cd extensions-clientName

Asenna tarvittavat työkalut

• AWS CLI (konfiguroi avaimet aws configure -komennolla).
• Node.js & npm (tai Yarn).
• Serverless Framework globaalisti:

npm install -g serverless

• Maven, jos kehität Javaa:

# Java-projekteissa
mvn clean package

• Muissa kielissä vastaavasti oma build-prosessi (npm, pip, dotnet build, jne.).

5.4 Muokkaa serverless.yml

• Aseta haluamasi runtime (java21, nodejs22.x tms.).
• Vaihda package.artifact osoittamaan buildattuun tiedostoon (esim. Java: target/extensions-clientName-1.0.0-shaded.jar).

Deployaa Serverless-ympäristöön

serverless deploy

• Tämä luo Lambda-funktion/funktiot, API Gatewayn reitit ja konfiguroi kaiken AWS:ään.

5.5 Testaa

• Kun deploy valmistuu, komentorivi näyttää API Gateway -endpointin.
• Lähetä testipyyntö cURLilla:

curl https://example.com/ext/your-endpoint

• Jos kaikki on kunnossa, saat HTTP 200 -vastauksen tai muun konfiguroidun paluukoodin.

6. Miksi tämä malli on hyödyllinen?

Partnerit saavat vapauden kehittää

• Koska heillä on omat GitHub-repot ja AWS CLI -oikeudet, he voivat lisätä uusia toiminnallisuuksia ja julkaista ne ilman, että AI Commercen ydintiimi joutuu jatkuvasti tekemään integraatioita.

Tietoturva ja hallinta pysyvät AI Commerce-tiimillä

• Vaikka partnerit voivat deployata koodia, AI Commerce säilyttää täyden pääsyn ja hallintaoikeuden infrastruktuuriin (VPC, IAM, RDS, jne.).
• Käyttöoikeudet on rajattu vain tarpeellisiin resursseihin.

Hyöty Composable Commerce -arkkitehtuurista

• Partneri voi korvata tai laajentaa AI Commercen ominaisuuksia itsenäisillä mikropalveluilla.
• Käyttökokemus pysyy yhtenäisenä, koska Sveltellä rakennettu käyttöliittymä ja AWS -pilvipalvelut piilottavat sisäisen hajautetun arkkitehtuurin.

Skaalautuvuus

• Lambda-funktiot skaalaavat automaattisesti AWS:n serverless-mallin mukaan, joten partnerien kasvavat liikennemäärät eivät kaada ydintä.

Kustannustehokkuus

• Maksat vain käytöstä: jos Lambda-funktioita ei kutsuta, niistä ei synny kustannuksia (pois lukien pieni tallennustila, jonka käyttö on kuitenkin käytännössä veloituksetonta).

7. Laajentaminen ja “ylikirjoitus”

Laajennukset: Kumppanit voivat lisätä uutta logiikkaa, esim. webhooks-rajapintoja tai täysin uuden reitityksen. Näin he voivat tuoda AI Commerceen ominaisuuksia, joita ytimessä ei ole.

Ylikirjoitus: Joissakin tapauksissa on mahdollista ohittaa AI Commercen natiivi reitti, kuten haku tai tuotesuodatus, suuntaamalla frontend suoraan kumppanin Lambda-rajapintaan. Tällöin puhutaan Composable Commerce -mallin äärimmäisestä joustavuudesta, missä frontend valitsee käytettävän mikroservicen.

8. Suosituksia isoille projekteille: ERP- ja tiimi-integraatiot

• Eri Lambda-funktio isoille projekteille
  • Jos projekti on laaja (kuten ERP-integraatio), on usein järkevää käyttää omaa Lambda-funktiota, jotta koodi pysyy selkeänä ja helpommin hallittavana.
• Useita pienempiä funktioita
  • Joskus taas on parempi jakaa iso toiminnallisuus pienempiin palasiin, jolloin kukin Lambda hoitaa yhden vastuualueen, esimerkiksi “ERPOrdersHandler”, “ERPProductsHandler” jne.
• GitHub-hakemistorakenne
  • Voitte säilyttää kaikki toiminnot yhdessä repositoriossa (esim. extensions-adidas/erp/…) tai useammassa, riippuen projektin koosta ja julkaisusyklistä.

9. Yhteenveto

AICommercen uusi serverless “Lamda” -ympäristö mahdollistaa kumppaneiden kehittää ja ylläpitää omaa mikropalvelukoodiaan saumattomasti AI Commercen ytimessä. Tämä tukee Composable Commerce -arkkitehtuuria, jossa jokainen osa-alue on erillinen, mutta silti turvallisesti ja tiiviisti kytketty AI Commercen pääpalveluihin:

• Nopea VPC-ympäristö takaa vähäisen latenssin.
• Yhdenmukainen domain-rakenne varmistaa, että loppukäyttäjän näkökulmasta kaikki toimii yhtenäisenä järjestelmänä.
• Partnerin omat AWS CLI -avaimet sekä GitHub-repot antavat joustoa ja omatoimisuutta.
• Rajatut resurssit (API Gateway -throttling, Lambda-muistirajoitukset) takaavat, että järjestelmä pysyy vakaan suorituskyvyn rajoissa.
• Mahdollisuus “ylikirjoittaa” tai laajentaa AICommercen natiiveja ominaisuuksia avaa ovet monimutkaistenkin integraatioiden toteuttamiseen.

Kiitos, että tutustuit tähän artikkeliin. Toivomme, että se tarjoaa selkeän käsityksen siitä, miten AI Commercea voi laajentaa ja räätälöidä serverittömässä ympäristössämme. Mikäli tarvitsette lisäohjeita, voitte ottaa yhteyttä suoraan AI Commercen tukitiimiin tai avata tiketin suoraan partnerirepositorion GitHub-projektissa. Onnea matkaan Composable Commerce -polullanne!