Felsöka egen värd för integreringskörning

GÄLLER FÖR: Azure Data Factory Azure Synapse Analytics Microsoft Purview

I den här artikeln beskrivs vanliga felsökningsmetoder för lokalt installerad integrationskörning (IR) i Azure Data Factory- och Synapse-arbetsytor.

Samla in självhostade IR-loggar

Azure Data Factory och Azure Synapse Analytics

För misslyckade aktiviteter som körs på en lokalt installerad IR eller en delad IR stöder tjänsten visning och uppladdning av felloggar. Om du vill hämta felrapport-ID följer du anvisningarna här och anger sedan rapport-ID:t för att söka efter relaterade kända problem.

1. På sidan Övervaka för tjänstgränssnittet väljer du Pipelinekörningar.

2. Under Aktivitetskörningar går du till kolumnen Fel och väljer den markerade knappen för att visa aktivitetsloggarna, enligt följande skärmbild:

   • Azure Data Factory
   • Azure Synapse

   

   Aktivitetsloggarna visas för den misslyckade aktivitetskörningen.

   

3. Om du vill ha mer hjälp väljer du Skicka loggar.

   Fönstret Dela loggarna för den självhostade integration runtime (IR) med Microsoft öppnas.

   

4. Välj vilka loggar du vill skicka.

   • För en lokalt installerad IR kan du ladda upp loggar som är relaterade till den misslyckade aktiviteten eller alla loggar på den lokalt installerade IR-noden.
   • För en delad IR kan du bara ladda upp loggar som är relaterade till den misslyckade aktiviteten.

5. När loggarna laddas upp behåller du ett register över rapport-ID:t för senare användning om du behöver ytterligare hjälp med att lösa problemet.

   

Microsoft Purview

För misslyckade Microsoft Purview aktiviteter som körs på en lokalt installerad IR eller delad IR stöder tjänsten visning och uppladdning av felloggar från Windows Event Viewer.

Du kan söka efter eventuella fel som visas i felguiden nedan. För att få support- och felsökningsvägledning för SHIR-problem kan du behöva generera ett felrapport-ID och kontakta Microsofts support.

Följ dessa instruktioner för att generera felrapport-ID för Microsoft Support:

1. Innan du startar en genomsökning i Microsoft Purview styrningsportalen:

   1. Gå till den dator där den lokalt installerade integrationskörningen är installerad och öppna Windows Event Viewer.
   2. Rensa Windows Event Viewer loggarna i avsnittet Integration Runtime. Högerklicka på loggarna och välj alternativet Rensa loggar.
   3. Gå tillbaka till Microsoft Purview-styrningsportalen och starta genomsökningen.

2. När genomsökningen visar statusen Failed går du tillbaka till den virtuella SHIR-datorn eller datorn och uppdaterar loggboken i avsnittet Integration Runtime.

3. Aktivitetsloggarna visas för det misslyckade genomsökningsförsöket.

4. För att få ytterligare hjälp från Microsoft, välj Send Logs.

   Fönstret Dela loggarna från den egenvärdade integrationsmiljön (SHIR) med Microsoft öppnas.

   

5. Välj vilka loggar du vill skicka.

   • För en lokalt installerad IR kan du ladda upp loggar som är relaterade till den misslyckade aktiviteten eller alla loggar på den lokalt installerade IR-noden.
   • För en delad IR kan du bara ladda upp loggar som är relaterade till den misslyckade aktiviteten.

6. När loggarna laddas upp behåller du ett register över rapport-ID:t för senare användning om du behöver ytterligare hjälp med att lösa problemet.

   

Allmänt fel eller fel i lokalt installerad IR

Problem med slut på minne

• Symtom

  Ett OutOfMemoryException-fel (OOM) inträffar när du försöker köra en sökningsaktivitet med en länkad IR eller en lokalt installerad IR.

• Orsak

  En ny aktivitet kan leda till ett OOM-fel om IR-datorn har en tillfälligt hög minnesanvändning. Problemet kan orsakas av en stor mängd samtidig aktivitet, och felet beror på designen.

• Lösning

  Kontrollera resursanvändningen och samtidig aktivitetskörning på IR-noden. Justera den interna och utlösande tiden för aktivitetskörningar för att undvika för mycket körning på en enda IR-nod samtidigt.

Problem med gräns för samtidiga jobb

• Symtom

  När du försöker öka gränsen för samtidiga jobb från användargränssnittet låser sig processen i Uppdateringsstatus .

  Exempelscenario: Det maximala värdet för samtidiga jobb är för närvarande inställt på 24 och du vill öka antalet så att jobben kan köras snabbare. Det minsta värde som du kan ange är 3, och det högsta värdet är 32. Du ökar värdet från 24 till 32 och väljer sedan knappen Uppdatera . Processen fastnar i Uppdateringsstatus , enligt följande skärmbild. Du uppdaterar sidan men värdet visas fortfarande som 24. Den har inte uppdaterats till 32 som förväntat.

  

• Orsak

  Gränsen för antalet samtidiga jobb beror på datorns logikkärna och minne. Försök att ändra värdet nedåt till exempelvis 24 och visa sedan resultatet.

  Tips

  • Mer information om antalet logikkärnor och hur du fastställer antalet logikkärnor för datorn finns i Four sätt att hitta antalet kärnor i processorn på Windows 10.
  • Om du vill lära dig att beräkna math.log går du till Logaritmkalkylatorn.

Problem med SSL-certifikat för lokalt installerad IR med hög tillgänglighet (HA)

• Symtom

  En arbetsnoden för lokalt installerad IR har rapporterat följande fel:

  "Det gick inte att hämta delade tillstånd från den primära noden net.tcp://abc.cloud.corp. Microsoft.com:8060/ExternalService.svc/. Aktivitets-ID: XXXXX X.509-certifikatet CN=abc.cloud.corp.Microsoft.com, OU=test, O=Microsoft kedjebygge misslyckades. Certifikatet som användes har en förtroendekedja som inte kan verifieras. Ersätt certifikatet eller ändra certificateValidationMode. Återkallningsfunktionen kunde inte göra någon återkallningskontroll eftersom återkallningsservern var offline."

• Orsak

  När du hanterar fall som rör en SSL/TLS-handskakning kan du stöta på problem som rör verifiering av certifikatkedjan.

