BPM શૈલી એકીકરણ

હાય હેબ્ર!

અમારી કંપની ERP-ક્લાસ સોફ્ટવેર સોલ્યુશન્સના વિકાસમાં નિષ્ણાત છે, જેમાં મોટા પ્રમાણમાં બિઝનેસ લોજિક અને વર્કફ્લો એ la EDMS સાથે ટ્રાન્ઝેક્શનલ સિસ્ટમ્સનો સિંહફાળો છે. અમારા ઉત્પાદનોના આધુનિક સંસ્કરણો JavaEE તકનીકો પર આધારિત છે, પરંતુ અમે માઇક્રોસર્વિસિસ સાથે પણ સક્રિયપણે પ્રયોગ કરી રહ્યા છીએ. આવા ઉકેલોના સૌથી સમસ્યારૂપ ક્ષેત્રોમાંનું એક એ અડીને આવેલા ડોમેન્સથી સંબંધિત વિવિધ સબસિસ્ટમનું એકીકરણ છે. અમે જે પણ આર્કિટેક્ચરલ શૈલીઓ, ટેક્નોલોજી સ્ટેક્સ અને ફ્રેમવર્કનો ઉપયોગ કરીએ છીએ તેને ધ્યાનમાં લીધા વિના, એકીકરણ કાર્યોએ હંમેશા અમને ભારે માથાનો દુખાવો આપ્યો છે, પરંતુ તાજેતરમાં આવી સમસ્યાઓ હલ કરવામાં પ્રગતિ થઈ છે.

તમારા ધ્યાન પર લાવવામાં આવેલા લેખમાં, હું નિયુક્ત વિસ્તારમાં NPO ક્રિસ્ટાના અનુભવ અને સ્થાપત્ય સંશોધન વિશે વાત કરીશ. અમે એપ્લિકેશન ડેવલપરના દૃષ્ટિકોણથી એકીકરણ સમસ્યાના સરળ ઉકેલના ઉદાહરણ પર પણ વિચાર કરીશું અને આ સરળતા પાછળ શું છુપાયેલું છે તે શોધીશું.

અસ્વીકરણ

લેખમાં વર્ણવેલ આર્કિટેક્ચરલ અને તકનીકી ઉકેલો ચોક્કસ કાર્યોના સંદર્ભમાં વ્યક્તિગત અનુભવના આધારે મારા દ્વારા ઓફર કરવામાં આવે છે. આ ઉકેલો સાર્વત્રિક હોવાનો દાવો કરતા નથી અને ઉપયોગની અન્ય શરતો હેઠળ શ્રેષ્ઠ ન પણ હોઈ શકે.

BPM ને ​​તેની સાથે શું લેવાદેવા છે?

આ પ્રશ્નનો જવાબ આપવા માટે, અમારે અમારા ઉકેલોની લાગુ પડતી સમસ્યાઓની વિશિષ્ટતાઓમાં થોડો અભ્યાસ કરવાની જરૂર છે. અમારી લાક્ષણિક ટ્રાન્ઝેક્શનલ સિસ્ટમમાં બિઝનેસ લોજીકનો મુખ્ય ભાગ છે ડેટાબેઝમાં યુઝર ઇન્ટરફેસ દ્વારા ડેટા દાખલ કરવો, મેન્યુઅલી અને આપોઆપ આ ડેટાને તપાસવો, તેને કેટલાક વર્કફ્લોમાંથી પસાર કરવો, તેને અન્ય સિસ્ટમ / વિશ્લેષણાત્મક ડેટાબેઝ / આર્કાઇવમાં પ્રકાશિત કરવો, રિપોર્ટ્સ જનરેટ કરવું. આમ, ગ્રાહકો માટે સિસ્ટમનું મુખ્ય કાર્ય તેમની આંતરિક વ્યવસાય પ્રક્રિયાઓનું સ્વચાલિતકરણ છે.

સગવડતા માટે, અમે કોમ્યુનિકેશન કી દ્વારા સંયુક્ત ડેટા સેટના કેટલાક અમૂર્ત તરીકે સંચારમાં "દસ્તાવેજ" શબ્દનો ઉપયોગ કરીએ છીએ, જેની સાથે ચોક્કસ વર્કફ્લો "જોડાયેલ" હોઈ શકે છે.
પરંતુ એકીકરણ તર્ક વિશે શું? છેવટે, એકીકરણનું કાર્ય સિસ્ટમના આર્કિટેક્ચર દ્વારા બનાવવામાં આવે છે, જે ગ્રાહકની વિનંતી પર નહીં, પરંતુ સંપૂર્ણપણે જુદા જુદા પરિબળોના પ્રભાવ હેઠળ ભાગોમાં "જોવાયેલું" છે:

• કોનવેના કાયદાના પ્રભાવ હેઠળ;
• અન્ય ઉત્પાદનો માટે અગાઉ વિકસિત સબસિસ્ટમના પુનઃઉપયોગના પરિણામે;
• બિન-કાર્યકારી જરૂરિયાતોને આધારે આર્કિટેક્ટ દ્વારા નક્કી કર્યા મુજબ.

એકીકરણ તર્કને મુખ્ય વર્કફ્લોના બિઝનેસ લોજિકથી અલગ કરવાની એક મોટી લાલચ છે જેથી કરીને એકીકરણ આર્ટિફેક્ટ્સ સાથે બિઝનેસ લોજિકને દૂષિત ન કરી શકાય અને એપ્લિકેશન ડેવલપરને સિસ્ટમના આર્કિટેક્ચરલ લેન્ડસ્કેપની વિચિત્રતામાં ડૂબી જવાથી બચાવી શકાય. આ અભિગમના ઘણા ફાયદા છે, પરંતુ પ્રેક્ટિસ તેની બિનકાર્યક્ષમતા દર્શાવે છે:

