Apache NIFI - ພາບລວມໂດຍຫຍໍ້ຂອງຄຸນນະສົມບັດໃນການປະຕິບັດ

ການນໍາສະເຫນີ

ມັນເກີດຂຶ້ນດັ່ງນັ້ນໃນບ່ອນເຮັດວຽກຂອງຂ້ອຍໃນປັດຈຸບັນຂ້ອຍຕ້ອງຮູ້ຈັກກັບເຕັກໂນໂລຢີນີ້. ຂ້ອຍຈະເລີ່ມຕົ້ນດ້ວຍພື້ນຖານເລັກນ້ອຍ. ໃນກອງປະຊຸມຕໍ່ໄປ, ທີມງານຂອງພວກເຮົາໄດ້ຖືກບອກວ່າພວກເຮົາຈໍາເປັນຕ້ອງສ້າງການປະສົມປະສານກັບ ລະ​ບົບ​ທີ່​ຮູ້​ຈັກ​. ໂດຍການລວມຕົວມັນຫມາຍຄວາມວ່າລະບົບທີ່ມີຊື່ສຽງນີ້ຈະສົ່ງຄໍາຮ້ອງຂໍໃຫ້ພວກເຮົາຜ່ານ HTTP ໄປຫາຈຸດສິ້ນສຸດສະເພາະ, ແລະພວກເຮົາ, ຜິດປົກກະຕິພຽງພໍ, ຈະສົ່ງຄໍາຕອບຄືນໃນຮູບແບບຂອງຂໍ້ຄວາມ SOAP. ທຸກສິ່ງທຸກຢ່າງເບິ່ງຄືວ່າງ່າຍດາຍແລະ trivial. ຈາກນີ້, ມັນດັ່ງຕໍ່ໄປນີ້ທີ່ທ່ານຕ້ອງການ ...

ຈຸດປະສົງ

ສ້າງ 3 ບໍລິການ. ທໍາອິດຂອງພວກເຂົາແມ່ນການບໍລິການປັບປຸງຖານຂໍ້ມູນ. ການບໍລິການນີ້, ເມື່ອຂໍ້ມູນໃຫມ່ມາຮອດຈາກລະບົບພາກສ່ວນທີສາມ, ປັບປຸງຂໍ້ມູນໃນຖານຂໍ້ມູນແລະສ້າງໄຟລ໌ໃນຮູບແບບ CSV ເພື່ອໂອນມັນໄປສູ່ລະບົບຕໍ່ໄປ. ຈຸດສິ້ນສຸດຂອງບໍລິການທີສອງຖືກເອີ້ນວ່າ - ບໍລິການຂົນສົ່ງ FTP, ເຊິ່ງໄດ້ຮັບໄຟລ໌ທີ່ຖືກໂອນ, ກວດສອບມັນ, ແລະວາງໄວ້ໃນບ່ອນເກັບຂໍ້ມູນຜ່ານ FTP. ການບໍລິການທີສາມ, ການບໍລິການໂອນຂໍ້ມູນຜູ້ບໍລິໂພກ, ເຮັດວຽກ asynchronously ກັບສອງຄັ້ງທໍາອິດ. ມັນໄດ້ຮັບການຮ້ອງຂໍຈາກລະບົບພາຍນອກຂອງພາກສ່ວນທີສາມທີ່ຈະໄດ້ຮັບໄຟລ໌ທີ່ສົນທະນາຂ້າງເທິງ, ເອົາໄຟລ໌ຕອບສະຫນອງທີ່ກຽມພ້ອມ, ດັດແປງມັນ (ປັບປຸງ id, ລາຍລະອຽດ, linkToFile ພາກສະຫນາມ) ແລະສົ່ງຄໍາຕອບໃນຮູບແບບຂອງຂໍ້ຄວາມ SOAP. ນັ້ນແມ່ນ, ຮູບພາບລວມແມ່ນດັ່ງຕໍ່ໄປນີ້: ສອງບໍລິການທໍາອິດເລີ່ມຕົ້ນການເຮັດວຽກຂອງພວກເຂົາພຽງແຕ່ເມື່ອຂໍ້ມູນສໍາລັບການປັບປຸງມາຮອດ. ການບໍລິການທີສາມເຮັດວຽກຢ່າງຕໍ່ເນື່ອງເນື່ອງຈາກວ່າມີຜູ້ບໍລິໂພກຂໍ້ມູນຈໍານວນຫຼາຍ, ປະມານ 1000 ຄໍາຮ້ອງຂໍຂໍ້ມູນຕໍ່ນາທີ. ການບໍລິການແມ່ນມີຢູ່ຕະຫຼອດເວລາ ແລະຕົວຢ່າງຂອງພວກມັນຕັ້ງຢູ່ໃນສະພາບແວດລ້ອມຕ່າງໆເຊັ່ນ: ການທົດສອບ, ການສາທິດ, ການຜະລິດກ່ອນການຜະລິດ ແລະຜະລິດຕະພັນ. ຂ້າງລຸ່ມນີ້ແມ່ນແຜນວາດຂອງວິທີການບໍລິການເຫຼົ່ານີ້ເຮັດວຽກ. ຂໍໃຫ້ຂ້າພະເຈົ້າຊີ້ແຈງທັນທີວ່າບາງລາຍລະອຽດໄດ້ຖືກເຮັດໃຫ້ງ່າຍດາຍເພື່ອຫຼີກເວັ້ນການສັບສົນທີ່ບໍ່ຈໍາເປັນ.

