Olika integrationsuppgiftslägen

En uppgift genereras när data rör sig genom Alumio, och den hjälper till att spåra data i varje steg i integrationsprocessen. Den ger insikter om integrationens status, om den är framgångsrik, pågår, i kö, om den hoppar över eller om den har stött på fel. Förutom att mäta datautbyte inom Alumio fungerar Tasks alltså också som grund för övervakning och felsökning av integrationer.

Det är därför en av de första sakerna som Alumio instrumentpanel visar dig är realtidsstatusen för dina integrationsuppgifter. Förutom att visa dig det totala antalet uppgifter du har genererat, ger uppgiftsövervakaren på Alumios instrumentpanel en tydlig översikt över de olika stadierna i en uppgifts livscykel inom Alumio. Det bryter ner resan för data som flyttas från en applikation till en annan enligt följande:

• Ny uppgift: När data först importeras från en källa som en del av en rutt identifieras den som en ny uppgift.
• Bearbetningsuppgift: När Alumio börjar skicka dessa data till en målapp går uppgiften över till bearbetning.
• Avslutad uppgift: Om uppgiften är klar markeras den som färdig.
• Misslyckad uppgift: Om ett fel uppstår under datautbytet märks aktiviteten som misslyckad.
• Hoppade över uppgift: I scenarier som testning eller när vissa data behöver filtreras kan uppgifter medvetet hoppas över manuellt eller på ett automatiserat sätt.

Låt oss kort utforska hur var och en av dessa uppgiftsstatus är avgörande för hur Alumio iPaaS hjälper till att effektivisera och övervaka hela integrationsprocessen varje steg på vägen.

Ny uppgift:

För att integrera data mellan program måste du först samla in data från ett källprogram (System A) och sedan skicka dessa data till ett målprogram (System B). En ny uppgift genereras när Alumio framgångsrikt importerar data från System A, via en Inkommande konfiguration, inom en rutt.

När du ställer in denna Inkommande konfiguration låter Alumio dig definiera exakt vilka data som ska hämtas och hur ofta de ska hämtas. Behöver du hämta all tillgänglig data eller bara specifika delar av en dataenhet (t.ex. beställningar från en specifik region)? Ska dataformatet konverteras (t.ex. från XML till JSON)? Hur ofta ska data importeras - varje minut, timme, dag eller vecka? Alumio tillhandahåller Transformers för att modifiera och strukturera inkommande data och en schemaläggare för att avgöra när och hur ofta data ska hämtas. Detta säkerställer att du kan vara mycket specifik om vilken typ av data du vill skicka till målapplikationen.

Till exempel, när ett affärssystem integreras med både en e-handelsplattform och ett PIM-system, hämtar Alumio produktdata och skapar en ny uppgift och ställer den i kö för bearbetning. I det här skedet kan du filtrera specifika poster (t.ex. endast uppdaterade produkter), standardisera format (t.ex. konvertera valutor) och berika data (t.ex. lägga till saknade attribut). Detta gör att du först kan samla in och strukturera data inom Alumio innan du bestämmer dig för hur du ska omvandla den till olika destinationer. Du kan mappa produktkategorier på olika sätt för PIM-systemet medan du justerar prissättningsformaten för e-handelsplattformen — allt från samma nya uppgift.

Obs!: Om en inkommande konfiguration inte är konfigurerad inom en (aktiv) rutt skapas inte en ny uppgiftd.

Bearbetningsuppgifter:

När du skapar en utgående konfiguration och kör rutten i Alumio för att skicka data som du har hämtat från en källa (system A) till ett målprogram (system B), förvandlas en ny uppgift till en bearbetningsaktivitet.

Som tidigare nämnts är detta anledningen till att Alumio inte omedelbart skickar (exporterar) data som den hämtar in (importerar) via en inkommande konfiguration och köar den som en ny uppgift. Det är så att du kan välja var och hur du vill skicka dessa data genom att bygga en utgående konfiguration. Behöver du filtrera, ändra eller kartlägga formatet på de data du har importerat för att matcha målprogrammet? Eller vill du skicka data i partier varje minut, timme, vecka etc.? Alumio låter dig bestämma hur du vill omvandla och schemalägga dessa data som du har hämtat från System A innan du skickar ut dem till system B.