• મુખ્ય વર્કફ્લોના અમલીકરણમાં મર્યાદિત વિસ્તરણ બિંદુઓને કારણે એકીકરણ સમસ્યાઓનું નિરાકરણ સામાન્ય રીતે સિંક્રનસ કૉલ્સના રૂપમાં સૌથી સરળ વિકલ્પો પર સ્લાઇડ કરે છે (નીચે સિંક્રનસ એકીકરણની ખામીઓ વિશે વધુ);
• જ્યારે અન્ય સબસિસ્ટમ તરફથી પ્રતિસાદની આવશ્યકતા હોય ત્યારે એકીકરણ આર્ટિફેક્ટ્સ મુખ્ય વ્યવસાયના તર્કમાં પ્રવેશ કરે છે;
• એપ્લિકેશન ડેવલપર એકીકરણને અવગણે છે અને વર્કફ્લો બદલીને તેને સરળતાથી તોડી શકે છે;
• વપરાશકર્તાના દૃષ્ટિકોણથી સિસ્ટમ એક સંપૂર્ણ બનવાનું બંધ કરે છે, સબસિસ્ટમ વચ્ચેની "સીમ્સ" ધ્યાનપાત્ર બને છે, અનાવશ્યક વપરાશકર્તા કામગીરીઓ દેખાય છે જે એક સબસિસ્ટમમાંથી બીજી સબસિસ્ટમમાં ડેટા ટ્રાન્સફર શરૂ કરે છે.

અન્ય અભિગમ એ છે કે કોર બિઝનેસ લોજિક અને વર્કફ્લોના અભિન્ન ભાગ તરીકે એકીકરણની ક્રિયાપ્રતિક્રિયાઓને ધ્યાનમાં લેવી. એપ્લીકેશન ડેવલપર્સની કૌશલ્યની આવશ્યકતાઓને આસમાને પહોંચતી અટકાવવા માટે, ઉકેલ પસંદ કરવા માટે ન્યૂનતમ વિકલ્પો સાથે, નવી એકીકરણ ક્રિયાપ્રતિક્રિયાઓ સરળતાથી અને કુદરતી રીતે કરવી જોઈએ. આ તે લાગે છે તેના કરતાં વધુ મુશ્કેલ છે: સાધન તેના ઉપયોગ માટે જરૂરી વિવિધ વિકલ્પો પ્રદાન કરવા માટે અને તે જ સમયે પોતાને પગમાં ગોળી મારવાની મંજૂરી આપતું નથી તેટલું શક્તિશાળી હોવું જોઈએ. એકીકરણ કાર્યોના સંદર્ભમાં એન્જિનિયરે જવાબ આપવો જોઈએ તેવા ઘણા પ્રશ્નો છે, પરંતુ એપ્લિકેશન ડેવલપરે તેમના રોજિંદા કાર્યમાં જેના વિશે વિચારવું જોઈએ નહીં: વ્યવહારની સીમાઓ, સુસંગતતા, પરમાણુતા, સુરક્ષા, સ્કેલિંગ, લોડ અને સંસાધન વિતરણ, રૂટીંગ, માર્શલિંગ, પ્રચાર અને સ્વિચિંગ સંદર્ભો, વગેરે. એપ્લિકેશન વિકાસકર્તાઓને એકદમ સરળ નિર્ણય નમૂનાઓ ઓફર કરવા જરૂરી છે, જેમાં આવા તમામ પ્રશ્નોના જવાબો પહેલેથી જ છુપાયેલા છે. આ પેટર્ન પૂરતી સુરક્ષિત હોવી જોઈએ: વ્યવસાયિક તર્ક ઘણી વાર બદલાય છે, જે ભૂલો રજૂ કરવાનું જોખમ વધારે છે, ભૂલોની કિંમત એકદમ નીચા સ્તરે રહેવી જોઈએ.

પરંતુ તેમ છતાં, BPM ને ​​તેની સાથે શું લેવાદેવા છે? વર્કફ્લોના અમલીકરણ માટે ઘણા વિકલ્પો છે ...
ખરેખર, અમારા ઉકેલોમાં વ્યાપાર પ્રક્રિયાઓનું બીજું અમલીકરણ ખૂબ જ લોકપ્રિય છે - રાજ્ય સંક્રમણ રેખાકૃતિની ઘોષણાત્મક સેટિંગ દ્વારા અને સંક્રમણો માટે વ્યવસાયિક તર્ક સાથે હેન્ડલર્સને કનેક્ટ કરીને. તે જ સમયે, રાજ્ય કે જે વ્યવસાય પ્રક્રિયામાં "દસ્તાવેજ" ની વર્તમાન સ્થિતિ નક્કી કરે છે તે "દસ્તાવેજ" નું જ લક્ષણ છે.

પ્રોજેક્ટની શરૂઆતમાં પ્રક્રિયા આ રીતે દેખાય છે

આવા અમલીકરણની લોકપ્રિયતા રેખીય વ્યવસાય પ્રક્રિયાઓ બનાવવાની સંબંધિત સરળતા અને ઝડપને કારણે છે. જો કે, જેમ જેમ સોફ્ટવેર સિસ્ટમ્સ વધુ જટિલ બનતી જાય છે તેમ તેમ બિઝનેસ પ્રક્રિયાનો સ્વચાલિત ભાગ વધે છે અને વધુ જટિલ બને છે. વિઘટન, પ્રક્રિયાઓના ભાગોના પુનઃઉપયોગ તેમજ ફોર્કિંગ પ્રક્રિયાઓની જરૂર છે જેથી દરેક શાખા સમાંતર રીતે ચલાવવામાં આવે. આવી પરિસ્થિતિઓમાં, સાધન અસુવિધાજનક બને છે, અને રાજ્ય સંક્રમણ રેખાકૃતિ તેની માહિતી સામગ્રી ગુમાવે છે (એકીકરણ ક્રિયાપ્રતિક્રિયાઓ આકૃતિમાં બિલકુલ પ્રતિબિંબિત થતી નથી).

આવશ્યકતાઓને સ્પષ્ટ કરવાના અનેક પુનરાવર્તનો પછી આ પ્રક્રિયા જેવો દેખાય છે

આ પરિસ્થિતિમાંથી બહાર નીકળવાનો માર્ગ એ એન્જિનનું એકીકરણ હતું jBPM સૌથી જટિલ વ્યવસાય પ્રક્રિયાઓ સાથેના કેટલાક ઉત્પાદનોમાં. ટૂંકા ગાળામાં, આ ઉકેલને થોડી સફળતા મળી: નોટેશનમાં એકદમ માહિતીપ્રદ અને અપ-ટૂ-ડેટ ડાયાગ્રામ જાળવી રાખીને જટિલ વ્યવસાયિક પ્રક્રિયાઓને અમલમાં મૂકવાનું શક્ય બન્યું. BPMN2.

જટિલ વ્યવસાય પ્રક્રિયાનો એક નાનો ભાગ

