🥇BPM शैली एकीकरण | प्रोहोस्टर

नमस्ते, Habr!

हाम्रो कम्पनीले ERP-क्लास सफ्टवेयर समाधानहरूको विकासमा माहिर छ, जसमा ठूलो मात्रामा व्यापारिक तर्क र कार्यप्रवाह a la EDMS को साथ लेनदेन प्रणालीहरूले ठूलो हिस्सा ओगटेको छ। हाम्रा उत्पादनहरूका आधुनिक संस्करणहरू JavaEE प्रविधिहरूमा आधारित छन्, तर हामी माइक्रोसर्भिसेसहरूमा पनि सक्रिय रूपमा प्रयोग गरिरहेका छौं। त्यस्ता समाधानहरूको सबैभन्दा समस्याग्रस्त क्षेत्रहरू मध्ये एक छेउछाउका डोमेनहरूसँग सम्बन्धित विभिन्न उपप्रणालीहरूको एकीकरण हो। एकीकरण कार्यहरूले हामीलाई सधैं ठूलो टाउको दुखाइ दिएको छ, वास्तुकला शैलीहरू, टेक्नोलोजी स्ट्याकहरू र फ्रेमवर्कहरू जुन हामीले प्रयोग गर्छौं, तर हालसालै त्यस्ता समस्याहरू समाधान गर्न प्रगति भएको छ।

तपाईको ध्यानमा ल्याइएको लेखमा, म निर्दिष्ट क्षेत्रमा एनपीओ क्रिस्टाको अनुभव र वास्तु अनुसन्धानको बारेमा कुरा गर्नेछु। हामी अनुप्रयोग विकासकर्ताको दृष्टिकोणबाट एकीकरण समस्याको सरल समाधानको उदाहरण पनि विचार गर्नेछौं र यो सरलता पछाडि लुकेको छ भनेर पत्ता लगाउनेछौं।

अस्वीकरण

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

BPM ले यसको साथ के गर्नु पर्छ?

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

सुविधाको लागि, हामी संचारमा "कागजात" शब्दलाई डेटा सेटको केही अमूर्तताको रूपमा प्रयोग गर्छौं, साझा कुञ्जीद्वारा एकताबद्ध हुन्छ, जसमा एक विशिष्ट कार्यप्रवाह "संलग्न" हुन सक्छ।
तर एकीकरण तर्कको बारेमा के हो? आखिर, एकीकरणको कार्य प्रणालीको वास्तुकलाद्वारा उत्पन्न हुन्छ, जुन ग्राहकको अनुरोधमा होइन, तर पूर्णतया फरक कारकहरूको प्रभावमा भागहरूमा "आउ" गरिएको छ:

Conway को कानून को प्रभाव अन्तर्गत;
अन्य उत्पादनहरूको लागि पहिले विकसित उपप्रणालीहरूको पुन: प्रयोगको परिणामको रूपमा;
वास्तुकार द्वारा निर्णय गरे अनुसार, गैर-कार्यात्मक आवश्यकताहरूको आधारमा।

त्यहाँ एकीकरण तर्कलाई मुख्य कार्यप्रवाहको व्यापार तर्कबाट अलग गर्ने ठूलो प्रलोभन छ ताकि एकीकरण कलाकृतिहरूको साथ व्यापार तर्कलाई प्रदूषित नहोस् र अनुप्रयोग विकासकर्तालाई प्रणालीको वास्तुकला परिदृश्यको विशेषताहरूमा जान नपरोस्। यस दृष्टिकोणको धेरै फाइदाहरू छन्, तर अभ्यासले यसको असक्षमता देखाउँदछ:

मुख्य कार्यप्रवाहको कार्यान्वयनमा सीमित विस्तार बिन्दुहरूको कारणले एकीकरण समस्याहरू समाधान गर्ने सामान्यतया सिंक्रोनस कलहरूको रूपमा सरल विकल्पहरूमा स्लाइड हुन्छ (तल सिंक्रोनस एकीकरणको कमजोरीहरूमा थप);
अर्को उपप्रणालीबाट प्रतिक्रिया आवश्यक हुँदा एकीकरण कलाकृतिहरूले अझै पनि मुख्य व्यापार तर्कमा प्रवेश गर्दछ;
अनुप्रयोग विकासकर्ताले एकीकरणलाई बेवास्ता गर्दछ र कार्यप्रवाह परिवर्तन गरेर सजिलैसँग तोड्न सक्छ;
प्रणाली प्रयोगकर्ताको दृष्टिकोणबाट एकल पूरै हुन बन्द हुन्छ, उपप्रणालीहरू बीचको "सीमहरू" उल्लेखनीय हुन्छन्, अनावश्यक प्रयोगकर्ता अपरेशनहरू देखा पर्दछ जसले डाटालाई एक उपप्रणालीबाट अर्कोमा स्थानान्तरण गर्न थाल्छ।

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

तर अझै, BPM ले यसको साथ के गर्नु पर्छ? कार्यप्रवाह लागू गर्नका लागि धेरै विकल्पहरू छन् ...
वास्तवमा, व्यापार प्रक्रियाहरूको अर्को कार्यान्वयन हाम्रो समाधानहरूमा धेरै लोकप्रिय छ - राज्य संक्रमण रेखाचित्रको घोषणात्मक सेटिङ र व्यापार तर्कसँग ह्यान्डलरहरूलाई संक्रमणहरूमा जोड्ने। एकै समयमा, राज्य जसले व्यापार प्रक्रियामा "कागजात" को हालको स्थिति निर्धारण गर्दछ "कागजात" को विशेषता हो।

यो प्रक्रिया परियोजनाको सुरुमा जस्तो देखिन्छ

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

आवश्यकताहरू स्पष्ट गर्ने धेरै पुनरावृत्तिहरू पछि यो प्रक्रिया जस्तो देखिन्छ

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

एक जटिल व्यापार प्रक्रिया को एक सानो भाग

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

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

माथिको आधारमा, हामी निष्कर्षमा पुग्न सक्छौं: BPM शैलीमा प्रक्रियाको दृष्टिकोणले हामीलाई अझ जटिल व्यावसायिक प्रक्रियाहरू स्वचालित गर्न, यी प्रक्रियाहरूमा सामंजस्यपूर्ण रूपमा एकीकरण गतिविधिहरू फिट गर्न र लागू गरिएको प्रक्रियालाई उपयुक्त नोटेशनमा दृश्यात्मक रूपमा प्रदर्शन गर्ने क्षमता कायम राख्नको लागि कार्यहरूको विस्तृत दायरा समाधान गर्न अनुमति दिन्छ।

एकीकरण ढाँचाको रूपमा सिंक्रोनस कलहरूको बेफाइदाहरू

सिंक्रोनस एकीकरणले सरल ब्लकिङ कललाई बुझाउँछ। एउटा उपप्रणालीले सर्भर साइडको रूपमा कार्य गर्दछ र इच्छित विधिको साथ API लाई उजागर गर्दछ। अर्को उपप्रणालीले ग्राहक पक्षको रूपमा कार्य गर्दछ र, सही समयमा, परिणामको अपेक्षाको साथ कल गर्दछ। प्रणालीको वास्तुकलामा निर्भर गर्दै, क्लाइन्ट र सर्भर पक्षहरू एउटै अनुप्रयोग र प्रक्रियामा, वा फरकमा होस्ट गर्न सकिन्छ। दोस्रो अवस्थामा, तपाईंले RPC को केही कार्यान्वयन लागू गर्न र प्यारामिटरहरूको मार्शल र कलको परिणाम प्रदान गर्न आवश्यक छ।

यस्तो एकीकरण ढाँचामा कमजोरीहरूको एकदम ठूलो सेट छ, तर यो यसको सरलताको कारण व्यवहारमा धेरै व्यापक रूपमा प्रयोग गरिन्छ। कार्यान्वयनको गतिले मनमोहक बनाउँछ र तपाइँलाई "बर्निङ" समयसीमाको अवस्थामा, प्राविधिक ऋणमा समाधान लेखेर यसलाई बारम्बार लागू गर्दछ। तर यो पनि हुन्छ कि अनुभवहीन विकासकर्ताहरूले यसलाई अनजाने रूपमा प्रयोग गर्छन्, केवल नकारात्मक परिणामहरू महसुस गर्दैनन्।