Enligt vårt tidigare exempel skapar schemaläggning av sändning av data som du har hämtat in från ERP-systemet till e-handelsplattformen en bearbetningsuppgift. En bearbetningsuppgift går in i kön i Alumio och gör sig redo att skicka data när den är schemalagd.
‍

Anmärkning: Alumio gör det också möjligt för användare att välja alternativet ”Real-time processing” när de bygger en rutt, i de fall där kritiska data måste integreras omedelbart. I det här fallet skapas en bearbetningsuppgift direkt i stället för en ny uppgift i det ögonblick som rutten körs, och den försöker omedelbart bli en färdig uppgift.
‍

Avslutade uppgifter:

En bearbetningsaktivitet blir en avslutad uppgift när datautbytet mellan källa- och målprogrammet har slutförts. Detta innebär att Alumio har skickat importerade data till målsystemet och att de omvandlings- eller schemaläggningsregler som du konfigurerat har tillämpats utan problem.

Om till exempel ERP-systemet framgångsrikt skickar produktuppdateringar till e-handelsplattformen och all data har tagits emot, bearbetats och lagrats korrekt, flyttas uppgiften från status Bearbetning till Färdig.

Misslyckade uppgifter:

En bearbetningsuppgift blir en misslyckad uppgift om något hindrar datautbytet från att behandlas framgångsrikt. Detta kan bero på en rad problem, till exempel:

• Målprogrammet (System B) är tillfälligt otillgängligt.
• Dataformatet matchar inte den förväntade strukturen i mottagningssystemet.
• Autentiserings- eller behörighetsfel som förhindrar datautbyte.

När en uppgift misslyckas tillhandahåller Alumio felloggar och felsökningsalternativ som hjälper dig att snabbt identifiera och lösa problemet. Du kan försöka igen uppgiften när problemet har åtgärdats och se till att inga data går förlorade.

Om ett affärssystem till exempel försöker skicka produktuppdateringar till ett e-handelssystem, men SKU-fältet saknas eller är felaktigt formaterat, kommer uppgiften att misslyckas och felinformationen loggas för granskning. Du kan sedan kontrollera loggarna för att identifiera och snabbt lösa felet och försöka igen uppgiften.
‍

Hoppade över uppgifter:

Det finns också en ”Hoppade uppgifter” i Alumio iPaaS som räknar de uppgifter som av olika skäl som testning eller fördefinierade filtreringsregler avsiktligt kringgås. En uppgift kategoriseras som ”Hoppade över” när Alumio upptäcker att data som behandlas inte behöver skickas till målsystemet. Detta händer när:

• Data finns redan i målsystemet och har inte ändrats.
• Integrationslogiken har villkor som avgör om data ska behandlas (t.ex. att bara skicka nya beställningar men hoppa över redan behandlade).
• Omformningsreglerna filtrerar bort specifika data innan de når den utgående konfigurationen.

Alumio låter dig manuellt hoppa över specifika data eller tillämpa regler för att automatiskt hoppa över specifika data i bulk. Låt oss till exempel säga att en ERP är inställd på att skicka produktuppdateringar till en e-handelsplattform var tionde minut, men inga ändringar har gjorts i produktdata sedan den senaste uppdateringen. Alumio kan känna igen detta och markera uppgiften som hoppad. Detta förhindrar onödig bearbetning. Detta hjälper till att optimera prestanda och undvika redundanta API-anrop.

Eftersom överhoppade data förblir lagrade i Alumio gör det också möjligt för Alumio iPaaS att fungera som ett cache-system. Detta innebär att om tidigare hoppade data blir relevanta senare, till exempel en beställning som flyttas från ”Väntande” till ”Betald”, kan du enkelt bearbeta den igen utan att behöva hämta den igen från källprogrammet. Detta förbättrar effektiviteten och minskar belastningen på anslutna system.

‍

Hur Alumio kan användas som cachningssystem

Alumio kan också användas som ett cache-system, där endast delta-versioner av data, eller endast uppdaterade eller nya versioner av data, kommer att skickas från en applikation till en annan.

Låt oss till exempel säga att vi regelbundet drar in tusen poster, vilket uppgår till tusentals produkter, från en applikation till en annan. Det är produktivt att bara skicka data för de produkter som har ett uppdaterat pris, lager, lager etc. till den andra applikationen, eller data för produkter som är helt nya och inte har registrerats i den andra applikationen ännu.