લાંબા ગાળામાં, સોલ્યુશન અપેક્ષાઓ મુજબ જીવી શક્યું ન હતું: વિઝ્યુઅલ ટૂલ્સ દ્વારા વ્યવસાયિક પ્રક્રિયાઓ બનાવવાની ઉચ્ચ શ્રમ તીવ્રતાએ સ્વીકાર્ય ઉત્પાદકતા સૂચકાંકો હાંસલ કરવાની મંજૂરી આપી ન હતી, અને સાધન પોતે વિકાસકર્તાઓમાં સૌથી વધુ નાપસંદ બન્યું હતું. એન્જિનની આંતરિક રચના વિશે પણ ફરિયાદો હતી, જેના કારણે ઘણા "પેચો" અને "ક્રચેસ" દેખાયા હતા.

jBPM નો ઉપયોગ કરવાનું મુખ્ય સકારાત્મક પાસું વ્યવસાય પ્રક્રિયાના દાખલા માટે તેની પોતાની સતત સ્થિતિ હોવાના ફાયદા અને નુકસાનની અનુભૂતિ હતી. અમે સિગ્નલો અને સંદેશાઓ દ્વારા અસુમેળ ક્રિયાપ્રતિક્રિયાઓનો ઉપયોગ કરીને વિવિધ એપ્લિકેશનો વચ્ચે જટિલ એકીકરણ પ્રોટોકોલને અમલમાં મૂકવા માટે પ્રક્રિયા અભિગમનો ઉપયોગ કરવાની શક્યતા પણ જોઈ. સતત રાજ્યની હાજરી આમાં નિર્ણાયક ભૂમિકા ભજવે છે.

ઉપરના આધારે, અમે નિષ્કર્ષ પર આવી શકીએ છીએ: BPM શૈલીમાં પ્રક્રિયાનો અભિગમ અમને વધુ જટિલ વ્યવસાયિક પ્રક્રિયાઓને સ્વચાલિત કરવા, આ પ્રક્રિયાઓમાં સુમેળભર્યા સંકલન પ્રવૃત્તિઓને સુમેળમાં ફિટ કરવા અને અમલી પ્રક્રિયાને યોગ્ય સંકેતમાં દૃષ્ટિની રીતે દર્શાવવાની ક્ષમતા જાળવી રાખવા માટે અમને વિશાળ શ્રેણીના કાર્યોને ઉકેલવા દે છે.

એકીકરણ પેટર્ન તરીકે સિંક્રનસ કૉલ્સના ગેરફાયદા

સિંક્રનસ એકીકરણ એ સૌથી સરળ અવરોધિત કૉલનો સંદર્ભ આપે છે. એક સબસિસ્ટમ સર્વર બાજુ તરીકે કાર્ય કરે છે અને ઇચ્છિત પદ્ધતિ સાથે API ને ખુલ્લું પાડે છે. અન્ય સબસિસ્ટમ ક્લાયન્ટ સાઈડ તરીકે કામ કરે છે અને યોગ્ય સમયે પરિણામની અપેક્ષા સાથે કોલ કરે છે. સિસ્ટમના આર્કિટેક્ચર પર આધાર રાખીને, ક્લાયંટ અને સર્વર બાજુઓ એક જ એપ્લિકેશન અને પ્રક્રિયામાં અથવા અલગ અલગમાં હોસ્ટ કરી શકાય છે. બીજા કિસ્સામાં, તમારે આરપીસીના કેટલાક અમલીકરણને લાગુ કરવાની જરૂર છે અને પરિમાણોનું માર્શલિંગ પ્રદાન કરવું અને કૉલના પરિણામની જરૂર છે.

આવા એકીકરણ પેટર્નમાં ખામીઓનો એકદમ મોટો સમૂહ છે, પરંતુ તેની સરળતાને કારણે વ્યવહારમાં તેનો ખૂબ વ્યાપક ઉપયોગ થાય છે. અમલીકરણની ગતિ મોહિત કરે છે અને તમને "બર્નિંગ" ડેડલાઇનની પરિસ્થિતિઓમાં તેને ફરીથી અને ફરીથી લાગુ કરવા માટે બનાવે છે, ઉકેલને તકનીકી ઋણમાં લખે છે. પરંતુ એવું પણ બને છે કે બિનઅનુભવી વિકાસકર્તાઓ તેનો ઉપયોગ બેભાનપણે કરે છે, ફક્ત નકારાત્મક પરિણામોની અનુભૂતિ કરતા નથી.

સબસિસ્ટમ્સની કનેક્ટિવિટીમાં સૌથી વધુ સ્પષ્ટ વધારો ઉપરાંત, "સ્પ્રેડિંગ" અને "સ્ટ્રેચિંગ" ટ્રાન્ઝેક્શનમાં ઓછી સ્પષ્ટ સમસ્યાઓ છે. ખરેખર, જો વ્યવસાયિક તર્ક કોઈ ફેરફાર કરે છે, તો વ્યવહારો અનિવાર્ય છે, અને વ્યવહારો, બદલામાં, આ ફેરફારોથી પ્રભાવિત અમુક એપ્લિકેશન સંસાધનોને લોક કરે છે. એટલે કે, જ્યાં સુધી એક સબસિસ્ટમ બીજા તરફથી પ્રતિસાદની રાહ ન જુએ ત્યાં સુધી તે વ્યવહાર પૂર્ણ કરી શકશે નહીં અને તાળાઓ રિલીઝ કરી શકશે નહીં. આ વિવિધ અસરોનું જોખમ નોંધપાત્ર રીતે વધારે છે:

• સિસ્ટમ પ્રતિભાવ ખોવાઈ જાય છે, વપરાશકર્તાઓ વિનંતીઓના જવાબો માટે લાંબો સમય રાહ જુએ છે;
• ઓવરફ્લો થ્રેડ પૂલને કારણે સર્વર સામાન્ય રીતે વપરાશકર્તાની વિનંતીઓનો પ્રતિસાદ આપવાનું બંધ કરે છે: મોટાભાગના થ્રેડો વ્યવહાર દ્વારા કબજે કરેલા સંસાધનના લોક પર "સ્ટેન્ડ" હોય છે;
• ડેડલૉક્સ દેખાવાનું શરૂ થાય છે: તેમની ઘટનાની સંભાવના વ્યવહારોની અવધિ, વ્યવસાયના તર્કની માત્રા અને વ્યવહારમાં સામેલ તાળાઓ પર ભારપૂર્વક આધાર રાખે છે;
• વ્યવહાર સમયસમાપ્તિ સમાપ્તિ ભૂલો દેખાય છે;
• જો કાર્યને મોટી માત્રામાં ડેટાની પ્રક્રિયા કરવાની અને બદલવાની જરૂર હોય તો સર્વર OutOfMemory પર "પડે" અને સિંક્રનસ એકીકરણની હાજરી પ્રક્રિયાને "હળવા" વ્યવહારોમાં વિભાજિત કરવાનું ખૂબ મુશ્કેલ બનાવે છે.

