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

हॅलो, हब्र!

आमची कंपनी ईआरपी-क्लास सॉफ्टवेअर सोल्यूशन्स विकसित करण्यात माहिर आहे, ज्यामध्ये मोठ्या प्रमाणात व्यवसाय तर्क आणि वर्कफ्लो a la EDMS सह व्यवहार प्रणालींचा मोठा वाटा आहे. आमच्या उत्पादनांच्या आधुनिक आवृत्त्या JavaEE तंत्रज्ञानावर आधारित आहेत, परंतु आम्ही मायक्रोसर्व्हिसेससह सक्रियपणे प्रयोग करत आहोत. अशा सोल्यूशन्समधील सर्वात समस्याप्रधान क्षेत्रांपैकी एक म्हणजे समीप डोमेनशी संबंधित विविध उपप्रणालींचे एकत्रीकरण. आम्ही वापरत असलेल्या स्थापत्य शैली, तंत्रज्ञान स्टॅक आणि फ्रेमवर्ककडे दुर्लक्ष करून, एकत्रीकरण कार्यांमुळे आम्हाला नेहमीच मोठी डोकेदुखी झाली आहे, परंतु अलीकडे अशा समस्यांचे निराकरण करण्यात प्रगती झाली आहे.

तुमच्या लक्षात आणून दिलेल्या लेखात, मी नियुक्त केलेल्या क्षेत्रातील एनपीओ क्रिस्टा च्या अनुभव आणि आर्किटेक्चरल संशोधनाबद्दल बोलेन. ऍप्लिकेशन डेव्हलपरच्या दृष्टिकोनातून एकत्रीकरण समस्येवर सोप्या उपायाचे उदाहरण देखील आम्ही पाहू आणि या साधेपणामागे काय दडलेले आहे ते शोधू.

अस्वीकरण

लेखात वर्णन केलेले आर्किटेक्चरल आणि तांत्रिक उपाय माझ्याद्वारे विशिष्ट कार्यांच्या संदर्भात वैयक्तिक अनुभवावर आधारित आहेत. हे उपाय सार्वत्रिक असल्याचा दावा करत नाहीत आणि इतर वापराच्या परिस्थितीनुसार ते इष्टतम असू शकत नाहीत.

BPM चा त्याच्याशी काय संबंध?

या प्रश्नाचे उत्तर देण्यासाठी, आम्हाला आमच्या उपायांच्या लागू केलेल्या समस्यांच्या तपशीलांमध्ये थोडेसे शोधले पाहिजे. आमच्या ठराविक ट्रान्झॅक्शनल सिस्टीममधील बिझनेस लॉजिकचा मुख्य भाग म्हणजे वापरकर्ता इंटरफेसद्वारे डेटाबेसमध्ये डेटा प्रविष्ट करणे, हा डेटा व्यक्तिचलितपणे आणि आपोआप तपासणे, काही वर्कफ्लोमधून पास करणे, दुसर्या सिस्टम / विश्लेषणात्मक डेटाबेस / संग्रहणावर प्रकाशित करणे, अहवाल तयार करणे. अशा प्रकारे, ग्राहकांसाठी सिस्टमचे मुख्य कार्य त्यांच्या अंतर्गत व्यवसाय प्रक्रियेचे ऑटोमेशन आहे.

सोयीसाठी, आम्ही संप्रेषणामध्ये "दस्तऐवज" हा शब्द वापरतो, डेटा सेटचे काही अमूर्तीकरण, एका सामान्य कीद्वारे एकत्रित केले जाते, ज्यामध्ये विशिष्ट कार्यप्रवाह "संलग्न" केला जाऊ शकतो.
पण इंटिग्रेशन लॉजिकचे काय? शेवटी, एकीकरणाचे कार्य सिस्टमच्या आर्किटेक्चरद्वारे व्युत्पन्न केले जाते, जे ग्राहकाच्या विनंतीनुसार नसून पूर्णपणे भिन्न घटकांच्या प्रभावाखाली भागांमध्ये "सावले" जाते:

कॉनवेच्या कायद्याच्या प्रभावाखाली;
इतर उत्पादनांसाठी पूर्वी विकसित केलेल्या उपप्रणालींच्या पुनर्वापराचा परिणाम म्हणून;
वास्तुविशारदाने ठरवल्याप्रमाणे, गैर-कार्यक्षम आवश्यकतांवर आधारित.

मुख्य वर्कफ्लोच्या व्यवसाय तर्कशास्त्रापासून एकत्रीकरण तर्कशास्त्र वेगळे करण्याचा एक मोठा प्रलोभन आहे जेणेकरुन एकीकरण कलाकृतींसह व्यवसाय तर्क दूषित होऊ नये आणि अनुप्रयोग विकासकाला सिस्टमच्या आर्किटेक्चरल लँडस्केपच्या वैशिष्ट्यांचा शोध घेण्यापासून वाचवता येईल. या दृष्टिकोनाचे बरेच फायदे आहेत, परंतु सराव त्याची अकार्यक्षमता दर्शवते:

मुख्य वर्कफ्लोच्या अंमलबजावणीमध्ये मर्यादित विस्तार बिंदूंमुळे एकीकरण समस्या सोडवणे सहसा सिंक्रोनस कॉलच्या रूपात सर्वात सोप्या पर्यायांकडे सरकते (खाली समकालिक एकत्रीकरणाच्या कमतरतांबद्दल अधिक);
जेव्हा दुसर्‍या उपप्रणालीकडून अभिप्राय आवश्यक असतो तेव्हा एकत्रीकरण कलाकृती मुख्य व्यवसाय तर्कामध्ये प्रवेश करतात;
ऍप्लिकेशन डेव्हलपर इंटिग्रेशनकडे दुर्लक्ष करतो आणि वर्कफ्लो बदलून ते सहजपणे खंडित करू शकतो;
वापरकर्त्याच्या दृष्टीकोनातून सिस्टम एकल होणे थांबवते, उपप्रणालींमधील "सीम्स" लक्षात येण्याजोग्या होतात, अनावश्यक वापरकर्ता ऑपरेशन्स दिसतात जे एका सबसिस्टममधून दुसर्‍या सबसिस्टममध्ये डेटाचे हस्तांतरण सुरू करतात.

मुख्य व्यवसाय तर्कशास्त्र आणि कार्यप्रवाहाचा अविभाज्य भाग म्हणून एकत्रीकरण परस्परसंवादांचा विचार करणे हा दुसरा दृष्टिकोन आहे. ऍप्लिकेशन डेव्हलपर्सच्या कौशल्याची आवश्यकता गगनाला भिडण्यापासून दूर ठेवण्यासाठी, नवीन एकत्रीकरण परस्परसंवाद तयार करणे सोपे आणि नैसर्गिकरित्या केले पाहिजे, समाधान निवडण्यासाठी कमीत कमी पर्यायांसह. हे दिसते त्यापेक्षा अधिक कठीण आहे: साधन वापरकर्त्याला त्याच्या वापरासाठी आवश्यक विविध पर्याय प्रदान करण्यासाठी पुरेसे शक्तिशाली असणे आवश्यक आहे आणि त्याच वेळी स्वतःला पायात गोळी मारण्याची परवानगी देऊ नये. असे अनेक प्रश्न आहेत ज्यांची उत्तरे एका अभियंत्याने एकत्रीकरण कार्यांच्या संदर्भात दिली पाहिजेत, परंतु अनुप्रयोग विकासकाने त्यांच्या दैनंदिन कामात ज्यांचा विचार करू नये: व्यवहाराच्या सीमा, सातत्य, अणु, सुरक्षा, स्केलिंग, लोड आणि संसाधन वितरण, राउटिंग, मार्शलिंग, प्रसार आणि संदर्भ बदलणे इ. ऍप्लिकेशन डेव्हलपरना अगदी सोपे निर्णय टेम्पलेट ऑफर करणे आवश्यक आहे, ज्यामध्ये अशा सर्व प्रश्नांची उत्तरे आधीच लपलेली आहेत. हे नमुने पुरेसे सुरक्षित असले पाहिजेत: व्यवसायाचे तर्क खूप वेळा बदलतात, ज्यामुळे त्रुटींचा परिचय होण्याचा धोका वाढतो, त्रुटींची किंमत अगदी कमी पातळीवर राहिली पाहिजे.

पण तरीही, बीपीएमचा त्याच्याशी काय संबंध आहे? कार्यप्रवाह लागू करण्यासाठी बरेच पर्याय आहेत ...
खरंच, व्यवसाय प्रक्रियांची आणखी एक अंमलबजावणी आमच्या सोल्यूशन्समध्ये खूप लोकप्रिय आहे - राज्य संक्रमण आकृतीच्या घोषणात्मक सेटिंगद्वारे आणि संक्रमणाशी व्यवसाय तर्कासह हँडलर्स कनेक्ट करणे. त्याच वेळी, व्यवसाय प्रक्रियेत "दस्तऐवज" ची वर्तमान स्थिती निर्धारित करणारी स्थिती ही "दस्तऐवज" चे गुणधर्म आहे.

प्रकल्पाच्या सुरूवातीस ही प्रक्रिया कशी दिसते

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

आवश्यकता स्पष्ट करण्याच्या अनेक पुनरावृत्तीनंतर ही प्रक्रिया कशी दिसते

या परिस्थितीतून बाहेर पडण्याचा मार्ग म्हणजे इंजिनचे एकत्रीकरण jBPM सर्वात जटिल व्यवसाय प्रक्रिया असलेल्या काही उत्पादनांमध्ये. अल्पावधीत, या सोल्यूशनला काही यश मिळाले: नोटेशनमध्ये बर्‍यापैकी माहितीपूर्ण आणि अद्ययावत आकृती राखून जटिल व्यावसायिक प्रक्रिया लागू करणे शक्य झाले. BPMN2.

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

