Alumio
Arkitektur & Säkerhet
Hur fungerar Alumio integrationsplattform?
Alumio är en molnbaserad, lågkodad ”Integration Platform as a Service” (iPaaS). Alumio är en API-ledd lösning och hjälper till att ansluta flera system, programvara, applikationer och datakällor — i lokala miljöer och molnmiljöer.
Som en lågkodslösning erbjuder Alumio ett användarvänligt gränssnitt för både utvecklare och företagsanvändare för att skapa, övervaka och hantera alla integrationer i ett visuellt gränssnitt: utan anpassad kod och med enkla klick-och-konfigurationsalternativ. Alumio presenterar också utvecklarvänliga funktioner för att flexibelt kartlägga och omvandla data, automatisera komplexa arbetsflöden, hantera kantfall och implementera (eller till och med bygga) anslutningspaket för att bygga snabbare anslutningar och anpassade integrationer.
Alumio integrationsplattform är byggd för att hjälpa företag att utveckla, styra och organisera säkra IT-ekosystem på ett skalbart sätt genom att centralisera all integration och data på ett dedikerat molnutrymme och tillhandahålla infrastruktur för en enda hyresgäst. Det hjälper till att synkronisera data över alla integrerade system, förhindrar datasilor och minskar dupliceringsfel. Alumio tillhandahåller datasäkerhet som ständigt förbättras och uppdateras och garanterar minimalt stillestånd och är utrustad med återaktiveringsprocedurer, cachelagring och buffertfunktioner för att säkerställa affärskontinuitet under alla tider.
Även om allt ovanstående kan vara tillräckligt för att förklara Alumio ur en affärsmässig synvinkel, är det viktigt för tekniska proffs att utforska arkitekturen som Alumio bygger på, för att förstå hur den verkligen fungerar.
Vad omfattar Alumio arkitektur och säkerhetsinfrastruktur?
För att ge en djupgående förståelse för vad som gör Alumio low-code integrationsplattform till en flexibel, skalbar och framtidssäker lösning ger detta white paper en teknisk djupdykning i:
Alumio-arkitekturen
Alumio-plattformens säkerhet
Alumio-infrastrukturen
Alumio prestandafunktioner
1. Alumio-arkitekturen
Upptäck hur vår framtidssäkra integrationsplattform fungerar
Alumio är utformat för att vara nästa generations API-driven företags-iPaaS (integration Platform as a Service) som hjälper till att skapa, övervaka och hantera framtidssäkra integrationer och IT-ekosystem. För att uppnå och förkroppsliga denna vision följer det arkitektoniska tillvägagångssättet bakom Alumio-plattformen följande designprinciper:
Beroendeinjektion
Frikopplad arkitektur
PHP-FIKON
Sexkantig design
1.1 Integrationsgränssnittet
Alumios användarvänliga webbgränssnitt är utvecklat i React och är frikopplat från backend. Detta gör det möjligt för front-end-utveckling att vara mestadels oberoende av backend-utvecklingen inom plattformen. Användargränssnittet körs lokalt i användarens webbläsare och kommunicerar direkt till backend via OpenAPI via HTTPS. Användargränssnittet implementerar autentiseringen som erbjuds av backend och läser konfiguration, (UI) scheman etc. från backend.
Separera affärslogik för användargränssnittet och backend”
Alumios användargränssnitt tolkar data som skickas av backend och formaterar den i vyer, formulär, valideringar etc. All data som utbyts mellan användargränssnittet och backend formateras med JSON.
1.2 Beroendeinjektion (DI)
I traditionell mjukvaruutveckling används beroendeinjektion för att separera problem och användning av objekt. Alumio tillämpar beroendeinjektionsmetoden vid utveckling och/eller konfiguration av plattformsspecifika komponenter (HTTP/SOAP/databas/filsystemklienter, abonnenter, transformatorer, utgivare etc.). Detta gör det möjligt att återanvända konfigurationen utan att orsaka hinder i programvaran.
Alumio Dependency Injection säkerställer att konfigurationen kan optimeras”
Praktiskt taget innebär detta att till exempel en HTTP-klient kan konfigureras för många olika anslutningar, oberoende av om de hämtar eller skickar data. Beroendeinjektionen hjälper till att minska konfigurationen och underhållet som krävs för ett Alumio-projekt.
1.3 Aspektorienterad programmering (AOP)
Alumio implementerar AOP (Aspect-Oriented Programming), vilket innebär att det skiljer olika typer av affärslogik från varandra. Loggning av applikationsbehandling implementeras automatiskt på grund av AOP, vilket innebär att varje klient, transformator, och andra objekt kan ha loggning aktiverad utan att behöva utveckla en loggningsfunktion inom dessa objekt. AOP-punktsnitten är också tillgängliga för slutanvändare av Alumio, som sedan kan lägga till DI-plugins till de medföljande punktsnitten.
1.4 Konfiguration av integrationer
Alumio har flera konfigurationstyper som beskrivs nedan, nämligen:
Konfiguration av fjärrsystemgränssnitt
Integrationsspecifik konfiguration
Allmän konfiguration
1.5 Konfiguration för gränssnitt med fjärrsystem
Alumio erbjuder flera generiska klientkonfigurationsalternativ för gränssnitt med fjärrsystem.
Konfiguration av fjärrsystemgränssnitt
Konfigurera HTTP-klienter och använd dem för gränssnitt med HTTP-slutpunkter med HTTP-kompatibla metoder. Förfrågningar kan utökas till att innehålla post-data. Autentiseringsmetoder som OAuth 2.0 kan konfigureras på en HTTP-klient med DI.
PDO
Konfigurera databasklienter som sträcker sig från MySQL till Oracle för att hämta och posta databasdata, utföra lagrade procedurer etc.
SOAP
Konfigurera klienter för att ansluta till en SOAP-tjänst för att hämta och publicera data med hjälp av allmänt tillgängliga förfrågningsmetoder. Alumio erbjuder en lösning för att anpassa sig till de inneboende skillnaderna mellan SOAP-tjänster, som att lägga till ett anpassat autentiseringshölje eller ändra meddelandestrukturen.
Filsystem
Konfigurera filsystem för att läsa och skriva filer på tjänster som FTP, SFTP, AWS S3, HTTP, etc. Filsysteminteraktioner utförs statslöst.
1.6 Konfiguration för att upprätthålla integrationer
Integrationer mellan fjärrsystem upprätthålls med minst en rutt, bestående av en inkommande konfiguration och en utgående konfiguration. Integrationer kan ytterligare utökas med hjälp av transformatorer, som kan tillämpas på rutter, inkommande konfigurationer och utgående konfigurationer. Elementen beskrivs i detalj nedan:
Konfiguration av fjärrsystemgränssnitt
Inkommande konfiguration
En inkommande konfiguration använder fjärrsystemgränssnittskonfiguration (SOAP, REST, FTP, etc.) för att producera data för nästa del (er) av rutten/rutterna de är konfigurerade för. En Inkommande konfiguration kan ha transformatorer anslutna till dem för att manipulera de producerade data innan data skickas vidare.
Obs! I detta skede kan alla utländska filformat (XML, CSV, EDI) konverteras till JSON, eftersom Alumio arbetar med JSON-schemat.
Det är möjligt att använda en enda inkommande konfiguration i flera rutter, vilket möjliggör ett effektivare IT-landskap genom att ta emot data en gång och skicka dem till flera fjärrsystem efteråt.
Utgående konfiguration
Utgående konfigurationer kan ha transformatorer anslutna till dem för att manipulera mottagna data innan data skickas till fjärrsystem.
Obs! I detta skede kan JSON-data konverteras igen till andra filformat (XML, CSV, EDI etc.)
Transformatorkonfiguration
Transformation tillåter dataval/reduktion, översättning/kartläggning, kodning, beräkning, sortering/ordning, sammanslagning/sammanfogning/sökning från andra källor, aggregering, generering av surrogatnycklar, transponering/svängning av matris-/objektnycklar och värden och validering.
Transformatorer kan också användas för att filtrera bort hela datapunkter som produceras av inkommande konfigurationer, vilket förhindrar onödiga köobjekt.
1.7 Generell konfiguration
Integrationer mellan fjärrsystem upprätthålls med minst en rutt, bestående av en inkommande konfiguration och en utgående konfiguration. Integrationer kan ytterligare utökas med hjälp av transformatorer, som kan tillämpas på rutter, inkommande konfigurationer och utgående konfigurationer. Elementen beskrivs i detalj nedan:
Miljövariabler
Förvaring
Konfigurera databasklienter som sträcker sig från MySQL till Oracle för att hämta och posta databasdata, utföra lagrade procedurer etc.
1.8 Kö
All data som kommer in på plattformen och är beredd att behandlas av en utgående konfiguration blir tillgänglig i kön. Dessa köobjekt säkerställer att konfigurerade rutter kan inspekteras och visar aktivitetsstatus för att visa vilket arbete som har utförts och vad som inte har gjorts.
Det finns flera sätt för ett köobjekt att visas: schemalagda inkommande konfigurationer, webhook-samtal till plattformen, och proxy-förfrågningar via plattformen. Många av dessa är i realtid eller kan konfigureras som sådana. Varje köobjekt innehåller konfigurationsdata: var data härstammar från och vart de går.
Köobjekten visar också de data som är anslutna till dem. Slutligen visar köobjekten vilken loggning som har gjorts på den inkommande sidan och på den utgående sidan. Dessa loggar kan innehålla fel och ge åtkomst till felsökningsinformation som HTTP-fel.
1.9 Loggning
Alumio loggar all data och händelser under behandlingen av inkommande och utgående data. Känsliga data som API-lösenord filtreras automatiskt bort från loggdata och krypterade miljövariabler. Loggdata samlas in och synkroniseras till en elastisk stack. Logginformationen visas för varje uppgift som skapats och varje prenumerera/publiceringsåtgärd i Alumio.
Utlösare kan skapas i den elastiska stacken baserat på loggdata. Detta kan användas som övervakning. Till exempel kan en varning skickas när ett antal av flera uppgifter misslyckas inom en enda timme.
1.10 Övervakning
Konfigurera utlösare för att uppdatera underhållsansvariga om integreringarnas hälsa, om uppgifter (köobjekt) fastnar, misslyckas med att publicera och så vidare. Det är möjligt att få Alumio övervakningsmeddelanden via e-post.
1.11 Processor
De flesta integrationer körs i två separata processer, en för inkommande data och en annan för att bearbeta data. Bearbetningen startas vanligtvis med en schemaläggare, annars startas den som en del av en realtidsåtgärd på grund av konfigurationsinställningar, som sedan körs tillsammans med processen för inkommande data.
Processorn är ett konfigurerbart element som gör det möjligt för plattformen att ställa in det maximala antalet uppgifter (köobjekt) som ska behandlas för en given rutt. Genom att ställa in ett maximalt antal uppgifter kan plattformen förhindra överbelastning av mottagande fjärrsystem. Detta säkerställer att de viktigaste integrationerna fortsätter att fungera medan andra integrationer väntar.
1.12 Applikationslagring
Alumio använder Elastic Stack och MySQL för att lagra applikationsdata och loggar. Loggarna som produceras under exekveringen av Alumio skickas till Elastic Stack och indexeras där för att säkerställa att loggar snabbt är tillgängliga från Alumio-gränssnittet. Tack vare AOP är dessa loggar mycket granulära och kan justeras när plattformen utvecklas.
Konfiguration, miljövariabler, uppgifter och användare lagras i MySQL. Allteftersom Alumio utvecklas upprätthålls MySQL-datastrukturerna med migreringar för att möjliggöra uppgradering av befintliga projekt till den senaste versionen av plattformen.
1.13 Bearbetningsanslutning
Utlösta inkommande anslutningar (Webhooks)
Webhooks tillåter system att skicka automatiska meddelanden eller information till Alumio. Det är ett kraftfullt sätt att automatiskt skicka data från en app till en annan.
Transparenta realtidsanslutningar (HTTP Proxy)
Schemalagda inkommande anslutningar
Schemalagda/realtidsutgående anslutningar
1.14 Autentisering
Autentisering med Alumio API är säkrad med Google OAuth. När användare har skapats i Alumio kan de logga in på Alumo med flera olika metoder:
1. Google Microsoft-konto
2. Socialt konto (Företagskonton stöds inte)
3. Azure AD, SAML, Okta, ADFS, OpenID, LDAP, Google Arbetsyta (endast företagslicenser)
4. Registrera ett nytt Alumio-konto
För extra säkerhet krävs Multi-Factor Authentication (MFA) för att logga in på Alumio-miljön.
Som standard läggs en kunddomän till i kundens Alumio-instans. Användare med ett tilldelat Google-konto kommer automatiskt att etableras till plattformen. Konfigurationen avgör om användaren har skrivskyddad eller skapande och/eller redigeringsbehörighet.
1.15 JSON-schema
Alumio använder JSON-scheman för att erbjuda ett tydligt dataformat att kommunicera med. Scheman används för att bestämma hur användarinmatning ska se ut, hur konfigurationsobjekt ska definieras, hur formulär ska renderas etc. Dessa scheman ger ett tydligt och konsekvent applikationsgränssnitt.
1.16 Typer av dataenheter
Dataenheter för fördefinierade element standardiseras så mycket som möjligt. Detta innebär att Alumio har en mellanstandard för många datatyper (t.ex. beställningar, produkter, kreditnoteringar, personer etc.). Att ha dessa mellanliggande standarder minskar komplexiteten i gränssnitt med (delvis) kända system, vilket minskar de mutationer som behövs på givna data och den övergripande komplexiteten i att konfigurera dataflöden.
1.17 Symfony - Alumio utvecklingsramverk
Alumio-ramverket är utvecklat på Symfony, som erbjuder många out-of-the-box och generiska funktioner som har implementerats inom Alumio. Symfonys beroendeinjektion kopplar samman alla huvudkomponenter i Alumio.
Huvudsakliga Alumio-komponenter är i huvudsak de funktioner som kan utökas med hjälp av vårt modulsystem. Detta inkluderar komponenter som autentisering, Alumio beroendeinjektion, OpenAPI, loggning, inkommande, utgående och många fler. Symfony erbjuder också vanligare komponenter som ska implementeras som Doctrine.
Uppfinna inte hjulet på nytt: Alumio använder Symfony-bibliotek för generiska funktioner”
Om Symfony: Det är världens ledande ramverk med en stor uppsättning frikopplade och återanvändbara komponenter som några av de bästa applikationerna bygger på. Symfony Community består av över 600 000 utvecklare från mer än 120 länder som anammar och främjar bästa praxis, standardisering och interoperabilitet mellan applikationer. Symfony är allt som du kan förvänta dig av ett ramverk: hastighet, flexibilitet, återanvändbara komponenter etc.
1.18 OpenAPI/Swagger
Alumio avslöjar sina funktioner genom OpenAPI, den moderna API-definitionen med öppen standard. Varje åtgärd definieras och görs tillgänglig via detta API med tydliga scheman för att skicka och hämta data. Alla element som visas/redigeras i Alumio användargränssnitt analyseras via detta API. Även bearbetning av rutter kan utföras via API, som att köra en inkommande konfiguration och exportera data från en given rutt.
Ange din e-postadress för att fortsätta läsa den här sidan
2. Alumio-plattformens säkerhet
Upptäck de höga säkerhetsstandarderna för vår integrationsplattform
Vår integrationsplattform flyttar data från ett system till ett annat, vilket kan innehålla viktig information om ditt företag, ekonomirelaterade data och dina kunders personliga och identifierbara information (PII). Säkerheten för dina uppgifter måste säkerställas.
Säkerhet finns i vårt DNA och är inbäddad från teknisk nivå i varje Alumio-process. Säkerheten för vår produkt, infrastruktur och data är vår högsta prioritet. Vårt säkerhets- och riskhanteringsteam arbetar enligt branschstandarder för att säkerställa att dina data är säkra. För att säkerställa att vår efterlevnad och säkerhet uppfyller de högsta standarderna övervakar vi vår plattform i stor utsträckning. Vårt produktteam arbetar ständigt med att förbättra och uppdatera plattformen för att uppfylla de senaste säkerhetsstandarderna, för att ge våra kunddata bästa möjliga säkerhet.
2.1 Säkerhet genom design
Alumio integrationsplattform är byggd med bästa tekniska ramverk och säkra metoder för mjukvaruutveckling. Alla korrigeringar, nya funktioner och förbättringar släpps först efter flera rigorösa tester och en strikt granskningsprocess. Vårt testprogram består av automatiserad kodtestning avseende kodkvalitet, samt manuell testning där varje kodrad kontrolleras och testas av minst två äldre utvecklare.
Alumios ingenjörer utvecklar kärnapplikationen baserat på konceptet ”Security-by-Design”:
2.2 Överensstämmelse med säkerhetsstandarder
Alumio är stolt över sitt engagemang för att skydda känslig information. Som ett bevis på detta har Alumio genomgått en rigorös implementeringsprocess och uppnått överensstämmelse med ISO 27001, en internationellt erkänd standard för ledningssystem för informationssäkerhet. Denna standard innehåller bästa praxis och riktlinjer för att upprätta, implementera, underhålla och kontinuerligt förbättra hanteringssystem för informationssäkerhet för att säkerställa sekretess, integritet och tillgänglighet för information.
2.3 Tillgång till Alumio integrationsplattform
Tillgången förklaras:
Rollbaserad åtkomstkontroll (RBAC)
Våra anställda har åtkomst baserat på användarroller med begreppet minsta privilegium, så ingen åtkomst beviljas till en nivå som inte beskrivs som nödvändig i ”rollen”.
Säkerhet för fjärråtkomst
Fjärråtkomst till Alumio kodbas och infrastruktur är endast möjlig efter inloggning på företagets VPN. Logga in i Alumio-applikationen kan göras med en tvåfaktorsautentisering.
Vitlistning av IP-adresser
Åtkomst till Alumios kodbas och infrastruktur är endast möjlig efter inloggning på företagets VPN. Dessa IP-adresser är statiska och vitlistas av våra systemadministratörer.
Tillgång till leverantörssupport
Leverantörens åtkomst baseras på Amazon Web Services säkerhetsåtgärder.
Användarspårning
Alla användarinloggningsåtgärder loggas, som inloggnings-ID (användarnamn Fan-ID), datum/tid för senaste inloggning, plats för inloggning (t.ex.: IP-adress), enhetsidentifierare (t.ex. MAC-adress). Loggarna skjuts till en plats med ett särskilt åtkomstkrav under en period av 8 veckor.
Regelbundna åtkomstgranskningar
Alumio har en process på plats som säkerställer att regelbundna åtkomstgranskningar kommer att hållas. Dessa kommer att meddela chefer om problem med offboarding, vilket gör det möjligt för Alumio att uppdatera våra processer och åtgärda eventuella ändringar som krävs.
Hårddiskkryptering
Alumio-anställda är skyldiga att tillämpa hårddiskkryptering på sina lokala maskiner, vilket anges i integrationspolicyn för anställda.
Brandväggskonfiguration
Alumio-anställda är skyldiga att tillämpa brandväggskonfiguration på sina lokala maskiner, enligt introduktionspolicyn för anställda.
Anställda inom teknik, tjänster, support och drift (i princip alla som har tillgång till allt som anses vara säkerhetskänsligt) måste använda företagets VPN med multifaktorautentisering aktiverad, för att lagra och generera alla referenser som används för att utföra jobbfunktioner.
Ingenjörsanställda med tillgång till produktionssystem måste också genomgå olika nivåer av säkerhetsutbildning minst årligen. Alla våra anställda får alltid bara tillgång till det minimala antalet applikationer eller system som behövs för att utföra sina jobbfunktioner.
2.4 Säkerhet för nätverk och infrastruktur
Ansvarsområden:
Amazon Web Services ansvarar för:
Elastic ansvarar förAble för:
Amazon Web Services ansvarar för:
Alumio följer riktlinjerna och bästa praxis för följande säkerhetsstandarder:
2.5 Nätverk: datalagring och datahantering
All kommunikation från och till datacentret för Amazon Web Services och Alumio använder minst 256-bitars SSL kryptering och sker via HTTPS, port 443.
Standardinställningar:
Data i vila:
Data under transitering:
2.6 Datalagring och bearbetning
Alumio-integrationen har tre sätt att lagra data:
Loggning
Transformationsspår
Förvaring
2.7 Automatiserad kommunikation av data
Alumio överför automatiskt följande information till Amazon Web Services datacenter:
Online-status:
Utskick:
Spårningsinformation:
Uppdateringar av integrationsprocessen:
2.8 Användarinitierad kommunikation av data
På begäran av en behörig användare kommunicerar Alumios plattform följande till Alumios datacenter:
Information om utförandet av en integrationsprocess, inklusive total körtid, loggning för varje steg i processen och felmeddelanden om körningsfel. API-data eller uppgiftsrelaterade loggar (meddelanden via rutter = uppgifter) sparas i 2 veckor. Serverrelaterade loggar sparas i en månad. Båda kan konfigureras efter behov baserat på den köpta Alumio-utgåvan.
Alumio erbjuder möjligheten att tillhandahålla export av serverloggar. Alla auktoriserade användare kan exportera uppgiftsrelaterade loggar.
Alumio gör säkerhetskopior av följande:
När processer byggs för specifika kopplingar kan databasschemainformation överföras för att definiera fältmappningsregler. Inga faktiska data överförs.
2.9 Lokal datakommunikationssäkerhet
Inga inkommande brandväggsportar behöver vara öppna för att Alumio integrationsplattform ska kunna kommunicera med datacentret. Alumios integrationsgränssnitt initierar alltid anslutningen. Amazon Web Services datacenter skickar aldrig data automatiskt till Alumios integrationsplattform (eller privat värdlösning). När Alumio-funktionen initierar en anslutning använder den ett SSL-handslag för att autentisera datacentret innan data överförs. Alumio använder det digitala certifikat som skapas automatiskt vid registrering och autentisering.
3. Alumio-infrastrukturen
Utforska mer om vad som gör vår integrationsplattform skalbar, säker och framtidssäker
Alumio integrationsplattform är en molnbaserad lösning som levereras i en enda klientinfrastruktur i vår kundregion. Oavsett om det är Europa, Asien eller USA, erbjuder Alumio snabb, säker och kompatibel distribution av vår integrationsplattform. Alumio-licensmodellen inkluderar hosting/applikation (hantering) och uppdateringar. Alumio tillhandahåller nätverk, servrar, lagring, operativsystem (OS), databas och andra tjänster för att vara värd för konsumentens köpta Alumio-utgåva.
Värdinfrastruktur är en viktig aspekt som påverkar plattformens skalbarhet. Alumio levererar högpresterande hosting-infrastrukturer som är redo för global utrullning till små och medelstora företag och internationella företag.
3.1 Övervakning
Jämfört med ESB är iPaaS en molnbaserad plattform som använder relativt lätt arkitektur och inte behöver någon lokal installation. Medan både ESB och iPaaS specialiserar sig på att integrera äldre system, kan iPaaS flexibelt ansluta till många fler stora eller små SaaS, molnappar och datakällor, i både lokala och molnmiljöer.
Medan ESB implementerar en komplex meddelandearkitektur för att ansluta applikationer, använder iPaaS en API-first strategi. Detta hjälper iPaaS att bygga snabbare och mer flexibla integrationer, som enkelt kan modifieras eller genomgå dataomvandling, utan förlust av dataintegritet eller affärskontinuitet.
Dessutom, som tidigare nämnts, måste en ESB drivas av erfaren IT-personal som är noggrant utbildad och utbildad i att genomföra den. Däremot tillhandahåller iPaaS ett molnbaserat webbgränssnitt som både utvecklare och medborgaranvändare (CTO, projektledare, juniorutvecklare) kan samarbeta på distans för att utveckla, styra och orkestrera integrationer.
3.2 Säkerhetskopior
För att förhindra dataförlust är det nödvändigt att göra regelbundna säkerhetskopior. Till skillnad från många leverantörer väljer Alumio säkerhetskopior baserade på filbaserad säkerhetskopieringsteknik. Detta ger Alumio möjlighet att återställa till och med en enda fil. Det kan avsevärt minska återställningstiden och erbjuder mer komfort för utvecklare som letar efter specifika filer.
Alumio använder R1Soft, som är marknadsledande på marknaden för avancerad säkerhetskopieringsprogramvara. Som standard förutsätter säkerhetskopian 1 återställningspunkt, som kompletteras med ”ändringarna” från återställningsmomentet. Dessa säkerhetskopior görs utanför din molnmiljö och är främst avsedda att snabbt komma åt en fullständig kopia av din miljö i händelse av en olycka. Säkerhetskopian är en fullständig säkerhetskopia och kommer att skrivas varje natt till en NAS-server (Network Attached Storage) i nätverket, men utanför din molnmiljö. Denna säkerhetskopia kan användas om servern oväntat går sönder. Inom Alumios standardservicenivåer görs säkerhetskopieringen 1 gång per dag och lagras i 7 dagar.
Alumio kan återställa varje dag inom denna period. Dessutom är det möjligt att utöka och intensifiera säkerhetskopieringsschemat, skicka säkerhetskopiorna till din fysiska plats och skapa flera återställningspunkter.
3.3 Katastrofåterställning
Alumio ser till att återhämtning alltid kan ske vid allvarliga funktionsfel. Katastrofåterställning tar tid. Som ett resultat skiljer sig den tid som planeras per SLA-variant. Standard SLA anger att Alumio kräver mellan 1 - 2 timmar under kontorstid för att börja återställa dina data. Tiden som krävs för att återställa programmet i sin helhet beror på storleken på din applikation (antal GB) men är +/- 1 timme per 10 GB data som ska återställas. Alumio infrastrukturhantering förlitar sig också på Amazon Disaster Recovery och Elastic Disaster Recovery-policyn och förfarandena. Iness behov.
3.4 Distributionsregioner och strategi
När din instans av Alumio-plattformen distribueras väljer den en primär distributionsregion för ditt företag baserat på ditt val. Din primära distributionsregion innehåller alla dina Alumio-data och är där dina huvudsakliga organisationsprocesser äger rum. Detta gäller värdinfrastrukturen som levereras av Amazon Web Services och Elastic Stack.
3.5 Distribution i flera regioner
Alumio rekommenderar Enterprise-företag som en klusterlösning för en högpresterande infrastruktur som är redo för global utrullning.
Den högpresterande infrastrukturen är ett Kubernetes-baserat system för automatisering av distribution, skalning och hantering av containeriserade applikationer inom flera regioner.
3.6 Skalbarhet
Värdmässigt är det så skalbart som Amazon Web Services kan erbjuda. De funktioner som utvecklats i Alumio är utformade med skalbarhet i åtanke. All logik kan dock ersättas med anpassad logik för att förbättra prestanda och därmed skala upp.
Skalning kan göras enligt inställningar, och de kan ställas in per region (t.ex. ett land). Detta är dock troligtvis inte nödvändigt.
Att ha skalbarhet medför viss komplexitet när det gäller konfigurationen av Alumio-installationen. Annars är den enda begränsningen begränsningarna för hosting.
4. Alumio-prestandan
Säkerställa affärskontinuitet och hög drifttid för programvaruanslutning
Det finns flera viktiga aspekter av Alumio integrationsplattform som bidrar till att avsevärt förbättra dess prestanda, säkerhet och tillförlitlighet:
4.1 Robust lagrings- och kösystem
Datapaket som ”in-process data” lagras tillfälligt i vårt robusta kösystem, beroende på typ av transformation och valt Alumio-paket, till MySQL, Elastic, Apache spark, Google GCP eller Amazons Redshift.
De används för att garantera bearbetning i stor skala för alla enskilda sidor av data som överförs. Om något system går offline tillåter arkitekturen ovan att elegant pausa och återuppta flödesbehandlingsaktiviteter utan förlust av data.
4.2 Stora data
Alumio är byggd som en högpresterande integrationsplattform för att hjälpa externa applikationer att anslutas och hantera big data. Data omvandlas till mindre paket som kallas 'Alumio uppgifter'. Dessa kan flöda genom vårt system på ett skalbart sätt till externt anslutna applikationer via vårt API, som stöds av vår robusta kömekanism.
4.3 DevOps
Alumio har ett komplett DevOps-team som övervakar Alumio-plattformen dygnet runt. DevOps-teamet har människor på flera platser och varje teammedlem är fullt utrustad för att arbeta på distans eller från ett Alumio-kontor.
4.4. Använda kodstandarder
Alumios kärnteam har definierat en mjukvaruutvecklingsprocess för att säkerställa att Alumio upprätthåller skalbarhet, tillförlitlighet och är 100% tillgänglig. SDLC är den process som följs för varje Alumio mjukvara (komponent) projekt. Varje projekt består av en detaljerad plan som beskriver hur man utvecklar, underhåller, ersätter och ändrar eller förbättrar specifik programvara. Denna metod säkerställer kvaliteten på Alumio integrationsplattform.
Alumio utvecklar och förbättrar sina applikationer genom att använda sunda metoder för programvaruutveckling i livscykeln (SDLC) såsom:
Affärsresultatet för Alumio arkitektur och säkerhet
En nästa generations integrationsplattform för snabba, flexibla och framtidssäkra integrationer
Nu när vi har utforskat Alumios arkitektur, säkerhetsdesign, skalbar infrastruktur och prestandafördelar på djupet, låt oss sammanfatta hur allt detta går samman för att driva vad Alumios integrationsplattform erbjuder. Här är några av de viktigaste användningsfall och fördelar som Alumio iPaaS (integration Platform as a Service) är utformad för att ge:
Alla dataflöden i integrerade system görs synliga och tillgängliga på ett användarvänligt gränssnitt, vilket förhindrar problem med svarta lådor och möjliggör enkla konfigurationer.
Se till att data synkroniseras och bearbetas i realtid, omvandla data flexibelt och använd datamappning och routing för att minska duplicering och förbättra noggrannheten.
Ett robust övervaknings- och loggningssystem hjälper till att snabbt upptäcka och meddela integrationsfel och API-konflikter, vilket sparar kostnader och tid vid felsökning.
Minska manuellt arbete och datainmatning genom att automatisera processer som produktoptimering, anställning, fakturering och fakturering, lagerhantering, marknadsföring, kundsupport och mer.
Flytta och förena data från äldre system med ETL, migrera anpassade fält och anpassade objekt och implementera förkonfigurerade anslutningar för att integrera äldre system med molnappar.
Organisera alla integrationer och data från en intuitiv instrumentpanel. Lägg till eller ersätt programvaruintegrationer på ett smidigt sätt. Lås upp datasilos och öka plattformsresurserna när dina integrationer växer.
Anslut data och system för alla partners, leverantörer och kunder med hjälp av standardanpassade protokoll och format som JSON, Edifact, X12, CSV, XML, CxML.
Skapa datasjöar eller samla helt enkelt all data från olika anslutna system för att bli ett hyperlärande, ”digitalt först och datadrivet” företag.
Undvik driftstopp och säkerställ kontinuitet i verksamheten med cachelagringsfunktioner, databuffring och återaktiveringsprocedurer för dina integrationer och IT-ekosystem.
Centralisera alla dina data och anslutna system på ett säkert molnutrymme, få fullständig datakontroll och följ viktiga sekretesslagar som GDPR, SOC2, CCPA, FERPA, HIPAA och mer.
