Maak kennis met de Alumio Route Builder
Verbind, orkestreer en beheer nu integraties op grote schaal vanuit één visuele interface
Het team dat dit consumeert, vraagt om wat het nodig heeft in plaats van te ontvangen wat iemand anders heeft besloten te publiceren. Dat is het verschil tussen vragen en ontvangen, en de hele reden waarom we het doen.
Een team dat iets bouwt bovenop de bestaande business wil één centrale plek om vragen te stellen. Meestal krijgen ze een lijst met endpoints, die elk een vaste structuur retourneren die is bepaald door de ontwikkelaar. Zo doet de app vier aanroepen om één scherm samen te stellen en een vijfde omdat de eerste vier de prijs niet bevatten. SAP is nooit ontworpen om op die manier vragen te beantwoorden, wat niemands schuld is en ieders probleem. Door SAP en GraphQL te koppelen, ontstaat er één centrale plek waar vragen gesteld kunnen worden, waardoor het team dat de applicatie gebruikt kan beschrijven wat het nodig heeft in plaats van te moeten uitzoeken wat er beschikbaar is.
DATA DIE TUSSEN SYSTEMEN STROOMT
Klanten
Materialen
Prijzen
Voorraad
Bestellingen
Bestelstatus
Een gebruikersteam vraagt slechts één keer om wat een scherm nodig heeft, in plaats van het samen te stellen uit vier afzonderlijke aanroepen, wat de oorzaak is van de meeste latentie in dit soort applicaties.
Een tweede aanvraag betekent niet per se een tweede arrangement, omdat er om een andere vorm van hetzelfde product wordt gevraagd en niet om iets dat er speciaal voor gemaakt moet worden.
De mate waarin een enkele vraag doorwerkt in SAP is bewust vastgesteld, zodat een ogenschijnlijk eenvoudig verzoek niet ongemerkt een kostbaar verzoek wordt dat pas aan het einde van het kwartaal opvalt.
Wat SAP beheert hoeft niet te worden geherstructureerd ten behoeve van een applicatie, omdat de vertaling plaatsvindt tussen de twee en niet binnen een van beide.
Wanneer een applicatie een klant, diens prijzen en openstaande bestellingen nodig heeft, vraagt en ontvangt de applicatie deze gegevens gezamenlijk. Op die manier wordt het scherm opgebouwd vanuit één uitwisseling in plaats van vanuit vier afzonderlijke uitwisselingen.
Wanneer een ander team aan iets begint te bouwen, vraagt het om de gewenste vorm in plaats van te wachten tot iemand anders er een publiceert. Daardoor kost de tweede applicatie slechts een fractie van wat de eerste kostte.
Wanneer een verzoek meer vraagt dan nodig is, is het de door u ingestelde scope die het antwoord geeft, en niet het verzoek zelf. Zo kan een ogenschijnlijk eenvoudige vraag niet ongemerkt uitgroeien tot een vraag die de helft van het ERP-systeem meesleept.
Alumio fungeert als een beheerde integratie-backbone tussen verkoopkanalen en fulfillment-systemen. Orders worden gerouteerd, getransformeerd en gevalideerd, terwijl statusupdates naar elk kanaal worden teruggestuurd.
Authenticeer je systemen met de kant-en-klare connectors van Alumio. Kies uit meer dan 200 connector-pakketten in de marketplace, plus onbeperkte aangepaste integraties.
Bepaal in een visuele interface hoe datavelden tussen systemen worden gekoppeld. Pas formaten aan, verrijk records en pas bedrijfslogica toe, zonder dat er maatwerkcode nodig is.
Configureer flows zodat ze in real-time, op basis van events, volgens een schema of beide worden uitgevoerd. Verminder handmatige gegevensinvoer en laat Alumio de verplaatsing en transformatie tussen systemen afhandelen.
.svg){kind=icon}
Zodra je eerste integratie live is, kun je je ERP, PIM, WMS of CRM eenvoudig op dezelfde hub aansluiten. Bestaande flows blijven gewoon draaien. Je hoeft niets opnieuw op te bouwen.
De applicaties die deze vragen stellen, willen zelden alleen het ERP-systeem raadplegen. Een scherm met een klantgegevens laat meestal zien wat de klant heeft gekocht, wat er is verzonden en waarover de klant voor het laatst contact heeft opgenomen met de klantenservice. Dat zijn drie systemen. Alumio bewaart die verbindingen naast dit systeem, waardoor één vraag vanuit meerdere bronnen beantwoord kan worden zonder dat het team dat de vraag gebruikt weet waar elk onderdeel vandaan komt.
Ja, en de aanpak maakt dit anders dan de rest: de consument stelt de vraag en Alumio geeft antwoord, in plaats van dat er iets op een vast tijdstip wordt gepubliceerd en later wordt opgehaald. Niets wordt ergens naartoe gepusht. Wat een vraag kan omvatten en hoe diepgaand, is wat je configureert, en wat er beantwoord kan worden, hangt af van wat SAP daarvoor beschikbaar stelt.
Nee, en de tweede verbinding kost een fractie van de eerste, omdat de vormen en de reikwijdte al vastgelegd zijn tegen de tijd dat het volgende team arriveert. Dat geldt niet voor een eindpunt dat iemand per gebruiker bouwt, en daarom worden ze in portefeuilles opgeslagen. Waar een waarde geassembleerd moet worden in plaats van gelezen, doet de Code Transformer dat.
Het is smaller dan een ontwikkelaar zou willen en breder dan een ERP-team zou verkiezen, en daarom moet het vastgelegd worden in plaats van overgelaten te worden aan degene die het toevallig schrijft. Een vraag die een klant bij elke bestelling ooit krijgt, is makkelijk te formuleren, maar duur om te beantwoorden. Door de scope op één plek vast te leggen, wordt de limiet een beslissing in plaats van iets dat onder druk wordt ontdekt.
Wat misleidend kan zijn, is een vraag die minder informatie bevat dan gevraagd, omdat de applicatie de gegevens weergeeft en het scherm er daardoor leger uitziet dan zou moeten. Alumio geeft aan tot welk bereik het antwoord beperkt was, waardoor een gedeeltelijk antwoord als zodanig wordt weergegeven. Elke uitwisseling wordt live gemonitord en vastgelegd met de inhoud ervan. Bij een weigering wordt een melding met de reden weergegeven, indien geconfigureerd worden herhaalpogingen uitgevoerd en gaat er niets ongemerkt verloren.
Spreek met een Alumio-integratiespecialist. Wij brengen de juiste architectuur voor jouw systemen in kaart, op de juiste schaal, zodat je bedrijfsactiviteiten bij elke verandering betrouwbaar blijven.
.svg)