दीर्घकाळात, समाधान अपेक्षेनुसार जगू शकले नाही: व्हिज्युअल साधनांद्वारे व्यवसाय प्रक्रिया तयार करण्याच्या उच्च श्रम तीव्रतेमुळे स्वीकार्य उत्पादकता निर्देशक साध्य होऊ शकले नाहीत आणि हे साधन स्वतःच विकसकांमध्ये सर्वात नापसंत बनले. इंजिनच्या अंतर्गत संरचनेबद्दल देखील तक्रारी होत्या, ज्यामुळे बरेच “पॅच” आणि “क्रचेस” दिसू लागले.

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

वरील आधारे, आम्ही निष्कर्ष काढू शकतो: BPM शैलीतील प्रक्रियेचा दृष्टीकोन आम्हाला अधिक जटिल व्यावसायिक प्रक्रिया स्वयंचलित करण्यासाठी, या प्रक्रियेमध्ये सामंजस्याने एकीकरण क्रियाकलाप बसवण्यासाठी आणि लागू केलेल्या प्रक्रियेला योग्य नोटेशनमध्ये दृश्यमानपणे प्रदर्शित करण्याची क्षमता राखून ठेवण्यासाठी विस्तृत कार्ये सोडविण्यास अनुमती देतो.

एकीकरण नमुना म्हणून सिंक्रोनस कॉलचे तोटे

सिंक्रोनस इंटिग्रेशन सर्वात सोपा ब्लॉकिंग कॉलचा संदर्भ देते. एक उपप्रणाली सर्व्हर साइड म्हणून कार्य करते आणि इच्छित पद्धतीसह API उघड करते. दुसरी उपप्रणाली क्लायंटची बाजू म्हणून काम करते आणि योग्य वेळी, निकालाच्या अपेक्षेने कॉल करते. सिस्टमच्या आर्किटेक्चरच्या आधारावर, क्लायंट आणि सर्व्हर बाजू एकाच अनुप्रयोग आणि प्रक्रियेमध्ये किंवा भिन्न मध्ये होस्ट केल्या जाऊ शकतात. दुसऱ्या प्रकरणात, तुम्हाला RPC ची काही अंमलबजावणी लागू करणे आणि पॅरामीटर्सचे मार्शलिंग आणि कॉलचे परिणाम प्रदान करणे आवश्यक आहे.

अशा एकत्रीकरण पॅटर्नमध्ये बर्‍याच प्रमाणात कमतरता आहेत, परंतु त्याच्या साधेपणामुळे ते व्यवहारात मोठ्या प्रमाणात वापरले जाते. अंमलबजावणीची गती मोहित करते आणि "बर्निंग" डेडलाइनच्या परिस्थितीत, तांत्रिक कर्जामध्ये समाधान लिहून आपल्याला ते पुन्हा पुन्हा लागू करण्यास प्रवृत्त करते. परंतु असे देखील घडते की अननुभवी विकासक हे नकळतपणे वापरतात, फक्त नकारात्मक परिणामांची जाणीव होत नाही.

उपप्रणालींच्या कनेक्टिव्हिटीमध्ये सर्वात स्पष्ट वाढीव्यतिरिक्त, "स्प्रेडिंग" आणि "स्ट्रेचिंग" व्यवहारांमध्ये कमी स्पष्ट समस्या आहेत. खरंच, जर व्यवसाय तर्कशास्त्राने काही बदल केले, तर व्यवहार अपरिहार्य आहेत आणि व्यवहार, या बदलांमुळे काही अनुप्रयोग संसाधने लॉक करतात. म्हणजेच, जोपर्यंत एक उपप्रणाली दुसर्‍याकडून प्रतिसादाची प्रतीक्षा करत नाही तोपर्यंत ती व्यवहार पूर्ण करू शकणार नाही आणि लॉक सोडू शकणार नाही. हे विविध प्रभावांचा धोका लक्षणीय वाढवते:

सिस्टम प्रतिसाद गमावला आहे, वापरकर्ते विनंत्यांच्या उत्तरांसाठी बराच वेळ प्रतीक्षा करतात;
थ्रेड पूल ओव्हरफ्लो झाल्यामुळे सर्व्हर सामान्यतः वापरकर्त्याच्या विनंतीला प्रतिसाद देणे थांबवतो: बहुतेक थ्रेड्स व्यवहाराद्वारे व्यापलेल्या संसाधनाच्या लॉकवर "स्टँड" असतात;
डेडलॉक्स दिसू लागतात: त्यांच्या घटनेची संभाव्यता व्यवहाराच्या कालावधीवर, व्यवहारात गुंतलेल्या व्यवसायातील तर्क आणि लॉकचे प्रमाण यावर अवलंबून असते;
व्यवहार कालबाह्यता त्रुटी दिसतात;
जर कार्यासाठी मोठ्या प्रमाणात डेटावर प्रक्रिया करणे आणि बदलणे आवश्यक असल्यास सर्व्हर OutOfMemory वर "पडतो".

