👩🏽‍🎓 👃🏽 🏕️ वर्कफ़्लो कोर - .Net कोर के लिए एक व्यवसाय प्रक्रिया इंजन 🖤 🐏 👩‍🏫

सभी को नमस्कार!

हमने विंडोज वर्कफ़्लो फ़ाउंडेशन .Net कोर का उपयोग करके परियोजना के प्रवासन के विषय का समर्थन करने का निर्णय लिया, जो कि DIRECTUM के सहयोगियों द्वारा शुरू किया गया था, क्योंकि हमने कुछ साल पहले इसी तरह की समस्या का सामना किया था और अपने तरीके से चले गए थे।

कहानी से शुरू करते हैं

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

हालांकि, जब बड़े ग्राहकों के साथ सामना किया गया, तो हमने महसूस किया कि बहुत अधिक लचीले उपकरण की आवश्यकता थी, क्योंकि एक्सेस अधिकारों के समन्वय की प्रक्रियाओं के लिए उनकी आवश्यकताओं ने एक अच्छे, वजनदार वर्कफ़्लो के नियमों की मांग की थी। आवश्यकताओं का विश्लेषण करने के बाद, हमने अपनी आवश्यकताओं के लिए उपयुक्त BPMN प्रारूप में अपना स्वयं का प्रोसेस एडिटर विकसित करने का निर्णय लिया। हम थोड़ी देर बाद React.js + SVG का उपयोग करके संपादक के विकास के बारे में बात करेंगे, और आज हम बैकएंड विषय पर चर्चा करेंगे - वर्कफ़्लो इंजन या व्यवसाय प्रक्रिया इंजन।

आवश्यकताओं

सिस्टम के विकास की शुरुआत में, हमारे पास इंजन के लिए निम्नलिखित आवश्यकताएं थीं:

प्रक्रिया आरेख, एक समझने योग्य प्रारूप, हमारे प्रारूप से इंजन प्रारूप में प्रसारित करने की क्षमता के लिए समर्थन
प्रक्रिया राज्य भंडारण
प्रक्रिया संस्करण समर्थन
प्रक्रिया के समानांतर निष्पादन (शाखाओं) के लिए समर्थन
एक उपयुक्त वाणिज्यिक उत्पाद में समाधान का उपयोग करने के लिए एक उपयुक्त लाइसेंस
क्षैतिज स्केलिंग के लिए समर्थन

बाजार का विश्लेषण करने के बाद (2014 के लिए), हम .Net: विंडोज वर्कफ़्लो फ़ाउंडेशन के लिए लगभग गैर-वैकल्पिक समाधान पर बस गए।

विंडोज वर्कफ़्लो फाउंडेशन (WWF)

डब्ल्यूडब्ल्यूएफ माइक्रोसॉफ्ट की तकनीक है जो वर्कफ़्लोज़ को परिभाषित करने, निष्पादित करने और प्रबंधित करने के लिए है।

इसके तर्क का आधार क्रियाओं (गतिविधियों) के लिए कंटेनरों का एक समूह है और इन कंटेनरों से अनुक्रमिक प्रक्रियाओं के निर्माण की क्षमता है। कंटेनर साधारण हो सकता है - इस प्रक्रिया में एक निश्चित कदम जहां गतिविधि की जाती है। यह एक प्रबंधक हो सकता है - जिसमें ब्रांचिंग का तर्क है।

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

लेकिन अगर जल्द या बाद में कोई योजनाओं के साथ ज़ेन को समझ सकता है और उन्हें पढ़ना सीख सकता है, तो इंजन की पारदर्शिता की कमी उपयोगकर्ताओं द्वारा सिस्टम के संचालन के दौरान पहले से ही परेशानी को जोड़ती है। जब त्रुटि Wf के आंतों से आती है, तो यह पता लगाना हमेशा संभव नहीं होता है कि 100% क्या वास्तव में विफलता का कारण था। बंद स्रोत और रिश्तेदार राक्षसी मामले में मदद नहीं करते हैं। अक्सर बग फिक्स लक्षणों के कारण थे।

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