ການລົງເລິກດ້ານວິຊາການ

ເມື່ອວາງແຜນການແກ້ໄຂບັນຫາ, ພວກເຮົາທໍາອິດຕັດສິນໃຈເຮັດຄໍາຮ້ອງສະຫມັກໃນ Java ໂດຍໃຊ້ກອບ Spring, Nginx balancer, ຖານຂໍ້ມູນ Postgres ແລະດ້ານວິຊາການອື່ນໆແລະບໍ່ແມ່ນສິ່ງດ້ານວິຊາການ. ນັບຕັ້ງແຕ່ເວລາທີ່ຈະພັດທະນາການແກ້ໄຂທາງວິຊາການໄດ້ອະນຸຍາດໃຫ້ພວກເຮົາພິຈາລະນາວິທີການອື່ນໆເພື່ອແກ້ໄຂບັນຫານີ້, ການເບິ່ງຂອງພວກເຮົາໄດ້ຕົກຢູ່ໃນເທກໂນໂລຍີ Apache NIFI, ເຊິ່ງເປັນຄົນອັບເດດ: ໃນບາງວົງ. ຂ້ອຍຈະເວົ້າທັນທີວ່າເທກໂນໂລຍີນີ້ອະນຸຍາດໃຫ້ພວກເຮົາສັງເກດເຫັນ 3 ບໍລິການເຫຼົ່ານີ້. ບົດຄວາມນີ້ຈະອະທິບາຍເຖິງການພັດທະນາການບໍລິການຂົນສົ່ງໄຟລ໌ແລະການບໍລິການໂອນຂໍ້ມູນໃຫ້ກັບຜູ້ບໍລິໂພກ, ແຕ່ຖ້າບົດຄວາມເປັນປະໂຫຍດ, ຂ້ອຍຈະຂຽນກ່ຽວກັບການບໍລິການສໍາລັບການປັບປຸງຂໍ້ມູນໃນຖານຂໍ້ມູນ.

ມັນເປັນແນວໃດ?

NIFI ເປັນສະຖາປັດຕະຍະກໍາທີ່ແຈກຢາຍສໍາລັບການໂຫຼດຂະຫນານທີ່ໄວແລະການປຸງແຕ່ງຂໍ້ມູນ, ຈໍານວນຫລາຍຂອງ plugins ສໍາລັບແຫຼ່ງແລະການຫັນປ່ຽນ, ຮຸ່ນຂອງການຕັ້ງຄ່າແລະອື່ນໆອີກ. A ໂບນັດງາມແມ່ນວ່າມັນແມ່ນງ່າຍຫຼາຍທີ່ຈະນໍາໃຊ້. ຂະບວນການເລັກນ້ອຍເຊັ່ນ getFile, sendHttpRequest ແລະອື່ນໆສາມາດຖືກສະແດງເປັນສີ່ຫລ່ຽມ. ແຕ່ລະຮູບສີ່ຫຼ່ຽມມົນສະແດງເຖິງຂະບວນການ, ການໂຕ້ຕອບຂອງທີ່ສາມາດເບິ່ງໄດ້ໃນຮູບຂ້າງລຸ່ມນີ້. ເອກະສານລາຍລະອຽດເພີ່ມເຕີມກ່ຽວກັບການໂຕ້ຕອບການຕັ້ງຄ່າຂະບວນການໄດ້ຖືກຂຽນໄວ້ ທີ່ນີ້ , ສໍາລັບຜູ້ທີ່ເວົ້າພາສາລັດເຊຍ - ທີ່ນີ້. ເອກະສານອະທິບາຍຢ່າງສົມບູນກ່ຽວກັບວິທີປົດລ໋ອກ ແລະ ແລ່ນ NIFI, ເຊັ່ນດຽວກັນກັບວິທີການສ້າງຂະບວນການ, ເຊິ່ງເອີ້ນກັນວ່າສີ່ຫຼ່ຽມມົນ.
ຄວາມຄິດທີ່ຈະຂຽນບົດຄວາມໄດ້ເກີດມາຫຼັງຈາກການຄົ້ນຫາທີ່ຍາວນານແລະໂຄງສ້າງຂໍ້ມູນທີ່ໄດ້ຮັບເຂົ້າໄປໃນສິ່ງທີ່ມີສະຕິ, ເຊັ່ນດຽວກັນກັບຄວາມປາຖະຫນາທີ່ຈະເຮັດໃຫ້ຊີວິດງ່າຍຂຶ້ນສໍາລັບນັກພັດທະນາໃນອະນາຄົດ..