આર્કિટેક્ચરલ દૃષ્ટિકોણથી, એકીકરણ દરમિયાન બ્લોકિંગ કૉલ્સનો ઉપયોગ વ્યક્તિગત સબસિસ્ટમના ગુણવત્તા નિયંત્રણમાં ઘટાડો તરફ દોરી જાય છે: એક સબસિસ્ટમના ગુણવત્તા લક્ષ્યોને અન્ય સબસિસ્ટમના ગુણવત્તા લક્ષ્યોથી અલગ કરીને તેની ખાતરી કરવી અશક્ય છે. જો વિવિધ ટીમો દ્વારા સબસિસ્ટમ વિકસાવવામાં આવી હોય, તો આ એક મોટી સમસ્યા છે.

જો એકીકૃત કરવામાં આવી રહેલી સબસિસ્ટમ અલગ-અલગ એપ્લિકેશનમાં હોય અને બંને બાજુ સિંક્રનસ ફેરફારો કરવાની જરૂર હોય તો વસ્તુઓ વધુ રસપ્રદ બને છે. આ ફેરફારોને વ્યવહારિક કેવી રીતે બનાવવું?

જો અલગ-અલગ વ્યવહારોમાં ફેરફારો કરવામાં આવે છે, તો મજબૂત અપવાદ હેન્ડલિંગ અને વળતર પ્રદાન કરવાની જરૂર પડશે, અને આ સિંક્રનસ એકીકરણનો મુખ્ય ફાયદો - સરળતાને સંપૂર્ણપણે દૂર કરે છે.

વિતરિત વ્યવહારો પણ ધ્યાનમાં આવે છે, પરંતુ અમે તેનો ઉપયોગ અમારા ઉકેલોમાં કરતા નથી: વિશ્વસનીયતાની ખાતરી કરવી મુશ્કેલ છે.

વ્યવહારોની સમસ્યાના ઉકેલ તરીકે "સાગા".

માઇક્રોસર્વિસિસની વધતી જતી લોકપ્રિયતા સાથે, તેની માંગ વધી રહી છે સાગા પેટર્ન.

આ પેટર્ન લાંબા વ્યવહારોની ઉપરોક્ત સમસ્યાઓને સંપૂર્ણ રીતે હલ કરે છે, અને વ્યવસાયિક તર્કની બાજુથી સિસ્ટમની સ્થિતિનું સંચાલન કરવાની શક્યતાઓને પણ વિસ્તૃત કરે છે: અસફળ વ્યવહાર પછી વળતર સિસ્ટમને તેની મૂળ સ્થિતિમાં પાછું ફેરવી શકતું નથી, પરંતુ વૈકલ્પિક પ્રદાન કરે છે. ડેટા પ્રોસેસિંગ રૂટ. જ્યારે તમે પ્રક્રિયાને "સારા" અંત સુધી લાવવાનો પ્રયાસ કરો છો ત્યારે તે તમને સફળતાપૂર્વક પૂર્ણ થયેલા ડેટા પ્રોસેસિંગ પગલાંને પુનરાવર્તિત ન કરવાની મંજૂરી આપે છે.

રસપ્રદ વાત એ છે કે, મોનોલિથિક સિસ્ટમ્સમાં, આ પેટર્ન પણ સુસંગત છે જ્યારે તે ઢીલી રીતે જોડાયેલા સબસિસ્ટમના એકીકરણની વાત આવે છે અને લાંબા વ્યવહારો અને અનુરૂપ સંસાધન તાળાઓને કારણે નકારાત્મક અસરો હોય છે.

BPM શૈલીમાં અમારી વ્યાપારી પ્રક્રિયાઓના સંદર્ભમાં, તે સાગાસને અમલમાં મૂકવું ખૂબ જ સરળ હોવાનું બહાર આવ્યું છે: સાગાસના વ્યક્તિગત પગલાંને વ્યવસાય પ્રક્રિયામાં પ્રવૃત્તિઓ તરીકે સેટ કરી શકાય છે, અને વ્યવસાય પ્રક્રિયાની સતત સ્થિતિ નક્કી કરે છે, વચ્ચે અન્ય વસ્તુઓ, સાગાસની આંતરિક સ્થિતિ. એટલે કે, અમને કોઈ વધારાની સંકલન પદ્ધતિની જરૂર નથી. તમારે ફક્ત એક ટ્રાન્સપોર્ટ તરીકે "ઓછામાં ઓછી એક વાર" ગેરંટી માટે સમર્થન સાથે સંદેશ બ્રોકરની જરૂર છે.

પરંતુ આવા સોલ્યુશનની પોતાની "કિંમત" પણ છે:

• વ્યવસાયિક તર્ક વધુ જટિલ બને છે: તમારે વળતર મેળવવાની જરૂર છે;
• સંપૂર્ણ સુસંગતતા છોડી દેવાની જરૂર પડશે, જે મોનોલિથિક સિસ્ટમ્સ માટે ખાસ કરીને સંવેદનશીલ હોઈ શકે છે;
• આર્કિટેક્ચર થોડું વધુ જટિલ બની જાય છે, સંદેશ બ્રોકરની વધારાની જરૂર છે;
• વધારાના મોનિટરિંગ અને એડમિનિસ્ટ્રેશન ટૂલ્સની જરૂર પડશે (જોકે સામાન્ય રીતે આ પણ સારું છે: સિસ્ટમ સેવાની ગુણવત્તામાં વધારો થશે).

મોનોલિથિક સિસ્ટમ્સ માટે, "સેગ્સ" નો ઉપયોગ કરવા માટેનું સમર્થન એટલું સ્પષ્ટ નથી. માઇક્રોસર્વિસિસ અને અન્ય SOA માટે, જ્યાં સંભવતઃ, પહેલેથી જ બ્રોકર છે, અને પ્રોજેક્ટની શરૂઆતમાં સંપૂર્ણ સુસંગતતા બલિદાન આપવામાં આવ્યું હતું, આ પેટર્નનો ઉપયોગ કરવાના ફાયદા નોંધપાત્ર રીતે ગેરફાયદા કરતાં વધી શકે છે, ખાસ કરીને જો ત્યાં અનુકૂળ API હોય. વ્યવસાય તર્ક સ્તર.