आर्किटेक्चरल दृष्टिकोनातून, इंटिग्रेशन दरम्यान ब्लॉकिंग कॉलचा वापर केल्याने वैयक्तिक उपप्रणालीचे गुणवत्ता नियंत्रण गमावले जाते: एका उपप्रणालीचे गुणवत्ता लक्ष्य दुसर्‍या उपप्रणालीच्या गुणवत्ता लक्ष्यापासून वेगळे करणे अशक्य आहे. जर उपप्रणाली वेगवेगळ्या संघांनी विकसित केल्या असतील तर ही एक मोठी समस्या आहे.

समाकलित केल्या जाणार्‍या उपप्रणाली वेगवेगळ्या ऍप्लिकेशन्समध्ये असल्यास आणि दोन्ही बाजूंनी समकालिक बदल करणे आवश्यक असल्यास गोष्टी अधिक मनोरंजक होतात. हे बदल व्यवहारात कसे करायचे?

जर स्वतंत्र व्यवहारांमध्ये बदल केले गेले, तर मजबूत अपवाद हाताळणी आणि भरपाई प्रदान करणे आवश्यक आहे आणि यामुळे समकालिक एकत्रीकरणाचा मुख्य फायदा पूर्णपणे काढून टाकला जातो - साधेपणा.

वितरित व्यवहार देखील लक्षात येतात, परंतु आम्ही ते आमच्या उपायांमध्ये वापरत नाही: विश्वासार्हता सुनिश्चित करणे कठीण आहे.

व्यवहारांच्या समस्येवर उपाय म्हणून "सागा".

मायक्रोसर्व्हिसेसच्या वाढत्या लोकप्रियतेसह, मागणी वाढत आहे गाथा पॅटर्न.

हा पॅटर्न दीर्घ व्यवहारांच्या वरील समस्यांचे उत्तम प्रकारे निराकरण करतो आणि व्यवसाय तर्कशास्त्राच्या बाजूने सिस्टमची स्थिती व्यवस्थापित करण्याच्या शक्यता देखील वाढवतो: अयशस्वी व्यवहारानंतरची भरपाई सिस्टमला त्याच्या मूळ स्थितीत परत आणू शकत नाही, परंतु पर्याय प्रदान करते. डेटा प्रक्रिया मार्ग. जेव्हा तुम्ही प्रक्रियेला "चांगल्या" शेवटपर्यंत आणण्याचा प्रयत्न करता तेव्हा ते तुम्हाला यशस्वीरित्या पूर्ण झालेल्या डेटा प्रोसेसिंग चरणांची पुनरावृत्ती न करण्याची परवानगी देते.

विशेष म्हणजे, मोनोलिथिक सिस्टीममध्ये, हा पॅटर्न देखील संबंधित असतो जेव्हा तो सैलपणे जोडलेल्या उपप्रणालींच्या एकत्रीकरणासाठी येतो आणि दीर्घ व्यवहारांमुळे आणि संबंधित संसाधन लॉकमुळे नकारात्मक प्रभाव पडतो.

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

परंतु या सोल्यूशनची स्वतःची "किंमत" देखील आहे:

व्यवसाय तर्क अधिक जटिल होते: तुम्हाला नुकसान भरपाईची आवश्यकता आहे;
पूर्ण सुसंगतता सोडून देणे आवश्यक आहे, जे विशेषतः मोनोलिथिक सिस्टमसाठी संवेदनशील असू शकते;
आर्किटेक्चर थोडे अधिक क्लिष्ट होते, संदेश ब्रोकरची अतिरिक्त आवश्यकता आहे;
अतिरिक्त देखरेख आणि प्रशासन साधने आवश्यक असतील (जरी सर्वसाधारणपणे हे अगदी चांगले आहे: सिस्टम सेवेची गुणवत्ता वाढेल).

मोनोलिथिक सिस्टमसाठी, "सॅग्स" वापरण्याचे औचित्य इतके स्पष्ट नाही. मायक्रोसर्व्हिसेस आणि इतर SOA साठी, जेथे, बहुधा, आधीपासूनच एक दलाल आहे, आणि प्रकल्पाच्या सुरूवातीस संपूर्ण सातत्याचा त्याग केला गेला आहे, या पॅटर्नचा वापर करण्याचे फायदे तोट्यांपेक्षा लक्षणीयरीत्या जास्त असू शकतात, विशेषत: येथे सोयीस्कर API असल्यास. व्यवसाय तर्क पातळी.

मायक्रोसर्व्हिसेसमध्ये व्यवसाय तर्कशास्त्र एन्कॅप्युलेशन

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

विविध BPMS च्या आर्किटेक्चरकडे पाहताना, व्यवसाय लॉजिकला चिकाटीपासून वेगळे करणे वाजवी वाटू शकते: प्लॅटफॉर्म आणि डोमेन-स्वतंत्र मायक्रोसर्व्हिसेसचा एक स्तर तयार करा जो डोमेन व्यवसाय लॉजिक कार्यान्वित करण्यासाठी पर्यावरण आणि कंटेनर तयार करतो आणि डोमेन डेटा टिकून राहण्याची व्यवस्था स्वतंत्रपणे करतो. अतिशय सोप्या आणि हलक्या वजनाच्या मायक्रो सर्व्हिसेसचा थर. या प्रकरणात व्यवसाय प्रक्रिया पर्सिस्टन्स लेयरच्या सेवांचे आयोजन करतात.

