👬 👼 🎨 हमने अपना वर्कफ़्लो इंजन कैसे बनाया 🕺🏽 😿 👩🏻‍⚕️

DIRECTUM में, हम DirectumRX ECM प्रणाली विकसित कर रहे हैं। ईसीएम प्रणाली के लिए वर्कफ़्लो मॉड्यूल का मुख्य तत्व इंजन है। वह जीवन चक्र के दौरान प्रक्रिया उदाहरण (उदाहरण) की स्थिति को बदलने के लिए जिम्मेदार है। इससे पहले कि आप वर्कफ़्लो मॉड्यूल विकसित करना शुरू करें, आपको तय करना चाहिए: एक तैयार इंजन लें या अपना खुद का लिखें। शुरू में, हम पहले विकल्प के लिए गए। हमने विंडोज वर्कफ़्लो फाउंडेशन (डब्ल्यूएफएफ) इंजन लिया, और कुल मिलाकर यह हमारे अनुकूल है। लेकिन समय के साथ, हमने महसूस किया कि हमें अपने स्वयं के इंजन की आवश्यकता है। यह कैसे हुआ, और इसके बारे में क्या हुआ, मैं नीचे बताऊंगा।

पुराना इंजन

क्यों wf?

2013 में वापस, जब डायरेक्टमआरएक्स के लिए वर्कफ़्लो मॉड्यूल विकसित करने का समय था, तो हमने एक तैयार इंजन लेने का फैसला किया। Windows वर्कफ़्लो फ़ाउंडेशन (WF), ActiveFlow, K2.NET, WorkflowEngine.NET, cDevWorkflow, NetBpm से देखा गया। कुछ मूल्य से खुश नहीं थे, कुछ कच्चे थे, कुछ, उस समय तक, लंबे समय तक समर्थित नहीं थे।
नतीजतन, विकल्प डब्ल्यूएफ पर गिर गया। हमने तब Microsoft स्टैक (WCF, WPF) का सक्रिय रूप से उपयोग किया और निर्णय लिया कि एक और डब्ल्यू हमें नुकसान नहीं पहुंचाएगा। एक अन्य लाभ Microsoft गोल्ड एप्लीकेशन डेवलपमेंट पार्टनर के रूप में हमारी स्थिति थी, जिसने Microsoft तकनीकों का उपयोग करके उत्पादों को विकसित करना संभव बना दिया। खैर, सामान्य तौर पर, इंजन की क्षमताओं ने हमें अनुकूल बनाया और हमारे लगभग सभी मामलों को कवर किया।

डब्ल्यूएफ के साथ क्या गलत है?

WF का उपयोग करने के 6 वर्षों के बाद, हमने कई समस्याओं को संचित किया है, और इन समस्याओं को हल करने की लागत बहुत अधिक थी। हमने अपना इंजन विकसित करने के बारे में सोचना शुरू किया। मैं आपको उनमें से कुछ के बारे में बताता हूँ।

महंगी डायग्नोस्टिक्स और बग फिक्स