• Lösning

  • Här är ett snabbt och intuitivt sätt att felsöka ett versionsfel för X.509-certifikatkedjan:

    1. Exportera certifikatet, som måste verifieras. Det gör du så här:

       a. I Windows väljer du Start, börjar skriva certificates och väljer sedan Hantera datorcertifikat.

       b) I Utforskarens vänstra ruta söker du efter det certifikat som du vill kontrollera, högerklickar på det och väljer sedan Alla aktiviteter>Exportera.

       Skärmbild av "Alla uppgifter" & "Exportera" kontroll för ett certifikat på "Hantera datorcertifikat" -rutan.

    2. Kopiera det exporterade certifikatet till klientdatorn.

    3. Kör följande kommando i kommandotolken på klientsidan. Se till att ersätta <sökvägen till certifikatet> och <sökvägen till utdata-txt-filen> med de faktiska sökvägarna.

       Certutil -verify -urlfetch    <certificate path>   >     <output txt file path> 
       

       Till exempel:

       Certutil -verify -urlfetch c:\users\test\desktop\servercert02.cer > c:\users\test\desktop\Certinfo.txt
       

    4. Sök efter fel i TXT-utdatafilen. Du hittar felsammanfattningen i slutet av TXT-filen.

       Till exempel:

       

       Om du inte ser något fel i slutet av loggfilen, som du ser i följande skärmbild, kan du överväga att certifikatkedjan har skapats på klientdatorn.

       

  • Om filnamnstillägget AIA (Authority Information Access), CDP (CRL Distribution Point) eller OCSP (Online Certificate Status Protocol) har konfigurerats i certifikatfilen kan du kontrollera det på ett mer intuitivt sätt:

    1. Hämta den här informationen genom att kontrollera certifikatinformationen enligt följande skärmbild:

       

    2. Kör följande kommando. Se till att ersätta <certifikatsökvägen> med certifikatets faktiska sökväg.

         Certutil   -URL    <certificate path> 
       

       Verktyget för URL-hämtning öppnas.

    3. Om du vill verifiera certifikat med filnamnstilläggen AIA, CDP och OCSP väljer du Hämta.

       

       Du har skapat certifikatkedjan om certifikatstatusen från AIA är Verifierad och certifikatstatusen från CDP eller OCSP är Verifierad.

       Om du misslyckas när du försöker hämta AIA eller CDP arbetar du med nätverksteamet för att förbereda klientdatorn för att ansluta till mål-URL:en. Det räcker om antingen HTTP-sökvägen eller LDAP-sökvägen (Lightweight Directory Access Protocol) kan verifieras.

Lokalt installerad IR kunde inte läsa in filen eller sammansättningen

• Symtom

  Följande felmeddelande visas:

  ”Det går inte att läsa in filen eller sammansättningen XXXXXXXXXXXXXXXX, Version=4.0.2.0, Culture=neutral, PublicKeyToken=XXXXXXXX eller något av dess beroenden. Det går inte att hitta den angivna filen. Aktivitets-ID: 92693b45-b4bf-4fc8-89da-2d3dc56f27c3”

  Här är ett mer specifikt felmeddelande:

  ”Det går inte att läsa in filen eller sammansättningen 'System.ValueTuple, Version=4.0.2.0, Culture=neutral, PublicKeyToken=XXXXXXXXX eller något av dess beroenden. Det går inte att hitta den angivna filen. Aktivitets-ID: 92693b45-b4bf-4fc8-89da-2d3dc56f27c3”

• Orsak

  I Processövervakaren kan du visa följande resultat:

  

  Tips

  I Processövervakaren kan du ange filter enligt följande skärmbild.

  Föregående felmeddelande säger att DLL System.ValueTuple inte finns i den relaterade mappen Global Assembly Cache (GAC). i mappen C:\Program\Microsoft Integration Runtime\4.0\Gateway eller i mappen C:\Program\Microsoft Integration Runtime\4.0\Delad mapp.

  I grund och botten läser processen in DLL först från GAC-mappen, sedan från den delade mappen och slutligen från gatewaymappen. Därför kan du läsa in DLL-filen från valfri användbar sökväg.

  

• Lösning

  Filen System.ValueTuple.dll finns i mappen C:\Program Files\Microsoft Integration Runtime\4.0\Gateway\DataScan. Lös problemet genom att kopiera filen System.ValueTuple.dll till mappen C:\Program Files\Microsoft Integration Runtime\4.0\Gateway.

  Du kan använda samma metod för att lösa andra problem med saknad fil eller sammansättning.

• Mer information om det här problemet

  Anledningen till att du ser System.ValueTuple.dll under %windir%\Microsoft.NET\assembly och %windir%\assembly är att detta är ett .NET beteende.

  I följande fel kan du tydligt se att sammansättningen System.ValueTuple saknas. Det här problemet uppstår när programmet försöker kontrollera System.ValueTuple.dll sammansättning.

  "<LogProperties><ErrorInfo>[{"Code":0,"Message":"Typinitieraren för 'Npgsql.PoolManager' utlöste ett undantag.","EventType":0,"Category":5,"Data":{},"MsgId":null,"ExceptionType":"System.TypeInitializationException","Source":"Npgsql","StackTrace":"","InnerEventInfos":[{"Code":0,"Message":"Kunde inte läsa in filen eller assemblyn 'System.ValueTuple, Version=4.0.2.0, Kultur=neutral, PublicKeyToken=XXXXXXXXX' eller någon av dess beroenden. Systemet kan inte hitta den angivna filen.","EventType":0,"Kategori":5,"Data":{},"MsgId":null,"ExceptionType":"System.IO.FileNotFoundException","Källa":"Npgsql","StackTrace":"","InnerEventInfos":[]}]}]</ErrorInfo></LogProperties>"

  För mer information om GAC, se Global Assembly Cache.

Autentiseringsnyckeln för självhostad IR saknas

• Symtom

  Den självhostade integrationskörningen går plötsligt offline utan en autentiseringsnyckel, och händelseloggen visar följande felmeddelande:

  ”Autentiseringsnyckeln har inte tilldelats ännu”

  

• Orsak

  • IR-noden med egen värd eller logisk lokalt installerad IR i Azure portalen togs bort.
  • En ren avinstallation utfördes.