नीचे की पंक्ति में, समाधान ने पर्याप्त रूप से काम किया और सफलतापूर्वक उत्पादन में चला गया। लेकिन .Net कोर के लिए हमारे उत्पादों के संक्रमण ने हमें डब्ल्यूडब्ल्यूएफ को छोड़ने और एक अन्य व्यवसाय प्रक्रिया इंजन की तलाश करने के लिए मजबूर किया, क्योंकि मई 2019 तक, विंडोज वर्कफ्लो फाउंडेशन को .Net कोर में माइग्रेट नहीं किया गया है। जैसा कि हम एक नए इंजन की तलाश में थे - एक अलग लेख का विषय, लेकिन अंत में हम वर्कफ़्लो कोर पर बस गए।

वर्कफ़्लो कोर

वर्कफ़्लो कोर एक मुक्त व्यापार प्रक्रिया इंजन है। यह एमआईटी लाइसेंस के तहत विकसित किया गया है, अर्थात इसे वाणिज्यिक विकास में सुरक्षित रूप से उपयोग किया जा सकता है।

यह सक्रिय रूप से एक व्यक्ति द्वारा किया जाता है, कई और समय-समय पर एक पुल अनुरोध करता है। अन्य भाषाओं (जावा, पायथन और कई और) के लिए पोर्ट हैं।

इंजन हल्के के रूप में तैनात है। वास्तव में, यह किसी व्यावसायिक नियमों द्वारा समूहीकृत क्रियाओं के क्रमिक निष्पादन के लिए एक मेजबान है।

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

बॉक्स के बाहर बाहरी भंडारण (हठ भंडारण) में प्रक्रिया की स्थिति के लिए समर्थन है। प्रदाता इसके लिए मानक हैं:

MongoDB
SQL सर्वर
PostgreSQL
SQLite
Amazon DynamoDB

अपने प्रदाता लिखें एक समस्या नहीं है। हम किसी भी मानक के स्रोतों को लेते हैं और एक उदाहरण के रूप में करते हैं।

क्षैतिज स्केलिंग समर्थित है, अर्थात, आप एक साथ कई नोड्स पर इंजन को चला सकते हैं, जबकि प्रक्रिया राज्यों के भंडारण का एक बिंदु (एक हठ भंडारण) है। इस मामले में, इंजन की आंतरिक कार्य कतार का प्लेसमेंट सामान्य भंडारण में होना चाहिए (खरगोशमेक्यूक्यू, एक विकल्प के रूप में)। कई नोड्स द्वारा एक कार्य के निष्पादन को बाहर करने के लिए, एक ही समय में एक लॉक मैनेजर प्रदान किया जाता है। बाहरी भंडारण प्रदाताओं के साथ समानता से, मानक कार्यान्वयन हैं:

एज़्योर स्टोरेज लीज़
Redis
AWS डायनमोडीबी
SQLServer (स्रोत में है, लेकिन प्रलेखन में कुछ भी नहीं कहा गया है)

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

चलो चलते हैं।

चरण (चरण)

एक कदम प्रक्रिया में एक कदम है जिस पर कोई भी कार्य किया जाता है। पूरी प्रक्रिया को चरणों के अनुक्रम से बनाया गया है। एक कदम कई क्रियाएं कर सकता है, दोहराया जा सकता है, उदाहरण के लिए, बाहर से कुछ घटना के लिए। ऐसे कदमों का एक सेट है जो "बॉक्स से बाहर" तर्क से संपन्न हैं:

WaitFor
अगर
जब
foreach
विलंब
समानांतर
अनुसूची
पुनरावृत्ति होना

बेशक, कुछ अंतर्निहित प्राथमिकताओं पर आप प्रक्रिया नहीं कर सकते। हमें ऐसे कदमों की आवश्यकता है जो व्यावसायिक कार्यों को पूरा करें। इसलिए, अब, उन्हें एक तरफ रख दें और अपने स्वयं के तर्क के साथ कदम उठाएं। ऐसा करने के लिए, आपको StepBody अमूर्तता से विरासत में प्राप्त करने की आवश्यकता है।