साल बीतते गए, उत्पाद की संख्या और भार बढ़ता गया। कीड़े दिखाई देने लगे, जिसके निदान और सुधार में बहुत सारे संसाधन लगे। यह कारणों की एक जटिल द्वारा सुविधा प्रदान की गई थी: पिछले इंजन को एम्बेड करते समय दक्षताओं की कमी, डिज़ाइन त्रुटियों और WF की विशेषताएं।
हमारे पास WF DirectumRX में निर्माण करने के लिए पर्याप्त बुनियादी क्षमताएं थीं, समान स्तर साधारण बग से निपटने के लिए पर्याप्त था। जटिल मामलों के लिए, दक्षताओं की कमी हो गई - लॉग का विश्लेषण, उदाहरण की स्थिति का विश्लेषण, और इसी तरह, मुश्किल थे।
WF पर पाठ्यक्रमों के लिए एक व्यक्ति को भेजना संभव था, लेकिन यह संभावना नहीं है कि वे सिखाते हैं कि कैसे एक उदाहरण की स्थिति का विश्लेषण करें और लॉग के साथ इसके परिवर्तन को संबद्ध करें। और स्पष्ट रूप से, किसी को भी वस्तुतः मृत प्रौद्योगिकी के साथ अपने कौशल को उन्नत करने की कोई इच्छा नहीं थी।
दूसरा तरीका यह है कि उपयुक्त योग्यता वाले व्यक्ति को काम पर रखा जाए। लेकिन इज़ेव्स्क में एक खोजने के लिए ऐसा कोई तुच्छ कार्य नहीं है, और इस तथ्य पर नहीं कि इसका स्तर हमारी समस्याओं को हल करने के लिए पर्याप्त है।
वास्तव में, हम WF का समर्थन करने के लिए एक उच्च प्रवेश सीमा के साथ सामना कर रहे हैं। एक तरीका या दूसरा, मुझे लगता है कि हम इस समस्या से निपटेंगे, यदि कई अन्य कारणों से नहीं।
एक और समस्या यह थी कि प्रक्रिया आरेखों का निर्माण करते समय हम अपने स्वयं के संकेतन का उपयोग करते हैं। यह अधिक दृश्य और विकसित करने में आसान है। उदाहरण के लिए, WF पूर्ण-विकसित ग्राफ़ को लागू करने की अनुमति नहीं देता है, आप डेड-एंड ब्लॉक को आकर्षित नहीं कर सकते हैं, समानांतर शाखाओं को खींचने की विशेषताएं हैं। इसके लिए पेबैक हमारे सर्किट का WF सर्किट में रूपांतरण है, जो इतना सरल नहीं है और कई सीमाएं लगाता है। डिबगिंग करते समय, मुझे डब्ल्यूएफ सर्किट की स्थिति का विश्लेषण करना था, इस वजह से दृश्यता खो गई थी, मुझे यह समझने के लिए ब्लॉक और चेहरों की एक-दूसरे से तुलना करनी थी कि उदाहरण किस कदम पर था।

DirectumRX में सर्किट का प्रतिनिधित्व

WF में सर्किट का प्रतिनिधित्व
इसके अलावा, हमें इस तथ्य से सामना करना पड़ा कि डब्ल्यूएफ प्रलेखन खराब भंडार का उदाहरण देता है। जैसा कि मैंने ऊपर लिखा है, प्रक्रिया की स्थिति को समझने के लिए बग का विश्लेषण करते समय यह आवश्यक है। इसके अलावा, डेटा का हिस्सा एन्क्रिप्ट किया गया है, जो विश्लेषण के साथ हस्तक्षेप भी करता है।

एक DBMS के रूप में पोस्टग्रेट करता है

अब कई वर्षों के लिए, रूस में आयात प्रतिस्थापन के लिए एक प्रवृत्ति रही है, और अधिक से अधिक बार मंच के लिए आवश्यकताओं में से एक ओपन सोर्स डेटाबेस मैनेजमेंट सिस्टम (डीबीएमएस) या घरेलू-निर्मित डीबीएमएस का समर्थन है। ज्यादातर यह Postgres है। बॉक्स से बाहर, WF केवल MS SQL का समर्थन करता है। अन्य डेटाबेस के साथ काम करने के लिए, आप तीसरे पक्ष के प्रदाताओं का उपयोग कर सकते हैं। हमने DevArt से dotConnect को चुना।
जबकि भार हल्का था, सब कुछ अच्छी तरह से काम किया। लेकिन जैसे ही हमने लोड के तहत सिस्टम को हटा दिया, समस्याएं दिखाई दीं। डब्ल्यूएफ अचानक प्रसंस्करण इंस्टेंस को रोक सकता है और बंद कर सकता है (तैयार लेनदेन समाप्त हो गया है), या सभी संदेश एमएसएमक्यू जहर क्यू, आदि पर चले गए। हमने इन सभी समस्याओं से निपटा, लेकिन इस पर बहुत समय बिताया। इस बात की कोई गारंटी नहीं थी कि एक नया दिखाई नहीं देगा, जिसके समाधान के लिए समान राशि खर्च करनी होगी।

.Net कोर पर ध्यान दें