उपप्रणालीको जडानमा सबैभन्दा स्पष्ट वृद्धिको अतिरिक्त, त्यहाँ "फैलिएको" र "तान्दै" लेनदेनको साथ कम स्पष्ट समस्याहरू छन्। वास्तवमा, यदि व्यापार तर्कले कुनै परिवर्तन गर्दछ, तब लेनदेनहरू अपरिहार्य छन्, र लेनदेनहरू, बदलामा, यी परिवर्तनहरूद्वारा प्रभावित निश्चित अनुप्रयोग स्रोतहरू लक हुन्छन्। त्यो हो, जबसम्म एउटा सबसिस्टमले अर्कोबाट प्रतिक्रियाको लागि पर्खदैन, यसले लेनदेन पूरा गर्न र लकहरू जारी गर्न सक्षम हुने छैन। यसले महत्त्वपूर्ण रूपमा विभिन्न प्रभावहरूको जोखिम बढाउँछ:

प्रणाली उत्तरदायित्व हराएको छ, प्रयोगकर्ताहरूले अनुरोधहरूको जवाफको लागि लामो समय पर्खिरहेका छन्;
सर्भरले सामान्यतया ओभरफ्लोइङ्ग थ्रेड पूलको कारण प्रयोगकर्ता अनुरोधहरूको जवाफ दिन रोक्छ: धेरै जसो थ्रेडहरू लेनदेन द्वारा कब्जा गरिएको स्रोतको लकमा "स्ट्यान्ड" हुन्छन्;
गतिरोधहरू देखा पर्न थाल्छन्: तिनीहरूको घटनाको सम्भाव्यता लेनदेनको अवधिमा निर्भर गर्दछ, व्यापार तर्क र लेनदेनमा संलग्न लकहरूको मात्रा;
लेनदेन टाइमआउट म्याद समाप्ति त्रुटिहरू देखा पर्छन्;
सर्भर OutOfMemory मा "पत्छ" यदि कार्यलाई डेटाको ठूलो मात्रामा प्रशोधन र परिवर्तन गर्न आवश्यक छ, र सिंक्रोनस एकीकरणको उपस्थितिले प्रक्रियालाई "हल्का" लेनदेनमा विभाजन गर्न धेरै गाह्रो बनाउँछ।

आर्किटेक्चरल दृष्टिकोणबाट, एकीकरणको क्रममा ब्लकिङ कलहरूको प्रयोगले व्यक्तिगत उपप्रणालीहरूको गुणस्तर नियन्त्रण गुमाउँछ: अर्को उपप्रणालीको गुणस्तर लक्ष्यहरूबाट अलगावमा एक उपप्रणालीको गुणस्तर लक्ष्यहरू सुनिश्चित गर्न असम्भव छ। यदि उपप्रणालीहरू विभिन्न टोलीहरूद्वारा विकसित हुन्छन् भने, यो ठूलो समस्या हो।

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

यदि परिवर्तनहरू अलग-अलग लेनदेनहरूमा गरिन्छ भने, तब बलियो अपवाद ह्यान्डलिंग र क्षतिपूर्ति प्रदान गर्न आवश्यक हुनेछ, र यसले सिंक्रोनस एकीकरणको मुख्य फाइदालाई पूर्ण रूपमा हटाउँछ - सरलता।

वितरित लेनदेनहरू पनि दिमागमा आउँछन्, तर हामी तिनीहरूलाई हाम्रो समाधानहरूमा प्रयोग गर्दैनौं: यो विश्वसनीयता सुनिश्चित गर्न गाह्रो छ।

"सागा" लेनदेनको समस्याको समाधानको रूपमा

माइक्रो सर्भिसेसको बढ्दो लोकप्रियतासँगै यसको माग पनि बढिरहेको छ सागा पैटर्न.

यो ढाँचाले लामो लेनदेनको माथिका समस्याहरूलाई पूर्ण रूपमा समाधान गर्दछ, र व्यापार तर्कको पक्षबाट प्रणालीको अवस्था व्यवस्थापन गर्ने सम्भावनाहरू विस्तार गर्दछ: असफल लेनदेन पछि क्षतिपूर्तिले प्रणालीलाई यसको मूल स्थितिमा फिर्ता गर्न सक्दैन, तर वैकल्पिक प्रदान गर्दछ। डाटा प्रोसेसिंग मार्ग। यसले तपाइँलाई "राम्रो" अन्त्यमा प्रक्रिया ल्याउन प्रयास गर्दा सफलतापूर्वक सम्पन्न डाटा प्रोसेसिंग चरणहरू दोहोर्याउन अनुमति दिन्छ।

चाखलाग्दो कुरा के छ भने, मोनोलिथिक प्रणालीहरूमा, यो ढाँचा पनि सान्दर्भिक हुन्छ जब यो ढिलो रूपमा जोडिएको उपप्रणालीहरूको एकीकरणको लागि आउँछ र त्यहाँ लामो लेनदेनहरू र सम्बन्धित स्रोत लकहरूको कारणले नकारात्मक प्रभावहरू हुन्छन्।

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

तर यस्तो समाधान पनि यसको आफ्नै "मूल्य" छ:

व्यापार तर्क अधिक जटिल हुन्छ: तपाईं क्षतिपूर्ति बाहिर काम गर्न आवश्यक छ;
यो पूर्ण स्थिरता त्याग्न आवश्यक हुनेछ, जो विशेष गरी मोनोलिथिक प्रणालीहरूको लागि संवेदनशील हुन सक्छ;
वास्तुकला अलि बढी जटिल हुन्छ, त्यहाँ सन्देश ब्रोकरको लागि अतिरिक्त आवश्यकता छ;
अतिरिक्त अनुगमन र प्रशासन उपकरणहरू आवश्यक हुनेछ (यद्यपि सामान्य रूपमा यो पनि राम्रो छ: प्रणाली सेवाको गुणस्तर बढ्नेछ)।

मोनोलिथिक प्रणालीहरूको लागि, "स्यागहरू" प्रयोग गर्ने औचित्य यति स्पष्ट छैन। माइक्रोसर्भिसेस र अन्य SOA को लागि, जहाँ, सम्भवतः, पहिले नै ब्रोकर छ, र परियोजनाको सुरुमा पूर्ण स्थिरता बलिदान गरिएको थियो, यो ढाँचा प्रयोग गर्ने फाइदाहरूले बेफाइदाहरूलाई उल्लेखनीय रूपमा बढाउँछ, विशेष गरी यदि त्यहाँ सुविधाजनक API छ भने। व्यापार तर्क स्तर।

माइक्रोसर्भिसेसहरूमा व्यापार तर्कको एन्केप्सुलेशन

जब हामीले माइक्रोसर्भिसेसको साथ प्रयोग गर्न थाल्यौं, एक उचित प्रश्न उठ्यो: डोमेन डाटा स्थिरता प्रदान गर्ने सेवाको सम्बन्धमा डोमेन व्यापार तर्क कहाँ राख्ने?

विभिन्न BPMS को वास्तुकला हेर्दा, व्यवसाय तर्कलाई दृढताबाट अलग गर्नु उचित देखिन्छ: प्लेटफर्म र डोमेन-स्वतन्त्र माइक्रोसर्भिसेसहरूको एक तह सिर्जना गर्नुहोस् जसले डोमेन व्यापार तर्क कार्यान्वयनको लागि वातावरण र कन्टेनर बनाउँछ, र डोमेन डेटा स्थिरतालाई छुट्टै रूपमा व्यवस्थित गर्दछ। धेरै सरल र हल्का माइक्रो सेवाहरूको तह। यस अवस्थामा व्यापार प्रक्रियाहरूले दृढता तहको सेवाहरू अर्केस्ट्रेट गर्दछ।

यस दृष्टिकोणको एक धेरै ठूलो प्लस छ: तपाईले प्लेटफर्मको कार्यक्षमतालाई तपाईले चाहानु भएसम्म बढाउन सक्नुहुन्छ, र प्लेटफर्म माइक्रोसर्भिसेसको केवल समान तहले यसबाट "फ्याट" हुनेछ। कुनै पनि डोमेनबाट व्यापार प्रक्रियाहरूले तुरुन्तै प्लेटफर्मको नयाँ कार्यक्षमता प्रयोग गर्ने मौका पाउँछन् जब यो अपडेट हुन्छ।