या दृष्टिकोनाचा खूप मोठा फायदा आहे: आपण आपल्या आवडीनुसार प्लॅटफॉर्मची कार्यक्षमता वाढवू शकता आणि प्लॅटफॉर्म मायक्रोसर्व्हिसेसचा केवळ संबंधित स्तर यातून "चरबी" मिळवेल. प्लॅटफॉर्मची नवीन कार्यक्षमता अद्ययावत होताच ती वापरण्याची संधी कोणत्याही डोमेनमधील व्यवसाय प्रक्रियांना लगेच मिळते.

अधिक तपशीलवार अभ्यासाने या दृष्टिकोनातील महत्त्वपूर्ण कमतरता उघड केल्या:

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

सरतेशेवटी, मला मूलभूत गोष्टींवर परत जावे लागले: डोमेन डेटा आणि डोमेन बिझनेस लॉजिक एका मायक्रोसर्व्हिसमध्ये एन्कॅप्स्युलेट करा. हा दृष्टीकोन प्रणालीमधील अविभाज्य घटक म्हणून मायक्रोसर्व्हिसची धारणा सुलभ करते आणि वरील समस्यांना जन्म देत नाही. हे देखील विनामूल्य नाही:

व्यवसाय तर्कशास्त्र (विशेषतः, व्यवसाय प्रक्रियेचा भाग म्हणून वापरकर्ता क्रियाकलाप प्रदान करण्यासाठी) आणि API प्लॅटफॉर्म सेवांसह परस्परसंवादासाठी API मानकीकरण आवश्यक आहे; API बदलांकडे अधिक काळजीपूर्वक लक्ष देणे, फॉरवर्ड आणि बॅकवर्ड सुसंगतता आवश्यक आहे;
अशा प्रत्येक मायक्रोसेवेचा भाग म्हणून बिझनेस लॉजिकचे कार्य सुनिश्चित करण्यासाठी अतिरिक्त रनटाइम लायब्ररी जोडणे आवश्यक आहे आणि यामुळे अशा लायब्ररींसाठी नवीन आवश्यकता निर्माण होतात: हलकीपणा आणि कमीतकमी संक्रमणात्मक अवलंबित्व;
बिझनेस लॉजिक डेव्हलपर्सना लायब्ररी आवृत्त्यांचा मागोवा ठेवणे आवश्यक आहे: जर मायक्रोसर्व्हिस बर्याच काळापासून अंतिम केली गेली नसेल तर बहुधा त्यात लायब्ररीची जुनी आवृत्ती असेल. नवीन वैशिष्ट्य जोडण्यात हा एक अनपेक्षित अडथळा असू शकतो आणि आवृत्त्यांमध्ये विसंगत बदल असल्यास अशा सेवेचे जुने व्यावसायिक तर्क लायब्ररींच्या नवीन आवृत्त्यांमध्ये स्थलांतरित करणे आवश्यक असू शकते.

अशा आर्किटेक्चरमध्ये प्लॅटफॉर्म सेवांचा एक स्तर देखील असतो, परंतु हा स्तर यापुढे डोमेन व्यवसाय लॉजिक कार्यान्वित करण्यासाठी कंटेनर बनवत नाही, परंतु केवळ त्याचे वातावरण, सहायक "प्लॅटफॉर्म" कार्ये प्रदान करते. अशा लेयरची आवश्यकता केवळ डोमेन मायक्रोसर्व्हिसेसची हलकीपणा राखण्यासाठीच नाही तर व्यवस्थापनाचे केंद्रीकरण करण्यासाठी देखील आहे.

उदाहरणार्थ, व्यवसाय प्रक्रियेतील वापरकर्ता क्रियाकलाप कार्ये व्युत्पन्न करतात. तथापि, कार्यांसह कार्य करताना, वापरकर्त्याने सर्वसाधारण सूचीमधील सर्व डोमेनमधील कार्ये पाहिली पाहिजेत, याचा अर्थ असा की डोमेन व्यवसाय तर्कशास्त्रापासून मुक्त असलेली योग्य कार्य नोंदणी प्लॅटफॉर्म सेवा असणे आवश्यक आहे. या संदर्भात व्यवसाय लॉजिकचे एन्केप्सुलेशन ठेवणे खूप समस्याप्रधान आहे आणि ही या आर्किटेक्चरची आणखी एक तडजोड आहे.

अॅप्लिकेशन डेव्हलपरच्या नजरेतून व्यवसाय प्रक्रियांचे एकत्रीकरण

आधीच वर नमूद केल्याप्रमाणे, ऍप्लिकेशन डेव्हलपरने चांगल्या विकास उत्पादकतेवर विश्वास ठेवण्यासाठी अनेक ऍप्लिकेशन्सच्या परस्परसंवादाच्या अंमलबजावणीच्या तांत्रिक आणि अभियांत्रिकी वैशिष्ट्यांपासून अमूर्त असणे आवश्यक आहे.

