Vi presenterar Alumio Route Builder
Anslut, orkestrera och styr integrationer i stor skala från ett visuellt gränssnitt
En inloggad köpares eget pris efterfrågas av AS/400 medan Shopware-sidan laddas, så en företagskund ser den exakta siffran som deras konto alltid har haft snarare än en kopia som gjordes igår kväll.
På ett AS/400-system är en kunds pris vanligtvis utdata från ett program snarare än ett värde som finns i en tabell, eftersom årtionden av avtal, avbrott och undantag byggdes in i logiken istället för i data. Det gör det till något man kan be om och inte något man på ett förnuftigt sätt kan kopiera, och en Shopware-butik som kopierar det blir fel för de kunder som betyder mest. Så B2B-köpare ringer in beställningar som de kunde ha lagt online. Att koppla Shopware och IBM AS/400 ställer frågan i det ögonblick då sidan behöver ett svar, där Alumio fungerar som en API-gateway mellan de två.
DATA SOM FLÖDAR MELLAN DEM
Kundkonton
Kontospecifika priser
Lagerpositioner
Försäljningsorder
Orderbekräftelser
Produktregister
Priset som en inloggad Shopware-kund ser begärs från AS/400 när sidan laddas, så ett avtal som bara finns i ett program är fortfarande vad köparen debiteras.
Ingenting behöver extraheras och plattas ut i en prislista, vilket är viktigt eftersom undantagen som gör ett handelspris korrekt är det första ett extrakt förlorar.
En köpare som alltid har ringt för att kontrollera sitt pris kan lägga beställningen själv, eftersom butiken svarar med samma nummer som säljkontoret skulle ha läst upp.
AS/400 stannar kvar där prissättningen ligger, och Alumio når den via det gränssnitt som den gör tillgängligt, så butiken får en funktion utan att det äldre systemet ändras.
När en inloggad Shopware-kund tittar på en produkt begär Alumio priset för det kontot från AS/400 och returnerar det till butiken i samma begäran, så att sidan visar ett livesvar snarare än ett cachat svar.
En inköpare slutför utcheckningen i Shopware och ordern skrivs in i de AS/400-register som säljkontoret redan arbetar utifrån, så en onlineorder och en telefonorder anländer till samma plats och hanteras på samma sätt.
Tillgängligheten kontrolleras mot AS/400-posterna innan beställningen accepteras i kassan, så en kund som har fått ett pris får inte veta två dagar senare att lagret bakom det gick till någon annan.
Alumio fungerar som en central integrationsplattform mellan försäljningskanaler och logistiksystem. Order dirigeras, transformeras och valideras, samtidigt som statusuppdateringar skickas tillbaka till varje kanal.
Autentisera dina system med Alumios färdiga kopplingar. Välj bland över 200 kopplingspaket i vår marketplace, utöver obegränsade anpassade integrationer.
Definiera hur datafält mappas mellan system i ett visuellt gränssnitt. Justera format, berika poster och tillämpa affärslogik – helt utan behov av anpassad kod.
Konfigurera flöden så att de körs i realtid baserat på händelser, enligt ett schema eller både och. Minska manuell datainmatning och låt Alumio hantera förflyttning och transformering mellan system.
.svg){kind=icon}
När din första integration är live, ansluter du enkelt ditt ERP, PIM, WMS eller CRM till samma hubb. Befintliga flöden fortsätter att köras. Ingen ombyggnad från grunden krävs.
Det en företagskund måste göra innan de kan köpa överhuvudtaget är frågan som öppnar upp nästa kontakt. Godkända konton är en förutsättning här, och när beställningar väl anländer via Shopware är det kunderna ber om härnäst att få veta när varorna skickades, så en orderstatusaviseringstjänst är det vanliga tillägget. Alumio har den kontakten parallellt med denna, så en leverans som registreras i AS/400 når köparen utan att säljkontoret skickar ett e-postmeddelande.
Den här är en liveförfrågan snarare än en synkronisering, vilket är hela poängen. Alumio fungerar som en API-gateway mellan Shopware och AS/400, så en prisförfrågan som görs medan en sida laddas besvaras i den förfrågan och ingenting lagras däremellan. Lager- och produktdata kan fortfarande köras enligt ett schema där ett livesvar inte behövs, och att välja vilka flöden som är live och vilka som är schemalagda är ett konfigurationsbeslut.
Nej, och att fråga är en mindre byggprocess än att kopiera. Att hålla IBM AS/400-kontoprissättning inuti Shopware skulle innebära att man förvandlar programlogik till en tabell, håller den tabellen aktuell och har fel varje gång ett avtal ändras. Databaskopplingar finns med på listan över vad Alumio publicerar som stödt, så en plattform utan eget API är fortfarande tillgänglig, och arbetet formar en begäran och ett svar i gränssnittet.
Det kan det, och att fråga är rätt tillvägagångssätt snarare än en kompromiss. IBM AS/400 är en plattform snarare än en applikation, så vad den innehåller och vad den exponerar är vad programmen som skrivits för den verksamheten var byggda för att göra, och kontoprissättning är vanligtvis ett av dessa program. Alumio når den via det gränssnitt som den gör tillgängligt och skickar svaret till Shopware medan sidan fortfarande laddas, så avtalet behöver aldrig dupliceras.
En förfrågan som aldrig kommer tillbaka är ett annat fel än ett meddelande som aldrig skickats, eftersom en kund väntar på just detta. Shopware-butiken är konfigurerad att återgå till ett tillstånd du väljer, utan att visa något pris och en offertförfrågan-rutt snarare än en felaktig siffra. Alumio övervakar varje IBM AS/400-förfrågan i realtid och loggar svaret, så en timeout-avisering skickas omedelbart med kontot och orsaken, försöken körs där de är konfigurerade och ingenting prissätts i tysthet från en inaktuell kopia.
Prata med en integrationsspecialist på Alumio. Vi tar fram rätt arkitektur för dina system, i rätt skala, så att din verksamhet förblir stabil genom alla förändringar.
.svg)