थप विस्तृत अध्ययनले यस दृष्टिकोणको महत्त्वपूर्ण कमजोरीहरू प्रकट गर्‍यो:

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

अन्तमा, मैले आधारभूत कुराहरूमा फर्कनुपर्‍यो: डोमेन डाटा र डोमेन ब्यापार तर्कलाई एक माइक्रोसर्भिसमा इनक्याप्स्युलेट गर्नुहोस्। यो दृष्टिकोणले प्रणालीमा अभिन्न अंगको रूपमा माइक्रोसर्भिसको धारणालाई सरल बनाउँछ र माथिका समस्याहरूलाई जन्म दिँदैन। यो पनि नि: शुल्क छैन:

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

प्लेटफर्म सेवाहरूको एक तह पनि यस्तो वास्तुकलामा अवस्थित छ, तर यो तहले अब डोमेन व्यापार तर्क कार्यान्वयन गर्न कन्टेनर बनाउँदैन, तर केवल यसको वातावरण, सहायक "प्लेटफर्म" प्रकार्यहरू प्रदान गर्दछ। यस्तो तह डोमेन माइक्रोसर्भिसेसको हल्कापन कायम राख्न मात्र होइन, व्यवस्थापनलाई केन्द्रीकृत गर्न पनि आवश्यक छ।

उदाहरणका लागि, व्यापार प्रक्रियाहरूमा प्रयोगकर्ता गतिविधिहरूले कार्यहरू उत्पन्न गर्दछ। यद्यपि, कार्यहरूसँग काम गर्दा, प्रयोगकर्ताले सामान्य सूचीमा सबै डोमेनहरूबाट कार्यहरू देख्नै पर्छ, जसको मतलब त्यहाँ डोमेन व्यापार तर्कबाट खाली गरिएको उपयुक्त कार्य दर्ता प्लेटफर्म सेवा हुनुपर्छ। यस सन्दर्भमा व्यापार तर्कको इन्क्याप्सुलेशन राख्नु एकदम समस्याग्रस्त छ, र यो यस वास्तुकलाको अर्को सम्झौता हो।

एक आवेदन विकासकर्ता को आँखा मार्फत व्यापार प्रक्रियाहरु को एकीकरण

माथि उल्लेख गरिएझैं, अनुप्रयोग विकासकर्ता राम्रो विकास उत्पादकतामा भरोसा गर्न सक्षम हुन धेरै अनुप्रयोगहरूको अन्तरक्रियाको कार्यान्वयनको प्राविधिक र ईन्जिनियरिङ् सुविधाहरूबाट सार हुनुपर्छ।

विशेष गरी लेखको लागि आविष्कार गरिएको बरु गाह्रो एकीकरण समस्या समाधान गर्ने प्रयास गरौं। यो एक "खेल" कार्य हुनेछ जसमा तीन अनुप्रयोगहरू समावेश छन्, जहाँ प्रत्येकले केही डोमेन नाम परिभाषित गर्दछ: "app1", "app2", "app3"।

प्रत्येक अनुप्रयोग भित्र, एकीकरण बस मार्फत "बल खेल्न" सुरु गर्ने व्यापार प्रक्रियाहरू सुरु हुन्छन्। "बल" नामक सन्देशहरूले बलको रूपमा काम गर्नेछ।

खेलको नियम:

पहिलो खेलाडी पहलकर्ता हो। उसले अन्य खेलाडीहरूलाई खेलमा आमन्त्रित गर्छ, खेल सुरु गर्छ र यसलाई कुनै पनि समयमा अन्त्य गर्न सक्छ;
अन्य खेलाडीहरूले खेलमा उनीहरूको सहभागिता घोषणा गर्छन्, एकअर्का र पहिलो खेलाडीसँग "परिचित हुनुहोस्";
बल प्राप्त गरेपछि, खेलाडीले अर्को सहभागी खेलाडी छनोट गर्छ र उसलाई बल पास गर्छ। पासहरूको कुल संख्या गणना गरिएको छ;
प्रत्येक खेलाडीसँग "ऊर्जा" हुन्छ, जुन त्यो खेलाडीले बलको प्रत्येक पासको साथ घट्छ। जब ऊर्जा समाप्त हुन्छ, खेलाडी खेलबाट हटाइन्छ, उनीहरूको सेवानिवृत्तिको घोषणा गर्दै;
यदि खेलाडी एक्लै छोडियो भने, उसले तुरुन्तै आफ्नो प्रस्थान घोषणा गर्दछ;
जब सबै खेलाडीहरू हटाइन्छ, पहिलो खेलाडीले खेलको अन्त्य घोषणा गर्दछ। यदि उसले पहिले नै खेल छोड्यो भने, त्यसपछि यो पूरा गर्नको लागि खेल पछ्याउन बाँकी छ।

यो समस्या समाधान गर्नको लागि, म व्यापार प्रक्रियाहरूको लागि हाम्रो DSL प्रयोग गर्नेछु, जसले तपाईंलाई कम्तिमा बोइलरप्लेटको साथ कोटलिनमा कम्प्याक्ट रूपमा तर्क वर्णन गर्न अनुमति दिन्छ।

एप १ अनुप्रयोगमा, पहिलो खेलाडीको व्यापार प्रक्रिया (उनी पनि खेलको शुरुवातकर्ता हुन्) काम गर्नेछ:

कक्षा प्रारम्भिक प्लेयर

import ru.krista.bpm.ProcessInstance
import ru.krista.bpm.runtime.ProcessImpl
import ru.krista.bpm.runtime.constraint.UniqueConstraints
import ru.krista.bpm.runtime.dsl.processModel
import ru.krista.bpm.runtime.dsl.taskOperation
import ru.krista.bpm.runtime.instance.MessageSendInstance

data class PlayerInfo(val name: String, val domain: String, val id: String)

class PlayersList : ArrayList<PlayerInfo>()

// Это класс экземпляра процесса: инкапсулирует его внутреннее состояние
class InitialPlayer : ProcessImpl<InitialPlayer>(initialPlayerModel) {
    var playerName: String by persistent("Player1")
    var energy: Int by persistent(30)
    var players: PlayersList by persistent(PlayersList())
    var shotCounter: Int = 0
}

// Это декларация модели процесса: создается один раз, используется всеми
// экземплярами процесса соответствующего класса
val initialPlayerModel = processModel<InitialPlayer>(name = "InitialPlayer",
                                                     version = 1) {

    // По правилам, первый игрок является инициатором игры и должен быть единственным
    uniqueConstraint = UniqueConstraints.singleton

    // Объявляем активности, из которых состоит бизнес-процесс
    val sendNewGameSignal = signal<String>("NewGame")
    val sendStopGameSignal = signal<String>("StopGame")
    val startTask = humanTask("Start") {
        taskOperation {
            processCondition { players.size > 0 }
            confirmation { "Подключилось ${players.size} игроков. Начинаем?" }
        }
    }
    val stopTask = humanTask("Stop") {
        taskOperation {}
    }
    val waitPlayerJoin = signalWait<String>("PlayerJoin") { signal ->
        players.add(PlayerInfo(
                signal.data!!,
                signal.sender.domain,
                signal.sender.processInstanceId))
        println("... join player ${signal.data} ...")
    }
    val waitPlayerOut = signalWait<String>("PlayerOut") { signal ->
        players.remove(PlayerInfo(
                signal.data!!,
                signal.sender.domain,
                signal.sender.processInstanceId))
        println("... player ${signal.data} is out ...")
    }
    val sendPlayerOut = signal<String>("PlayerOut") {
        signalData = { playerName }
    }
    val sendHandshake = messageSend<String>("Handshake") {
        messageData = { playerName }
        activation = {
            receiverDomain = process.players.last().domain
            receiverProcessInstanceId = process.players.last().id
        }
    }
    val throwStartBall = messageSend<Int>("Ball") {
        messageData = { 1 }
        activation = { selectNextPlayer() }
    }
    val throwBall = messageSend<Int>("Ball") {
        messageData = { shotCounter + 1 }
        activation = { selectNextPlayer() }
        onEntry { energy -= 1 }
    }
    val waitBall = messageWaitData<Int>("Ball") {
        shotCounter = it
    }

    // Теперь конструируем граф процесса из объявленных активностей
    startFrom(sendNewGameSignal)
            .fork("mainFork") {
                next(startTask)
                next(waitPlayerJoin).next(sendHandshake).next(waitPlayerJoin)
                next(waitPlayerOut)
                        .branch("checkPlayers") {
                            ifTrue { players.isEmpty() }
                                    .next(sendStopGameSignal)
                                    .terminate()
                            ifElse().next(waitPlayerOut)
                        }
            }
    startTask.fork("afterStart") {
        next(throwStartBall)
                .branch("mainLoop") {
                    ifTrue { energy < 5 }.next(sendPlayerOut).next(waitBall)
                    ifElse().next(waitBall).next(throwBall).loop()
                }
        next(stopTask).next(sendStopGameSignal)
    }

    // Навешаем на активности дополнительные обработчики для логирования
    sendNewGameSignal.onExit { println("Let's play!") }
    sendStopGameSignal.onExit { println("Stop!") }
    sendPlayerOut.onExit { println("$playerName: I'm out!") }
}