चला एक ऐवजी कठीण एकत्रीकरण समस्या सोडवण्याचा प्रयत्न करूया, विशेषत: लेखासाठी शोधलेला. हे एक "गेम" कार्य असेल ज्यामध्ये तीन ऍप्लिकेशन्सचा समावेश असेल, जिथे प्रत्येकाने काही डोमेन नाव परिभाषित केले आहे: "app1", "app2", "app3".

प्रत्येक ऍप्लिकेशनच्या आत, व्यवसाय प्रक्रिया सुरू केल्या जातात ज्या एकीकरण बसद्वारे "प्ले बॉल" सुरू करतात. "बॉल" नावाचे संदेश बॉल म्हणून काम करतील.

खेळाचे नियम:

पहिला खेळाडू आरंभकर्ता आहे. तो इतर खेळाडूंना खेळासाठी आमंत्रित करतो, खेळ सुरू करतो आणि तो कधीही संपवू शकतो;
इतर खेळाडू गेममध्ये त्यांचा सहभाग घोषित करतात, एकमेकांशी आणि पहिल्या खेळाडूशी "परिचित व्हा";
चेंडू मिळाल्यानंतर, खेळाडू दुसरा सहभागी खेळाडू निवडतो आणि त्याच्याकडे चेंडू देतो. पासची एकूण संख्या मोजली जाते;
प्रत्येक खेळाडूमध्ये "ऊर्जा" असते, जी त्या खेळाडूच्या चेंडूच्या प्रत्येक पासने कमी होते. जेव्हा ऊर्जा संपते, तेव्हा खेळाडूला खेळातून काढून टाकले जाते, त्यांची निवृत्ती जाहीर केली जाते;
जर खेळाडू एकटा सोडला असेल तर तो ताबडतोब त्याचे निर्गमन घोषित करतो;
जेव्हा सर्व खेळाडू काढून टाकले जातात, तेव्हा पहिला खेळाडू गेम संपल्याची घोषणा करतो. जर त्याने आधी गेम सोडला असेल तर तो पूर्ण करण्यासाठी गेमचे अनुसरण करणे बाकी आहे.

या समस्येचे निराकरण करण्यासाठी, मी आमच्या डीएसएलचा वापर व्यावसायिक प्रक्रियेसाठी करेन, जे तुम्हाला कमीत कमी बॉयलरप्लेटसह कॉटलिनमधील तर्काचे संक्षिप्त वर्णन करण्यास अनुमती देते.

ऍप1 ऍप्लिकेशनमध्ये, पहिल्या खेळाडूची व्यवसाय प्रक्रिया (तो गेमचा आरंभकर्ता देखील आहे) कार्य करेल:

वर्ग आरंभिक खेळाडू

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

आकृती:

ऍप3 ऍप्लिकेशनमध्ये, आम्ही खेळाडूला थोड्या वेगळ्या वर्तनासह बनवू: यादृच्छिकपणे पुढील खेळाडू निवडण्याऐवजी, तो राउंड-रॉबिन अल्गोरिदमनुसार कार्य करेल:

RoundRobinPlayer वर्ग

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 विषय (इव्हेंट) म्हणून सादर केली जाते. एकाच रांगेतून सर्व संदेश पाठवणे ही एक तडजोड आहे. बिझनेस लॉजिक स्तरावर, तुम्ही आता सिस्टम स्ट्रक्चरमध्ये बदल न करता तुम्हाला हवे तितके नवीन प्रकारचे मेसेज सादर करू शकता. हे एक महत्त्वपूर्ण सरलीकरण आहे, परंतु त्यात काही जोखीम आहेत, जे आमच्या वैशिष्ट्यपूर्ण कार्यांच्या संदर्भात, आम्हाला इतके महत्त्वपूर्ण वाटत नाहीत.

तथापि, येथे एक सूक्ष्मता आहे: प्रत्येक अनुप्रयोग प्रवेशद्वारावरील रांगेतील "त्याचे" संदेश त्याच्या डोमेनच्या नावाने फिल्टर करतो. तसेच, सिग्नलमध्ये डोमेन निर्दिष्ट केले जाऊ शकते, जर तुम्हाला सिग्नलचा "स्कोप" एका अनुप्रयोगासाठी मर्यादित करण्याची आवश्यकता असेल. यामुळे बसची बँडविड्थ वाढली पाहिजे, परंतु व्यवसाय तर्क आता डोमेन नावांसह कार्य करणे आवश्यक आहे: संदेशांना संबोधित करण्यासाठी अनिवार्य, सिग्नलसाठी इष्ट.

एकत्रीकरण बसची विश्वासार्हता सुनिश्चित करणे

विश्वासार्हता अनेक गोष्टींनी बनलेली आहे:

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

व्यवसाय तर्काच्या धाग्याची सुरक्षितता सुनिश्चित करणे