public abstract class StepBody : IStepBody { public abstract ExecutionResult Run(IStepExecutionContext context); }

जब प्रक्रिया एक चरण में प्रवेश करती है तो रन विधि निष्पादित होती है। इसमें आवश्यक तर्क को रखना आवश्यक है।

  public abstract class StepBody : IStepBody { public abstract ExecutionResult Run(IStepExecutionContext context); }

कदम निर्भरता इंजेक्शन का समर्थन करते हैं। ऐसा करने के लिए, उन्हें आवश्यक निर्भरता के रूप में एक ही कंटेनर में पंजीकृत करने के लिए पर्याप्त है।

जाहिर है, प्रक्रिया को अपने स्वयं के संदर्भ की आवश्यकता है - एक जगह जहां निष्पादन के मध्यवर्ती परिणाम जोड़े जा सकते हैं। Wf कोर की एक प्रक्रिया के निष्पादन के लिए अपना स्वयं का संदर्भ है जो इसकी वर्तमान स्थिति के बारे में जानकारी संग्रहीत करता है। आप रन () विधि से संदर्भ चर का उपयोग करके इसे एक्सेस कर सकते हैं। बिल्ट-इन के अलावा, हम अपने संदर्भ का उपयोग कर सकते हैं।

हम प्रक्रिया का वर्णन और पंजीकरण करने के तरीकों का विश्लेषण नीचे अधिक विस्तार से करेंगे, अभी के लिए, हम केवल एक निश्चित वर्ग - संदर्भ को परिभाषित करते हैं।

  public class ProcessContext { public int Number1 {get;set;} public int Number2 {get;set;} public string StepResult {get;set;} public ProcessContext() { Number1 = 1; Number2 = 2; } }

चर संख्या में हम संख्या लिखते हैं; चर चरण में - चरण का परिणाम।

हमने संदर्भ पर फैसला किया। आप अपना खुद का कदम लिख सकते हैं:

  public class CustomStep : StepBody { private readonly Ilogger _log; public int Input1 { get; set; } public int Input2 { get; set; } public string Action { get; set; } public string Result { get; set; } public CustomStep(Ilogger log) { _log = log; } public override ExecutionResult Run(IStepExecutionContext context) { Result = ”none”; if (Action ==”sum”) { Result = Number1 + Number2; } if (Action ==”dif”){ Result = Number1 - Number2; } return ExecutionResult.Next(); } }

तर्क अत्यंत सरल है: दो नंबर और ऑपरेशन का नाम इनपुट में आता है। ऑपरेशन का परिणाम आउटपुट चर के परिणामस्वरूप लिखा गया है। यदि ऑपरेशन परिभाषित नहीं है, तो परिणाम कोई भी नहीं होगा।

हमने संदर्भ के बारे में फैसला किया, हमारे पास जिस तर्क की आवश्यकता है, उसके साथ एक कदम है। अब हमें इंजन में अपनी प्रक्रिया को पंजीकृत करने की आवश्यकता है।

प्रक्रिया का विवरण। इंजन में पंजीकरण।

एक प्रक्रिया का वर्णन करने के दो तरीके हैं। पहले कोड में विवरण है - हार्डकोड।

प्रक्रिया धाराप्रवाह इंटरफ़ेस के माध्यम से वर्णित है । सामान्यीकृत IWorkflow <T> इंटरफ़ेस से वारिस करना आवश्यक है, जहाँ T मॉडल संदर्भ वर्ग है। हमारे मामले में, यह एक ProcessContext है ।