private fun MessageSendInstance<InitialPlayer, Int>.selectNextPlayer() {
    val player = process.players.random()
    receiverDomain = player.domain
    receiverProcessInstanceId = player.id
    println("Step ${process.shotCounter + 1}: " +
            "${process.playerName} >>> ${player.name}")
}

व्यापार तर्क कार्यान्वयनको अतिरिक्त, माथिको कोडले व्यापार प्रक्रियाको वस्तु मोडेल उत्पादन गर्न सक्छ जुन रेखाचित्रको रूपमा देख्न सकिन्छ। हामीले भिजुअलाइजरलाई अझै लागू गरेका छैनौं, त्यसैले हामीले रेखाचित्र बनाउन केही समय खर्च गर्नुपर्‍यो (यहाँ मैले माथिको कोडको साथ रेखाचित्रको स्थिरता सुधार गर्न गेटहरूको प्रयोगको सन्दर्भमा BPMN नोटेशनलाई थोरै सरल बनाएको छु):

app2 ले अर्को खेलाडीको व्यापार प्रक्रिया समावेश गर्नेछ:

वर्ग RandomPlayer

import ru.krista.bpm.ProcessInstance
import ru.krista.bpm.runtime.ProcessImpl
import ru.krista.bpm.runtime.dsl.processModel
import ru.krista.bpm.runtime.instance.MessageSendInstance

data class PlayerInfo(val name: String, val domain: String, val id: String)

class PlayersList: ArrayList<PlayerInfo>()

class RandomPlayer : ProcessImpl<RandomPlayer>(randomPlayerModel) {

    var playerName: String by input(persistent = true, 
                                    defaultValue = "RandomPlayer")
    var energy: Int by input(persistent = true, defaultValue = 30)
    var players: PlayersList by persistent(PlayersList())
    var allPlayersOut: Boolean by persistent(false)
    var shotCounter: Int = 0

    val selfPlayer: PlayerInfo
        get() = PlayerInfo(playerName, env.eventDispatcher.domainName, id)
}

val randomPlayerModel = processModel<RandomPlayer>(name = "RandomPlayer", 
                                                   version = 1) {

    val waitNewGameSignal = signalWait<String>("NewGame")
    val waitStopGameSignal = signalWait<String>("StopGame")
    val sendPlayerJoin = signal<String>("PlayerJoin") {
        signalData = { playerName }
    }
    val sendPlayerOut = signal<String>("PlayerOut") {
        signalData = { playerName }
    }
    val waitPlayerJoin = signalWaitCustom<String>("PlayerJoin") {
        eventCondition = { signal ->
            signal.sender.processInstanceId != process.id 
                && !process.players.any { signal.sender.processInstanceId == it.id}
        }
        handler = { signal ->
            players.add(PlayerInfo(
                    signal.data!!,
                    signal.sender.domain,
                    signal.sender.processInstanceId))
        }
    }
    val waitPlayerOut = signalWait<String>("PlayerOut") { signal ->
        players.remove(PlayerInfo(
                signal.data!!,
                signal.sender.domain,
                signal.sender.processInstanceId))
        allPlayersOut = players.isEmpty()
    }
    val sendHandshake = messageSend<String>("Handshake") {
        messageData = { playerName }
        activation = {
            receiverDomain = process.players.last().domain
            receiverProcessInstanceId = process.players.last().id
        }
    }
    val receiveHandshake = messageWait<String>("Handshake") { message ->
        if (!players.any { message.sender.processInstanceId == it.id}) {
            players.add(PlayerInfo(
                    message.data!!, 
                    message.sender.domain, 
                    message.sender.processInstanceId))
        }
    }
    val throwBall = messageSend<Int>("Ball") {
        messageData = { shotCounter + 1 }
        activation = { selectNextPlayer() }
        onEntry { energy -= 1 }
    }
    val waitBall = messageWaitData<Int>("Ball") {
        shotCounter = it
    }

    startFrom(waitNewGameSignal)
            .fork("mainFork") {
                next(sendPlayerJoin)
                        .branch("mainLoop") {
                            ifTrue { energy < 5 || allPlayersOut }
                                    .next(sendPlayerOut)
                                    .next(waitBall)
                            ifElse()
                                    .next(waitBall)
                                    .next(throwBall)
                                    .loop()
                        }
                next(waitPlayerJoin).next(sendHandshake).next(waitPlayerJoin)
                next(waitPlayerOut).next(waitPlayerOut)
                next(receiveHandshake).next(receiveHandshake)
                next(waitStopGameSignal).terminate()
            }

    sendPlayerJoin.onExit { println("$playerName: I'm here!") }
    sendPlayerOut.onExit { println("$playerName: I'm out!") }
}

private fun MessageSendInstance<RandomPlayer, Int>.selectNextPlayer() {
    val player = if (process.players.isNotEmpty()) 
        process.players.random() 
    else 
        process.selfPlayer
    receiverDomain = player.domain
    receiverProcessInstanceId = player.id
    println("Step ${process.shotCounter + 1}: " +
            "${process.playerName} >>> ${player.name}")
}

रेखाचित्र:

app3 अनुप्रयोगमा, हामी खेलाडीलाई थोरै फरक व्यवहारको साथ बनाउनेछौं: अनियमित रूपमा अर्को खेलाडी छनौट गर्नुको सट्टा, उसले राउन्ड-रोबिन एल्गोरिदम अनुसार कार्य गर्नेछ:

कक्षा राउन्डरोबिन प्लेयर

import ru.krista.bpm.ProcessInstance
import ru.krista.bpm.runtime.ProcessImpl
import ru.krista.bpm.runtime.dsl.processModel
import ru.krista.bpm.runtime.instance.MessageSendInstance

data class PlayerInfo(val name: String, val domain: String, val id: String)

class PlayersList: ArrayList<PlayerInfo>()

class RoundRobinPlayer : ProcessImpl<RoundRobinPlayer>(roundRobinPlayerModel) {

    var playerName: String by input(persistent = true, 
                                    defaultValue = "RoundRobinPlayer")
    var energy: Int by input(persistent = true, defaultValue = 30)
    var players: PlayersList by persistent(PlayersList())
    var nextPlayerIndex: Int by persistent(-1)
    var allPlayersOut: Boolean by persistent(false)
    var shotCounter: Int = 0

    val selfPlayer: PlayerInfo
        get() = PlayerInfo(playerName, env.eventDispatcher.domainName, id)
}