માઇક્રોસર્વિસિસમાં બિઝનેસ લોજીકનું એન્કેપ્સ્યુલેશન

જ્યારે અમે માઇક્રોસર્વિસિસ સાથે પ્રયોગ કરવાનું શરૂ કર્યું, ત્યારે એક વાજબી પ્રશ્ન ઊભો થયો: ડોમેન ડેટા પર્સિસ્ટન્સ પ્રદાન કરતી સેવાના સંબંધમાં ડોમેન બિઝનેસ લોજિક ક્યાં મૂકવું?

જ્યારે વિવિધ BPMS ના આર્કિટેક્ચરને જોઈએ ત્યારે, વ્યવસાયના તર્કને દ્રઢતાથી અલગ કરવાનું વાજબી લાગે છે: પ્લેટફોર્મ અને ડોમેન-સ્વતંત્ર માઇક્રોસર્વિસિસનું એક સ્તર બનાવો જે ડોમેન બિઝનેસ લોજિકને એક્ઝિક્યુટ કરવા માટે પર્યાવરણ અને કન્ટેનર બનાવે છે, અને ડોમેન ડેટા પર્સિસ્ટન્સને અલગ તરીકે ગોઠવે છે. ખૂબ જ સરળ અને હળવા વજનની માઇક્રોસેવાઓનું સ્તર. આ કિસ્સામાં વ્યવસાયિક પ્રક્રિયાઓ સતત સ્તરની સેવાઓનું આયોજન કરે છે.

આ અભિગમમાં ખૂબ જ મોટો વત્તા છે: તમે પ્લેટફોર્મની કાર્યક્ષમતા તમને ગમે તેટલું વધારી શકો છો, અને પ્લેટફોર્મ માઇક્રોસર્વિસિસનું માત્ર અનુરૂપ સ્તર આમાંથી "ચરબી મેળવશે". કોઈપણ ડોમેનની વ્યાપાર પ્રક્રિયાઓને તરત જ પ્લેટફોર્મની નવી કાર્યક્ષમતા અપડેટ થતાં જ તેનો ઉપયોગ કરવાની તક મળે છે.

વધુ વિગતવાર અભ્યાસે આ અભિગમની નોંધપાત્ર ખામીઓ જાહેર કરી:

• એક પ્લેટફોર્મ સેવા કે જે એકસાથે ઘણા ડોમેન્સના વ્યવસાયિક તર્કને અમલમાં મૂકે છે તે નિષ્ફળતાના એક બિંદુ તરીકે મોટા જોખમો ધરાવે છે. વ્યાપાર તર્કમાં વારંવારના ફેરફારો સિસ્ટમ-વ્યાપી નિષ્ફળતા તરફ દોરી જતા ભૂલોનું જોખમ વધારે છે;
• પ્રદર્શન મુદ્દાઓ: વ્યવસાય તર્ક તેના ડેટા સાથે સાંકડા અને ધીમા ઇન્ટરફેસ દ્વારા કાર્ય કરે છે:
  • ડેટા ફરી એકવાર માર્શલ કરવામાં આવશે અને નેટવર્ક સ્ટેક દ્વારા પમ્પ કરવામાં આવશે;
  • સેવાના બાહ્ય API ના સ્તરે અપૂરતી ક્વેરી પેરામીટરાઇઝેશન ક્ષમતાઓને કારણે ડોમેન સેવા ઘણીવાર વ્યવસાયના તર્કની પ્રક્રિયા માટે જરૂરી કરતાં વધુ ડેટા પરત કરશે;
  • વ્યવસાયિક તર્કના કેટલાક સ્વતંત્ર ટુકડાઓ પ્રક્રિયા કરવા માટે સમાન ડેટાની વારંવાર વિનંતી કરી શકે છે (તમે ડેટાને કેશ કરતા સેશન બીન્સ ઉમેરીને આ સમસ્યાને ઘટાડી શકો છો, પરંતુ આ આર્કિટેક્ચરને વધુ જટિલ બનાવે છે અને ડેટાની તાજગી અને કેશ અમાન્યતાની સમસ્યાઓ ઊભી કરે છે);
• વ્યવહાર સમસ્યાઓ:
  • પ્લેટફોર્મ સેવા દ્વારા સંગ્રહિત સતત સ્થિતિ સાથેની વ્યવસાય પ્રક્રિયાઓ ડોમેન ડેટા સાથે અસંગત છે, અને આ સમસ્યાને ઉકેલવા માટે કોઈ સરળ રીતો નથી;
  • ડોમેન ડેટાના લોકને વ્યવહારમાંથી બહાર ખસેડવું: જો ડોમેન વ્યવસાયના તર્કમાં ફેરફાર કરવાની જરૂર હોય, તો પ્રથમ વાસ્તવિક ડેટાની શુદ્ધતા તપાસ્યા પછી, પ્રક્રિયા કરેલ ડેટામાં સ્પર્ધાત્મક ફેરફારની શક્યતાને બાકાત રાખવી જરૂરી છે. ડેટાનું બાહ્ય અવરોધ સમસ્યાને ઉકેલવામાં મદદ કરી શકે છે, પરંતુ આવા ઉકેલ વધારાના જોખમો વહન કરે છે અને સિસ્ટમની એકંદર વિશ્વસનીયતા ઘટાડે છે;
• અપડેટ કરતી વખતે વધારાની ગૂંચવણો: કેટલાક કિસ્સાઓમાં, તમારે પર્સિસ્ટન્સ સર્વિસ અને બિઝનેસ લોજિકને સિંક્રનસ અથવા કડક ક્રમમાં અપડેટ કરવાની જરૂર છે.

અંતે, મારે બેઝિક્સ પર પાછા જવું પડ્યું: ડોમેન ડેટા અને ડોમેન બિઝનેસ લોજિકને એક માઇક્રોસર્વિસમાં સમાવિષ્ટ કરો. આ અભિગમ સિસ્ટમમાં એક અભિન્ન ઘટક તરીકે માઇક્રોસર્વિસની ધારણાને સરળ બનાવે છે અને ઉપરોક્ત સમસ્યાઓને જન્મ આપતું નથી. આ પણ મફત નથી:

• વ્યાપાર તર્ક સાથે ક્રિયાપ્રતિક્રિયા માટે API માનકીકરણ જરૂરી છે (ખાસ કરીને, વ્યવસાય પ્રક્રિયાઓના ભાગ રૂપે વપરાશકર્તા પ્રવૃત્તિઓ પ્રદાન કરવા માટે) અને API પ્લેટફોર્મ સેવાઓ; API ફેરફારો પર વધુ ધ્યાન આપવું, આગળ અને પાછળની સુસંગતતા જરૂરી છે;
• આવી દરેક માઇક્રોસર્વિસના ભાગ રૂપે બિઝનેસ લોજિકની કામગીરીની ખાતરી કરવા માટે વધારાની રનટાઇમ લાઇબ્રેરીઓ ઉમેરવાની જરૂર છે, અને આ આવી લાઇબ્રેરીઓ માટે નવી આવશ્યકતાઓને જન્મ આપે છે: હળવાશ અને લઘુત્તમ સંક્રમિત અવલંબન;
• બિઝનેસ લોજિક ડેવલપર્સે લાઇબ્રેરી વર્ઝનનો ટ્રૅક રાખવાની જરૂર છે: જો માઇક્રોસર્વિસને લાંબા સમયથી ફાઇનલ કરવામાં ન આવ્યું હોય, તો મોટા ભાગે તેમાં લાઇબ્રેરીઓનું જૂનું વર્ઝન હશે. નવી સુવિધા ઉમેરવા માટે આ એક અણધારી અવરોધ બની શકે છે અને જો આવૃત્તિઓ વચ્ચે અસંગત ફેરફારો હોય તો આવી સેવાના જૂના વ્યવસાય તર્કને પુસ્તકાલયોના નવા સંસ્કરણોમાં સ્થાનાંતરિત કરવાની જરૂર પડી શકે છે.

આવા આર્કિટેક્ચરમાં પ્લેટફોર્મ સેવાઓનો એક સ્તર પણ હાજર હોય છે, પરંતુ આ સ્તર હવે ડોમેન બિઝનેસ લોજિકને એક્ઝિક્યુટ કરવા માટે કન્ટેનર બનાવે છે નહીં, પરંતુ માત્ર તેનું પર્યાવરણ, સહાયક "પ્લેટફોર્મ" કાર્યો પ્રદાન કરે છે. આવા સ્તરની જરૂર માત્ર ડોમેન માઇક્રોસર્વિસિસની હળવાશ જાળવવા માટે જ નહીં, પરંતુ મેનેજમેન્ટને કેન્દ્રિય બનાવવા માટે પણ છે.

ઉદાહરણ તરીકે, વ્યવસાયિક પ્રક્રિયાઓમાં વપરાશકર્તા પ્રવૃત્તિઓ કાર્યો પેદા કરે છે. જો કે, કાર્યો સાથે કામ કરતી વખતે, વપરાશકર્તાએ સામાન્ય સૂચિમાંના તમામ ડોમેન્સમાંથી કાર્યો જોવું આવશ્યક છે, જેનો અર્થ છે કે ત્યાં યોગ્ય કાર્ય નોંધણી પ્લેટફોર્મ સેવા હોવી જોઈએ, જે ડોમેન વ્યવસાયના તર્કથી મુક્ત છે. આ સંદર્ભમાં વ્યાપાર તર્કશાસ્ત્રના એન્કેપ્સ્યુલેશનને રાખવું એ ખૂબ જ સમસ્યારૂપ છે, અને આ આ આર્કિટેક્ચરનું બીજું સમાધાન છે.

એપ્લિકેશન ડેવલપરની નજર દ્વારા વ્યવસાય પ્રક્રિયાઓનું એકીકરણ

પહેલેથી જ ઉપર સૂચવ્યા મુજબ, એપ્લિકેશન ડેવલપર સારી વિકાસ ઉત્પાદકતા પર વિશ્વાસ કરવા માટે સક્ષમ થવા માટે ઘણી એપ્લિકેશનોની ક્રિયાપ્રતિક્રિયાના અમલીકરણની તકનીકી અને એન્જિનિયરિંગ સુવિધાઓથી અમૂર્ત હોવું આવશ્યક છે.

ચાલો એક જગ્યાએ મુશ્કેલ સંકલન સમસ્યાને હલ કરવાનો પ્રયાસ કરીએ, ખાસ કરીને લેખ માટે શોધાયેલ. આ એક "ગેમ" કાર્ય હશે જેમાં ત્રણ એપ્લિકેશનનો સમાવેશ થાય છે, જ્યાં તેમાંથી દરેક અમુક ડોમેન નામ વ્યાખ્યાયિત કરે છે: "app1", "app2", "app3".

દરેક એપ્લિકેશનની અંદર, વ્યવસાય પ્રક્રિયાઓ શરૂ કરવામાં આવે છે જે એકીકરણ બસ દ્વારા "બોલ રમવા" શરૂ કરે છે. "બોલ" નામના સંદેશાઓ બોલ તરીકે કામ કરશે.

રમતના નિયમો:

• પ્રથમ ખેલાડી પહેલ કરનાર છે. તે અન્ય ખેલાડીઓને રમત માટે આમંત્રિત કરે છે, રમત શરૂ કરે છે અને તેને કોઈપણ સમયે સમાપ્ત કરી શકે છે;
• અન્ય ખેલાડીઓ રમતમાં તેમની સહભાગિતા જાહેર કરે છે, એકબીજા અને પ્રથમ ખેલાડી સાથે "પરિચિત થાઓ";
• બોલ પ્રાપ્ત કર્યા પછી, ખેલાડી અન્ય ભાગ લેનાર ખેલાડીને પસંદ કરે છે અને તેને બોલ પસાર કરે છે. પાસની કુલ સંખ્યા ગણાય છે;
• દરેક ખેલાડીમાં "ઊર્જા" હોય છે, જે તે ખેલાડી દ્વારા બોલના દરેક પાસ સાથે ઘટે છે. જ્યારે ઊર્જા સમાપ્ત થાય છે, ત્યારે ખેલાડીને રમતમાંથી દૂર કરવામાં આવે છે, તેમની નિવૃત્તિની જાહેરાત કરે છે;
• જો ખેલાડી એકલો રહે છે, તો તે તરત જ તેના પ્રસ્થાનની ઘોષણા કરે છે;
• જ્યારે બધા ખેલાડીઓ નાબૂદ થાય છે, ત્યારે પ્રથમ ખેલાડી રમતનો અંત જાહેર કરે છે. જો તેણે અગાઉ રમત છોડી દીધી હોય, તો તે રમતને પૂર્ણ કરવા માટે તેને અનુસરવાનું રહે છે.