Microsoft द्वारा .Net Core की घोषणा करने के बाद, हमने निर्णय लिया कि हम अपने समाधानों के लिए क्रॉस-प्लेटफ़ॉर्म प्राप्त करने के लिए धीरे-धीरे इसमें जाएंगे। Microsoft ने बोर्ड पर डब्ल्यूएफ को नहीं लेने का फैसला किया, जिसने वर्कफ़्लो मॉड्यूल को .Net कोर को उस रूप में स्थानांतरित करने का रास्ता रोक दिया, जिसमें वह मौजूद था। हम जानते हैं कि .Net कोर पर अनौपचारिक DNS पोर्ट हैं, और उनमें से WF डेवलपर्स से भी हैं, लेकिन उनमें से सभी 100% संगत नहीं हैं। एक अन्य कारक Microsoft का विकास करने से इनकार कर रहा था। नेट। .Net कोर के पक्ष में

नया इंजन

समस्याओं, समाधान विकल्पों, रिफ्लेक्टरिंग और सुधारों की जटिलता, सभी पेशेवरों और विपक्षों का वजन उठाते हुए, हमने एक नए इंजन पर स्विच करने का फैसला किया। हमने मौजूदा लोगों का विश्लेषण करके शुरुआत की।

पसंद

इंजन चुनते समय मुख्य आवश्यकताएं थीं:

.Net कोर पर काम करें;
scalability
रूपांतरण के बाद निष्पादन को जारी रखने की क्षमता के साथ मौजूदा प्रक्रिया उदाहरणों का रूपांतरण
मौजूदा समस्याओं का विश्लेषण करने की उचित लागत
विभिन्न DBMS के साथ काम करें

इसके अलावा, यह आवश्यक था कि गतिविधि (गतिविधि) C # में एप्लिकेशन कोड निष्पादित कर सके, ब्लॉक को डिबग करना संभव था, आदि।
मौजूदा इंजनों के विश्लेषण के भाग के रूप में, हमने देखा:

समीक्षित समाधानों पर सभी आवश्यकताओं को लागू करने और भुगतान किए गए समाधानों की लागत को जोड़ने के बाद, हमने माना कि हमारा इंजन बहुत महंगा नहीं है, जबकि यह हमारे अनुरोधों के लिए 100% उपयुक्त होगा और इसे परिष्कृत करना आसान होगा।

कार्यान्वयन / वास्तुकला

पिछले कार्यान्वयन में, डब्ल्यूएफ मॉड्यूल एक डब्ल्यूसीएफ सेवा थी जिसमें डब्ल्यूएफ पुस्तकालय जुड़े हुए थे। वह प्रक्रिया के उदाहरणों को बनाने, प्रक्रियाओं को शुरू करने, व्यापार तर्क (डेवलपर्स द्वारा लिखित कोड) सहित ब्लॉकों को निष्पादित करने में सक्षम था। यह सब IIS एप्लिकेशन में होस्ट किया गया था।
नए कार्यान्वयन में, माइक्रोसैस आर्किटेक्चर की प्रवृत्ति के बाद, हमने तुरंत सेवा को दो में विभाजित करने का फैसला किया: वर्कफ़्लो प्रोसेस सर्विस (डब्ल्यूपीएस) और वर्कफ़्लो ब्लॉक सर्विस (डब्ल्यूबीएस), जिसे अलग से होस्ट किया जा सकता था। इस श्रृंखला की एक और कड़ी है एप्लीकेशन सर्विस, जो डायरेक्ट्यूमआरएक्स सिस्टम और बिजनेस लॉजिक को लागू करती है और क्लाइंट इसके साथ काम करते हैं।
WPS "चलता है" योजना के अनुसार, WBS ब्लॉक करता है और हर कदम पर व्यावसायिक तर्क चलाता है। प्रक्रिया शुरू करने का कमांड एप्लीकेशन सर्वर से आता है। सेवाओं के बीच बातचीत RabbitMQ का उपयोग करके किया जाता है। नीचे मैं आपको उनमें से प्रत्येक के बारे में अधिक बताऊंगा।

WPS

