Apache NIFI - پریکٹس میں مواقع کا ایک مختصر جائزہ

تعارف

ایسا ہوا کہ اپنے موجودہ کام کی جگہ پر مجھے اس ٹیکنالوجی سے واقف ہونا پڑا۔ میں ایک چھوٹے سے پس منظر سے شروع کروں گا۔ اگلی میٹنگ میں، ہماری ٹیم کو بتایا گیا کہ ہمیں اس کے ساتھ انضمام پیدا کرنے کی ضرورت ہے۔ معلوم نظام. انضمام سے اس کا مطلب یہ تھا کہ یہ معروف نظام ہمیں HTTP کے ذریعے ایک مخصوص اختتامی نقطہ پر درخواستیں بھیجے گا، اور ہم، عجیب بات ہے کہ، ایک SOAP پیغام کی شکل میں جوابات واپس بھیجیں گے۔ سب کچھ سادہ اور معمولی لگتا ہے۔ اس سے یہ مندرجہ ذیل ہے کہ آپ کو ضرورت ہے ...

ٹاسک

3 خدمات بنائیں۔ ان میں سے پہلی ڈیٹا بیس اپ ڈیٹ سروس ہے۔ یہ سروس، جب تھرڈ پارٹی سسٹم سے نیا ڈیٹا آتا ہے، ڈیٹا بیس میں ڈیٹا کو اپ ڈیٹ کرتا ہے اور اسے اگلے سسٹم میں منتقل کرنے کے لیے CSV فارمیٹ میں ایک فائل تیار کرتا ہے۔ دوسری سروس کے اختتامی نقطہ کو کہا جاتا ہے - FTP ٹرانسپورٹ سروس، جو منتقل شدہ فائل وصول کرتی ہے، اس کی توثیق کرتی ہے، اور اسے FTP کے ذریعے فائل اسٹوریج میں رکھتی ہے۔ تیسری سروس، کنزیومر ڈیٹا ٹرانسفر سروس، پہلی دو کے ساتھ متضاد طور پر کام کرتی ہے۔ اسے تیسرے فریق کے بیرونی نظام سے اوپر زیر بحث فائل وصول کرنے کی درخواست موصول ہوتی ہے، تیار جوابی فائل لی جاتی ہے، اس میں ترمیم کرتا ہے (ID، تفصیل، LinkToFile فیلڈز کو اپ ڈیٹ کرتا ہے) اور جواب SOAP پیغام کی شکل میں بھیجتا ہے۔ یعنی مجموعی تصویر کچھ یوں ہے: پہلی دو سروسز اپنا کام اسی وقت شروع کرتی ہیں جب اپ ڈیٹ کرنے کے لیے ڈیٹا آ جائے۔ تیسری سروس مسلسل کام کرتی ہے کیونکہ معلومات کے بہت سے صارفین ہیں، فی منٹ ڈیٹا کے لیے تقریباً 1000 درخواستیں ہیں۔ خدمات مسلسل دستیاب ہیں اور ان کی مثالیں مختلف ماحول میں واقع ہیں، جیسے کہ ٹیسٹ، ڈیمو، پری پروڈکشن اور پروڈکشن۔ ذیل میں ایک خاکہ ہے کہ یہ خدمات کیسے کام کرتی ہیں۔ میں فوراً واضح کرتا چلوں کہ غیر ضروری پیچیدگی سے بچنے کے لیے کچھ تفصیلات کو آسان بنایا گیا ہے۔

تکنیکی گہرا کرنا

مسئلہ کے حل کی منصوبہ بندی کرتے وقت، ہم نے سب سے پہلے جاوا میں اسپرنگ فریم ورک، نگینکس بیلنسر، پوسٹگریس ڈیٹا بیس اور دیگر تکنیکی چیزوں کا استعمال کرتے ہوئے ایپلی کیشنز بنانے کا فیصلہ کیا نہ کہ اتنی تکنیکی چیزوں کا۔ چونکہ ایک تکنیکی حل تیار کرنے کے وقت نے ہمیں اس مسئلے کو حل کرنے کے لیے دوسرے طریقوں پر غور کرنے کی اجازت دی، اس لیے ہماری نظریں اپاچی NIFI ٹیکنالوجی پر پڑیں، جو کہ بعض حلقوں میں فیشن ہے۔ میں ابھی کہوں گا کہ اس ٹیکنالوجی نے ہمیں ان 3 سروسز کو نوٹس کرنے کی اجازت دی۔ یہ مضمون فائل ٹرانسپورٹیشن سروس کی ترقی اور صارف کے لیے ڈیٹا ٹرانسفر سروس کی وضاحت کرے گا، لیکن اگر مضمون مفید ہے، تو میں ڈیٹا بیس میں ڈیٹا کو اپ ڈیٹ کرنے کی سروس کے بارے میں لکھوں گا۔