ຕົວຢ່າງ:

ຕົວຢ່າງຂອງວິທີການສີ່ຫລ່ຽມພົວພັນກັບກັນແລະກັນຖືກພິຈາລະນາ. ໂຄງການທົ່ວໄປແມ່ນຂ້ອນຂ້າງງ່າຍດາຍ: ພວກເຮົາໄດ້ຮັບການຮ້ອງຂໍ HTTP (ໃນທາງທິດສະດີ, ມີໄຟລ໌ຢູ່ໃນຕົວຂອງຄໍາຮ້ອງຂໍ. ເພື່ອສະແດງໃຫ້ເຫັນຄວາມສາມາດຂອງ NIFI, ໃນຕົວຢ່າງນີ້ຄໍາຮ້ອງຂໍເລີ່ມຕົ້ນຂະບວນການຮັບໄຟລ໌ຈາກການເກັບຮັກສາໄຟລ໌ທ້ອງຖິ່ນ. ), ຫຼັງຈາກນັ້ນພວກເຮົາສົ່ງຄືນຄໍາຕອບທີ່ຄໍາຮ້ອງຂໍໄດ້ຮັບ, ໃນຂະຫນານຂະບວນການໄດ້ຮັບໄຟລ໌ຈາກ FH ແລະຫຼັງຈາກນັ້ນຂະບວນການຍ້າຍມັນຜ່ານ FTP ກັບ FH. ມັນເປັນມູນຄ່າທີ່ຈະແຈ້ງວ່າຂະບວນການພົວພັນກັບກັນແລະກັນໂດຍຜ່ານອັນທີ່ເອີ້ນວ່າ flowFile. ນີ້ແມ່ນຫົວໜ່ວຍພື້ນຖານໃນ NIFI ທີ່ເກັບຮັກສາຄຸນລັກສະນະ ແລະເນື້ອຫາ. ເນື້ອຫາແມ່ນຂໍ້ມູນທີ່ສະແດງໂດຍໄຟລ໌ສະຕຣີມ. ນັ້ນແມ່ນ, ເວົ້າປະມານ, ຖ້າທ່ານໄດ້ຮັບໄຟລ໌ຈາກສີ່ຫລ່ຽມຫນຶ່ງແລະໂອນມັນໄປຫາບ່ອນອື່ນ, ເນື້ອຫາຈະເປັນໄຟລ໌ຂອງທ່ານ.

ດັ່ງທີ່ທ່ານສາມາດເຫັນໄດ້, ຮູບພາບນີ້ສະແດງໃຫ້ເຫັນເຖິງຂະບວນການທົ່ວໄປ. HandleHttpRequest - ຍອມຮັບການຮ້ອງຂໍ, ReplaceText - ສ້າງຮ່າງກາຍຕອບສະຫນອງ, HandleHttpResponse - ສົ່ງຄໍາຕອບ. FetchFile - ໄດ້ຮັບໄຟລ໌ຈາກການເກັບຮັກສາໄຟລ໌, ໂອນມັນໄປຫາສີ່ຫຼ່ຽມ PutSftp - ເອົາໄຟລ໌ນີ້ໃສ່ FTP, ຢູ່ທີ່ທີ່ຢູ່ທີ່ກໍານົດໄວ້. ໃນປັດຈຸບັນເພີ່ມເຕີມກ່ຽວກັບຂະບວນການນີ້.