वर्कफ़्लो प्रक्रिया सेवा एक माइक्रोसैस है जो प्रक्रियाओं को शुरू करने और प्रक्रिया आरेख को दरकिनार करने के लिए जिम्मेदार है।
सेवा रिपॉजिटरी में प्रक्रिया इंस्टेंसेस के संस्करण और क्रमबद्ध स्थिति के लिए समर्थन के साथ प्रक्रिया आरेख शामिल हैं। आप भंडारण के रूप में MS SQL और Postgres का उपयोग कर सकते हैं।
सेवा RabbitMQ के माध्यम से अन्य सेवाओं से प्राप्त संदेशों को संसाधित करने में सक्षम है। अनिवार्य रूप से, संदेश एक सेवा एपीआई है। सेवा प्राप्त करने वाले संदेशों के प्रकार:

StartProcess - एक नई प्रक्रिया उदाहरण बनाएँ और उस पर एक क्रॉल शुरू करें;
पूरा ब्लॉक - ब्लॉक का पूरा होना, इस संदेश के बाद, सेवा योजना के साथ आगे की प्रक्रिया को आगे बढ़ाती है;
सस्पेंड / रिज्यूमप्रोसेस - एक प्रक्रिया उदाहरण के निष्पादन को निलंबित करें, उदाहरण के लिए, ब्लॉक की प्रक्रिया करते समय त्रुटि के कारण, और त्रुटि के ठीक होने के बाद निष्पादन को फिर से शुरू करना;
एबोर्ट / रिस्टार्टप्रोसेस - प्रक्रिया की आवृत्ति को रोकें और इसे फिर से शुरू करें;
DeleteProcess - एक प्रक्रिया उदाहरण को हटा दें।

योजना में उनके (चेहरे) ब्लॉक और कनेक्शन शामिल हैं। प्रत्येक चेहरे में एक पहचानकर्ता होता है, तथाकथित "निष्पादन परिणाम"। 5 प्रकार के ब्लॉक हैं:

StartBlock;
ब्लॉक;
OrBlock;
AndBlock;
FinishBlock।

WPS का दृश्य
जब कोई संदेश प्रक्रिया की शुरुआत में आता है, तो सेवा एक उदाहरण बनाती है और योजना के अनुसार "चलना" शुरू करती है। योजना के अनुसार "चलने" के लिए जिम्मेदार वर्ग, हम मजाक में "स्टेपेटर" कहते हैं। एक सर्किट हमेशा एक StartBlock के साथ शुरू होता है। तब स्ट्राइडर सभी आउटगोइंग चेहरों को लेता है और उन्हें सक्रिय करता है। प्रत्येक ब्लॉक “और” ब्लॉक के सिद्धांत पर काम करता है, अर्थात सभी आने वाले चेहरे सक्रिय होने चाहिए ताकि ब्लॉक सक्रिय हो सके। एल्गोरिथ्म तब तय करता है कि किन ब्लॉकों को सक्रिय किया जा सकता है और इन ब्लॉकों को सक्रिय करने के लिए एक WBS संदेश भेजता है। डब्ल्यूबीएस ब्लॉक को संसाधित करता है और डब्ल्यूपीएस का परिणाम देता है। निष्पादन के परिणाम के आधार पर, स्ट्राइडर सक्रियण के लिए ब्लॉक से बाहर आने वाले उचित चेहरों का चयन करता है, और प्रक्रिया जारी रहती है।
विकास के दौरान, हम ब्लॉकों के बीच चक्रीय कनेक्शन से संबंधित दिलचस्प स्थितियों में आए, जिन्होंने निर्णय लिया कि कौन से ब्लॉक को सक्रिय / बंद करना है।
सेवा स्वायत्त है, अर्थात् बस उसे Json प्रारूप में योजना पास करें, अपना स्वयं का ब्लॉक हैंडलर लिखें, और आप संदेशों का आदान-प्रदान कर सकते हैं।

WBS