val roundRobinPlayerModel = processModel<RoundRobinPlayer>(
        name = "RoundRobinPlayer", 
        version = 1) {

    val waitNewGameSignal = signalWait<String>("NewGame")
    val waitStopGameSignal = signalWait<String>("StopGame")
    val sendPlayerJoin = signal<String>("PlayerJoin") {
        signalData = { playerName }
    }
    val sendPlayerOut = signal<String>("PlayerOut") {
        signalData = { playerName }
    }
    val waitPlayerJoin = signalWaitCustom<String>("PlayerJoin") {
        eventCondition = { signal ->
            signal.sender.processInstanceId != process.id 
                && !process.players.any { signal.sender.processInstanceId == it.id}
        }
        handler = { signal ->
            players.add(PlayerInfo(
                    signal.data!!, 
                    signal.sender.domain, 
                    signal.sender.processInstanceId))
        }
    }
    val waitPlayerOut = signalWait<String>("PlayerOut") { signal ->
        players.remove(PlayerInfo(
                signal.data!!, 
                signal.sender.domain, 
                signal.sender.processInstanceId))
        allPlayersOut = players.isEmpty()
    }
    val sendHandshake = messageSend<String>("Handshake") {
        messageData = { playerName }
        activation = {
            receiverDomain = process.players.last().domain
            receiverProcessInstanceId = process.players.last().id
        }
    }
    val receiveHandshake = messageWait<String>("Handshake") { message ->
        if (!players.any { message.sender.processInstanceId == it.id}) {
            players.add(PlayerInfo(
                    message.data!!, 
                    message.sender.domain, 
                    message.sender.processInstanceId))
        }
    }
    val throwBall = messageSend<Int>("Ball") {
        messageData = { shotCounter + 1 }
        activation = { selectNextPlayer() }
        onEntry { energy -= 1 }
    }
    val waitBall = messageWaitData<Int>("Ball") {
        shotCounter = it
    }

    startFrom(waitNewGameSignal)
            .fork("mainFork") {
                next(sendPlayerJoin)
                        .branch("mainLoop") {
                            ifTrue { energy < 5 || allPlayersOut }
                                    .next(sendPlayerOut)
                                    .next(waitBall)
                            ifElse()
                                    .next(waitBall)
                                    .next(throwBall)
                                    .loop()
                        }
                next(waitPlayerJoin).next(sendHandshake).next(waitPlayerJoin)
                next(waitPlayerOut).next(waitPlayerOut)
                next(receiveHandshake).next(receiveHandshake)
                next(waitStopGameSignal).terminate()
            }

    sendPlayerJoin.onExit { println("$playerName: I'm here!") }
    sendPlayerOut.onExit { println("$playerName: I'm out!") }
}

private fun MessageSendInstance<RoundRobinPlayer, Int>.selectNextPlayer() {
    var idx = process.nextPlayerIndex + 1
    if (idx >= process.players.size) {
        idx = 0
    }
    process.nextPlayerIndex = idx
    val player = if (process.players.isNotEmpty()) 
        process.players[idx] 
    else 
        process.selfPlayer
    receiverDomain = player.domain
    receiverProcessInstanceId = player.id
    println("Step ${process.shotCounter + 1}: " +
            "${process.playerName} >>> ${player.name}")
}

अन्यथा, खेलाडीको व्यवहार अघिल्लो भन्दा फरक छैन, त्यसैले रेखाचित्र परिवर्तन गर्दैन।

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

परीक्षण खेल()

@Test
public void testGame() throws InterruptedException {
    String pl2 = startProcess(app2, "RandomPlayer", playerParams("Player2", 20));
    String pl3 = startProcess(app2, "RandomPlayer", playerParams("Player3", 40));
    String pl4 = startProcess(app3, "RoundRobinPlayer", playerParams("Player4", 25));
    String pl5 = startProcess(app3, "RoundRobinPlayer", playerParams("Player5", 35));
    String pl1 = startProcess(app1, "InitialPlayer");
    // Теперь нужно немного подождать, пока игроки "познакомятся" друг с другом.
    // Ждать через sleep - плохое решение, зато самое простое. 
    // Не делайте так в серьезных тестах!
    Thread.sleep(1000);
    // Запускаем игру, закрывая пользовательскую активность
    assertTrue(closeTask(app1, pl1, "Start"));
    app1.getWaiting().waitProcessFinished(pl1);
    app2.getWaiting().waitProcessFinished(pl2);
    app2.getWaiting().waitProcessFinished(pl3);
    app3.getWaiting().waitProcessFinished(pl4);
    app3.getWaiting().waitProcessFinished(pl5);
}

private Map<String, Object> playerParams(String name, int energy) {
    Map<String, Object> params = new HashMap<>();
    params.put("playerName", name);
    params.put("energy", energy);
    return params;
}

परीक्षण चलाउनुहोस्, लग हेर्नुहोस्:

कन्सोल आउटपुट

Взята блокировка ключа lock://app1/process/InitialPlayer
Let's play!
Снята блокировка ключа lock://app1/process/InitialPlayer
Player2: I'm here!
Player3: I'm here!
Player4: I'm here!
Player5: I'm here!
... join player Player2 ...
... join player Player4 ...
... join player Player3 ...
... join player Player5 ...
Step 1: Player1 >>> Player3
Step 2: Player3 >>> Player5
Step 3: Player5 >>> Player3
Step 4: Player3 >>> Player4
Step 5: Player4 >>> Player3
Step 6: Player3 >>> Player4
Step 7: Player4 >>> Player5
Step 8: Player5 >>> Player2
Step 9: Player2 >>> Player5
Step 10: Player5 >>> Player4
Step 11: Player4 >>> Player2
Step 12: Player2 >>> Player4
Step 13: Player4 >>> Player1
Step 14: Player1 >>> Player4
Step 15: Player4 >>> Player3
Step 16: Player3 >>> Player1
Step 17: Player1 >>> Player2
Step 18: Player2 >>> Player3
Step 19: Player3 >>> Player1
Step 20: Player1 >>> Player5
Step 21: Player5 >>> Player1
Step 22: Player1 >>> Player2
Step 23: Player2 >>> Player4
Step 24: Player4 >>> Player5
Step 25: Player5 >>> Player3
Step 26: Player3 >>> Player4
Step 27: Player4 >>> Player2
Step 28: Player2 >>> Player5
Step 29: Player5 >>> Player2
Step 30: Player2 >>> Player1
Step 31: Player1 >>> Player3
Step 32: Player3 >>> Player4
Step 33: Player4 >>> Player1
Step 34: Player1 >>> Player3
Step 35: Player3 >>> Player4
Step 36: Player4 >>> Player3
Step 37: Player3 >>> Player2
Step 38: Player2 >>> Player5
Step 39: Player5 >>> Player4
Step 40: Player4 >>> Player5
Step 41: Player5 >>> Player1
Step 42: Player1 >>> Player5
Step 43: Player5 >>> Player3
Step 44: Player3 >>> Player5
Step 45: Player5 >>> Player2
Step 46: Player2 >>> Player3
Step 47: Player3 >>> Player2
Step 48: Player2 >>> Player5
Step 49: Player5 >>> Player4
Step 50: Player4 >>> Player2
Step 51: Player2 >>> Player5
Step 52: Player5 >>> Player1
Step 53: Player1 >>> Player5
Step 54: Player5 >>> Player3
Step 55: Player3 >>> Player5
Step 56: Player5 >>> Player2
Step 57: Player2 >>> Player1
Step 58: Player1 >>> Player4
Step 59: Player4 >>> Player1
Step 60: Player1 >>> Player4
Step 61: Player4 >>> Player3
Step 62: Player3 >>> Player2
Step 63: Player2 >>> Player5
Step 64: Player5 >>> Player4
Step 65: Player4 >>> Player5
Step 66: Player5 >>> Player1
Step 67: Player1 >>> Player5
Step 68: Player5 >>> Player3
Step 69: Player3 >>> Player4
Step 70: Player4 >>> Player2
Step 71: Player2 >>> Player5
Step 72: Player5 >>> Player2
Step 73: Player2 >>> Player1
Step 74: Player1 >>> Player4
Step 75: Player4 >>> Player1
Step 76: Player1 >>> Player2
Step 77: Player2 >>> Player5
Step 78: Player5 >>> Player4
Step 79: Player4 >>> Player3
Step 80: Player3 >>> Player1
Step 81: Player1 >>> Player5
Step 82: Player5 >>> Player1
Step 83: Player1 >>> Player4
Step 84: Player4 >>> Player5
Step 85: Player5 >>> Player3
Step 86: Player3 >>> Player5
Step 87: Player5 >>> Player2
Step 88: Player2 >>> Player3
Player2: I'm out!
Step 89: Player3 >>> Player4
... player Player2 is out ...
Step 90: Player4 >>> Player1
Step 91: Player1 >>> Player3
Step 92: Player3 >>> Player1
Step 93: Player1 >>> Player4
Step 94: Player4 >>> Player3
Step 95: Player3 >>> Player5
Step 96: Player5 >>> Player1
Step 97: Player1 >>> Player5
Step 98: Player5 >>> Player3
Step 99: Player3 >>> Player5
Step 100: Player5 >>> Player4
Step 101: Player4 >>> Player5
Player4: I'm out!
... player Player4 is out ...
Step 102: Player5 >>> Player1
Step 103: Player1 >>> Player3
Step 104: Player3 >>> Player1
Step 105: Player1 >>> Player3
Step 106: Player3 >>> Player5
Step 107: Player5 >>> Player3
Step 108: Player3 >>> Player1
Step 109: Player1 >>> Player3
Step 110: Player3 >>> Player5
Step 111: Player5 >>> Player1
Step 112: Player1 >>> Player3
Step 113: Player3 >>> Player5
Step 114: Player5 >>> Player3
Step 115: Player3 >>> Player1
Step 116: Player1 >>> Player3
Step 117: Player3 >>> Player5
Step 118: Player5 >>> Player1
Step 119: Player1 >>> Player3
Step 120: Player3 >>> Player5
Step 121: Player5 >>> Player3
Player5: I'm out!
... player Player5 is out ...
Step 122: Player3 >>> Player5
Step 123: Player5 >>> Player1
Player5: I'm out!
Step 124: Player1 >>> Player3
... player Player5 is out ...
Step 125: Player3 >>> Player1
Step 126: Player1 >>> Player3
Player1: I'm out!
... player Player1 is out ...
Step 127: Player3 >>> Player3
Player3: I'm out!
Step 128: Player3 >>> Player3
... player Player3 is out ...
Player3: I'm out!
Stop!
Step 129: Player3 >>> Player3
Player3: I'm out!