ໃນກໍລະນີນີ້, ການຮ້ອງຂໍແມ່ນການເລີ່ມຕົ້ນຂອງທຸກສິ່ງທຸກຢ່າງ. ໃຫ້ເບິ່ງຢູ່ໃນຕົວກໍານົດການການຕັ້ງຄ່າຂອງມັນ.

ທຸກສິ່ງທຸກຢ່າງຢູ່ທີ່ນີ້ຂ້ອນຂ້າງເປັນເລື່ອງເລັກໆນ້ອຍໆຍົກເວັ້ນ StandardHttpContextMap - ນີ້ແມ່ນປະເພດຂອງການບໍລິການທີ່ຊ່ວຍໃຫ້ທ່ານສົ່ງແລະຮັບຄໍາຮ້ອງຂໍ. ໃນລາຍລະອຽດເພີ່ມເຕີມແລະເຖິງແມ່ນວ່າມີຕົວຢ່າງ, ທ່ານສາມາດເບິ່ງ - ທີ່ນີ້

ຕໍ່ໄປ, ໃຫ້ເບິ່ງຕົວກໍານົດການການຕັ້ງຄ່າ ReplaceText ຂອງສີ່ຫຼ່ຽມມົນ. ມັນເປັນມູນຄ່າທີ່ຈະເອົາໃຈໃສ່ກັບ ReplacementValue - ນີ້ແມ່ນສິ່ງທີ່ຈະຖືກສົ່ງກັບຜູ້ໃຊ້ໃນຮູບແບບການຕອບສະຫນອງ. ໃນການຕັ້ງຄ່າທ່ານສາມາດປັບລະດັບຂອງການບັນທຶກ, ທ່ານສາມາດເບິ່ງບັນທຶກໄດ້ {ບ່ອນທີ່ທ່ານ unpacked nifi}/nifi-1.9.2/logs, ຍັງມີຕົວກໍານົດການລົ້ມເຫຼວ / ຄວາມສໍາເລັດ - ອີງຕາມຕົວກໍານົດການເຫຼົ່ານີ້ທ່ານສາມາດຄວບຄຸມຂະບວນການທັງຫມົດ. . ນັ້ນແມ່ນ, ໃນກໍລະນີຂອງການປຸງແຕ່ງຂໍ້ຄວາມທີ່ປະສົບຜົນສໍາເລັດ, ຂະບວນການສົ່ງຄໍາຕອບກັບຜູ້ໃຊ້ຈະຖືກເອີ້ນ, ແລະໃນກໍລະນີອື່ນພວກເຮົາຈະພຽງແຕ່ເຂົ້າສູ່ລະບົບຂະບວນການທີ່ບໍ່ສໍາເລັດ.

ບໍ່ມີຫຍັງທີ່ຫນ້າສົນໃຈໂດຍສະເພາະໃນຄຸນສົມບັດ HandleHttpResponse ຍົກເວັ້ນສະຖານະເມື່ອການຕອບສະຫນອງຖືກສ້າງຂື້ນຢ່າງສໍາເລັດຜົນ.

ພວກເຮົາໄດ້ຈັດຮຽງຄໍາຮ້ອງຂໍແລະການຕອບສະຫນອງ - ໃຫ້ພວກເຮົາກ້າວໄປສູ່ການຮັບໄຟລ໌ແລະວາງມັນຢູ່ໃນເຄື່ອງແມ່ຂ່າຍ FTP. FetchFile - ໄດ້ຮັບໄຟລ໌ຢູ່ໃນເສັ້ນທາງທີ່ລະບຸໄວ້ໃນການຕັ້ງຄ່າແລະສົ່ງມັນໄປຫາຂະບວນການຕໍ່ໄປ.

ແລະຫຼັງຈາກນັ້ນສີ່ຫຼ່ຽມ PutSftp - ວາງໄຟລ໌ໃນການເກັບຮັກສາໄຟລ໌. ພວກເຮົາສາມາດເບິ່ງຕົວກໍານົດການກໍາຫນົດຄ່າຂ້າງລຸ່ມນີ້.