वर्कफ्लो ब्लॉक सर्विस एक ऐसी सेवा है जो डायग्राम को ब्लॉक करती है। सेवा व्यवसाय तर्क के सार के बारे में जानती है, जैसे कार्य, कार्य, आदि। इन संस्थाओं को DirectumRX डेवलपमेंट स्टूडियो (DDS) के विकास परिवेश में जोड़ा जा सकता है। उदाहरण के लिए, हमारे ब्लॉकों में ब्लॉक शुरू करने की एक घटना है। इस ईवेंट हैंडलर के लिए कोड DDS में डेवलपर द्वारा लिखा गया है, और WBS इस कोड को निष्पादित करता है। वास्तव में, यह ब्लॉक हैंडलर का हमारा कार्यान्वयन है; आप इसे अपने स्वयं के साथ बदल सकते हैं।
सेवा ब्लॉक की स्थिति को संग्रहीत करती है। बुनियादी गुणों (Id, State) के अलावा, ब्लॉक में ब्लॉक के निष्पादन / समाप्ति / निलंबन के लिए आवश्यक अन्य जानकारी हो सकती है।
एक राज्य में ब्लॉक हो सकते हैं:

पूर्ण - ब्लॉक पर काम के सफल समापन के बाद इस राज्य में चला जाता है;
लंबित - एक प्रतीक्षा की स्थिति में है जब ब्लॉक के भीतर कुछ काम किया जा रहा है, उदाहरण के लिए, उपयोगकर्ता से किसी प्रकार की प्रतिक्रिया की आवश्यकता होती है;
निरस्त - प्रक्रिया बंद होने पर इस स्थिति में चला जाता है;
निलंबित - इस स्थिति में जाता है जब एक त्रुटि होने पर प्रक्रिया बंद हो जाती है।

जब कोई संदेश ब्लॉक के निष्पादन पर आता है, तो ब्लॉक निष्पादित होता है, और WBS ब्लॉक के निष्पादन के परिणाम के साथ एक संदेश भेजता है।

scalability

WPS और WBS को कई उदाहरणों में तैनात किया जा सकता है। एक समय में, केवल एक डब्ल्यूपीएस सेवा एक प्रक्रिया उदाहरण की प्रक्रिया कर सकती है। एक ही प्रसंस्करण ब्लॉकों पर लागू होता है - एक प्रक्रिया का उदाहरण एक समय में केवल एक ब्लॉक को संसाधित कर सकता है। यह प्रसंस्करण के दौरान प्रक्रिया पर लगाए गए ताले द्वारा मदद की जाती है। यदि किसी प्रक्रिया में किसी प्रक्रिया / ब्लॉक को संसाधित करने के लिए कतार में कई संदेश हैं, तो संदेश कुछ समय के लिए स्थगित हो जाता है। एक ही समय में, प्रत्येक सेवा एक साथ कई प्रक्रिया उदाहरणों पर काम कर सकती है।
एक स्थिति उत्पन्न हो सकती है जब ब्लॉक (समानांतर शाखाओं) को संसाधित करने के लिए एक के बाद एक कई संदेश एक प्रक्रिया में आते हैं। संदेशों को स्थगित करने की स्थितियों की संख्या को कम करने के लिए, WBS एक समय में कई संदेश लेता है और एक के बाद एक उन्हें चलाता है, इस प्रक्रिया को अवरुद्ध करने के कारण पुनः निष्पादन के लिए कतार में भेजकर दरकिनार कर देता है।

रूपांतरण