یہ کیا ہے

NIFI ڈیٹا کی تیز رفتار متوازی لوڈنگ اور پروسیسنگ، ذرائع اور تبدیلیوں کے لیے پلگ انز کی ایک بڑی تعداد، کنفیگریشنز کی ورژننگ اور بہت کچھ کے لیے ایک تقسیم شدہ فن تعمیر ہے۔ ایک اچھا بونس یہ ہے کہ اسے استعمال کرنا بہت آسان ہے۔ معمولی عمل جیسے getFile، sendHttpRequest اور دیگر کو مربع کے طور پر دکھایا جا سکتا ہے۔ ہر مربع ایک عمل کی نمائندگی کرتا ہے، جس کا تعامل ذیل کی تصویر میں دیکھا جا سکتا ہے۔ عمل کے سیٹ اپ کے تعاملات پر مزید تفصیلی دستاویزات لکھی گئی ہیں۔ یہاں روسی بولنے والوں کے لیے - یہاں. دستاویزات میں NIFI کو کھولنے اور چلانے کے طریقے کے ساتھ ساتھ پروسیس بنانے کا طریقہ بھی بتایا گیا ہے، جسے مربع بھی کہا جاتا ہے۔
ایک مضمون لکھنے کا خیال ایک طویل تلاش کے بعد پیدا ہوا اور موصول ہونے والی معلومات کو کسی ہوش میں لانے کے ساتھ ساتھ مستقبل کے ڈویلپرز کے لیے زندگی کو قدرے آسان بنانے کی خواہش کے بعد پیدا ہوا۔

مثال کے طور پر

مربع ایک دوسرے کے ساتھ کس طرح تعامل کرتا ہے اس کی ایک مثال سمجھا جاتا ہے۔ عمومی اسکیم بہت آسان ہے: ہمیں ایک HTTP درخواست موصول ہوتی ہے (نظریہ میں، درخواست کے باڈی میں ایک فائل کے ساتھ۔ NIFI کی صلاحیتوں کو ظاہر کرنے کے لیے، اس مثال میں درخواست مقامی فائل اسٹوریج سے فائل وصول کرنے کا عمل شروع کرتی ہے۔ )، پھر ہم جواب بھیجتے ہیں کہ درخواست موصول ہو گئی ہے، متوازی طور پر FH سے فائل وصول کرنے کے عمل اور پھر اسے FTP کے ذریعے FH میں منتقل کرنے کے عمل کے ساتھ۔ یہ واضح کرنے کے قابل ہے کہ عمل نام نہاد flowFile کے ذریعے ایک دوسرے کے ساتھ تعامل کرتے ہیں۔ یہ NIFI میں بنیادی ہستی ہے جو صفات اور مواد کو اسٹور کرتی ہے۔ مواد وہ ڈیٹا ہے جس کی سٹریم فائل کے ذریعے نمائندگی کی جاتی ہے۔ یعنی، موٹے طور پر، اگر آپ کو ایک مربع سے فائل موصول ہوتی ہے اور اسے دوسرے میں منتقل کرتے ہیں، تو مواد آپ کی فائل ہوگا۔

جیسا کہ آپ دیکھ سکتے ہیں، یہ تصویر عمومی عمل کو ظاہر کرتی ہے۔ HandleHttpRequest - درخواستیں قبول کرتا ہے، ReplaceText - ایک رسپانس باڈی تیار کرتا ہے، HandleHttpResponse - جواب بھیجتا ہے۔ FetchFile - فائل اسٹوریج سے فائل وصول کرتا ہے، اسے مربع PutSftp میں منتقل کرتا ہے - اس فائل کو FTP پر، مخصوص ایڈریس پر رکھتا ہے۔ اب اس عمل کے بارے میں مزید۔

اس صورت میں، درخواست ہر چیز کا آغاز ہے. آئیے اس کے کنفیگریشن پیرامیٹرز کو دیکھتے ہیں۔