यी सबैबाट धेरै महत्त्वपूर्ण निष्कर्ष निकाल्न सकिन्छ:

यदि आवश्यक उपकरणहरू उपलब्ध छन् भने, एप्लिकेसन विकासकर्ताहरूले व्यापार तर्कबाट टाढा नभई अनुप्रयोगहरू बीच एकीकरण अन्तरक्रियाहरू सिर्जना गर्न सक्छन्;
एकीकरण कार्यको जटिलता (जटिलता) जसलाई ईन्जिनियरिङ् दक्षताहरू आवश्यक पर्दछ फ्रेमवर्क भित्र लुकाउन सकिन्छ यदि यो सुरुमा फ्रेमवर्कको वास्तुकलामा राखिएको छ। कार्यको कठिनाई (कठीन) लुकाउन सकिँदैन, त्यसैले कोडमा कठिन कार्यको समाधान तदनुसार हेर्नेछ;
एकीकरण तर्कको विकास गर्दा, अन्ततः स्थिरता र सबै एकीकरण सहभागीहरूको राज्य परिवर्तनको रेखीयताको कमीलाई ध्यानमा राख्न आवश्यक छ। यसले हामीलाई बाहिरी घटनाहरू हुने क्रमप्रति असंवेदनशील बनाउन तर्कलाई जटिल बनाउन बाध्य बनाउँछ। हाम्रो उदाहरणमा, खेलाडीले खेलबाट बाहिरिएको घोषणा गरेपछि खेलमा भाग लिन बाध्य हुन्छ: अन्य खेलाडीहरूले उसलाई बल पास गर्न जारी राख्छन् जबसम्म उसको निकासको जानकारी नपुग्छ र सबै सहभागीहरूद्वारा प्रक्रिया गरिन्छ। यो तर्कले खेलका नियमहरू पालना गर्दैन र छनौट गरिएको वास्तुकलाको ढाँचा भित्र एक सम्झौता समाधान हो।

अर्को, हाम्रो समाधान, सम्झौता र अन्य बिन्दुहरूको विभिन्न सूक्ष्मताहरूको बारेमा कुरा गरौं।

सबै सन्देशहरू एउटै लाइनमा

सबै एकीकृत एप्लिकेसनहरूले एउटा एकीकरण बससँग काम गर्दछ, जुन बाह्य ब्रोकरको रूपमा प्रस्तुत गरिएको छ, सन्देशहरूको लागि एउटा BPMQueue र संकेतहरू (घटनाहरू) को लागि एउटा BPMTopic विषय। एउटै लामबाट सबै सन्देशहरू पास गर्नु आफैमा एक सम्झौता हो। व्यापार तर्क स्तरमा, तपाइँ अब प्रणाली संरचनामा परिवर्तन नगरीकन धेरै नयाँ प्रकारका सन्देशहरू परिचय गर्न सक्नुहुन्छ। यो एक महत्त्वपूर्ण सरलीकरण हो, तर यसले निश्चित जोखिमहरू बोक्छ, जुन हाम्रो विशिष्ट कार्यहरूको सन्दर्भमा, हामीलाई त्यति महत्त्वपूर्ण देखिएन।

यद्यपि, यहाँ एउटा सूक्ष्मता छ: प्रत्येक अनुप्रयोगले आफ्नो डोमेनको नामद्वारा प्रवेशद्वारमा रहेको लाइनबाट "यसको" सन्देशहरू फिल्टर गर्दछ। साथै, डोमेन संकेतहरूमा निर्दिष्ट गर्न सकिन्छ, यदि तपाइँ एकल अनुप्रयोगमा संकेतको "स्कोप" सीमित गर्न आवश्यक छ। यसले बसको ब्यान्डविथ बढाउनुपर्छ, तर व्यवसायिक तर्कले अब डोमेन नामहरू प्रयोग गर्नुपर्छ: सन्देशहरू सम्बोधन गर्न अनिवार्य, संकेतहरूको लागि वांछनीय।

एकीकरण बसको विश्वसनीयता सुनिश्चित गर्दै

विश्वसनीयता धेरै चीजहरू मिलेर बनेको छ:

चयन गरिएको सन्देश ब्रोकर वास्तुकलाको एक महत्वपूर्ण भाग हो र असफलताको एकल बिन्दु हो: यो पर्याप्त रूपमा गल्ती-सहिष्णु हुनुपर्छ। तपाईंले राम्रो समर्थन र ठूलो समुदायको साथ समय-परीक्षण कार्यान्वयनहरू मात्र प्रयोग गर्नुपर्छ;
सन्देश ब्रोकरको उच्च उपलब्धता सुनिश्चित गर्न आवश्यक छ, जसको लागि यसलाई भौतिक रूपमा एकीकृत अनुप्रयोगहरूबाट अलग गरिनु पर्छ (व्यावसायिक तर्कको साथ अनुप्रयोगहरूको उच्च उपलब्धता प्रदान गर्न धेरै गाह्रो र महँगो छ);
दलाल "कम्तीमा एक पटक" डेलिभरी ग्यारेन्टीहरू प्रदान गर्न बाध्य छ। यो एकीकरण बसको भरपर्दो सञ्चालनको लागि अनिवार्य आवश्यकता हो। "ठ्याक्कै एक पटक" स्तर ग्यारेन्टीको लागि कुनै आवश्यकता छैन: व्यापार प्रक्रियाहरू प्राय: सन्देशहरू वा घटनाहरूको दोहोर्याइएको आगमनको लागि संवेदनशील हुँदैनन्, र विशेष कार्यहरूमा जहाँ यो महत्त्वपूर्ण छ, निरन्तर प्रयोग गर्नु भन्दा व्यापार तर्कमा थप जाँचहरू थप्न सजिलो हुन्छ। बरु "महंगा" " ग्यारेन्टीहरू;
सन्देशहरू र संकेतहरू पठाउने व्यापार प्रक्रियाहरू र डोमेन डेटाको स्थितिमा परिवर्तनको साथ एक साझा लेनदेनमा संलग्न हुनुपर्छ। रुचाइएको विकल्प ढाँचा प्रयोग गर्न हुनेछ लेनदेन आउटबक्स, तर यसलाई डाटाबेस र रिलेमा थप तालिका चाहिन्छ। JEE अनुप्रयोगहरूमा, यसलाई स्थानीय JTA प्रबन्धक प्रयोग गरेर सरलीकृत गर्न सकिन्छ, तर चयन गरिएको ब्रोकरको जडान मोडमा काम गर्न सक्षम हुनुपर्छ। XA;
आगमन सन्देशहरू र घटनाहरूको ह्यान्डलरहरूले व्यापार प्रक्रियाको स्थिति परिवर्तन गर्ने लेनदेनको साथ पनि काम गर्नुपर्छ: यदि यस्तो लेनदेन फिर्ता भयो भने, सन्देशको रसिद पनि रद्द गरिनु पर्छ;
त्रुटिहरूको कारण डेलिभर हुन नसकेका सन्देशहरू छुट्टै स्टोरमा भण्डारण गर्नुपर्छ D.L.Q (मृत पत्र लाम)। यो गर्नको लागि, हामीले एउटा छुट्टै प्लेटफर्म माइक्रोसर्भिस सिर्जना गर्यौं जसले त्यस्ता सन्देशहरूलाई यसको भण्डारणमा भण्डार गर्दछ, तिनीहरूलाई विशेषताहरू (छिटो समूहबद्ध र खोजीका लागि) द्वारा अनुक्रमणिका बनाउँछ, र हेर्न, गन्तव्य ठेगानामा पुन: पठाउने, र सन्देशहरू मेटाउन API लाई उजागर गर्दछ। प्रणाली प्रशासकहरूले आफ्नो वेब इन्टरफेस मार्फत यस सेवासँग काम गर्न सक्छन्;
ब्रोकर सेटिङहरूमा, तपाईंले DLQ मा सन्देशहरू आउने सम्भावना कम गर्नको लागि डेलिभरी पुन: प्रयासहरूको संख्या र डेलिभरीहरू बीचको ढिलाइ समायोजन गर्न आवश्यक छ (इष्टतम प्यारामिटरहरू गणना गर्न लगभग असम्भव छ, तर तपाईंले अनुभवात्मक रूपमा कार्य गर्न सक्नुहुन्छ र तिनीहरूलाई समायोजन गर्न सक्नुहुन्छ। सञ्चालन);
DLQ स्टोरलाई निरन्तर अनुगमन गरिनुपर्छ, र अनुगमन प्रणालीले प्रणाली प्रशासकहरूलाई सूचित गर्नुपर्छ ताकि उनीहरूले सकेसम्म चाँडो प्रतिक्रिया दिन सकून्। यसले असफलता वा व्यापार तर्क त्रुटिको "क्षति क्षेत्र" कम गर्नेछ;
एकीकरण बस अनुप्रयोगहरूको अस्थायी अनुपस्थितिमा असंवेदनशील हुनुपर्छ: विषय सदस्यताहरू टिकाऊ हुनुपर्दछ, र अनुप्रयोगको डोमेन नाम अद्वितीय हुनुपर्छ ताकि अरू कसैले अनुप्रयोगको अनुपस्थितिमा लामबाट यसको सन्देश प्रशोधन गर्ने प्रयास नगरोस्।