एक नए इंजन में संक्रमण के बाद, यह सवाल उठा कि मौजूदा प्रक्रिया के उदाहरणों के साथ क्या करना है? पसंदीदा विकल्प उनका रूपांतरण था, ताकि वे नए इंजन पर काम करना जारी रखें। लाभ स्पष्ट हैं: हम केवल एक इंजन का समर्थन करते हैं, पुराने इंजन के समर्थन की समस्याएं गायब हो जाती हैं (ऊपर देखें)। लेकिन ऐसे जोखिम भी थे जिन्हें हम पूरी तरह से समझ नहीं पा रहे थे कि हमें क्रमबद्ध प्रक्रिया उदाहरणों से कैसे डेटा प्राप्त करना है। इसमें एक गिरावट भी थी: पुराने इंजन पर मौजूदा उदाहरणों को अंतिम रूप देना, और नए सिरे से लॉन्च करना। इस विकल्प का नुकसान पिछले एक के फायदे से है, साथ ही दोनों इंजनों को मोड़ने के लिए अतिरिक्त संसाधनों की आवश्यकता है।
रूपांतरण के लिए, हमें प्रक्रिया की पुरानी स्थिति को डब्ल्यूएफ प्रारूप में लेने और प्रक्रियाओं और ब्लॉकों की स्थिति उत्पन्न करने की आवश्यकता है। हमने एक उपयोगिता लिखी, जिसने डेटाबेस में एक प्रक्रिया उदाहरण की क्रमबद्ध स्थिति को लिया, इसे सक्रिय ब्लॉकों, चेहरों के निष्पादन परिणामों और सूची को निष्पादित करने की सूची से खींच लिया। परिणामस्वरूप, रूपांतरण के समय हमें उदाहरण मिला।
कैसे WF में प्रक्रिया उदाहरण डेटा ठीक से deserialize करने के लिए मुश्किलें पैदा हुईं। WF की प्रक्रिया (उदाहरण) का उदाहरण डेटाबेस में xaml के रूप में संग्रहीत किया जाता है। हम इस xaml की संरचना का स्पष्ट विवरण नहीं पा सके, हमें अनुभवजन्य तरीके से जाना पड़ा। डेटा को मैन्युअल रूप से पार्स किया और हमें आवश्यक जानकारी को बाहर निकाल दिया। इस कार्य के भाग के रूप में, हमने एक और विकल्प पर काम किया - उदाहरण का उपयोग करने और वस्तुओं से जानकारी प्राप्त करने का प्रयास करने के लिए, WF का उपयोग करना। लेकिन इस तथ्य के कारण कि ऐसी वस्तुओं की संरचना बहुत जटिल थी, हमने इस विचार को छोड़ दिया और "मैनुअल" पार्सिंग xaml पर बसे।
परिणामस्वरूप, रूपांतरण सफल रहा, और सभी प्रक्रिया उदाहरणों को नए इंजन द्वारा संसाधित किया जाने लगा।

निष्कर्ष

तो वर्कफ़्लो इंजन ने हमें क्या दिया? दरअसल, हम लेख की शुरुआत में सुनाई गई सभी समस्याओं को हराने में कामयाब रहे:

इंजन .NET कोर में लिखा गया है;
यह आईआईएस से स्वतंत्र एक स्व-मेजबान सेवा है;
परीक्षण ऑपरेशन के रूप में, हम कॉर्पोरेट सिस्टम में नए इंजन का सक्रिय रूप से उपयोग करते हैं और यह सुनिश्चित करने में कामयाब होते हैं कि बग के विश्लेषण में बहुत कम समय लगता है;
प्रारंभिक डेटा के अनुसार, पोस्टग्रेज पर लोड परीक्षण का संचालन, बगैर किसी समस्या के 5000 समवर्ती उपयोगकर्ताओं से लोड के साथ डब्ल्यूपीएस + डब्ल्यूबीएस बंडल कॉपी करता है;
और निश्चित रूप से, किसी भी दिलचस्प काम की तरह, यह एक दिलचस्प अनुभव है।

एक बोनस के रूप में, हमें एक स्पष्ट और समर्थित कोड मिला जिसे हम खुद के लिए अनुकूलित कर सकते हैं।
तीसरे पक्ष के उत्पाद की खरीद / अनुकूलन पर हमें जो खर्च करना होगा, उससे इंजन की लागत की तुलना की जा सकती है। फिलहाल, हम मानते हैं कि आपके अपने इंजन को विकसित करने का निर्णय उचित है।
हम 10,000+ समवर्ती उपयोगकर्ताओं के लिए लोड परीक्षण की प्रतीक्षा कर रहे हैं। शायद कुछ अनुकूलन की आवश्यकता होगी, या शायद यह बंद हो जाएगा? ;-)
हमने हाल ही में DirectumRX 3.2 जारी किया, जिसमें नया वर्कफ़्लो शामिल था। आइए देखें कि इंजन खुद को ग्राहकों को कैसे दिखाएगा।

हमने अपना वर्कफ़्लो इंजन कैसे बनाया