StandardHttpContextMap کے استثنا کے ساتھ یہاں سب کچھ معمولی ہے - یہ ایک قسم کی خدمت ہے جو آپ کو درخواستیں بھیجنے اور وصول کرنے کی اجازت دیتی ہے۔ مزید تفصیل میں اور یہاں تک کہ مثالوں کے ساتھ، آپ دیکھ سکتے ہیں - یہاں

اگلا، آئیے مربع کے ReplaceText کنفیگریشن پیرامیٹرز کو دیکھتے ہیں۔ یہ ReplacementValue پر توجہ دینے کے قابل ہے - یہ وہی ہے جو صارف کو جواب کی شکل میں واپس کیا جائے گا۔ ترتیبات میں آپ لاگنگ کی سطح کو ایڈجسٹ کر سکتے ہیں، آپ لاگز کو دیکھ سکتے ہیں {جہاں آپ نے nifi-1.9.2/logs کو کھولا ہے، ناکامی/کامیابی کے پیرامیٹرز بھی ہیں - ان پیرامیٹرز کی بنیاد پر آپ مجموعی طور پر عمل کو منظم کر سکتے ہیں۔ . یعنی کامیاب ٹیکسٹ پروسیسنگ کی صورت میں صارف کو جواب بھیجنے کے عمل کو بلایا جائے گا، اور دوسری صورت میں ہم صرف ناکام عمل کو لاگ کریں گے۔

HandleHttpResponse پراپرٹیز میں کوئی خاص دلچسپ چیز نہیں ہے سوائے اس اسٹیٹس کے جب جواب کامیابی کے ساتھ بنایا جاتا ہے۔

ہم نے درخواست اور جواب کو ترتیب دیا ہے - آئیے فائل وصول کرنے اور اسے FTP سرور پر رکھنے کی طرف بڑھتے ہیں۔ FetchFile - ترتیبات میں بیان کردہ راستے پر ایک فائل وصول کرتا ہے اور اسے اگلے عمل میں منتقل کرتا ہے۔

اور پھر PutSftp مربع - فائل کو فائل اسٹوریج میں رکھتا ہے۔ ہم ذیل میں ترتیب کے پیرامیٹرز دیکھ سکتے ہیں۔

اس حقیقت پر توجہ دینے کے قابل ہے کہ ہر مربع ایک الگ عمل ہے جسے شروع کرنا ضروری ہے۔ ہم نے سب سے آسان مثال کو دیکھا جس میں کسی پیچیدہ تخصیص کی ضرورت نہیں ہے۔ اگلا، ہم اس عمل کو قدرے پیچیدہ دیکھیں گے، جہاں ہم نالیوں پر تھوڑا سا لکھیں گے۔

زیادہ پیچیدہ مثال

ایس او اے پی میسج میں ترمیم کے عمل کی وجہ سے صارفین کو ڈیٹا ٹرانسفر سروس کچھ زیادہ ہی پیچیدہ نکلی۔ عمومی عمل نیچے دی گئی تصویر میں دکھایا گیا ہے۔

یہاں یہ خیال بھی زیادہ پیچیدہ نہیں ہے: ہمیں صارف کی طرف سے ایک درخواست موصول ہوئی کہ اسے ڈیٹا کی ضرورت ہے، جواب بھیجا کہ اسے پیغام موصول ہوا ہے، جوابی فائل وصول کرنے کا عمل شروع کیا، پھر ایک خاص منطق کے ساتھ اس میں ترمیم کی، اور پھر صارف کو فائل کو SOAP پیغام کی صورت میں سرور پر منتقل کیا۔

میرے خیال میں ان چوکوں کو دوبارہ بیان کرنے کی ضرورت نہیں ہے جو ہم نے اوپر دیکھے ہیں - آئیے سیدھے نئے کی طرف چلتے ہیں۔ اگر آپ کو کسی فائل میں ترمیم کرنے کی ضرورت ہے اور عام ReplaceText قسم کے مربع مناسب نہیں ہیں، تو آپ کو اپنا اسکرپٹ خود لکھنا ہوگا۔ یہ ExecuteGroogyScript مربع کا استعمال کرتے ہوئے کیا جا سکتا ہے۔ اس کی ترتیبات ذیل میں پیش کی گئی ہیں۔

اس اسکوائر میں اسکرپٹ لوڈ کرنے کے دو اختیارات ہیں۔ سب سے پہلے اسکرپٹ کے ساتھ فائل ڈاؤن لوڈ کرنا ہے۔ دوسرا اسکرپٹ باڈی میں اسکرپٹ داخل کرنا ہے۔ جہاں تک میں جانتا ہوں، executeScript مربع کئی زبانوں کو سپورٹ کرتا ہے - ان میں سے ایک گرووی ہے۔ میں جاوا ڈویلپرز کو مایوس کروں گا - آپ اس طرح کے چوکوں میں جاوا میں اسکرپٹ نہیں لکھ سکتے۔ ان لوگوں کے لیے جو واقعی کرنا چاہتے ہیں، آپ کو اپنا حسب ضرورت مربع بنانا ہوگا اور اسے NIFI سسٹم میں شامل کرنا ہوگا۔ یہ سارا آپریشن دف کے ساتھ کافی لمبا رقص کے ساتھ ہے، جس سے ہم اس مضمون میں نہیں نمٹیں گے۔ میں نے گرووی زبان کا انتخاب کیا۔ ذیل میں ایک ٹیسٹ اسکرپٹ ہے جو SOAP پیغام میں آئی ڈی کو بتدریج اپ ڈیٹ کرتا ہے۔ یہ نوٹ کرنا ضروری ہے۔ آپ فلو فائل سے فائل لیتے ہیں اور اسے اپ ڈیٹ کرتے ہیں، یہ نہ بھولیں کہ آپ کو اسے دوبارہ وہاں رکھنے کی ضرورت ہے، اپڈیٹ۔ یہ بات بھی قابل غور ہے کہ تمام لائبریریاں شامل نہیں ہیں۔ یہ ہو سکتا ہے کہ آپ کو اب بھی لبوں میں سے ایک درآمد کرنا پڑے۔ ایک اور منفی پہلو یہ ہے کہ اس مربع میں اسکرپٹ کو ڈیبگ کرنا کافی مشکل ہے۔ NIFI JVM سے جڑنے اور ڈیبگنگ کا عمل شروع کرنے کا ایک طریقہ ہے۔ ذاتی طور پر، میں نے ایک مقامی ایپلیکیشن شروع کی اور سیشن سے فائل وصول کرنے کی نقل تیار کی۔ میں نے مقامی طور پر ڈیبگنگ بھی کی۔ اسکرپٹ لوڈ کرتے وقت ظاہر ہونے والی خرابیاں گوگل کے لیے کافی آسان ہیں اور خود NIFI کے ذریعے لاگ میں لکھی جاتی ہیں۔

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)
}