ມັນເປັນມູນຄ່າທີ່ຈະເອົາໃຈໃສ່ກັບຄວາມຈິງທີ່ວ່າແຕ່ລະສີ່ຫລ່ຽມແມ່ນຂະບວນການແຍກຕ່າງຫາກທີ່ຕ້ອງໄດ້ຮັບການເປີດຕົວ. ພວກເຮົາໄດ້ເບິ່ງຕົວຢ່າງທີ່ງ່າຍດາຍທີ່ສຸດທີ່ບໍ່ຈໍາເປັນຕ້ອງມີການປັບແຕ່ງທີ່ສັບສົນ. ຕໍ່ໄປ, ພວກເຮົາຈະເບິ່ງຂະບວນການທີ່ສັບສົນເລັກນ້ອຍ, ບ່ອນທີ່ພວກເຮົາຈະຂຽນເລັກນ້ອຍໃນຮ່ອງ.

ຕົວຢ່າງທີ່ສັບສົນຫຼາຍ

ການ​ບໍ​ລິ​ການ​ໂອນ​ຂໍ້​ມູນ​ໃຫ້​ຜູ້​ບໍ​ລິ​ໂພກ​ໄດ້​ຫັນ​ອອກ​ຈະ​ເປັນ​ພຽງ​ເລັກ​ນ້ອຍ​ສັບ​ສົນ​ເນື່ອງ​ຈາກ​ຂະ​ບວນ​ການ​ຂອງ​ການ​ປັບ​ປຸງ​ຂໍ້​ຄວາມ SOAP ໄດ້​. ຂະບວນການທົ່ວໄປແມ່ນສະແດງຢູ່ໃນຮູບຂ້າງລຸ່ມນີ້.

ໃນທີ່ນີ້ແນວຄວາມຄິດແມ່ນບໍ່ສັບສົນໂດຍສະເພາະ: ພວກເຮົາໄດ້ຮັບຄໍາຮ້ອງຂໍຈາກຜູ້ບໍລິໂພກວ່າລາວຕ້ອງການຂໍ້ມູນ, ສົ່ງຄໍາຕອບທີ່ລາວໄດ້ຮັບຂໍ້ຄວາມ, ເລີ່ມຕົ້ນຂະບວນການໄດ້ຮັບໄຟລ໌ຕອບສະຫນອງ, ຫຼັງຈາກນັ້ນແກ້ໄຂມັນດ້ວຍເຫດຜົນທີ່ແນ່ນອນ, ແລະຫຼັງຈາກນັ້ນ. ໂອນໄຟລ໌ໄປຫາຜູ້ບໍລິໂພກໃນຮູບແບບຂອງຂໍ້ຄວາມ SOAP ກັບເຄື່ອງແມ່ຂ່າຍ.

ຂ້າພະເຈົ້າຄິດວ່າບໍ່ຈໍາເປັນຕ້ອງອະທິບາຍອີກສີ່ຫຼ່ຽມສີ່ຫຼ່ຽມເຫຼົ່ານີ້ທີ່ພວກເຮົາເຫັນຂ້າງເທິງ - ໃຫ້ພວກເຮົາຍ້າຍໄປຊື່ໃຫມ່. ຖ້າທ່ານຕ້ອງການແກ້ໄຂໄຟລ໌ໃດໆແລະສີ່ຫລ່ຽມ ReplaceText ທໍາມະດາແມ່ນບໍ່ເຫມາະສົມ, ທ່ານຈະຕ້ອງຂຽນສະຄິບຂອງທ່ານເອງ. ອັນນີ້ສາມາດເຮັດໄດ້ໂດຍໃຊ້ ExecuteGroogyScript square. ການຕັ້ງຄ່າຂອງມັນໄດ້ຖືກນໍາສະເຫນີຂ້າງລຸ່ມນີ້.