Med det här tillvägagångssättet kan du schemalägga en uppdatering varje minut och skicka bara en handfull uppgifter - till exempel tre, fem eller, vid topptider, kanske tjugo nya produktuppdateringar. Detta är mycket effektivare än att försöka skicka alla tusen poster varje minut. Genom att regelbundet kontrollera efter nya data och skicka endast dessa data säkerställer vi att vi inte slösar bort tid och resurser på att bearbeta överflödiga uppgifter. Om du behöver se de data som filtreras bort kan du kontrollera de loggar som Alumio hjälper till att underhålla för varje åtgärd och integration.
‍

Andra viktiga uppgiftsstatus inom Alumio

Utöver de primära uppgiftsstatusen som visas på instrumentpanelen hanterar Alumio även ytterligare uppgiftsstatus som spelar en avgörande roll för att säkerställa smidig databehandling. Dessa statusar är ”Försök igen”, ”Avvisad” och ”Väntar”, som hjälper till att automatisera felhantering, genomdriva datavalidering och ge manuell kontroll över specifika uppgifter vid behov.
‍

Försök igen:

Det är möjligt att du kan behöva bearbeta en uppgift om för att exportera data igen till målsystemet. Det kan bero på att uppgiften tidigare misslyckades på grund av ett konfigurationsproblem som sedan dess har åtgärdats, eller helt enkelt för att alla entiteter måste bearbetas om, även om de redan var markerade som Färdiga.

När alternativet ”Aktivera omförsök av misslyckade uppgifter” är aktiverat i en rutt, försöker Alumio automatiskt att ombehandla misslyckade uppgifter. Detta innebär att Alumio automatiskt försöker omarbeta uppgiften tills den antingen lyckas eller når den konfigurerade gränsen för försök igen. Den här funktionen hjälper till att återhämta sig från tillfälliga problem, till exempel kortvariga systemavbrott eller nätverksstörningar, utan att behöva manuellt ingripa. Om en uppgift fortsätter att misslyckas efter det maximala antalet försök på nytt kommer den att markeras som en Misslyckad uppgift och felinformationen loggas för felsökning.

Om du försöker om uppgifter manuellt ställs statusen för uppgifterna in på Nytt igen, så rutten kommer att bearbeta den till det utgående systemet i nästa körning. På sidan Uppgiftsöversikt kan du filtrera och välja att försöka om flera uppgifter samtidigt. Du kan också välja att välja en enda uppgift och försöka igen. På så sätt kan du bara försöka om en aktivitet som har statusen Färdig, Misslyckades eller Hoppade över.
‍

Avvisade uppgifter:

En uppgift kategoriseras som Avvisad när den inte uppfyller specifika systembegränsningar eller valideringsregler. Om till exempel en gräns på 1000 byte är inställd för entitetsdata och en uppgift överskrider denna tröskel kommer den att avvisas istället för att bearbetas. På samma sätt kan uppgifter med ogiltiga entitetsdata automatiskt avvisas för att förhindra att fel sprids genom integrationen. Orsaken till avvisningen registreras i Importeringsloggar på sidan Uppgiftsinformation, så att användare kan granska och åtgärda problemet innan de skickar in data igen.

‍

Väntande uppgifter:

I vissa fall kan användare konfigurera en rutt så att i stället för att en uppgift automatiskt markeras som Färdig eller Misslyckad efter bearbetning, går den in i ”Väntar” -statusen. Detta ger användarna möjlighet att manuellt granska uppgiften och bestämma dess resultat baserat på den information som finns tillgänglig i loggarna. Om en uppgift är i ”Väntar” -statusen kan användarna bestämma om den ska markeras som Färdig eller Misslyckad genom att använda menyn ”Åtgärder”. Massåtgärder kan också tillämpas för att uppdatera flera väntande uppgifter samtidigt. Denna status är särskilt användbar i fall där manuell validering krävs innan integrationsprocessen slutförs.

Nu när vi har förstått de olika typerna av uppgifter inom Alumio, låt oss utforska alla detaljer som en uppgift innehåller för att förstå hur den dessutom hjälper till att spåra, hantera och effektivisera integrationen i varje steg på vägen.