व्यवसाय प्रक्रियेच्या समान उदाहरणावर एकाच वेळी अनेक संदेश आणि कार्यक्रम प्राप्त होऊ शकतात, ज्याची प्रक्रिया समांतरपणे सुरू होईल. त्याच वेळी, अॅप्लिकेशन डेव्हलपरसाठी, सर्वकाही सोपे आणि थ्रेड-सेफ असावे.

प्रक्रिया व्यवसाय तर्क प्रत्येक बाह्य इव्हेंटवर प्रक्रिया करते जी या व्यवसाय प्रक्रियेस वैयक्तिकरित्या प्रभावित करते. या घटना असू शकतात:

व्यवसाय प्रक्रिया उदाहरण सुरू करणे;
व्यवसाय प्रक्रियेतील क्रियाकलापाशी संबंधित वापरकर्ता क्रिया;
संदेश किंवा सिग्नलची पावती ज्यासाठी व्यवसाय प्रक्रिया उदाहरण सदस्यता घेतली आहे;
व्यवसाय प्रक्रियेच्या उदाहरणाद्वारे सेट केलेल्या टाइमरची समाप्ती;
API द्वारे क्रिया नियंत्रित करा (उदा. प्रक्रिया रद्द करा).

अशी प्रत्येक घटना व्यवसाय प्रक्रियेची स्थिती बदलू शकते: काही क्रियाकलाप संपू शकतात आणि इतर सुरू होऊ शकतात, स्थिर गुणधर्मांची मूल्ये बदलू शकतात. कोणताही क्रियाकलाप बंद केल्याने खालीलपैकी एक किंवा अधिक क्रियाकलाप सक्रिय होऊ शकतात. ते, या बदल्यात, इतर कार्यक्रमांची प्रतीक्षा करणे थांबवू शकतात किंवा, त्यांना कोणत्याही अतिरिक्त डेटाची आवश्यकता नसल्यास, ते त्याच व्यवहारात पूर्ण करू शकतात. व्यवहार बंद करण्यापूर्वी, व्यवसाय प्रक्रियेची नवीन स्थिती डेटाबेसमध्ये संग्रहित केली जाते, जिथे ते पुढील बाह्य कार्यक्रमाची प्रतीक्षा करेल.

रिलेशनल डेटाबेसमध्ये साठवलेला पर्सिस्टंट बिझनेस प्रोसेस डेटा हा सिलेक्ट फॉर अपडेट वापरताना एक अतिशय सोयीस्कर प्रोसेसिंग सिंक्रोनाइझेशन पॉइंट आहे. जर एका व्यवहाराने डेटाबेसमधून व्यवसाय प्रक्रियेची स्थिती बदलण्यासाठी व्यवस्थापित केली असेल, तर समांतर इतर कोणत्याही व्यवहाराला दुसर्‍या बदलासाठी समान स्थिती मिळू शकणार नाही आणि पहिला व्यवहार पूर्ण झाल्यानंतर, दुसरा व्यवहार आधीच बदललेली स्थिती प्राप्त करण्याची हमी.

DBMS बाजूला निराशावादी लॉक वापरून, आम्ही सर्व आवश्यक आवश्यकता पूर्ण करतो आम्ल, आणि चालू उदाहरणांची संख्या वाढवून व्यवसाय तर्कासह अनुप्रयोग मोजण्याची क्षमता देखील राखून ठेवते.

तथापि, निराशावादी लॉक्समुळे आम्हाला डेडलॉकचा धोका असतो, याचा अर्थ असा आहे की व्यवसाय तर्कशास्त्रातील काही गंभीर प्रकरणांमध्ये डेडलॉकच्या बाबतीत सिलेक्ट फॉर अपडेट अजूनही काही वाजवी कालबाह्यतेपर्यंत मर्यादित असावे.

दुसरी समस्या म्हणजे व्यवसाय प्रक्रियेच्या प्रारंभाचे सिंक्रोनाइझेशन. कोणतीही व्यवसाय प्रक्रिया उदाहरण नसताना, डेटाबेसमध्ये कोणतीही स्थिती नाही, म्हणून वर्णन केलेली पद्धत कार्य करणार नाही. जर तुम्हाला एखाद्या विशिष्ट व्याप्तीमध्ये व्यवसाय प्रक्रियेच्या उदाहरणाची विशिष्टता सुनिश्चित करायची असेल, तर तुम्हाला प्रक्रिया वर्ग आणि संबंधित व्याप्तीशी संबंधित काही प्रकारचे सिंक्रोनाइझेशन ऑब्जेक्ट आवश्यक आहे. या समस्येचे निराकरण करण्यासाठी, आम्ही एक वेगळी लॉकिंग यंत्रणा वापरतो जी आम्हाला बाह्य सेवेद्वारे URI फॉरमॅटमध्ये की द्वारे निर्दिष्ट केलेल्या अनियंत्रित संसाधनावर लॉक घेण्यास अनुमती देते.

आमच्या उदाहरणांमध्ये, InitialPlayer व्यवसाय प्रक्रियेत एक घोषणा आहे

uniqueConstraint = UniqueConstraints.singleton