دراصل، یہ وہ جگہ ہے جہاں مربع کی تخصیص ختم ہوتی ہے۔ اگلا، اپ ڈیٹ شدہ فائل کو مربع میں منتقل کیا جاتا ہے، جو فائل کو سرور کو بھیجنے کا ذمہ دار ہے۔ ذیل میں اس مربع کی ترتیبات ہیں۔

ہم اس طریقہ کی وضاحت کرتے ہیں جس کے ذریعے SOAP پیغام منتقل کیا جائے گا۔ ہم کہاں لکھتے ہیں۔ اگلا آپ کو یہ بتانے کی ضرورت ہے کہ یہ صابن ہے۔

متعدد خصوصیات شامل کریں جیسے میزبان اور ایکشن (صابن ایکشن)۔ ہم محفوظ کرتے ہیں اور چیک کرتے ہیں۔ آپ SOAP کی درخواستیں بھیجنے کے طریقے کے بارے میں مزید تفصیلات دیکھ سکتے ہیں۔ یہاں

ہم نے NIFI کے عمل کو استعمال کرنے کے لیے کئی اختیارات کو دیکھا۔ وہ کس طرح بات چیت کرتے ہیں اور ان کا حقیقی فائدہ کیا ہے؟ جن مثالوں پر غور کیا جاتا ہے وہ آزمائشی ہیں اور اس سے قدرے مختلف ہیں جو دراصل لڑائی میں ہوتا ہے۔ مجھے امید ہے کہ یہ مضمون ڈویلپرز کے لیے تھوڑا کارآمد ثابت ہوگا۔ آپکی توجہ کا شکریہ. اگر آپ کے ذہن میں کوئی سوال ہے تو لکھیں۔ میں جواب دینے کی کوشش کروں گا۔

ماخذ: www.habr.com