આ સમસ્યાને ઉકેલવા માટે, હું વ્યવસાયિક પ્રક્રિયાઓ માટે અમારા DSL નો ઉપયોગ કરીશ, જે તમને ઓછામાં ઓછા બોઈલરપ્લેટ સાથે કોટલિનમાં તર્કનું સઘન વર્ણન કરવાની મંજૂરી આપે છે.

એપ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 માં અન્ય ખેલાડીની વ્યવસાય પ્રક્રિયા શામેલ હશે:

વર્ગ રેન્ડમ પ્લેયર

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 એપ્લિકેશનમાં, અમે ખેલાડીને થોડી અલગ વર્તણૂક સાથે બનાવીશું: આગલા ખેલાડીને રેન્ડમલી પસંદ કરવાને બદલે, તે રાઉન્ડ-રોબિન અલ્ગોરિધમ અનુસાર કાર્ય કરશે:

વર્ગ રાઉન્ડરોબિન પ્લેયર

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 બાજુ પર નિરાશાવાદી તાળાઓનો ઉપયોગ કરીને, અમે તમામ જરૂરી જરૂરિયાતોને પૂર્ણ કરીએ છીએ ACID, અને ચાલી રહેલ દાખલાઓની સંખ્યામાં વધારો કરીને વ્યવસાયના તર્ક સાથે એપ્લિકેશનને સ્કેલ કરવાની ક્ષમતા પણ જાળવી રાખે છે.

જો કે, નિરાશાવાદી તાળાઓ અમને ડેડલૉક્સની ધમકી આપે છે, જેનો અર્થ છે કે સિલેક્ટ ફોર અપડેટ હજુ પણ વ્યવસાયના તર્કશાસ્ત્રમાં કેટલાક ગંભીર કેસોમાં મડાગાંઠના કિસ્સામાં કેટલાક વાજબી સમયસમાપ્તિ સુધી મર્યાદિત હોવું જોઈએ.

બીજી સમસ્યા એ વ્યવસાય પ્રક્રિયાની શરૂઆતનું સુમેળ છે. જ્યારે ત્યાં કોઈ વ્યવસાય પ્રક્રિયા દાખલો નથી, ત્યારે ડેટાબેઝમાં કોઈ સ્થિતિ નથી, તેથી વર્ણવેલ પદ્ધતિ કામ કરશે નહીં. જો તમે ચોક્કસ અવકાશમાં વ્યવસાય પ્રક્રિયાના દાખલાની વિશિષ્ટતાને સુનિશ્ચિત કરવા માંગતા હો, તો તમારે પ્રક્રિયા વર્ગ અને અનુરૂપ અવકાશ સાથે સંકળાયેલ અમુક પ્રકારના સિંક્રનાઇઝેશન ઑબ્જેક્ટની જરૂર છે. આ સમસ્યાને ઉકેલવા માટે, અમે એક અલગ લોકીંગ મિકેનિઝમનો ઉપયોગ કરીએ છીએ જે અમને બાહ્ય સેવા દ્વારા URI ફોર્મેટમાં કી દ્વારા ઉલ્લેખિત મનસ્વી સંસાધન પર લૉક લેવાની મંજૂરી આપે છે.

અમારા ઉદાહરણોમાં, InitialPlayer વ્યવસાય પ્રક્રિયામાં ઘોષણા શામેલ છે

uniqueConstraint = UniqueConstraints.singleton

તેથી, લોગમાં સંબંધિત કીના લૉકને લેવા અને છોડવા વિશેના સંદેશા છે. અન્ય વ્યવસાયિક પ્રક્રિયાઓ માટે આવા કોઈ સંદેશા નથી: અનન્ય નિયંત્રણ સેટ નથી.

સતત સ્થિતિ સાથે વ્યવસાય પ્રક્રિયા સમસ્યાઓ

કેટલીકવાર સતત સ્થિતિ રાખવાથી માત્ર મદદ જ નથી થતી, પણ ખરેખર વિકાસને અવરોધે છે.
જ્યારે તમારે બિઝનેસ લોજિક અને/અથવા બિઝનેસ પ્રોસેસ મોડલમાં ફેરફાર કરવાની જરૂર હોય ત્યારે સમસ્યાઓ શરૂ થાય છે. આવો કોઈ ફેરફાર વ્યાપારી પ્રક્રિયાઓની જૂની સ્થિતિ સાથે સુસંગત હોવાનું જણાયું નથી. જો ડેટાબેઝમાં ઘણા "જીવંત" દાખલાઓ છે, તો અસંગત ફેરફારો કરવાથી ઘણી મુશ્કેલી થઈ શકે છે, જે અમે વારંવાર jBPM નો ઉપયોગ કરતી વખતે અનુભવીએ છીએ.

પરિવર્તનની ઊંડાઈના આધારે, તમે બે રીતે કાર્ય કરી શકો છો:

1. એક નવો વ્યવસાય પ્રક્રિયા પ્રકાર બનાવો જેથી જૂનામાં અસંગત ફેરફારો ન થાય અને નવા દાખલાઓ શરૂ કરતી વખતે જૂનાને બદલે તેનો ઉપયોગ કરો. જૂના દાખલાઓ "જૂની રીતે" કામ કરવાનું ચાલુ રાખશે;
2. વ્યવસાય તર્કને અપડેટ કરતી વખતે વ્યવસાય પ્રક્રિયાઓની સતત સ્થિતિને સ્થાનાંતરિત કરો.

પ્રથમ રસ્તો સરળ છે, પરંતુ તેની મર્યાદાઓ અને ગેરફાયદા છે, ઉદાહરણ તરીકે:

• ઘણા બિઝનેસ પ્રોસેસ મોડલ્સમાં બિઝનેસ લોજિકનું ડુપ્લિકેશન, બિઝનેસ લોજિકના વોલ્યુમમાં વધારો;
• ઘણીવાર નવા વ્યવસાયના તર્ક માટે ત્વરિત સંક્રમણ જરૂરી છે (લગભગ હંમેશા એકીકરણ કાર્યોની દ્રષ્ટિએ);
• વિકાસકર્તા જાણતા નથી કે કયા તબક્કે અપ્રચલિત મોડેલોને કાઢી નાખવાનું શક્ય છે.