• Lösning

  Om ingen av ovanstående orsaker gäller kan du gå till mappen %programdata%\Microsoft\Data Transfer\DataManagementGateway för att se om filen Configurations har tagits bort. Om den har tagits bort följer du anvisningarna i Netwrix-artikeln Detect som tog bort en fil från dina Windows filservrar.

  

Det går inte att använda lokalt installerad IR till att överbrygga två lokala datalager

• Symtom

  När du har skapat självhostade IR-instanser för både käll- och måldatalagren bör du ansluta de två IR-instanserna för att slutföra kopieringen. Om datalagren är konfigurerade i olika virtuella nätverk, eller om datalagren inte kan förstå gatewaymekanismen, ser du något av följande fel:

  • Drivrutinen för källan kan inte hittas i mål-IR
  • "Källan kan inte nås av destination-IR"

• Orsak

  Den självhostade IR är utformad som en central nod i en kopieringsaktivitet, inte en klientagent som behöver installeras för varje datastore.

  I det här fallet ska du skapa den länkade tjänsten för varje datalager med samma IR, då bör IR kunna komma åt båda datalagren via nätverket. Det spelar ingen roll om din IR är installerad i källdatalagret eller måldatalagret, eller i en tredje dator. Om du skapar två länkade tjänster med olika IR men som används i samma kopieringsaktivitet används IR-målet, och du måste installera drivrutinerna för båda datalagren på IR-måldatorn.

• Lösning

  Installera drivrutiner för både källdatalagret och destinationsdatalagret på mål-IR, och se till att den kan komma åt källdatalagret.

  Om trafiken inte kan passera genom nätverket mellan två datalager (till exempel om de är konfigurerade i två virtuella nätverk), kanske det inte går att slutföra kopieringen i en enda aktivitet, även om Integration Runtime (IR) är installerad. Om du inte kan utföra kopieringen i en enda aktivitet kan du skapa två kopieringsaktiviteter med två IR, var och en i en VENT:

  • Kopiera en IR från datalager 1 till Azure Blob Storage
  • Kopiera en annan IR från Azure Blob Storage till datalager 2.

  Den här lösningen kan simulera behovet att använda IR för att skapa en brygga som ansluter två frånkopplade datalager.

Problem med synkronisering av autentiseringsuppgifter orsakar att autentiseringsuppgifter försvinner från HA

• Symtom

  Om datakällans autentiseringsuppgift ”XXXXXXXXXX” tas bort från den aktuella integreringskörningsnoden med nyttolasten, får du följande felmeddelande:

  "När du tar bort länktjänsten på Azure portalen, eller om uppgiften har fel nyttolast, skapar du en ny länktjänst med dina autentiseringsuppgifter igen."

• Orsak

  Din självhostade IR är skapad i HA-läge med två noder, men noderna är inte i ett synkroniseringsläge för autentiseringsuppgifter. Det innebär att autentiseringsuppgifterna som lagras i dispatcher-noden inte synkroniseras med andra arbetsnoder. Om redundans inträffar från dispatcher-noden till arbetsnoden och autentiseringsuppgifterna bara finns i den tidigare dispatcher-noden, misslyckas aktiviteten när du försöker komma åt autentiseringsuppgifterna och föregående fel visas.

• Lösning

  Det enda sättet att undvika det här problemet är att se till att de två noderna är i synkroniseringsläge för autentiseringsuppgifter. Om de inte är synkroniserade måste du ange autentiseringsuppgifterna för den nya dispatchern igen.

Det går inte att välja certifikat eftersom den privata nyckeln saknas

• Symtom

  • Du importerar en PFX-fil till certifikatarkivet.

  • När du valde certifikatet via användargränssnittet för IR Configuration Manager fick du följande felmeddelande:

    ”Det gick inte att ändra krypteringsläge för intranätskommunikation. Det är troligt att certifikatets "<certifikatnamn>" kanske inte har en privat nyckel som kan utbyta nycklar eller att processen kanske inte har åtkomsträttigheter för den privata nyckeln. Mer information finns i det inre undantaget."

• Orsak

  • Användarkontot har för låg behörighet och kan inte komma åt den privata nyckeln.
  • Certifikatet genererades som en signatur, men inte som ett nyckelutbyte.

• Lösning

  • Om du vill använda gränssnittet ska du använda ett konto med tillräcklig behörighet för att komma åt den privata nyckeln.

  • Kör följande kommando för att importera certifikatet:

    certutil -importpfx FILENAME.pfx AT_KEYEXCHANGE
    

Problem med lokalt installerade integrationskörningsnoder med synkroniseringsproblem.

• Symtom

  Lokalt installerade IR-noder försöker synkronisera autentiseringsuppgifterna mellan noder men fastnar i processen, och efter ett tag visas felmeddelandet nedan:

  "Noden Integration Runtime (lokalt installerad) försöker synkronisera autentiseringsuppgifterna mellan noder. Det här kan ta några minuter.”

  Kommentar

  Om det här felet visas i över 10 minuter kontrollerar du anslutningen till avsändarnoden.

• Orsak

  Orsaken är att arbetsnoderna inte har åtkomst till de privata nycklarna. Du kan bekräfta det här i loggfilerna för självhostad integrationsmiljö nedan:

  [14]0460.3404::05/07/21-00:23:32.2107988 [System] A fatal error occurred when attempting to access the TLS server credential private key. The error code returned from the cryptographic module is 0x8009030D. The internal error state is 10001.

  Du har inga problem med synkroniseringsprocessen när du använder tjänstehuvudprincipens autentisering i den länkade tjänsten. Men när du byter autentiseringstyp till kontonyckel börjar synkroniseringsproblemet. Det här beror på att den lokala Integration Runtime-tjänsten körs under ett tjänstkonto (NT SERVICE\DIAHostService) och det behöver läggas till i privatnyckelns behörigheter.