व्यापार तर्कको थ्रेड सुरक्षा सुनिश्चित गर्दै

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

प्रक्रिया व्यापार तर्कले प्रत्येक बाह्य घटनालाई प्रक्रिया गर्दछ जसले व्यक्तिगत रूपमा यस व्यवसाय प्रक्रियालाई असर गर्छ। यी घटनाहरू हुन सक्छन्:

व्यापार प्रक्रिया उदाहरण सुरु गर्दै;
एक व्यापार प्रक्रिया भित्र एक गतिविधि सम्बन्धित प्रयोगकर्ता कार्य;
सन्देश वा संकेत को रसिद जसमा एक व्यापार प्रक्रिया उदाहरण सदस्यता लिइएको छ;
व्यापार प्रक्रिया उदाहरण द्वारा सेट टाइमर को समाप्ति;
API मार्फत कार्य नियन्त्रण गर्नुहोस् (जस्तै प्रक्रिया रद्द गर्नुहोस्)।

प्रत्येक यस्तो घटनाले व्यापार प्रक्रिया उदाहरणको अवस्था परिवर्तन गर्न सक्छ: केही गतिविधिहरू समाप्त हुन सक्छन् र अरू सुरु हुन सक्छन्, निरन्तर गुणहरूको मानहरू परिवर्तन हुन सक्छन्। कुनै पनि गतिविधि बन्द गर्दा निम्न मध्ये एक वा बढी गतिविधिहरू सक्रिय हुन सक्छ। ती, बारीमा, अन्य घटनाहरूको लागि पर्खन रोक्न सक्छन्, वा, यदि तिनीहरूलाई कुनै अतिरिक्त डेटा आवश्यक पर्दैन भने, तिनीहरूले समान लेनदेनमा पूरा गर्न सक्छन्। लेनदेन बन्द गर्नु अघि, व्यापार प्रक्रियाको नयाँ अवस्था डाटाबेसमा भण्डार गरिएको छ, जहाँ यसले अर्को बाह्य घटनाको लागि पर्खनेछ।

रिलेसनल डाटाबेसमा भण्डारण गरिएको लगातार व्यापार प्रक्रिया डाटा एक धेरै सुविधाजनक प्रोसेसिङ सिङ्क्रोनाइजेसन बिन्दु हो जब अपडेटको लागि चयन गर्नुहोस्। यदि एक लेनदेनले यसलाई परिवर्तन गर्न डेटाबेसबाट व्यापार प्रक्रियाको स्थिति प्राप्त गर्न व्यवस्थित गर्यो भने, त्यसपछि समानान्तर रूपमा कुनै अन्य लेनदेनले अर्को परिवर्तनको लागि समान स्थिति प्राप्त गर्न सक्षम हुनेछैन, र पहिलो लेनदेन पूरा भएपछि, दोस्रो एक हो। पहिले नै परिवर्तन गरिएको अवस्था प्राप्त गर्न ग्यारेन्टी।

DBMS पक्षमा निराशावादी लकहरू प्रयोग गरेर, हामी सबै आवश्यक आवश्यकताहरू पूरा गर्छौं एसिड, र चलिरहेको उदाहरणहरूको संख्या बढाएर व्यापार तर्कको साथ अनुप्रयोग मापन गर्ने क्षमता पनि कायम राख्नुहोस्।

यद्यपि, निराशावादी लकहरूले हामीलाई गतिरोधको धम्की दिन्छ, जसको मतलब यो हो कि SELECT FOR UPDATE अझै पनि व्यापार तर्कमा केही गम्भीर केसहरूमा गतिरोधको अवस्थामा केही उचित टाइमआउटमा सीमित हुनुपर्छ।

अर्को समस्या व्यापार प्रक्रिया को सुरुवात को सिंक्रोनाइजेसन छ। जब त्यहाँ कुनै व्यापार प्रक्रिया उदाहरण छैन, त्यहाँ डेटाबेसमा कुनै राज्य छैन, त्यसैले वर्णन गरिएको विधिले काम गर्दैन। यदि तपाइँ एक विशेष दायरामा व्यापार प्रक्रिया उदाहरणको विशिष्टता सुनिश्चित गर्न चाहनुहुन्छ भने, तपाइँलाई प्रक्रिया वर्ग र सम्बन्धित दायरासँग सम्बन्धित कुनै प्रकारको सिङ्क्रोनाइजेसन वस्तु चाहिन्छ। यो समस्या समाधान गर्नको लागि, हामी एक फरक लक गर्ने संयन्त्र प्रयोग गर्छौं जसले हामीलाई बाह्य सेवा मार्फत URI ढाँचामा कुञ्जीद्वारा निर्दिष्ट गरिएको स्वेच्छाचारी स्रोतमा लक लिन अनुमति दिन्छ।

हाम्रा उदाहरणहरूमा, InitialPlayer व्यापार प्रक्रियाले घोषणा समावेश गर्दछ

uniqueConstraint = UniqueConstraints.singleton

तसर्थ, लगमा सम्बन्धित कुञ्जीको लक लिने र रिलिज गर्ने बारे सन्देशहरू छन्। अन्य व्यापार प्रक्रियाहरूको लागि त्यस्ता कुनै सन्देशहरू छैनन्: unique Constraint सेट गरिएको छैन।

निरन्तर राज्यको साथ व्यापार प्रक्रिया समस्याहरू

कहिलेकाहीँ एक स्थिर अवस्थाले मद्दत मात्र गर्दैन, तर वास्तवमा विकासमा बाधा पुर्‍याउँछ।
समस्याहरू सुरु हुन्छन् जब तपाईंलाई व्यापार तर्क र / वा व्यापार प्रक्रिया मोडेलमा परिवर्तन गर्न आवश्यक हुन्छ। यस्तो कुनै पनि परिवर्तन व्यवसाय प्रक्रियाहरूको पुरानो अवस्थासँग मिल्दो पाइँदैन। यदि डाटाबेसमा धेरै "लाइभ" उदाहरणहरू छन् भने, त्यसोभए असंगत परिवर्तनहरूले धेरै समस्या निम्त्याउन सक्छ, जुन हामीले प्राय: jBPM प्रयोग गर्दा सामना गर्यौं।

