Увод
Десило се да сам на мом садашњем радном месту морао да се упознам са овом технологијом. Почећу са мало позадине. На следећем састанку, нашем тиму је речено да треба да направимо интеграцију са познати систем. Под интеграцијом се подразумевало да ће нам овај добро познати систем слати захтеве преко ХТТП-а до одређене крајње тачке, а ми бисмо, зачудо, враћали одговоре у облику СОАП поруке. Све изгледа једноставно и тривијално. Из овога следи да вам је потребно...
Задатак
Направите 3 услуге. Први од њих је услуга ажурирања базе података. Ова услуга, када стигну нови подаци из система треће стране, ажурира податке у бази података и генерише датотеку у ЦСВ формату да би је пренела на следећи систем. Крајња тачка другог сервиса се зове - ФТП транспортна услуга, која прима пренесену датотеку, потврђује је и ставља је у складиште датотека преко ФТП-а. Трећи сервис, услуга преноса података потрошача, ради асинхроно са прве две. Он прима захтев од спољног система треће стране да прими датотеку о којој смо горе говорили, узима датотеку спремног одговора, мења је (ажурира ид, опис, линкТоФиле поља) и шаље одговор у облику СОАП поруке. Односно, укупна слика је следећа: прве две службе почињу са радом тек када стигну подаци за ажурирање. Трећи сервис ради стално јер има много потрошача информација, око 1000 захтева за подацима у минути. Услуге су стално доступне и њихове инстанце се налазе у различитим окружењима, као што су тест, демо, предпродукција и продукција. Испод је дијаграм како ове услуге функционишу. Одмах да појасним да су неки детаљи поједностављени како би се избегла непотребна сложеност.
Тецхницал Деепенинг
Када смо планирали решење проблема, прво смо одлучили да направимо апликације у Јави користећи Спринг фрамеворк, Нгинк баланцер, Постгрес базу података и друге техничке и не баш техничке ствари. Пошто нам је време за развој техничког решења омогућило да размотримо и друге приступе решавању овог проблема, наш је поглед пао на Апацхе НИФИ технологију, која је модерна у одређеним круговима. Одмах ћу рећи да нам је ова технологија омогућила да приметимо ове 3 услуге. Овај чланак ће описати развој услуге транспорта датотека и услуге преноса података до потрошача, али ако је чланак користан, писаћу о сервису за ажурирање података у бази података.
Шта је ово
НИФИ је дистрибуирана архитектура за брзо паралелно учитавање и обраду података, велики број додатака за изворе и трансформације, верзионисање конфигурација и још много тога. Добар бонус је што је веома једноставан за коришћење. Тривијални процеси као што су гетФиле, сендХттпРекуест и други могу бити представљени као квадрати. Сваки квадрат представља процес чија се интеракција може видети на слици испод. Написана је детаљнија документација о интеракцијама подешавања процеса , за оне који говоре руски - . Документација савршено описује како да распакујете и покренете НИФИ, као и како да креирате процесе, такође познате као квадрати
Идеја да се напише чланак родила се након дугог тражења и структурирања добијених информација у нешто свесно, као и жеље да се будућим програмерима мало олакша живот.
Пример
Разматран је пример како квадрати међусобно делују. Општа шема је прилично једноставна: примамо ХТТП захтев (у теорији, са датотеком у телу захтева. Да бисмо демонстрирали могућности НИФИ-а, у овом примеру захтев покреће процес пријема датотеке из локалног складишта датотека ), затим шаљемо назад одговор да је захтев примљен, паралелно са процесом пријема фајла од ФХ и затим процесом његовог премештања преко ФТП-а у ФХ. Вреди појаснити да процеси међусобно комуницирају преко такозваног фловФиле-а. Ово је основни ентитет у НИФИ који чува атрибуте и садржај. Садржај је податак који представља датотека стрима. То јест, грубо говорећи, ако добијете датотеку из једног квадрата и пренесете је у други, садржај ће бити ваш фајл.
Као што видите, ова слика приказује општи процес. ХандлеХттпРекуест - прихвата захтеве, РеплацеТект - генерише тело одговора, ХандлеХттпРеспонсе - шаље одговор. ФетцхФиле - прима датотеку из складишта датотека, преноси је у квадрат ПутСфтп - ставља ову датотеку на ФТП, на наведену адресу. Сада више о овом процесу.
У овом случају, захтев је почетак свега. Хајде да погледамо његове конфигурационе параметре.
Овде је све прилично тривијално са изузетком СтандардХттпЦонтектМап - ово је врста услуге која вам омогућава да шаљете и примате захтеве. Детаљније, па чак и са примерима, можете видети -
Затим, погледајмо конфигурационе параметре квадрата РеплацеТект. Вреди обратити пажњу на РеплацементВалуе - то је оно што ће бити враћено кориснику у облику одговора. У подешавањима можете подесити ниво евидентирања, можете видети логове {где сте распаковали нифи}/нифи-1.9.2/логове, ту су и параметри неуспеха/успеха - на основу ових параметара можете регулисати процес у целини . То јест, у случају успешне обраде текста, биће позван процес слања одговора кориснику, ау другом случају ћемо једноставно евидентирати неуспешан процес.
Нема ничег посебно занимљивог у својствима ХандлеХттпРеспонсе осим статуса када је одговор успешно креиран.
Средили смо захтев и одговор - пређимо на пријем фајла и његово постављање на ФТП сервер. ФетцхФиле - прима датотеку на путањи наведеној у подешавањима и прослеђује је следећем процесу.
А затим ПутСфтп квадрат - поставља датотеку у складиште датотека. У наставку можемо видети параметре конфигурације.
Вреди обратити пажњу на чињеницу да је сваки квадрат посебан процес који се мора покренути. Погледали смо најједноставнији пример који не захтева никакво сложено прилагођавање. Затим ћемо процес погледати мало компликованији, где ћемо мало писати о жлебовима.
Сложенији пример
Испоставило се да је услуга преноса података до потрошача мало компликованија због процеса модификације СОАП поруке. Општи процес је приказан на слици испод.
Овде идеја такође није посебно компликована: добили смо захтев од потрошача да су му потребни подаци, послали одговор да је добио поруку, покренули процес пријема датотеке одговора, затим смо је уредили одређеном логиком, а затим пренео датотеку до потрошача у облику СОАП поруке на сервер.
Мислим да нема потребе да поново описујемо оне квадрате које смо видели горе - пређимо право на нове. Ако треба да измените било коју датотеку, а обични квадрати типа РеплацеТект нису прикладни, мораћете да напишете сопствену скрипту. Ово се може урадити помоћу квадрата ЕкецутеГроогиСцрипт. Његова подешавања су представљена у наставку.
Постоје две опције за учитавање скрипте у овај квадрат. Први је преузимањем датотеке са скриптом. Други је уметањем скрипте у сцриптБоди. Колико ја знам, квадрат екецутеСцрипт подржава неколико језика - један од њих је гроови. Разочараћу Јава програмере - не можете писати скрипте у Јави у таквим квадратима. За оне који то заиста желе, потребно је да креирате сопствени квадрат и додате га у НИФИ систем. Цела ова операција је праћена прилично дугим плесом са тамбуром, о чему се нећемо бавити у овом чланку. Изабрао сам гроови језик. Испод је тест скрипта која једноставно постепено ажурира ИД у СОАП поруци. Важно је напоменути. Узимате датотеку из фловФиле-а и ажурирате је, не заборавите да морате да је вратите тамо, ажурирану. Такође је вредно напоменути да нису укључене све библиотеке. Може се десити да ипак морате да увезете једну од библиотека. Још један недостатак је што је скрипту у овом квадрату прилично тешко отклонити. Постоји начин да се повежете на НИФИ ЈВМ и покренете процес отклањања грешака. Лично сам покренуо локалну апликацију и симулирао пријем датотеке са сесије. Такође сам локално исправљао грешке. Грешке које се појављују приликом учитавања скрипте су прилично једноставне за Гоогле и НИФИ их сам уписује у дневник.
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)
}Заправо, ту се завршава прилагођавање квадрата. Затим се ажурирана датотека преноси на квадрат, који је одговоран за слање датотеке на сервер. Испод су подешавања за овај квадрат.
Описујемо метод којим ће се СОАП порука пренети. Пишемо где. Затим морате назначити да је ово СОАП.
Додајте неколико својстава као што су хост и акција (соапАцтион). Чувамо и проверавамо. Можете видети више детаља о томе како да пошаљете СОАП захтеве
Размотрили смо неколико опција за коришћење НИФИ процеса. Како они комуницирају и која је њихова стварна корист? Разматрани примери су тестни и мало се разликују од онога што се стварно дешава у борби. Надам се да ће овај чланак бити мало користан за програмере. Хвала на пажњи. Ако имате питања, пишите. Покушаћу да одговорим.
Извор: ввв.хабр.цом