• Lösning

  För att lösa det här problemet måste du lägga till det självhostade integration runtime tjänstkontot (NT SERVICE\DIAHostService) till behörigheterna för den privata nyckeln. Så här kan du göra:

  1. Öppna Microsoft Management Console (MMC) med kommandot "Kör".

     

  2. Använd följande steg i MMC-fönstret:

     

     1. Välj Fil.
     2. Välj Lägg till/ta bort snapin-modul i rullgardinsmenyn.
     3. Välj Certifikat i panelen ”Tillgängliga snap-ins”.
     4. Markera Lägga till.
     5. I popup-fönstret ”Snapin-modul för certifikat” väljer du Datorkonto.
     6. Välj Nästa.
     7. I fönstret ”Välj dator” väljer du Lokal dator: datorn som den här konsolen körs i.
     8. Välj Slutför.
     9. Välj OK i fönstret ”Lägg till eller ta bort snapin-moduler”.

  3. I fönstret i MMC går du vidare med följande steg:

     

     1. I den vänstra mapplistan väljer du Konsolrot –> Certifikat (lokal dator) –> Personlig –> Certifikat.
     2. Högerklicka på Microsoft Intune Beta MDM.
     3. Välj Alla uppgifter i listrutan.
     4. Välj Hantera privata nycklar.
     5. Välj Lägg till under ”Grupp- eller användarnamn”.
     6. Välj NT SERVICE\DIAHostService för att ge fullständig åtkomst till det här certifikatet, tillämpa och spara.
     7. Välj Kontrollera namn och sedan OK.
     8. I fönstret ”Behörigheter” väljer du Tillämpa och sedan OK.

UserErrorJreNotFound-felmeddelande när du kör en kopieringsaktivitet till Azure

• Symtom

  När du försöker kopiera innehåll till Microsoft Azure med hjälp av ett Java-baserat verktyg eller program (till exempel kopiera ORC- eller Parquet-formatfiler) får du ett felmeddelande som liknar följande:

  ErrorCode=UserErrorJreNotFound,'Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,Message=Java Runtime Environment hittades inte. Gå till http://go.microsoft.com/fwlink/?LinkId=808605 för att ladda ner och installera på din Integration Runtime (egenhostad) noddator. Observera att 64-bitars Integration Runtime kräver 64-bitars JRE och 32-bitars Integration Runtime kräver 32-bitars JRE., Källa=Microsoft.DataTransfer.Common,Typ=System.DllNotFoundException, Meddelande=Det går inte att ladda DLL "jvm.dll": Den angivna modulen kunde inte hittas. (Undantag från HRESULT: 0x8007007E),Source=Microsoft. DataTransfer.Richfile.HiveOrcBridge

• Orsak

  Det här problemet kan ske av någon av följande orsaker:

  • Java Runtime Environment (JRE) är inte korrekt installerat på Integration Runtime-servern.

  • Din Integration Runtime-server saknar det nödvändiga beroendet för JRE.

  Som standard löser Integration Runtime JRE-sökvägen med hjälp av registerposter. Dessa poster bör anges automatiskt under JRE-installationen.

• Lösning

  Följ stegen i det här avsnittet noggrant. Det kan uppstå allvarliga problem om du gör felaktiga ändringar i registret. Innan du ändrar det bör du först säkerhetskopiera registret för att kunna återställa det om problem skulle uppstå.

  Åtgärda det här problemet genom att följa dessa steg för att kontrollera JRE-installationens status:

  1. Kontrollera att Integration Runtime (Diahost.exe) och JRE är installerade på samma plattform. Kontrollera följande villkor:

     • 64-bitars JRE för 64-bitars ADF Integration Runtime bör installeras i mappen: C:\Program Files\Java\

       Kommentar

       Mappen är inte C:\Program Files (x86)\Java\

     • Java Runtime (JRE) är version 11 eller senare, från en JRE-provider som Microsoft OpenJDK 11 eller Eclipse Temurin 11. Kontrollera att JAVA_HOME-systemmiljövariabeln är inställd på JDK-mappen (inte bara JRE-mappen) du kan också behöva lägga till mappen bin i systemets PATH-miljövariabel.

  2. Kontrollera lämpliga inställningar i registret. För att göra detta följer du stegen nedan:

     1. I menyn Kör skriver du Regedit och trycker sedan på Retur.

     2. Leta upp följande undernyckel i navigeringsfönstret:

        HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment.

        I fönstret Details (Information) bör det finnas en post för Current Version (Aktuell version) som visar JRE-versionen (till exempel 1.8).

        

     3. I navigeringsfönstret letar du upp en undernyckel som är en exakt matchning för versionen (till exempel 1.8) under JRE-mappen. I detaljpanelet bör det finnas en JavaHome-post. Värdet för den här posten är JRE-installationssökvägen.

        

  3. Leta upp mappen bin\server på följande sökväg:

     C:\Program Files\Java\jre1.8.0_74

     

  4. Kontrollera om den här mappen innehåller en jvm.dll-fil. Om den inte gör det söker du efter filen i bin\client mappen.

     

  Kommentar

  • Om någon av dessa konfigurationer inte är såsom det beskrivs i de här stegen kan du använda Windows-installationsprogrammet för JRE till att åtgärda problemen.
  • Om alla konfigurationer i de här stegen är korrekta enligt beskrivningen kan det finnas ett VC++-körningsbibliotek som saknas i systemet. Du kan åtgärda det här problemet genom att installera VC++ 2010 Redistributable Package.

Självhanterad IR-installation

Registreringsfel för integrationskörmiljö

• Symtom

  Ibland kanske du vill köra en lokalt installerad IR på ett annat konto av någon av följande orsaker:

  • Företagspolicyn tillåter inte tjänstkontot.
  • Viss autentisering krävs.

  När du har ändrat tjänstkontot i tjänstfönstret kan det hända att integreringskörningen slutar fungera och du får följande felmeddelande:

  "Noden Integration Runtime (lokalt installerad) har påträffat ett fel under registreringen. Det går inte att ansluta till värdtjänsten Integration Runtime (lokalt installerad).

  

• Orsak

  Många resurser beviljas endast till tjänstkontot. När du ändrar tjänstkontot till ett annat konto förblir behörigheterna för alla beroende resurser oförändrade.