परिवर्तनको गहिराइमा निर्भर गर्दै, तपाइँ दुई तरिकामा कार्य गर्न सक्नुहुन्छ:

नयाँ व्यापार प्रक्रिया प्रकार सिर्जना गर्नुहोस् ताकि पुरानोमा असंगत परिवर्तनहरू नगर्नुहोस्, र नयाँ उदाहरणहरू सुरु गर्दा पुरानोको सट्टा प्रयोग गर्नुहोस्। पुराना उदाहरणहरूले "पुरानो तरिका" काम गर्न जारी राख्नेछ;
व्यापार तर्क अपडेट गर्दा व्यापार प्रक्रियाहरूको निरन्तर अवस्था माइग्रेट गर्नुहोस्।

पहिलो तरिका सरल छ, तर यसको सीमितता र बेफाइदाहरू छन्, उदाहरणका लागि:

धेरै व्यापार प्रक्रिया मोडेलहरूमा व्यापार तर्कको नक्कल, व्यापार तर्क को मात्रा मा वृद्धि;
प्रायः नयाँ व्यापार तर्कमा तत्काल संक्रमण आवश्यक हुन्छ (लगभग सधैं एकीकरण कार्यहरूको सन्दर्भमा);
विकासकर्तालाई थाहा छैन कुन बिन्दुमा अप्रचलित मोडेलहरू मेटाउन सम्भव छ।

व्यवहारमा, हामी दुबै दृष्टिकोणहरू प्रयोग गर्छौं, तर हाम्रो जीवनलाई सरल बनाउन धेरै निर्णयहरू गरेका छौं:

डाटाबेसमा, व्यापार प्रक्रियाको निरन्तर अवस्था सजिलै पढ्न सकिने र सजिलैसँग प्रशोधन गरिएको फारममा भण्डार गरिएको छ: JSON ढाँचा स्ट्रिङमा। यसले तपाइँलाई एप भित्र र बाहिर दुबै माइग्रेसन गर्न अनुमति दिन्छ। चरम अवस्थाहरूमा, तपाइँ यसलाई ह्यान्डलहरूसँग ट्वीक गर्न सक्नुहुन्छ (विशेष गरी डिबगिङको समयमा विकासमा उपयोगी);
एकीकरण व्यापार तर्कले व्यापार प्रक्रियाहरूको नामहरू प्रयोग गर्दैन, जसले गर्दा कुनै पनि समयमा सहभागी प्रक्रियाहरू मध्ये एउटाको कार्यान्वयनलाई नयाँ नामको साथ बदल्न सम्भव छ (उदाहरणका लागि, "InitialPlayerV2")। बाइन्डिङ सन्देश र संकेतहरूको नाम मार्फत हुन्छ;
प्रक्रिया मोडेलको संस्करण नम्बर छ, जसलाई हामीले यो मोडेलमा असंगत परिवर्तनहरू गरेमा वृद्धि गर्छौं, र यो संख्या प्रक्रिया उदाहरणको अवस्थासँगै भण्डारण गरिन्छ;
प्रक्रियाको निरन्तर अवस्था आधारबाट पहिले सुविधाजनक वस्तु मोडेलमा पढिन्छ जुन मोडेलको संस्करण नम्बर परिवर्तन भएको खण्डमा माइग्रेसन प्रक्रियाले काम गर्न सक्छ;
माइग्रेसन प्रक्रिया व्यापार तर्कको छेउमा राखिएको छ र डाटाबेसबाट यसको पुनर्स्थापनाको समयमा व्यापार प्रक्रियाको प्रत्येक उदाहरणको लागि "आलसी" भनिन्छ;
यदि तपाइँ सबै प्रक्रिया उदाहरणहरूको स्थिति छिटो र सिंक्रोनस रूपमा माइग्रेट गर्न आवश्यक छ भने, थप क्लासिक डाटाबेस माइग्रेसन समाधानहरू प्रयोग गरिन्छ, तर तपाइँले त्यहाँ JSON सँग काम गर्नुपर्छ।

के मलाई व्यापार प्रक्रियाहरूको लागि अर्को फ्रेमवर्क चाहिन्छ?

लेखमा वर्णन गरिएका समाधानहरूले हामीलाई हाम्रो जीवनलाई महत्त्वपूर्ण रूपमा सरल बनाउन, एप्लिकेसन विकास स्तरमा समाधान गरिएका समस्याहरूको दायरा विस्तार गर्न र माइक्रोसर्भिसेसहरूमा व्यापार तर्कलाई अलग गर्ने विचारलाई अझ आकर्षक बनाउन अनुमति दियो। यसका लागि, धेरै काम गरिएको छ, व्यापार प्रक्रियाहरूको लागि एक धेरै "हल्का" फ्रेमवर्क सिर्जना गरिएको छ, साथै लागू कार्यहरूको विस्तृत दायराको सन्दर्भमा पहिचान गरिएका समस्याहरू समाधान गर्न सेवा घटकहरू। हामीसँग यी परिणामहरू साझा गर्ने इच्छा छ, साझा कम्पोनेन्टहरूको विकासलाई निःशुल्क इजाजतपत्र अन्तर्गत खुला पहुँचमा ल्याउन। यो केहि प्रयास र समय आवश्यक हुनेछ। त्यस्ता समाधानहरूको माग बुझ्नु हाम्रो लागि थप प्रोत्साहन हुन सक्छ। प्रस्तावित लेखमा, फ्रेमवर्कको क्षमताहरूमा धेरै कम ध्यान दिइएको छ, तर तिनीहरूमध्ये केही उदाहरणहरू प्रस्तुत गरिएका छन्। यद्यपि हामीले हाम्रो ढाँचा प्रकाशित गर्यौं भने, एउटा छुट्टै लेख यसमा समर्पित हुनेछ। यस बीचमा, तपाईंले प्रश्नको जवाफ दिएर थोरै प्रतिक्रिया दिनुभयो भने हामी आभारी हुनेछौं:

दर्ता भएका प्रयोगकर्ताहरूले मात्र सर्वेक्षणमा भाग लिन सक्छन्। साइन इन गर्नुहोस्कृपया

के मलाई व्यापार प्रक्रियाहरूको लागि अर्को फ्रेमवर्क चाहिन्छ?

18,8%हो, म लामो समय देखि यस्तै केहि खोज्दै छु।
12,5%यो तपाईंको कार्यान्वयनको बारेमा थप जान्न रोचक छ, यो उपयोगी हुन सक्छ2
6,2%हामी अवस्थित फ्रेमवर्कहरू मध्ये एक प्रयोग गर्छौं, तर हामी यसलाई प्रतिस्थापन गर्ने बारे सोचिरहेका छौं
18,8%हामी अवस्थित फ्रेमवर्कहरू मध्ये एक प्रयोग गर्छौं, सबै कुरा सूट3
18,8%फ्रेमवर्क बिना सामना 3
25,0%आफ्नो 4 लेख्नुहोस्

16 प्रयोगकर्ताहरूले मतदान गरे। 7 प्रयोगकर्ताहरू रोकिए।

स्रोत: www.habr.com

BPM शैली एकीकरण

अस्वीकरण

BPM ले यसको साथ के गर्नु पर्छ?

एकीकरण ढाँचाको रूपमा सिंक्रोनस कलहरूको बेफाइदाहरू

"सागा" लेनदेनको समस्याको समाधानको रूपमा

माइक्रोसर्भिसेसहरूमा व्यापार तर्कको एन्केप्सुलेशन

एक आवेदन विकासकर्ता को आँखा मार्फत व्यापार प्रक्रियाहरु को एकीकरण

सबै सन्देशहरू एउटै लाइनमा

एकीकरण बसको विश्वसनीयता सुनिश्चित गर्दै

व्यापार तर्कको थ्रेड सुरक्षा सुनिश्चित गर्दै

निरन्तर राज्यको साथ व्यापार प्रक्रिया समस्याहरू

के मलाई व्यापार प्रक्रियाहरूको लागि अर्को फ्रेमवर्क चाहिन्छ?

के मलाई व्यापार प्रक्रियाहरूको लागि अर्को फ्रेमवर्क चाहिन्छ?

एक टिप्पणी थप्न Отменить ответ