Vi presenterar Alumio Route Builder
Anslut, orkestrera och styr integrationer i stor skala från ett visuellt gränssnitt
Teamet som konsumerar detta ber om vad det behöver snarare än att ta emot vad någon bestämt sig för att publicera, vilket är skillnaden mellan att fråga och att bli skickad, och hela anledningen till att göra det.
Ett team som bygger upp något ovanpå verksamheten vill ha en enda plats att ställa frågor på. Det som vanligtvis ges är en lista med slutpunkter, där var och en returnerar en fast form som bestämts av den som byggde den, så appen gör fyra anrop för att sätta ihop en skärm och ett femte eftersom de första fyra inte inkluderade priset. SAP designades aldrig för att få frågor på det sättet, vilket inte är någons fel och allas problem. Att koppla samman SAP och GraphQL ger en enda plats att fråga framför sig, så att det konsumerande teamet beskriver vad det behöver snarare än att lära sig vad som finns tillgängligt.
DATA SOM FLÖDAR MELLAN DEM
Kunder
Material
Priser
Lager
Ordrar
Orderstatus
Ett konsumerande team frågar en enda gång efter vad en skärm behöver istället för att sätta ihop den från fyra separata anrop, vilket är därifrån den mesta latensen i dessa applikationer kommer.
En andra tillämpning betyder inte ett andra arrangemang, eftersom det efterfrågar en annan form av samma sak snarare än att behöva något som byggs speciellt för det.
Hur långt en enskild fråga får nå in i SAP bestäms medvetet, så att en bekväm förfrågan inte i hemlighet blir en dyr sådan som någon märker i slutet av kvartalet.
Det som SAP lagrar behöver inte omorganiseras till förmån för en applikation, eftersom översättningen sker mellan de två snarare än inuti någon av dem.
När en applikation behöver en kund, deras priser och deras öppna ordrar, frågar den efter dessa tillsammans och tar emot dem tillsammans, så skärmen byggs upp från en börs istället för fyra som måste sammanfogas.
När ett annat team börjar bygga något, frågar de efter den form de behöver snarare än att vänta på att någon ska publicera något åt dem, så den andra applikationen kostar en liten bråkdel av vad den första gjorde.
När en förfrågan efterfrågar mer än den borde, är det den omfattning du anger som svarar snarare än själva förfrågan, så en enda bekväm fråga kan inte i tysthet förvandlas till en som drar med sig halva ERP-systemet.
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.
Applikationer som ställer dessa frågor vill sällan bara ha ERP-systemet. En skärm som visar en kund vill vanligtvis ha vad de köpt, vad de fick skickat och vad de senast frågade support om, och det är tre system. Alumio har dessa kopplingar tillsammans med detta, så en fråga kan besvaras från mer än ett ställe utan att det konsumerande teamet vet var varje del kommer ifrån.
Ja, och riktningen är det som skiljer detta från resten: konsumenten frågar och Alumio svarar, snarare än att något publiceras på en timer och samlas in senare. Ingenting skjuts någonstans. Vad en fråga kan sträcka sig till, och hur djupt, är vad du konfigurerar, och vad som kan besvaras överhuvudtaget är vad SAP exponerar för den.
Nej, och den andra anslutningen kostar en bråkdel av den första, eftersom formerna och omfattningarna redan är överenskomna när nästa team anländer. Det gäller inte för en slutpunkt som någon bygger per konsument, vilket är anledningen till att fastigheter ackumulerar dem. Där ett värde måste samlas ihop snarare än läsas, monterar kodtransformatorn det.
Smalare än en utvecklare skulle önska och bredare än ett ERP-team skulle föredra, vilket är anledningen till att det måste avgöras snarare än att lämnas till den som råkar skriva. En fråga som tilltalar en kund med varje beställning de någonsin lagt är lätt att skriva och dyr att besvara. Att sätta omfattningen på ett ställe innebär att gränsen är ett beslut snarare än något som upptäcks under belastning.
Den som vilseleder är en fråga som besvaras med mindre än vad som efterfrågats, eftersom applikationen renderas och skärmen helt enkelt ser tommare ut än den borde. Alumio anger det omfång som svaret var begränsat till, så ett partiellt svar syns som ett. Varje utbyte övervakas live och loggas med vad det innehöll, ett avslag meddelar med orsaken, försök körs där det är konfigurerat och ingenting går förlorat i tysthet.
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)