વ્યવહારમાં, અમે બંને અભિગમોનો ઉપયોગ કરીએ છીએ, પરંતુ અમારા જીવનને સરળ બનાવવા માટે ઘણા નિર્ણયો લીધા છે:

• ડેટાબેઝમાં, વ્યવસાય પ્રક્રિયાની સતત સ્થિતિ સરળતાથી વાંચી શકાય તેવા અને સરળતાથી પ્રક્રિયા કરી શકાય તેવા સ્વરૂપમાં સંગ્રહિત થાય છે: JSON ફોર્મેટ સ્ટ્રિંગમાં. આ તમને એપ્લિકેશનની અંદર અને બહાર બંને સ્થાનાંતરણ કરવા દે છે. આત્યંતિક કેસોમાં, તમે તેને હેન્ડલ્સ (ખાસ કરીને ડીબગીંગ દરમિયાન વિકાસમાં ઉપયોગી) સાથે પણ ટ્વીક કરી શકો છો;
• સંકલન વ્યવસાય તર્ક વ્યવસાય પ્રક્રિયાઓના નામોનો ઉપયોગ કરતું નથી, જેથી કોઈપણ સમયે સહભાગી પ્રક્રિયાઓમાંથી એકના અમલીકરણને નવા નામ સાથે બદલી શકાય છે (ઉદાહરણ તરીકે, "InitialPlayerV2"). બંધનકર્તા સંદેશાઓ અને સંકેતોના નામ દ્વારા થાય છે;
• પ્રક્રિયા મોડેલમાં સંસ્કરણ નંબર હોય છે, જો આપણે આ મોડેલમાં અસંગત ફેરફારો કરીએ તો અમે તેને વધારીએ છીએ, અને આ નંબર પ્રક્રિયાના દાખલાની સ્થિતિ સાથે સંગ્રહિત થાય છે;
• પ્રક્રિયાની નિરંતર સ્થિતિને પહેલા બેઝમાંથી અનુકૂળ ઑબ્જેક્ટ મોડેલમાં વાંચવામાં આવે છે કે જો મૉડલનો સંસ્કરણ નંબર બદલાયો હોય તો સ્થળાંતર પ્રક્રિયા કામ કરી શકે છે;
• સ્થળાંતર પ્રક્રિયાને વ્યવસાયના તર્કની બાજુમાં મૂકવામાં આવે છે અને ડેટાબેઝમાંથી પુનઃસ્થાપના સમયે વ્યવસાય પ્રક્રિયાના દરેક ઉદાહરણ માટે તેને "આળસુ" કહેવામાં આવે છે;
• જો તમારે તમામ પ્રક્રિયાના દાખલાઓની સ્થિતિને ઝડપથી અને સિંક્રનસ રીતે સ્થાનાંતરિત કરવાની જરૂર હોય, તો વધુ ક્લાસિક ડેટાબેઝ સ્થળાંતર ઉકેલોનો ઉપયોગ કરવામાં આવે છે, પરંતુ તમારે ત્યાં JSON સાથે કામ કરવું પડશે.

શું મારે વ્યવસાય પ્રક્રિયાઓ માટે બીજા માળખાની જરૂર છે?

લેખમાં વર્ણવેલ ઉકેલો અમને અમારા જીવનને નોંધપાત્ર રીતે સરળ બનાવવા, એપ્લિકેશન ડેવલપમેન્ટ સ્તરે ઉકેલવામાં આવતા મુદ્દાઓની શ્રેણીને વિસ્તૃત કરવા અને વ્યવસાયિક તર્કને માઇક્રોસર્વિસિસમાં અલગ કરવાના વિચારને વધુ આકર્ષક બનાવવાની મંજૂરી આપે છે. આ માટે, ઘણું કામ કરવામાં આવ્યું છે, વ્યવસાય પ્રક્રિયાઓ માટે ખૂબ જ "હળવા" માળખું બનાવવામાં આવ્યું છે, તેમજ લાગુ કાર્યોની વિશાળ શ્રેણીના સંદર્ભમાં ઓળખાયેલી સમસ્યાઓના નિરાકરણ માટે સેવા ઘટકો. અમે આ પરિણામોને શેર કરવાની ઈચ્છા ધરાવીએ છીએ, સામાન્ય ઘટકોના વિકાસને મફત લાયસન્સ હેઠળ ઓપન એક્સેસમાં લાવવાની. આને થોડો પ્રયત્ન અને સમયની જરૂર પડશે. આવા ઉકેલોની માંગને સમજવી એ અમારા માટે વધારાનું પ્રોત્સાહન હોઈ શકે છે. સૂચિત લેખમાં, ફ્રેમવર્કની જ ક્ષમતાઓ પર ખૂબ ઓછું ધ્યાન આપવામાં આવ્યું છે, પરંતુ તેમાંના કેટલાક પ્રસ્તુત ઉદાહરણોમાંથી દૃશ્યમાન છે. જો આપણે તેમ છતાં અમારું માળખું પ્રકાશિત કરીએ, તો એક અલગ લેખ તેને સમર્પિત કરવામાં આવશે. આ દરમિયાન, જો તમે પ્રશ્નનો જવાબ આપીને થોડો પ્રતિસાદ આપો તો અમે આભારી રહીશું:

ફક્ત નોંધાયેલા વપરાશકર્તાઓ જ સર્વેમાં ભાગ લઈ શકે છે. સાઇન ઇન કરો, મહેરબાની કરીને.

શું મારે વ્યવસાય પ્રક્રિયાઓ માટે બીજા માળખાની જરૂર છે?

• 18,8%હા, હું ઘણા સમયથી આવું કંઈક શોધી રહ્યો છું.

• 12,5%તમારા અમલીકરણ વિશે વધુ જાણવા માટે તે રસપ્રદ છે, તે ઉપયોગી હોઈ શકે છે2

• 6,2%અમે હાલના ફ્રેમવર્કમાંથી એકનો ઉપયોગ કરીએ છીએ, પરંતુ અમે તેને બદલવા વિશે વિચારી રહ્યા છીએ

• 18,8%અમે હાલના ફ્રેમવર્કમાંથી એકનો ઉપયોગ કરીએ છીએ, બધું અનુકૂળ છે3

• 18,8%ફ્રેમવર્ક વિના સામનો 3

• 25,0%તમારું પોતાનું લખો

16 વપરાશકર્તાઓએ મતદાન કર્યું. 7 વપરાશકર્તાઓ દૂર રહ્યા.

સોર્સ: www.habr.com