Indledning
Det skete sådan, at jeg på min nuværende arbejdsplads var nødt til at stifte bekendtskab med denne teknologi. Jeg starter med lidt baggrund. På næste møde fik vores team at vide, at vi skulle skabe integration med kendt system. Med integration var det meningen, at dette velkendte system ville sende os forespørgsler via HTTP til et specifikt slutpunkt, og vi underligt nok ville sende tilbage svar i form af en SOAP-besked. Alt virker simpelt og trivielt. Heraf følger, at du har brug for...
Opgave
Opret 3 tjenester. Den første af dem er Database Update Service. Denne tjeneste, når der kommer nye data fra et tredjepartssystem, opdaterer dataene i databasen og genererer en fil i CSV-format for at overføre den til det næste system. Slutpunktet for den anden tjeneste kaldes - FTP Transport Service, som modtager den overførte fil, validerer den og lægger den i fillageret via FTP. Den tredje tjeneste, forbrugerdataoverførselstjenesten, fungerer asynkront med de to første. Den modtager en anmodning fra et eksternt tredjepartssystem om at modtage filen diskuteret ovenfor, tager klar-svar-filen, ændrer den (opdaterer id, beskrivelse, linkToFile-felter) og sender svaret i form af en SOAP-meddelelse. Det vil sige, at det overordnede billede er som følger: De to første tjenester begynder først deres arbejde, når dataene til opdatering er ankommet. Den tredje tjeneste fungerer konstant, fordi der er mange forbrugere af information, omkring 1000 anmodninger om data i minuttet. Tjenester er konstant tilgængelige, og deres forekomster er placeret i forskellige miljøer, såsom test, demo, præproduktion og prod. Nedenfor er et diagram over, hvordan disse tjenester fungerer. Lad mig med det samme præcisere, at nogle detaljer er blevet forenklet for at undgå unødvendig kompleksitet.
Teknisk uddybning
Da vi planlagde en løsning på problemet, besluttede vi først at lave applikationer i Java ved hjælp af Spring frameworket, Nginx balancer, Postgres database og andre tekniske og knap så tekniske ting. Da tiden til at udvikle en teknisk løsning tillod os at overveje andre tilgange til at løse dette problem, faldt vores blik på Apache NIFI-teknologien, som er på mode i visse kredse. Jeg vil med det samme sige, at denne teknologi gjorde det muligt for os at bemærke disse 3 tjenester. Denne artikel vil beskrive udviklingen af en filtransporttjeneste og en dataoverførselstjeneste til forbrugeren, men hvis artiklen er nyttig, vil jeg skrive om tjenesten til opdatering af data i databasen.
Hvad er det her
NIFI er en distribueret arkitektur til hurtig parallel indlæsning og behandling af data, et stort antal plugins til kilder og transformationer, versionering af konfigurationer og meget mere. En fin bonus er, at den er meget nem at bruge. Trivielle processer såsom getFile, sendHttpRequest og andre kan repræsenteres som firkanter. Hver firkant repræsenterer en proces, hvis vekselvirkning kan ses på figuren nedenfor. Der er skrevet mere detaljeret dokumentation om interaktioner med procesopsætning , for dem, der taler russisk - . Dokumentationen beskriver perfekt, hvordan man pakker ud og kører NIFI, samt hvordan man laver processer, også kendt som firkanter
Ideen til at skrive en artikel blev født efter en lang søgning og strukturering af den modtagne information til noget bevidst, samt ønsket om at gøre livet lidt lettere for fremtidige udviklere.
Eksempel
Et eksempel på, hvordan firkanter interagerer med hinanden, betragtes. Det generelle skema er ret simpelt: Vi modtager en HTTP-anmodning (i teorien med en fil i selve anmodningen. For at demonstrere NIFI's muligheder starter anmodningen i dette eksempel processen med at modtage en fil fra det lokale fillager ), så sender vi et svar tilbage om, at anmodningen er modtaget, sideløbende med processen med at modtage en fil fra FH og derefter processen med at flytte den via FTP til FH. Det er værd at præcisere, at processer interagerer med hinanden gennem den såkaldte flowFile. Dette er basisenheden i NIFI, der gemmer attributter og indhold. Indhold er de data, der repræsenteres af stream-filen. Det vil sige, groft sagt, hvis du modtager en fil fra en firkant og overfører den til en anden, vil indholdet være din fil.
Som du kan se, viser dette billede den generelle proces. HandleHttpRequest - accepterer anmodninger, ReplaceText - genererer en svartekst, HandleHttpResponse - sender et svar. FetchFile - modtager en fil fra et fillager, overfører den til firkanten PutSftp - sætter denne fil på FTP på den angivne adresse. Nu mere om denne proces.
I dette tilfælde er anmodning begyndelsen på alt. Lad os se på dens konfigurationsparametre.
Alt her er ret trivielt med undtagelse af StandardHttpContextMap - dette er en slags service, der giver dig mulighed for at sende og modtage anmodninger. Mere detaljeret og endda med eksempler kan du se -
Lad os derefter se på ReplaceText-konfigurationsparametrene for firkanten. Det er værd at være opmærksom på ReplacementValue - det er det, der returneres til brugeren i form af et svar. I indstillinger kan du justere niveauet for logning, du kan se logfilerne {hvor du udpakkede nifi}/nifi-1.9.2/logs, der er også fejl/succesparametre - ud fra disse parametre kan du regulere processen som helhed . Det vil sige, at i tilfælde af vellykket tekstbehandling, vil processen med at sende et svar til brugeren blive kaldt, og i et andet tilfælde vil vi blot logge den mislykkede proces.
Der er ikke noget særligt interessant i HandleHttpResponse-egenskaberne undtagen status, når et svar er oprettet.
Vi har sorteret anmodningen og svaret - lad os gå videre til at modtage filen og placere den på FTP-serveren. FetchFile - modtager en fil på stien angivet i indstillingerne og sender den til næste proces.
Og så PutSftp-firkanten - placerer filen i fillageret. Vi kan se konfigurationsparametrene nedenfor.
Det er værd at være opmærksom på, at hver firkant er en separat proces, der skal lanceres. Vi så på det enkleste eksempel, der ikke kræver nogen kompleks tilpasning. Dernæst vil vi se på processen lidt mere kompliceret, hvor vi vil skrive lidt om rillerne.
Mere komplekst eksempel
Dataoverførselstjenesten til forbrugeren viste sig at være lidt mere kompliceret på grund af processen med at ændre SOAP-meddelelsen. Den generelle proces er vist i figuren nedenfor.
Her er ideen heller ikke særlig kompliceret: vi modtog en anmodning fra forbrugeren om, at han havde brug for data, sendte et svar om, at han havde modtaget en besked, startede processen med at modtage svarfilen, så redigerede den med en vis logik, og så overført filen til forbrugeren i form af en SOAP-meddelelse til serveren.
Jeg tror, der er ingen grund til at beskrive de firkanter, som vi så ovenfor igen - lad os gå direkte til de nye. Hvis du har brug for at redigere en fil, og almindelige ReplaceText-firkanter ikke er egnede, bliver du nødt til at skrive dit eget script. Dette kan gøres ved at bruge ExecuteGroogyScript-firkanten. Dens indstillinger er præsenteret nedenfor.
Der er to muligheder for at indlæse scriptet i denne firkant. Den første er ved at downloade en fil med et script. Den anden er ved at indsætte et script i scriptBody. Så vidt jeg ved, understøtter executeScript-firkanten flere sprog - et af dem er groovy. Jeg vil skuffe java-udviklere - du kan ikke skrive scripts i java i sådanne firkanter. For dem, der virkelig vil, skal du oprette din egen brugerdefinerede firkant og tilføje den til NIFI-systemet. Hele denne operation er ledsaget af en ret lang dans med en tamburin, som vi ikke vil beskæftige os med i denne artikel. Jeg valgte det groovy sprog. Nedenfor er et testscript, der blot trinvist opdaterer id'et i en SOAP-meddelelse. Det er vigtigt at bemærke. Du tager filen fra flowFile og opdaterer den, glem ikke, at du skal lægge den tilbage der, opdateret. Det er også værd at bemærke, at ikke alle biblioteker er inkluderet. Det kan ske, at du stadig skal importere en af libs. En anden ulempe er, at scriptet i denne firkant er ret svært at fejlfinde. Der er en måde at oprette forbindelse til NIFI JVM og starte fejlfindingsprocessen. Personligt lancerede jeg en lokal applikation og simulerede modtagelse af en fil fra sessionen. Jeg lavede også fejlfinding lokalt. Fejl, der vises ved indlæsning af et script, er ret nemme at Google og skrives af NIFI selv til loggen.
import org.apache.commons.io.IOUtils
import groovy.xml.XmlUtil
import java.nio.charset.*
import groovy.xml.StreamingMarkupBuilder
def flowFile = session.get()
if (!flowFile) return
try {
flowFile = session.write(flowFile, { inputStream, outputStream ->
String result = IOUtils.toString(inputStream, "UTF-8");
def recordIn = new XmlSlurper().parseText(result)
def element = recordIn.depthFirst().find {
it.name() == 'id'
}
def newId = Integer.parseInt(element.toString()) + 1
def recordOut = new XmlSlurper().parseText(result)
recordOut.Body.ClientMessage.RequestMessage.RequestContent.content.MessagePrimaryContent.ResponseBody.id = newId
def res = new StreamingMarkupBuilder().bind { mkp.yield recordOut }.toString()
outputStream.write(res.getBytes(StandardCharsets.UTF_8))
} as StreamCallback)
session.transfer(flowFile, REL_SUCCESS)
}
catch(Exception e) {
log.error("Error during processing of validate.groovy", e)
session.transfer(flowFile, REL_FAILURE)
}Faktisk er det her, tilpasningen af firkanten slutter. Dernæst overføres den opdaterede fil til firkanten, som er ansvarlig for at sende filen til serveren. Nedenfor er indstillingerne for denne firkant.
Vi beskriver den metode, hvorved en SOAP-meddelelse vil blive transmitteret. Vi skriver hvor. Dernæst skal du angive, at dette er SOAP.
Tilføj flere egenskaber såsom vært og handling (soapAction). Vi gemmer og tjekker. Du kan se flere detaljer om, hvordan du sender SOAP-anmodninger
Vi har set på flere muligheder for at bruge NIFI-processer. Hvordan interagerer de, og hvad er deres reelle fordel? De betragtede eksempler er testeksempler og er lidt forskellige fra, hvad der faktisk sker i kamp. Jeg håber, at denne artikel vil være lidt nyttig for udviklere. Tak for din opmærksomhed. Hvis du har spørgsmål, så skriv. Jeg vil prøve at svare.
Kilde: www.habr.com