• Lösning

  Gå till händelseloggen för integreringskörning för att kontrollera felet.

  

  • Om felet i händelseloggen är ”UnauthorizedAccessException” gör du följande:

    1. Kontrollera DIAHostService inloggningstjänstkonto i Windows-tjänstpanelen.

       

    2. Kontrollera om inloggningstjänstkontot har läs-/skrivbehörighet för mappen %programdata%\Microsoft\DataTransfer\DataManagementGateway.

       • Om tjänstinloggningskontot inte har ändrats bör det ha läs-/skrivbehörighet som standard.

         

       • Om du har ändrat tjänstkontot för inloggning kan du åtgärda problemet genom att göra följande:

         a. Utför en ren avinstallation av den nuvarande självhostade integrationskörningen.
         b) Installera komponenterna för självhostad IR.
         Punkt c Ändra tjänstkontot genom att göra följande:

         i. Gå till installationsmappen för lokalt installerad IR och växla sedan till mappen Microsoft Integration Runtime\4.0\Shared.
         ii. Öppna ett kommandotolkfönster med utökade privilegier. Ersätt <användare> och <lösenord> med ditt eget användarnamn och lösenord och kör sedan följande kommando:
         dmgcmd.exe -SwitchServiceAccount "<user>" "<password>"
         iii. Om du vill ändra till LocalSystem-kontot måste du använda rätt format för det här kontot: dmgcmd.exe -SwitchServiceAccount "NT Authority\System" ""
         Använd inte det här formatet: dmgcmd.exe -SwitchServiceAccount "LocalSystem" ""
         iv. Du kan också ändra det direkt i "Tjänster" eftersom det lokala systemet har högre behörighet än administratör.
         v. Du kan använda en lokal användare/domänanvändare för IR-tjänstinloggningskontot.

         d. Registrera integreringskörningen.

  • Om felet är "Tjänsten "Integration Runtime Service" (DIAHostService) kunde inte starta. Kontrollera att du har tillräcklig behörighet för att starta systemtjänster", gör följande:

    1. Kontrollera DIAHostService inloggningstjänstkonto i Windows-tjänstpanelen.

       

    2. Kontrollera om inloggningstjänstkontot har Logga in som en tjänst behörighet att starta Windows-tjänsten:

       

• Mer information

  Om inget av de föregående två matchningsmönstren gäller i ditt fall kan du försöka samla in följande Windows händelseloggar:

  • Program- och tjänstloggar > Integration Runtime
  • Windows loggar >-program

Det går inte att hitta knappen Registrera för att registrera en lokalt installerad IR

• Symtom

  När du registrerar en lokalt installerad IR visas inte knappen Register i fönstret Configuration Manager.

  

• Orsak

  Från och med lanseringen av Integration Runtime 3.0 har knappen Register på befintliga integration runtime noder tagits bort för att möjliggöra en renare och säkrare miljö. Om en nod har registrerats på en integreringskörning, oavsett om den är online eller inte, omregistrerar du den till en annan integreringskörning genom att avinstallera den tidigare noden och sedan installera och registrera noden.

• Lösning

  1. I Control Panel avinstallerar du den befintliga integrationskörningen.

     Viktigt!

     I följande process väljer du Ja. Behåll inte data under avinstallationsprocessen.

     

  2. Om du inte har installationsprogrammets MSI-fil för integreringskörningen går du till Download Center och laddar ned den senaste integreringskörningen.

  3. Installera MSI-filen och registrera integreringskörningen.

Det går inte att registrera lokalt installerad IR på grund av localhost

• Symtom

  Du kan inte registrera den lokalt installerade IR:n på en ny dator när du använder get_LoopbackIpOrName.

  Felsökning: Ett körningsfel har inträffat. Typinitieraren för "Microsoft.DataTransfer.DIAgentHost.DataSourceCache" utlöste ett undantag. Ett oåterkalleligt fel inträffade under en databassökning.

  Exception detail: System.TypeInitializationException: Typinitieraren för "Microsoft.DataTransfer.DIAgentHost.DataSourceCache" utlöste ett undantag. >--- System.Net.Sockets.SocketException: Ett fel som inte kan återställas inträffade under en databassökning på System.Net.Dns.GetAddrInfo(Strängnamn).

• Orsak

  Problemet uppstår vanligtvis när localhost löses.

• Lösning

  Använd localhost IP-adress 127.0.0.1 som värd för filen och lös problemet.

Det gick inte att installera lokalt

• Symtom

  Du kan inte avinstallera en befintlig IR, installera en ny IR eller uppgradera en befintlig IR till en ny IR.

• Orsak

  Installationen av integrationskörningen beror på Windows Installer-tjänsten. Du kan uppleva installationsproblem av följande skäl:

  • Otillräckligt diskutrymme.
  • Brist på behörigheter.
  • Windows NT-tjänsten är låst.
  • Processoranvändningen är för hög.
  • MSI-filen finns på en långsam nätverksplats.
  • Vissa systemfiler eller register berördes oavsiktligt.

IR-tjänstkontot kunde inte hämta certifikatåtkomst

• Symtom

  När du installerar en lokalt installerad IR via Microsoft Integration Runtime Configuration Manager genereras ett certifikat med en betrodd certifikatutfärdare (CA). Det gick inte att använda certifikatet för att kryptera kommunikationen mellan två noder och följande felmeddelande visas:

  "Det gick inte att ändra krypteringsläget för intranätkommunikation: Det gick inte att bevilja Integration Runtime tjänstkonto åtkomst till certifikatet "<certificate name>". Felkod 103"

• Orsak

  Certifikatet använder nyckellagringsleverantör (KSP), som inte stöds ännu. Hittills har lokalt installerad IR endast stöd för csp-lagring (cryptographic service provider).

• Lösning

  Vi rekommenderar att du använder CSP-certifikat i det här fallet.

  Lösning 1

  Kör följande kommando för att importera certifikatet:

  Certutil.exe -CSP "CSP or KSP" -ImportPFX FILENAME.pfx

  

  Lösning 2

  Om du vill konvertera certifikatet kör du följande kommandon:

  openssl pkcs12 -in .\xxxx.pfx -out .\xxxx_new.pem -password pass: <EnterPassword> openssl pkcs12 -export -in .\xxxx_new.pem -out xxxx_new.pfx

  Före och efter konvertering:

  

  

Lokalt installerad integrationskörning version 5.x

För uppgraderingen till version 5.x av den lokalt installerade integrationskörningen behöver vi .NET Framework Runtime 4.7.2 eller senare. På nedladdningssidan hittar du nedladdningslänkar för den senaste 4.x-versionen och de senaste två 5.x-versionerna.

För Azure Data Factory v2- och Azure Synapse kunder:

• Om automatisk uppdatering är på och du redan har uppgraderat din .NET Framework Runtime till 4.7.2 eller senare uppgraderas den lokalt installerade integrationskörningen automatiskt till den senaste 5.x-versionen.
• Om automatisk uppdatering är på och du inte har uppgraderat din .NET Framework Runtime till 4.7.2 eller senare uppgraderas inte den lokalt installerade integrationskörningen automatiskt till den senaste 5.x-versionen. Den självhostade integrationsmiljön kommer att stanna kvar i den nuvarande 4.x-versionen. Du kan se en varning för en .NET Framework Runtime-uppgradering i portalen och den lokalt installerade integrationskörningsklienten.
• Om automatisk uppdatering är avstängd och du redan har uppgraderat din .NET Framework Runtime till 4.7.2 eller senare kan du manuellt ladda ned den senaste 5.x och installera den på datorn.
• Om automatisk uppdatering är avstängd och du inte har uppgraderat din .NET Framework Runtime till 4.7.2 eller senare. När du försöker installera integrationskörningen 5.x manuellt och registrera nyckeln måste du uppgradera din .NET Framework Runtime-version först.

Problem med lokalt installerad IR-anslutning

Lokalt installerad integreringskörning kan inte ansluta till molntjänsten

• Symtom

  När du försöker registrera den lokalt installerade integrationskörningen visar Configuration Manager följande felmeddelande:

  "Noden Integration Runtime (lokalt installerad) har påträffat ett fel under registreringen."

  

• Orsak

  Den lokalt installerade IR:en kan inte ansluta till tjänstens serverdel. Det här problemet orsakas vanligtvis av nätverksinställningar i brandväggen.