म्हणून, लॉगमध्ये संबंधित की लॉक घेण्याबद्दल आणि सोडण्याबद्दल संदेश आहेत. इतर व्यवसाय प्रक्रियांसाठी असे कोणतेही संदेश नाहीत: अद्वितीय बंधन सेट केलेले नाही.

सतत स्थितीसह व्यवसाय प्रक्रिया समस्या

काहीवेळा सतत स्थिती राहणे केवळ मदत करत नाही तर खरोखर विकासास अडथळा आणते.
जेव्हा तुम्हाला व्यवसाय तर्क आणि/किंवा व्यवसाय प्रक्रिया मॉडेलमध्ये बदल करण्याची आवश्यकता असते तेव्हा समस्या सुरू होतात. असा कोणताही बदल व्यवसाय प्रक्रियांच्या जुन्या स्थितीशी सुसंगत असल्याचे आढळत नाही. जर डेटाबेसमध्ये अनेक "लाइव्ह" उदाहरणे असतील, तर विसंगत बदल केल्याने खूप त्रास होऊ शकतो, ज्याचा आम्हाला jBPM वापरताना अनेकदा सामना करावा लागतो.

बदलाच्या खोलीवर अवलंबून, आपण दोन प्रकारे कार्य करू शकता:

जुन्यामध्ये विसंगत बदल करू नयेत म्हणून नवीन व्यवसाय प्रक्रिया प्रकार तयार करा आणि नवीन उदाहरणे सुरू करताना जुन्याऐवजी त्याचा वापर करा. जुनी उदाहरणे "जुन्या पद्धतीने" कार्य करत राहतील;
बिझनेस लॉजिक अपडेट करताना बिझनेस प्रोसेस्सची सक्तीची स्थिती स्थलांतरित करा.

पहिला मार्ग सोपा आहे, परंतु त्याच्या मर्यादा आणि तोटे आहेत, उदाहरणार्थ:

अनेक व्यवसाय प्रक्रिया मॉडेल्समध्ये व्यवसाय तर्कशास्त्राचे डुप्लिकेशन, व्यवसाय तर्कशास्त्राच्या प्रमाणात वाढ;
बर्‍याचदा नवीन व्यवसाय तर्कामध्ये त्वरित संक्रमण आवश्यक असते (जवळजवळ नेहमीच एकत्रीकरण कार्यांच्या बाबतीत);
विकसकाला माहित नाही की अप्रचलित मॉडेल हटवणे कोणत्या टप्प्यावर शक्य आहे.

व्यवहारात, आम्ही दोन्ही पद्धती वापरतो, परंतु आमचे जीवन सोपे करण्यासाठी अनेक निर्णय घेतले आहेत:

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

मला व्यवसाय प्रक्रियेसाठी आणखी एक फ्रेमवर्क आवश्यक आहे का?

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

केवळ नोंदणीकृत वापरकर्तेच सर्वेक्षणात भाग घेऊ शकतात. साइन इन करा, आपले स्वागत आहे.

मला व्यवसाय प्रक्रियेसाठी आणखी एक फ्रेमवर्क आवश्यक आहे का?

18,8%होय, मी बर्याच काळापासून असे काहीतरी शोधत आहे.
12,5%आपल्या अंमलबजावणीबद्दल अधिक जाणून घेणे मनोरंजक आहे, ते उपयुक्त असू शकते2
6,2%आम्ही विद्यमान फ्रेमवर्कपैकी एक वापरतो, परंतु आम्ही ते बदलण्याचा विचार करत आहोत
18,8%आम्ही विद्यमान फ्रेमवर्कपैकी एक वापरतो, सर्वकाही सूट3
18,8%फ्रेमवर्कशिवाय सामना करणे3
25,0%तुमचे स्वतःचे लिहा

16 वापरकर्त्यांनी मतदान केले. 7 वापरकर्ते दूर राहिले.

स्त्रोत: www.habr.com

बीपीएम शैली एकत्रीकरण

अस्वीकरण

BPM चा त्याच्याशी काय संबंध?

एकीकरण नमुना म्हणून सिंक्रोनस कॉलचे तोटे

व्यवहारांच्या समस्येवर उपाय म्हणून "सागा".

मायक्रोसर्व्हिसेसमध्ये व्यवसाय तर्कशास्त्र एन्कॅप्युलेशन

अॅप्लिकेशन डेव्हलपरच्या नजरेतून व्यवसाय प्रक्रियांचे एकत्रीकरण

सर्व संदेश एका रांगेत

एकत्रीकरण बसची विश्वासार्हता सुनिश्चित करणे

व्यवसाय तर्काच्या धाग्याची सुरक्षितता सुनिश्चित करणे

सतत स्थितीसह व्यवसाय प्रक्रिया समस्या

मला व्यवसाय प्रक्रियेसाठी आणखी एक फ्रेमवर्क आवश्यक आहे का?

मला व्यवसाय प्रक्रियेसाठी आणखी एक फ्रेमवर्क आवश्यक आहे का?

एक टिप्पणी जोडा Отменить ответ