यह इस तरह दिखता है:

  public class SimpleWorkflow : IWorkflow<ProcessContext> { public void Build(IWorkflowBuilder<ProcessContext> builder) { //    } public string Id => "SomeWorkflow"; public int Version => 1; }

विवरण स्वयं बिल्ड विधि के अंदर होगा। आईडी और संस्करण फ़ील्ड भी आवश्यक हैं। Wf कोर प्रक्रिया संस्करण का समर्थन करता है - आप समान पहचानकर्ता के साथ n प्रक्रिया संस्करण पंजीकृत कर सकते हैं। यह तब सुविधाजनक होता है जब आपको किसी मौजूदा प्रक्रिया को अपडेट करने की आवश्यकता होती है और साथ ही मौजूदा कार्यों को "लाइव" देना होता है।

हम एक सरल प्रक्रिया का वर्णन करते हैं:

  public class SimpleWorkflow : IWorkflow<ProcessContext> { public void Build(IWorkflowBuilder<ProcessContext> builder) { builder.StartWith<CustomStep>() .Input(step => step.Input1, data => data.Number1) .Input(step => step.Input2, data => data.Number2) .Input(step => step.Action, data => “sum”) .Output(data => data.StepResult, step => step.Result) .EndWorkflow(); } public string Id => "SomeWorkflow"; public int Version => 1; }

यदि "मानव" भाषा में अनुवाद किया जाता है, तो यह कुछ इस तरह से निकलेगा : प्रक्रिया कस्टमस्टेप चरण से शुरू होती है। पिच फ़ील्ड Input1 का मूल्य संदर्भ फ़ील्ड नंबर 1 से लिया गया है। पिच फ़ील्ड Input2 का मान संदर्भ फ़ील्ड नंबर 2 से लिया गया है, एक्शन फ़ील्ड को "योग" मान के साथ सख्ती से इंगित किया गया है। परिणाम फ़ील्ड से StepResult संदर्भ फ़ील्ड में लिखा जाता है। प्रक्रिया को पूरा करें।

सहमत हूं, कोड बहुत पठनीय निकला, सी # में विशेष ज्ञान के बिना भी, यह पता लगाना काफी संभव है।

हमारी प्रक्रिया में एक और कदम जोड़ें, जो लॉग में पिछले चरण के परिणाम का उत्पादन करेगा:

  public class CustomStep : StepBody { private readonly Ilogger _log; public string TextToOutput { get; set; } public CustomStep(Ilogger log) { //    _log = log; } public override ExecutionResult Run(IStepExecutionContext context) { _log.Debug(TextToOutput); return ExecutionResult.Next(); } }

और प्रक्रिया को अपडेट करें:

  public class SimpleWorkflow : IWorkflow<ProcessContext> { public void Build(IWorkflowBuilder<ProcessContext> builder) { builder.StartWith<CustomStep>() .Input(step => step.Input1, data => data.Number1) .Input(step => step.Input2, data => data.Number2) .Input(step => step.Action, data => “sum”) .Output(data => data.StepResult, step => step.Result) .Then<OutputStep>.Input(step => step.TextToOutput, data => data.StepResult) .EndWorkflow(); } public string Id => "SomeWorkflow"; public int Version => 2; }

अब, अतिरिक्त ऑपरेशन के साथ कदम के बाद, परिणाम को लॉग में आउटपुट करने का चरण निम्नानुसार है। इनपुट करने के लिए, हम परिणाम और संदर्भ चर पास करते हैं जिसमें निष्पादन का परिणाम अंतिम चरण में लिखा गया था। मैं यह सुनिश्चित करने की स्वतंत्रता लूंगा कि वास्तविक प्रणालियों में एक कोड (हार्डकोड) के माध्यम से ऐसा विवरण बहुत कम उपयोग में होगा। जब तक कुछ कार्यालय प्रक्रियाओं के लिए। सर्किट को अलग से स्टोर करने में सक्षम होना बहुत अधिक दिलचस्प है। कम से कम, हमें हर बार इस परियोजना को फिर से इकट्ठा करने की ज़रूरत नहीं है क्योंकि हमें इस प्रक्रिया में कुछ बदलना होगा या एक नया जोड़ना होगा। Wf core json स्कीमा को स्टोर करके यह सुविधा प्रदान करता है। हम अपने उदाहरण का विस्तार करना जारी रखते हैं।

Json प्रक्रिया विवरण

आगे मैं कोड के माध्यम से एक विवरण प्रदान नहीं करूंगा। यह विशेष रूप से दिलचस्प नहीं है, और केवल लेख को फुलाएगा।

Wf कोर json में स्कीमा विवरण का समर्थन करता है। मेरी राय में, जैसन xaml की तुलना में अधिक दृश्य है (टिप्पणियों में होलीवर के लिए एक अच्छा विषय :))। फ़ाइल संरचना बहुत सरल है:

 { "Id": "SomeWorkflow", "Version": 1, "DataType": "App.ProcessContext, App", "Steps": [ { /*step1*/ }, { /*step2*/ } ] }

डेटाटाइप फ़ील्ड संदर्भ वर्ग के पूरी तरह से योग्य नाम और उस विधानसभा के नाम को इंगित करता है जिसमें यह वर्णित है। चरण प्रक्रिया में सभी चरणों का एक संग्रह संग्रहीत करता है। चरण तत्व भरें:

 { "Id": "SomeWorkflow", "Version": 1, "DataType": "App.ProcessContext, App", "Steps": [ { "Id": "Eval", "StepType": "App.CustomStep, App", "NextStepId": "Output", "Inputs": { "Input1": "data.Number1", "Input2": "data.Number2" }, "Outputs": { "StepResult": "step.Result" } }, { "Id": "Output", "StepType": "App.OutputStep, App", "Inputs": { "TextToOutput": "data.StepResult" } } ] }

आइए json के माध्यम से चरण विवरण की संरचना पर करीब से नज़र डालें।

Id और NextStepId फ़ील्ड इस चरण के पहचानकर्ता को संग्रहीत करते हैं और यह संकेत देते हैं कि कौन सा चरण अगला हो सकता है। इसके अलावा, संग्रह के तत्वों का क्रम महत्वहीन है।

StepType DataType फ़ील्ड के समान है, इसमें चरण का पूरी तरह से योग्य वर्ग नाम होता है (एक प्रकार जो StepBody से विरासत में आता है और चरण तर्क को लागू करता है) और असेंबली का नाम। अधिक दिलचस्प इनपुट और आउटपुट ऑब्जेक्ट हैं। उन्हें मैपिंग के रूप में सेट किया जाता है।

इनपुट्स के मामले में , json element नाम हमारे स्टेप के क्लास फील्ड का नाम है; तत्व का मूल्य वर्ग में क्षेत्र का नाम है, प्रक्रिया का संदर्भ।

आउटपुट के लिए, इसके विपरीत, जैसन तत्व का नाम कक्षा में फ़ील्ड का नाम है, प्रक्रिया का संदर्भ; तत्व मूल्य हमारे कदम के वर्ग क्षेत्र का नाम है।

डेटा के माध्यम से संदर्भ फ़ील्ड क्यों निर्दिष्ट किए जाते हैं। {Field_name} , और आउटपुट के मामले में, चरण {Field_name} ? क्योंकि wf कोर तत्व मान को C # एक्सप्रेशन के रूप में निष्पादित किया जाता है ( डायनामिक एक्सप्रेशंस लाइब्रेरी का उपयोग किया जाता है)। यह एक बहुत ही उपयोगी चीज है, इसकी मदद से आप सीधे योजना के अंदर कुछ व्यावसायिक तर्क रख सकते हैं, अगर, ज़ाहिर है, वास्तुकार इस तरह के अपमान को मंजूरी देता है :)।

हम योजना को मानक आदिम के साथ विविधता देते हैं। एक सशर्त जोड़ें यदि बाहरी घटना को चरणबद्ध और संसाधित किया जाता है।

अगर

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

 { "Id": "IfStep", "StepType": "WorkflowCore.Primitives.If, WorkflowCore", "NextStepId": "nextStep", "Inputs": { "Condition": "<<expression to evaluate>>" }, "Do": [ [ { /*do1*/ }, { /*do2*/ } ] ] }

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

 { "Id": "Jump", "StepType": "App.JumpStep, App", "NextStepId": "" }

लगता है कि मैं क्या कर रहा हूँ? सच है, हम एक सेवा चरण की शुरुआत करते हैं, जो पारगमन प्रक्रिया को NextStepId में एक कदम पर ले जाता है।

हमारी योजना को अपडेट करें:

 { "Id": "SomeWorkflow", "Version": 1, "DataType": "App.ProcessContext, App", "Steps": [ { "Id": "Eval", "StepType": "App.CustomStep, App", "NextStepId": "MyIfStep", "Inputs": { "Input1": "data.Number1", "Input2": "data.Number2" }, "Outputs": { "StepResult": "step.Result" } }, { "Id": "MyIfStep", "StepType": "WorkflowCore.Primitives.If, WorkflowCore", "NextStepId": "OutputEmptyResult", "Inputs": { "Condition": "!String.IsNullOrEmpty(data.StepResult)" }, "Do": [ [ { "Id": "Jump", "StepType": "App.JumpStep, App", "NextStepId": "Output" } ] ] }, { "Id": "Output", "StepType": "App.OutputStep, App", "Inputs": { "TextToOutput": "data.StepResult" } }, { "Id": "OutputEmptyResult", "StepType": "App.OutputStep, App", "Inputs": { "TextToOutput": "\"Empty result\"" } } ] }

यदि चरण यह देखने के लिए जाँच करता है कि क्या Eval चरण का परिणाम खाली है। यदि यह खाली नहीं है, तो हम परिणाम प्रदर्शित करते हैं; यदि यह खाली है, तो संदेश " खाली परिणाम "। जंप स्टेप प्रोसेस को आउटपुट स्टेप पर ले जाता है, जो डू कलेक्शन के बाहर है। इस प्रकार, हमने योजना की "ऊर्ध्वाधरता" बनाए रखी है। इसके अलावा, इस तरह से, एन कदम पीछे की ओर कूद सकते हैं, अर्थात। एक चक्र को व्यवस्थित करने के लिए। Wf कोर में छोरों के लिए अंतर्निहित प्राइमेटिव हैं, लेकिन वे हमेशा सुविधाजनक नहीं होते हैं। उदाहरण के लिए, बीपीएन में, लूप्स का आयोजन इफ के माध्यम से किया जाता है।

इस दृष्टिकोण या मानक का उपयोग करें, यह आपके ऊपर है। हमारे लिए, ऐसा संगठन अधिक सुविधाजनक कदम था।

WaitFor

WaitFor आदिम बाहरी दुनिया को प्रक्रिया को प्रभावित करने की अनुमति देता है जब यह पहले से ही चल रहा है। उदाहरण के लिए, यदि प्रक्रिया के चरण में किसी उपयोगकर्ता द्वारा आगे के पाठ्यक्रम की मंजूरी आवश्यक है। प्रक्रिया WaitFor चरण में तब तक खड़ी रहेगी जब तक कि यह एक ऐसी घटना प्राप्त नहीं कर लेती जिसे इसे सब्सक्राइब किया जाता है।

आदिम संरचना:

 { "Id": "Wait", "StepType": "WorkflowCore.Primitives.WaitFor, WorkflowCore", "NextStepId": "NextStep", "CancelCondition": "If(cancel==true)", "Inputs": { "EventName": "\"UserAction\"", "EventKey": "\"DoSum\"", "EffectiveDate": "DateTime.Now" } }

मैं मापदंडों को थोड़ा समझाऊंगा।

रद्द करना - एक व्यवधान की प्रतीक्षा करने की शर्त। किसी घटना के लिए प्रतीक्षा को बाधित करने और प्रक्रिया के माध्यम से आगे बढ़ने की क्षमता प्रदान करता है। उदाहरण के लिए, यदि कोई प्रक्रिया एक ही समय में n अलग-अलग घटनाओं की प्रतीक्षा कर रही है (wf कोर चरणों के समानांतर निष्पादन का समर्थन करता है), तो सभी के आने की प्रतीक्षा करना आवश्यक नहीं है, इस मामले में रद्द करने से हमें मदद मिलेगी। हम संदर्भ चर में एक तार्किक ध्वज जोड़ते हैं और घटना को प्राप्त करने पर हम ध्वज को सही पर सेट करते हैं - सभी WaitFor चरण पूरे हो जाते हैं।

EventName और EventKey - घटना का नाम और कुंजी। घटनाओं को भेद करने के लिए फ़ील्ड्स की आवश्यकता होती है, अर्थात्, एक वास्तविक प्रणाली में बड़ी संख्या में एक साथ काम करने वाली प्रक्रियाओं के साथ। ताकि इंजन समझ सके कि किस प्रक्रिया के लिए कौन सी घटना का इरादा है और कौन सा कदम।

प्रभावीटेट - एक वैकल्पिक क्षेत्र जो एक इवेंट टाइमस्टैम्प जोड़ता है। यदि आप किसी घटना को "भविष्य में" प्रकाशित करना चाहते हैं तो यह काम आ सकता है। इसे तुरंत प्रकाशित करने के लिए, आप पैरामीटर को खाली छोड़ सकते हैं या वर्तमान समय सेट कर सकते हैं।

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

  public class CustomStep : StepBody { private readonly Ilogger _log; public string TextToOutput { get; set; } public CustomStep(Ilogger log) { _log = log; } public override ExecutionResult Run(IStepExecutionContext context) { //-  return ExecutionResult.WaitForEvent("eventName", "eventKey", DateTime.Now); } }

हमने मानक WaitForEvent () एक्सटेंशन विधि का उपयोग किया। यह पहले से बताए गए मापदंडों EventName , EventKey और EffectDate को स्वीकार करता है। इस तरह के कदम के तर्क को पूरा करने के बाद, प्रक्रिया वर्णित घटना की प्रतीक्षा करेगी और इंजन बस में घटना के प्रकाशित होने पर फिर से रन () विधि को कॉल करेगी। हालाँकि, वर्तमान रूप में, हम प्रारंभिक चरण के क्षणों और घटना के बाद प्रविष्टि में अंतर नहीं कर सकते हैं। लेकिन मैं किसी भी तरह से तर्क को कदम के स्तर से पहले-बाद में अलग करना चाहूंगा। और EventPublished ध्वज हमें इसमें मदद करेगा। यह प्रक्रिया के सामान्य संदर्भ के अंदर स्थित है, आप इसे इस तरह प्राप्त कर सकते हैं:

 var ifEvent=context.ExecutionPointer.EventPublished;

इस ध्वज के आधार पर, आप बाहरी घटना से पहले और बाद में तर्क को सुरक्षित रूप से विभाजित कर सकते हैं।

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

इंजन में पंजीकरण प्रक्रिया। बस में घटना का प्रकाशन।

इसलिए, प्रक्रिया के चरणों और विवरणों के तर्क के कार्यान्वयन के साथ पता लगा। जो चीज बनी हुई है वह सबसे महत्वपूर्ण है, जिसके बिना प्रक्रिया काम नहीं करेगी - विवरण को पंजीकृत करने की आवश्यकता है।

हम मानक AddWorkflow () एक्सटेंशन विधि का उपयोग करेंगे, जो हमारे IoC कंटेनर में इसकी निर्भरता को जगह देगा।

यह इस तरह दिखता है:

 public static IServiceCollection AddWorkflow(this IServiceCollection services, Action<WorkflowOptions> setupAction = null)

IServiceCollection - इंटरफ़ेस - सेवा विवरणों के संग्रह के लिए एक अनुबंध। वह Microsoft से DI के अंदर रहता है (इसके बारे में और अधिक यहाँ पढ़ा जा सकता है )

WorkflowOptions - मूल इंजन सेटिंग्स। उन्हें खुद को सेट करने के लिए आवश्यक नहीं है; मानक मूल्य पहले परिचित के लिए काफी स्वीकार्य हैं। हम और आगे जा रहे हैं।

यदि प्रक्रिया को कोड में वर्णित किया गया था, तो पंजीकरण इस तरह होता है:

 var host = _serviceProvider.GetService<IWorkflowHost>(); host.RegisterWorkflow<SomeWorkflow, ProcessContext>();

यदि इस प्रक्रिया को json के माध्यम से वर्णित किया जाता है, तो इसे निम्नानुसार पंजीकृत होना चाहिए (निश्चित रूप से, json विवरण को भंडारण स्थान से पहले से लोड किया जाना चाहिए):

 var host = _serviceProvider.GetService<IWorkflowHost>(); var definitionLoader = _serviceProvider.GetService<IDefinitionLoader>(); var definition = loader.LoadDefinition({*json  *});

इसके अलावा, दोनों विकल्पों के लिए, कोड समान होगा:

 host.Start(); //      host.StartWorkflow(definitionId, version, context); //      /// host.Stop(); / /

डिफेंडआईड पैरामीटर प्रक्रिया पहचानकर्ता है। प्रक्रिया आईडी फ़ील्ड में क्या लिखा है। इस स्थिति में, id = SomeWorkflow ।

संस्करण पैरामीटर निर्दिष्ट करता है कि प्रक्रिया का कौन सा संस्करण चलना है। इंजन एक पहचानकर्ता के साथ तुरंत n प्रक्रिया संस्करणों को पंजीकृत करने की क्षमता प्रदान करता है। यह सुविधाजनक है जब आपको पहले से चल रहे कार्यों को तोड़ने के बिना प्रक्रिया के विवरण में परिवर्तन करने की आवश्यकता होती है - नए संस्करण के अनुसार नए बनाए जाएंगे, पुराने वाले पुराने पर चुपचाप रहेंगे।

संदर्भ पैरामीटर प्रक्रिया संदर्भ का एक उदाहरण है।

Host.Start () और host.Stop () विधियाँ प्रक्रिया होस्टिंग शुरू और बंद करती हैं। यदि आवेदन में प्रक्रियाओं का प्रक्षेपण एक लागू कार्य है और समय-समय पर किया जाता है, तो होस्टिंग को रोक दिया जाना चाहिए। यदि आवेदन में विभिन्न प्रक्रियाओं के कार्यान्वयन पर मुख्य ध्यान दिया गया है, तो होस्टिंग को रोका नहीं जा सकता है।

बाहर की दुनिया से इंजन बस को संदेश भेजने की एक विधि है, जो फिर उन्हें ग्राहकों के बीच वितरित करेगी:

 Task PublishEvent(string eventName, string eventKey, object eventData, DateTime effectiveDate = null);

लेख में इसके मापदंडों का वर्णन अधिक था ( देखें WaitFor आदिम भाग )।

निष्कर्ष

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

ओपनसोर्स वर्कफ़्लो कोर इंजन पर स्विच करने से कुछ समस्याओं का समाधान हुआ, जिसने हमें डब्ल्यूडब्ल्यूएफ पर शांति से रहने से रोका। उनमें से सबसे महत्वपूर्ण, निश्चित रूप से, समर्थन। नेट कोर और इस तरह की कमी है, यहां तक कि योजनाओं में, डब्ल्यूडब्ल्यूएफ।

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

बेशक, कुछ समस्याओं को हल करने के लिए, वर्कफ़्लो कोर अपने स्वयं के नए लाए। हमें इंजन कोर में महत्वपूर्ण परिवर्तन करना था। लेकिन। खरोंच से अपने स्वयं के इंजन को विकसित करने की तुलना में समय के लिए खुद को कम लागत में "परिष्करण" पर काम करें। अंतिम समाधान गति और स्थिरता के मामले में काफी स्वीकार्य था, इसने हमें इंजन के साथ समस्याओं के बारे में भूलने और उत्पाद के व्यवसाय मूल्य के विकास पर ध्यान केंद्रित करने की अनुमति दी।

PS यदि विषय दिलचस्प हो जाता है, तो इंजन के गहन विश्लेषण और जटिल व्यावसायिक समस्याओं के समाधान के साथ wf कोर पर अधिक लेख होंगे।

वर्कफ़्लो कोर - .Net कोर के लिए एक व्यवसाय प्रक्रिया इंजन