• Lösning

  1. Kontrollera om integreringskörningstjänsten körs. I så fall går du till steg 2.

     

  2. Om ingen proxy har konfigurerats för den lokalt installerade integreringskörningen, vilket är standardinställningen, kör du följande PowerShell-kommando på den dator där den lokalt installerade integreringskörningen är installerad:

     (New-Object System.Net.WebClient).DownloadString("https://wu2.frontend.clouddatahub.net/")
     

     Kommentar

     Tjänst-URL:en kan variera beroende på platsen för din datafabrik eller Synapse-arbetsyteinstans. Om du vill hitta tjänst-URL:en använder du sidan Hantera i användargränssnittet i datafabriken eller Azure Synapse-instansen för att hitta Integration runtimes och klickar på din lokala IR för att redigera den. Där väljer du fliken Noder och klickar på Visa tjänst-URL:er.

     Följande är det förväntade svaret:

     

  3. Om du inte får det svar som du hade förväntat dig använder du någon av följande metoder efter behov:

     • Om du får ett meddelande om att det inte gick att matcha fjärrnamnet finns det ett problem med Domain Name System (DNS). Kontakta nätverksteamet för att åtgärda problemet.
     • Om du får meddelandet "ssl/tls cert is not trusted" kontrollerar du certifikatet (https://wu2.frontend.clouddatahub.net/) för att se om det är betrott på datorn och installerar sedan det offentliga certifikatet med hjälp av Certifikathanteraren. Den här åtgärden bör åtgärda problemet.
     • Gå till Windows>Event viewer (loggar)>Applications and Services Logs>Integration Runtime, och leta efter eventuella fel som orsakas av DNS, en brandväggsregel, eller företagsnätverksinställningar. Om du upptäcker ett sådant fel, försök stänga anslutningen tvångsmässigt. Eftersom varje företag har sina egna anpassade nätverksinställningar kontaktar du nätverksteamet för att felsöka dessa problem.

  4. Om ”proxy” har konfigurerats på den lokalt installerade integreringskörningen kontrollerar du att proxyservern kan komma åt tjänstslutpunkten. Ett exempelkommando finns i PowerShell, webbegäranden och proxyn.

     $user = $env:username
     $webproxy = (get-itemproperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet
     Settings').ProxyServer
     $pwd = Read-Host "Password?" -assecurestring
     $proxy = new-object System.Net.WebProxy
     $proxy.Address = $webproxy
     $account = new-object System.Net.NetworkCredential($user,[Runtime.InteropServices.Marshal]::PtrToStringAuto([Runtime.InteropServices.Marshal]::SecureStringToBSTR($pwd)), "")
     $proxy.credentials = $account
     $url = "https://wu2.frontend.clouddatahub.net/"
     $wc = new-object system.net.WebClient
     $wc.proxy = $proxy
     $webpage = $wc.DownloadData($url)
     $string = [System.Text.Encoding]::ASCII.GetString($webpage)
     $string
     

  Följande är det förväntade svaret:

  

  Kommentar

  Proxyöverväganden:

  • Kontrollera om proxyservern behöver placeras i listan Säkra mottagare. I så fall kontrollerar du att dessa domäner finns på listan Betrodda mottagare.
  • Kontrollera om SSL/TLS-certifikatet wu2.frontend.clouddatahub.net/ är betrott på proxyservern.
  • Om du använder Active Directory autentisering på proxyn ändrar du tjänstkontot till det användarkonto som kan komma åt proxyn som "Integration Runtime Service".

Felmeddelande: Lokalt installerad integrationskörningsnod/logisk lokalt installerad IR är i inaktivt tillstånd/ "Körs (begränsad)"

• Orsak

  Den lokalt installerade integrerade runtime-noden kan ha statusen Inaktiv, vilket visas i följande skärmbild:

  

  Det här beteendet inträffar när noder inte kan kommunicera med varandra.

• Lösning

  1. Logga in på den nodvärdbaserade virtuella datorn (VM). Under Applications and Services Logs>Integration Runtime öppnar du Event Viewer och filtrerar felloggarna.

  2. Kontrollera om en fellogg innehåller följande fel:

     System.ServiceModel.EndpointNotFoundException: Could not connect to net.tcp://xxxxxxx.bwld.com:8060/ExternalService.svc/WorkerManager. The connection attempt lasted for a time span of 00:00:00.9940994. TCP error code 10061: No connection could be made because the target machine actively refused it 10.2.4.10:8060. 
     System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it. 
     10.2.4.10:8060
     at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress)
     at System.Net.Sockets.Socket.Connect(EndPoint remoteEP)
     at System.ServiceModel.Channels.SocketConnectionInitiator.Connect(Uri uri, TimeSpan timeout)
     

  3. Om du ser det här felet kör du följande kommando i kommandotolken:

     telnet 10.2.4.10 8060
     

  4. Om du får kommandoradsfelet "Det gick inte att öppna anslutningen till värden" som visas på följande skärmbild kontaktar du IT-avdelningen för att få hjälp med att åtgärda problemet. När du har lyckats med telnet kontaktar du Microsoft Support om du fortfarande har problem med nodstatusen för integrationskörningen.

     

  5. Kontrollera om felloggen innehåller följande post:

     Error log: Cannot connect to worker manager: net.tcp://xxxxxx:8060/ExternalService.svc/ No DNS entries exist for host azranlcir01r1. No such host is known Exception detail: System.ServiceModel.EndpointNotFoundException: No DNS entries exist for host xxxxx. ---> System.Net.Sockets.SocketException: No such host is known at System.Net.Dns.GetAddrInfo(String name) at System.Net.Dns.InternalGetHostByName(String hostName, Boolean includeIPv6) at System.Net.Dns.GetHostEntry(String hostNameOrAddress) at System.ServiceModel.Channels.DnsCache.Resolve(Uri uri) --- End of inner exception stack trace --- Server stack trace: at System.ServiceModel.Channels.DnsCache.Resolve(Uri uri)
     

  6. Försök att lösa problemet på något av eller båda följande sätt:

     • Placera alla noder i samma domän.
     • Lägg till IP-adressen till värdmappningen i alla värdfiler för den värdbaserade virtuella datorn.

Anslutningsproblem mellan lokalt installerad IR och din datafabrik eller Azure Synapse instans eller den lokalt installerade IR:en och datakällan eller mottagaren

Om du vill felsöka problemet med nätverksanslutningen bör du veta hur du samlar in nätverksspårningen, förstå hur du ska använda den och analysera Microsoft Network Monitor (Netmon)-spårningen innan du tillämpar Netmon Tools i verkliga fall från den lokalt installerade IR:n.

• Symtom

  Ibland kan du behöva felsöka vissa anslutningsproblem mellan den lokalt installerade IR:en och din datafabrik eller Azure Synapse instans, som du ser i följande skärmbild, eller mellan den lokalt installerade IR:en och datakällan eller mottagaren.

  

  I båda fallen kan du stöta på följande fel:

  • "Kopiering misslyckades med felet: Typ=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException, Meddelande=Kan inte ansluta till SQL Server: 'IP-adress'"

  • "Ett eller fler fel uppstod. Ett fel inträffade när begäran skickades. Den underliggande anslutningen stängdes: Ett oväntat fel inträffade vid en mottagning. Det går inte att läsa data från transportanslutningen: En befintlig anslutning stängdes med tvång av fjärrvärden. En befintlig anslutning stängdes av med tvång av fjärrvärdens Aktivitets-ID."

• Lösning

  När du stöter på föregående fel kan du felsöka dem genom att följa anvisningarna i det här avsnittet.

  • Samla in en Netmon-spårning för analys:

    1. Du kan ange att filtret ska se en återställning från servern till klientsidan. I följande skärmbild av exemplet kan du se att serversidan är Data Factory-servern.

       

    2. När du får återställningspaketet kan du hitta konversationen genom att följa Transmission Control Protocol (TCP).

       

    3. Hämta konversationen mellan klienten och Data Factory-servern genom att ta bort filtret.

  • En analys av Netmon-spårningen som du har samlat in visar att TTL-summan (Time to Live) är 64. Enligt de värden som anges i artikeln IP Time to Live (TTL) och Hop Limit Basics som extraheras i följande lista kan du se att det är Linux-systemet som återställer paketet och orsakar frånkopplingen.

    Standardvärdena för TTL och Hoppgräns varierar mellan olika operativsystem, enligt listan här:

    • Linux kernel 2.4 (cirka 2001): 255 för TCP, User Datagram Protocol (UDP) och Internet Control Message Protocol (ICMP)
    • Linux kernel 4.10 (2015): 64 för TCP, UDP och ICMP
    • Windows XP (2001): 128 för TCP, UDP och ICMP
    • Windows 10 (2015): 128 för TCP, UDP och ICMP
    • Windows Server 2008: 128 för TCP, UDP och ICMP
    • Windows Server 2019 (2018): 128 för TCP, UDP och ICMP
    • macOS (2001): 64 för TCP, UDP och ICMP

    

    I föregående exempel visas TTL som 61 i stället för 64, för när nätverkspaketet når målet måste det gå igenom olika hopp, till exempel routrar eller nätverksenheter. Antalet routrar eller nätverksenheter dras av för att producera den slutliga TTL:n.

    I det här fallet kan du se att en återställning kan skickas från Linux-systemet med TTL 64.

  • Kontrollera var återställningsenheten kommer ifrån genom att kontrollera det fjärde hoppet från lokalt installerad IR.

    Nätverkspaket från Linux System A med TTL 64 –> B TTL 64 minus 1 = 63 –> C TTL 63 minus 1 = 62 –> TTL 62 minus 1 = 61 lokalt installerad IR

  • I en idealisk situation skulle antalet TTL-hopp vara 128, vilket innebär att Windows-operativsystemet kör din datainstans. Som visas i följande exempel, 128 minus 107 = 21 hopp, vilket innebär att 21 hopp för paketet skickades från datafabriksinstansen till den lokalt installerade IR:n under trevägshandskakningen för TCP.

    

    Därför måste du kontakta nätverksteamet för att kontrollera vad det fjärde hoppet är från den lokalt installerade IR:n. Om det är brandväggen, såsom med Linux-systemet, kontrollerar du alla loggar för att se varför enheten gör en återställning av paketet efter TCP-handskakningens tredje steg.

    Om du är osäker på var du ska undersöka kan du försöka hämta Netmon-spårningen från både den lokalt installerade IR:en och brandväggen under den problematiska tiden. Den här metoden hjälper dig att ta reda på vilken enhet som kan ha återställt paketet och orsakat frånkopplingen. I det här fallet måste du också engagera ditt nätverksteam för att gå vidare.

Analysera Netmon-spårningen

När du försöker telnet 8.8.8.8 888 med den insamlade Netmon-spårningen bör du se spårningen i följande skärmbilder:

Föregående bilder visar att du inte kunde upprätta en TCP-anslutning till 8.8.8.8.8-serversidan på port 888, så du ser ytterligare två SynReTransmit-paket där. Eftersom källan SELF-HOST2 inte kunde ansluta till 8.8.8.8 med det första paketet fortsätter den att försöka upprätta anslutningen.

Lyckade scenarier visas i följande exempel:

• Om du kan använda telnet 8.8.8.8 53 utan problem, sker en lyckad TCP-handshake och sessionen avslutas med en TCP-handshake.

  

  

• Föregående TCP 3-handskakning skapar följande arbetsflöde:

  

• Handskakningen TCP 4 för att slutföra sessionen illustreras av följande arbetsflöden:

  

  

Ta reda på om det här meddelandet påverkar dig

Det här meddelandet gäller för följande scenarier:

Scenario 1: Utgående kommunikation från en lokalt installerad integrationskörning som körs lokalt bakom en företagsbrandvägg

Så här avgör du om du påverkas:

• Du påverkas inte om du definierar brandväggsregler baserat på fullständigt kvalificerade domännamn (FQDN) som använder metoden som beskrivs i Konfigurera en brandväggskonfiguration och tillåtlista för IP-adresser.

• Du påverkas om du specifikt aktiverar tillåtelselistan för utgående IP-adresser i företagets brandvägg.

  Om du påverkas vidtar du följande åtgärd: Senast den 8 november 2020 meddelar du nätverksinfrastrukturteamet att uppdatera nätverkskonfigurationen för att använda de senaste IP-adresserna för datafabriken. Om du vill ladda ned de senaste IP-adresserna går du till Identifiera tjänsttaggar med hjälp av nedladdningsbara JSON-filer.

Scenario 2: Utgående kommunikation från en lokalt installerad integrationskörning som körs på en Azure virtuell dator i ett kundhanterat Azure virtuellt nätverk

Så här avgör du om du påverkas:

• Kontrollera om du har några regler för utgående nätverkssäkerhetsgrupp (NSG) i ett privat nätverk som innehåller lokalt installerad integrationskörning. Om det inte finns några utgående begränsningar påverkas du inte.

• Om du har begränsningar för utgående regelrestriktioner, kontrollera om du använder tjänsttaggar. Om du använder tjänsttaggar påverkas du inte. Du behöver inte ändra eller lägga till något eftersom det nya IP-intervallet finns under dina befintliga tjänsttaggar.

  

• Du påverkas om du uttryckligen aktiverar listan över tillåtna utgående IP-adresser i NSG-regelinställningen i det virtuella nätverket på Azure.

  Om du påverkas vidtar du följande åtgärd: Senast den 8 november 2020 meddelar du nätverksinfrastrukturteamet att uppdatera NSG-reglerna för din Azure konfiguration av virtuella nätverk för att använda de senaste IP-adresserna för datafabriken. Om du vill ladda ned de senaste IP-adresserna går du till Identifiera tjänsttaggar med hjälp av nedladdningsbara JSON-filer.

Scenario 3: Utgående kommunikation från SSIS Integration Runtime i ett kundhanterat Azure virtuellt nätverk

Så här avgör du om du påverkas:

• Kontrollera om du har några utgående NSG-regler i ett privat nätverk som innehåller SQL Server Integration Services (SSIS) Integration Runtime. Om det inte finns några utgående begränsningar påverkas du inte.

• Om du har begränsningar för utgående regelrestriktioner, kontrollera om du använder tjänsttaggar. Om du använder tjänsttaggar påverkas du inte. Du behöver inte ändra eller lägga till något eftersom det nya IP-intervallet finns under dina befintliga tjänsttaggar.

• Du påverkas om du uttryckligen aktiverar listan över tillåtna utgående IP-adresser i NSG-regelinställningen i det virtuella nätverket på Azure.

  Om du påverkas vidtar du följande åtgärd: Senast den 8 november 2020 meddelar du nätverksinfrastrukturteamet att uppdatera NSG-reglerna för din Azure konfiguration av virtuella nätverk för att använda de senaste IP-adresserna för datafabriken. Om du vill ladda ned de senaste IP-adresserna går du till Identifiera tjänsttaggar med hjälp av nedladdningsbara JSON-filer.

Det går inte att upprätta en förtroenderelation för den säkra SSL/TLS-kanalen

• Symtom

  Det gick inte att ansluta den lokalt installerade IR:en till tjänsten Azure Data Factory eller Azure Synapse.

  När du kontrollerar händelseloggen för lokalt installerad IR efter att ha gått till WindowsEvent viewer (loggar)< c3 />Applications and Services LogsIntegration Runtime hittar du följande felmeddelande.

  "Den underliggande anslutningen stängdes: Det gick inte att upprätta en förtroenderelation för den säkra SSL/TLS-kanalen. Fjärrcertifikatet är ogiltigt enligt valideringsproceduren."

  Det enklaste sättet att kontrollera tjänstens servercertifikat är att öppna tjänstens URL i webbläsaren. Öppna till exempel länken kontrollera servercertifikat (https://eu.frontend.clouddatahub.net/) på den dator där den lokalt installerade IR:en är installerad och visa sedan servercertifikatinformationen.

  

  

• Orsak

  Det finns två möjliga orsaker till det här problemet:

  • Orsak 1: Roten CA för tjänstens servercertifikat är inte betrodd på den dator där den lokalt installerade IR:n finns.
  • Orsak 2: Du använder en proxy i din miljö, och tjänstens servercertifikat ersätts av proxyn. Det ersatta servercertifikatet är inte betrott av den dator där den lokalinstallerade IR:n finns.

• Lösning

  • För orsak 1: Se till att tjänstens servercertifikat och dess certifikatkedja är betrodda på den dator där lokalt installerad IR är installerad.
  • För orsak 2: Lita antingen på den ersatta rot-CA på IR-maskinen med lokal installation, eller konfigurera proxyn så att den inte ersätter tjänstens server-certifikat.

  Mer information om att lita på certifikat på Windows finns i Installera det betrodda rotcertifikatet.

• Ytterligare information
  Vi har distribuerat ett nytt SSL-certifikat som är signerat från DigiCert. Kontrollera om DigiCert Global Root G2 finns i den betrodda rotcertifikatutfärdaren.

  

  Om den inte finns i de betrodda rotcertifikatutfärdarna, ladda ned den här.

Relaterat innehåll

Om du vill ha mer hjälp med felsökning kan du prova följande resurser:

• Data Factory-bloggen
• Data Factory-funktionsbegäranden

• Azure videor

• Microsoft Q&A sida
• Stack overflow-forum för Data Factory
• X-information om Data Factory
• Prestandaguide för mappning av dataflöden