ມີສອງທາງເລືອກໃນການໂຫລດສະຄິບເຂົ້າໄປໃນສີ່ຫຼ່ຽມນີ້. ທໍາອິດແມ່ນໂດຍການດາວໂຫຼດໄຟລ໌ທີ່ມີ script. ອັນທີສອງແມ່ນໂດຍການໃສ່ script ເຂົ້າໄປໃນ scriptBody. ເທົ່າທີ່ຂ້ອຍຮູ້, executeScript square ສະຫນັບສະຫນູນຫລາຍພາສາ - ຫນຶ່ງໃນນັ້ນແມ່ນ groovy. ຂ້ອຍຈະຜິດຫວັງກັບນັກພັດທະນາ java - ທ່ານບໍ່ສາມາດຂຽນສະຄິບໃນ java ໃນສີ່ຫຼ່ຽມດັ່ງກ່າວ. ສໍາລັບຜູ້ທີ່ຕ້ອງການແທ້ໆ, ທ່ານຈໍາເປັນຕ້ອງສ້າງສີ່ຫລ່ຽມທີ່ກໍາຫນົດເອງຂອງທ່ານເອງແລະເພີ່ມມັນໃສ່ລະບົບ NIFI. ການປະຕິບັດງານທັງຫມົດນີ້ແມ່ນປະກອບດ້ວຍການເຕັ້ນທີ່ຍາວນານກັບ tambourine, ເຊິ່ງພວກເຮົາຈະບໍ່ຈັດການກັບໃນບົດຄວາມນີ້. ຂ້ອຍເລືອກພາສາ groovy. ຂ້າງລຸ່ມນີ້ແມ່ນສະຄຣິບທົດສອບທີ່ພຽງແຕ່ເພີ່ມການປັບປຸງ id ໃນຂໍ້ຄວາມ SOAP. ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະສັງເກດ. ທ່ານເອົາໄຟລ໌ຈາກ flowFile ແລະປັບປຸງມັນ, ຢ່າລືມວ່າທ່ານຈໍາເປັນຕ້ອງເອົາມັນກັບຄືນໄປບ່ອນນັ້ນ, ປັບປຸງ. ມັນຍັງເປັນມູນຄ່າທີ່ສັງເກດວ່າບໍ່ແມ່ນຫ້ອງສະຫມຸດທັງຫມົດຖືກລວມເຂົ້າ. ມັນອາດຈະເກີດຂື້ນວ່າທ່ານຍັງຕ້ອງນໍາເຂົ້າຫນຶ່ງໃນ libs. ການຫຼຸດລົງອີກອັນຫນຶ່ງແມ່ນວ່າ script ໃນສີ່ຫຼ່ຽມນີ້ແມ່ນຂ້ອນຂ້າງຍາກທີ່ຈະດີບັກ. ມີວິທີການເຊື່ອມຕໍ່ກັບ NIFI JVM ແລະເລີ່ມຕົ້ນຂະບວນການ debugging ໄດ້. ສ່ວນບຸກຄົນ, ຂ້າພະເຈົ້າໄດ້ເປີດຕົວຄໍາຮ້ອງສະຫມັກໃນທ້ອງຖິ່ນແລະຈໍາລອງການໄດ້ຮັບໄຟລ໌ຈາກກອງປະຊຸມ. ຂ້ອຍຍັງໄດ້ແກ້ບັນຫາຢູ່ໃນທ້ອງຖິ່ນ. ຂໍ້ຜິດພາດທີ່ປາກົດໃນເວລາໂຫລດສະຄິບແມ່ນຂ້ອນຂ້າງງ່າຍຕໍ່ Google ແລະຖືກຂຽນໂດຍ 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.

ເພີ່ມຄຸນສົມບັດຫຼາຍຢ່າງເຊັ່ນ: ເຈົ້າພາບແລະການປະຕິບັດ (soapAction). ພວກເຮົາບັນທຶກແລະກວດສອບ. ທ່ານສາມາດເບິ່ງລາຍລະອຽດເພີ່ມເຕີມກ່ຽວກັບວິທີສົ່ງຄໍາຮ້ອງຂໍ SOAP ທີ່ນີ້

ພວກເຮົາໄດ້ເບິ່ງຫຼາຍທາງເລືອກສໍາລັບການນໍາໃຊ້ຂະບວນການ NIFI. ເຂົາເຈົ້າມີການພົວພັນກັນແນວໃດ ແລະຜົນປະໂຫຍດທີ່ແທ້ຈິງຂອງພວກມັນແມ່ນຫຍັງ? ຕົວຢ່າງທີ່ພິຈາລະນາແມ່ນການທົດສອບແລະແຕກຕ່າງກັນເລັກນ້ອຍຈາກສິ່ງທີ່ເກີດຂື້ນໃນການຕໍ່ສູ້. ຂ້າພະເຈົ້າຫວັງວ່າບົດຄວາມນີ້ຈະເປັນປະໂຫຍດພຽງເລັກນ້ອຍສໍາລັບນັກພັດທະນາ. ຂອບໃຈສໍາລັບຄວາມສົນໃຈຂອງທ່ານ. ຖ້າທ່ານມີຄໍາຖາມໃດໆ, ຂຽນ. ຂ້ອຍຈະພະຍາຍາມຕອບ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com