ការរួមបញ្ចូលរចនាប័ទ្ម BPM

សួស្តី ហាប!

ក្រុមហ៊ុនរបស់យើងមានឯកទេសក្នុងការអភិវឌ្ឍដំណោះស្រាយកម្មវិធី ERP-class ដែលជាចំណែករបស់សត្វតោដែលត្រូវបានកាន់កាប់ដោយប្រព័ន្ធប្រតិបត្តិការជាមួយនឹងចំនួនដ៏ច្រើននៃតក្កវិជ្ជាអាជីវកម្មនិងលំហូរឯកសារ a la EDMS ។ កំណែបច្ចុប្បន្ននៃផលិតផលរបស់យើងគឺផ្អែកលើបច្ចេកវិទ្យា JavaEE ប៉ុន្តែយើងក៏កំពុងធ្វើការពិសោធន៍យ៉ាងសកម្មជាមួយសេវាកម្មមីក្រូផងដែរ។ ផ្នែកមួយក្នុងចំណោមបញ្ហាបំផុតនៃដំណោះស្រាយបែបនេះគឺការរួមបញ្ចូលនៃប្រព័ន្ធរងផ្សេងៗដែលជាកម្មសិទ្ធិរបស់ដែនដែលនៅជាប់គ្នា។ បញ្ហានៃការរួមបញ្ចូលតែងតែធ្វើឱ្យយើងឈឺក្បាលយ៉ាងខ្លាំង ដោយមិនគិតពីរចនាប័ទ្មស្ថាបត្យកម្ម ជង់បច្ចេកវិទ្យា និងក្របខ័ណ្ឌដែលយើងប្រើ ប៉ុន្តែថ្មីៗនេះមានការវិវឌ្ឍន៍ក្នុងការដោះស្រាយបញ្ហាបែបនេះ។

នៅក្នុងអត្ថបទដែលខ្ញុំនាំយកមកជូនអ្នក ខ្ញុំនឹងនិយាយអំពីបទពិសោធន៍ និងការស្រាវជ្រាវស្ថាបត្យកម្មដែល NPO Krista មាននៅក្នុងតំបន់ដែលបានកំណត់។ យើងក៏នឹងក្រឡេកមើលឧទាហរណ៍នៃដំណោះស្រាយសាមញ្ញមួយចំពោះបញ្ហាសមាហរណកម្មពីទស្សនៈរបស់អ្នកអភិវឌ្ឍន៍កម្មវិធី និងស្វែងរកអ្វីដែលលាក់នៅពីក្រោយភាពសាមញ្ញនេះ។

អេស

ដំណោះស្រាយស្ថាបត្យកម្ម និងបច្ចេកទេសដែលបានពិពណ៌នានៅក្នុងអត្ថបទត្រូវបានស្នើឡើងដោយខ្ញុំដោយផ្អែកលើបទពិសោធន៍ផ្ទាល់ខ្លួននៅក្នុងបរិបទនៃកិច្ចការជាក់លាក់។ ដំណោះស្រាយទាំងនេះមិនអះអាងថាជាសកលទេ ហើយប្រហែលជាមិនល្អបំផុតក្រោមលក្ខខណ្ឌនៃការប្រើប្រាស់ផ្សេងទៀត។

តើ BPM ទាក់ទងនឹងវាអ្វីខ្លះ?

ដើម្បីឆ្លើយសំណួរនេះ យើងត្រូវស្វែងយល់ឱ្យកាន់តែស៊ីជម្រៅបន្តិចទៅលើចំណុចជាក់លាក់នៃបញ្ហាដែលបានអនុវត្តនៃដំណោះស្រាយរបស់យើង។ ផ្នែកសំខាន់នៃតក្កវិជ្ជាធុរកិច្ចនៅក្នុងប្រព័ន្ធប្រតិបត្តិការធម្មតារបស់យើងគឺការបញ្ចូលទិន្នន័យទៅក្នុងមូលដ្ឋានទិន្នន័យតាមរយៈចំណុចប្រទាក់អ្នកប្រើ ការផ្ទៀងផ្ទាត់ដោយដៃ និងការផ្ទៀងផ្ទាត់ដោយស្វ័យប្រវត្តិនៃទិន្នន័យនេះ អនុវត្តវាតាមរយៈលំហូរការងារមួយចំនួន បោះពុម្ពវាទៅប្រព័ន្ធផ្សេងទៀត / មូលដ្ឋានទិន្នន័យវិភាគ / បណ្ណសារ បង្កើតរបាយការណ៍។ . ដូច្នេះមុខងារសំខាន់នៃប្រព័ន្ធសម្រាប់អតិថិជនគឺស្វ័យប្រវត្តិកម្មនៃដំណើរការអាជីវកម្មផ្ទៃក្នុងរបស់ពួកគេ។

ដើម្បីភាពងាយស្រួល យើងប្រើពាក្យ "ឯកសារ" ក្នុងការទំនាក់ទំនងជាអរូបីនៃសំណុំទិន្នន័យដែលរួបរួមគ្នាដោយគន្លឹះទូទៅដែលលំហូរការងារជាក់លាក់មួយអាចត្រូវបាន "ភ្ជាប់" ។
ប៉ុន្តែចុះយ៉ាងណាចំពោះតក្កវិជ្ជារួមបញ្ចូល? យ៉ាងណាមិញ កិច្ចការសមាហរណកម្មត្រូវបានបង្កើតឡើងដោយស្ថាបត្យកម្មនៃប្រព័ន្ធ ដែលត្រូវបាន "កាត់" ជាផ្នែកៗ មិនមែនតាមសំណើរបស់អតិថិជននោះទេ ប៉ុន្តែស្ថិតនៅក្រោមឥទ្ធិពលនៃកត្តាខុសគ្នាទាំងស្រុង៖

• ជាកម្មវត្ថុនៃច្បាប់ Conway;
• ជាលទ្ធផលនៃការប្រើប្រាស់ឡើងវិញនូវប្រព័ន្ធរងដែលបានបង្កើតឡើងពីមុនសម្រាប់ផលិតផលផ្សេងទៀត;
• តាមការសម្រេចចិត្តរបស់ស្ថាបត្យករ ដោយផ្អែកលើតម្រូវការមិនដំណើរការ។

មានការល្បួងដ៏អស្ចារ្យមួយដើម្បីបំបែកតក្កវិជ្ជាសមាហរណកម្មចេញពីតក្កវិជ្ជាអាជីវកម្មនៃលំហូរការងារសំខាន់ ដើម្បីកុំឱ្យបំពុលតក្កវិជ្ជាអាជីវកម្មជាមួយនឹងវត្ថុបុរាណនៃការរួមបញ្ចូល និងជួយសង្រ្គោះអ្នកអភិវឌ្ឍន៍កម្មវិធីពីតម្រូវការក្នុងការស្វែងយល់ពីលក្ខណៈនៃទិដ្ឋភាពស្ថាបត្យកម្មនៃប្រព័ន្ធ។ វិធីសាស្រ្តនេះមានគុណសម្បត្តិមួយចំនួន ប៉ុន្តែការអនុវត្តបង្ហាញពីភាពគ្មានប្រសិទ្ធភាពរបស់វា៖

• ការដោះស្រាយបញ្ហាសមាហរណកម្មជាធម្មតាត្រលប់ទៅជម្រើសដ៏សាមញ្ញបំផុតក្នុងទម្រង់នៃការហៅចូលសមកាលកម្ម ដោយសារចំណុចបន្ថែមមានកំណត់ក្នុងការអនុវត្តលំហូរការងារចម្បង (គុណវិបត្តិនៃការរួមបញ្ចូលសមកាលកម្មត្រូវបានពិភាក្សាខាងក្រោម);
• វត្ថុបុរាណនៃការធ្វើសមាហរណកម្មនៅតែជ្រាបចូលទៅក្នុងតក្កវិជ្ជាអាជីវកម្មស្នូល នៅពេលដែលមតិកែលម្អពីប្រព័ន្ធរងផ្សេងទៀតត្រូវបានទាមទារ។
• អ្នកអភិវឌ្ឍន៍កម្មវិធីមិនអើពើនឹងការរួមបញ្ចូល ហើយអាចបំបែកវាបានយ៉ាងងាយស្រួលដោយការផ្លាស់ប្តូរលំហូរការងារ។
• ប្រព័ន្ធឈប់នៅតែមួយពីទស្សនៈរបស់អ្នកប្រើ "ថ្នេរ" រវាងប្រព័ន្ធរងអាចកត់សម្គាល់បាន ហើយប្រតិបត្តិការរបស់អ្នកប្រើលែងត្រូវការតទៅទៀត ចាប់ផ្តើមផ្ទេរទិន្នន័យពីប្រព័ន្ធរងមួយទៅប្រព័ន្ធមួយទៀត។

វិធីសាស្រ្តមួយផ្សេងទៀតគឺដើម្បីពិចារណាអន្តរកម្មនៃការរួមបញ្ចូលជាផ្នែកសំខាន់មួយនៃតក្កវិជ្ជា និងលំហូរការងារស្នូល។ ដើម្បីការពារគុណវុឌ្ឍិរបស់អ្នកអភិវឌ្ឍន៍កម្មវិធីពីការកើនឡើងខ្ពស់ ការបង្កើតអន្តរកម្មនៃការរួមបញ្ចូលថ្មីគួរតែមានភាពងាយស្រួល និងគ្មានការប្រឹងប្រែង ដោយមានឱកាសតិចតួចបំផុតក្នុងការជ្រើសរើសដំណោះស្រាយ។ នេះពិបាកធ្វើជាងវា៖ ឧបករណ៍ត្រូវតែមានថាមពលគ្រប់គ្រាន់ដើម្បីផ្តល់ឱ្យអ្នកប្រើប្រាស់នូវជម្រើសជាច្រើនដែលត្រូវការសម្រាប់ការប្រើប្រាស់របស់វា ដោយមិនអនុញ្ញាតឱ្យគាត់ "បាញ់ខ្លួនឯងដោយជើង"។ មានសំណួរជាច្រើនដែលវិស្វករត្រូវតែឆ្លើយក្នុងបរិបទនៃកិច្ចការរួមបញ្ចូល ប៉ុន្តែអ្នកអភិវឌ្ឍន៍កម្មវិធីមិនគួរគិតអំពីកិច្ចការប្រចាំថ្ងៃរបស់គាត់៖ ព្រំដែនប្រតិបត្តិការ ភាពស៊ីសង្វាក់គ្នា អាតូមិក សុវត្ថិភាព ការធ្វើមាត្រដ្ឋាន ការផ្ទុក និងការចែកចាយធនធាន ការកំណត់ផ្លូវ ការដាក់ពង្រាយ។ ការចែកចាយ និងការផ្លាស់ប្តូរបរិបទ។ល។ វាចាំបាច់ក្នុងការផ្តល់ជូនអ្នកបង្កើតកម្មវិធីនូវគំរូដំណោះស្រាយសាមញ្ញយុត្តិធម៌ ដែលចម្លើយចំពោះសំណួរទាំងអស់នោះត្រូវបានលាក់រួចហើយ។ គំរូទាំងនេះត្រូវតែមានសុវត្ថិភាពណាស់៖ តក្កវិជ្ជាអាជីវកម្មផ្លាស់ប្តូរជាញឹកញាប់ ដែលបង្កើនហានិភ័យនៃការណែនាំអំពីកំហុស តម្លៃនៃកំហុសត្រូវតែស្ថិតក្នុងកម្រិតទាបគួរសម។

ប៉ុន្តែតើ BPM មានអ្វីដែលត្រូវធ្វើជាមួយវា? មានជម្រើសជាច្រើនសម្រាប់អនុវត្តដំណើរការការងារ...
ជាការពិត ការអនុវត្តដំណើរការអាជីវកម្មមួយផ្សេងទៀតគឺមានប្រជាប្រិយភាពខ្លាំងនៅក្នុងដំណោះស្រាយរបស់យើង - តាមរយៈនិយមន័យប្រកាសនៃដ្យាក្រាមការផ្លាស់ប្តូររដ្ឋ និងការភ្ជាប់ទំនាក់ទំនងរបស់អ្នកដោះស្រាយជាមួយនឹងតក្កវិជ្ជាអាជីវកម្មសម្រាប់ការផ្លាស់ប្តូរ។ ក្នុងករណីនេះ រដ្ឋដែលកំណត់ទីតាំងបច្ចុប្បន្ននៃ "ឯកសារ" នៅក្នុងដំណើរការអាជីវកម្ម គឺជាគុណលក្ខណៈនៃ "ឯកសារ" ខ្លួនឯង។

នេះគឺជាអ្វីដែលដំណើរការមើលទៅដូចនៅពេលចាប់ផ្តើមគម្រោង

ភាពពេញនិយមនៃការអនុវត្តនេះគឺដោយសារតែភាពសាមញ្ញ និងល្បឿននៃការបង្កើតដំណើរការអាជីវកម្មលីនេអ៊ែរ។ ទោះជាយ៉ាងណាក៏ដោយ ដោយសារប្រព័ន្ធសូហ្វវែរកាន់តែស្មុគស្មាញ ផ្នែកស្វ័យប្រវត្តិនៃដំណើរការអាជីវកម្មកាន់តែរីកចម្រើន និងកាន់តែស្មុគស្មាញ។ វាមានតំរូវការសំរាប់ការរលួយ ការប្រើប្រាស់ឡើងវិញនូវផ្នែកនៃដំណើរការ ក៏ដូចជាដំណើរការសាខា ដូច្នេះសាខានីមួយៗត្រូវបានប្រតិបត្តិស្របគ្នា។ នៅក្រោមលក្ខខណ្ឌបែបនេះ ឧបករណ៍ក្លាយជាការរអាក់រអួល ហើយដ្យាក្រាមការផ្លាស់ប្តូររដ្ឋបាត់បង់ខ្លឹមសារព័ត៌មានរបស់វា (អន្តរកម្មនៃការរួមបញ្ចូលមិនត្រូវបានឆ្លុះបញ្ចាំងនៅក្នុងដ្យាក្រាមទាល់តែសោះ)។

នេះគឺជាអ្វីដែលដំណើរការមើលទៅបន្ទាប់ពីការបញ្ជាក់ឡើងវិញនូវតម្រូវការជាច្រើន

ផ្លូវចេញពីស្ថានភាពនេះគឺការរួមបញ្ចូលម៉ាស៊ីន jBPM ចូលទៅក្នុងផលិតផលមួយចំនួនជាមួយនឹងដំណើរការអាជីវកម្មដ៏ស្មុគស្មាញបំផុត។ ក្នុងរយៈពេលខ្លី ដំណោះស្រាយនេះបានទទួលជោគជ័យខ្លះ៖ វាអាចទៅរួចក្នុងការអនុវត្តដំណើរការអាជីវកម្មដ៏ស្មុគស្មាញ ខណៈពេលដែលរក្សាបាននូវដ្យាក្រាមដែលមានព័ត៌មានត្រឹមត្រូវ និងពាក់ព័ន្ធនៅក្នុងសញ្ញាណ។ BPMN2.

ផ្នែកតូចមួយនៃដំណើរការអាជីវកម្មដ៏ស្មុគស្មាញ

ក្នុងរយៈពេលវែង ដំណោះស្រាយមិនស្របតាមការរំពឹងទុកទេ៖ អាំងតង់ស៊ីតេពលកម្មខ្ពស់នៃការបង្កើតដំណើរការអាជីវកម្មតាមរយៈឧបករណ៍ដែលមើលឃើញមិនអនុញ្ញាតឱ្យសម្រេចបាននូវសូចនាករផលិតភាពដែលអាចទទួលយកបាន ហើយឧបករណ៍ខ្លួនវាបានក្លាយជាផ្នែកមួយដែលមិនចូលចិត្តបំផុតក្នុងចំណោមអ្នកអភិវឌ្ឍន៍។ វាក៏មានការត្អូញត្អែរអំពីរចនាសម្ព័ន្ធខាងក្នុងរបស់ម៉ាស៊ីនដែលនាំឱ្យមានរូបរាងនៃ "បំណះ" និង "ឈើច្រត់" ជាច្រើន។

ទិដ្ឋភាពវិជ្ជមានចម្បងនៃការប្រើប្រាស់ jBPM គឺការយល់ដឹងអំពីអត្ថប្រយោជន៍ និងគ្រោះថ្នាក់នៃការមានស្ថានភាពបន្តផ្ទាល់របស់ឧទាហរណ៍នៃដំណើរការអាជីវកម្ម។ យើងក៏បានឃើញលទ្ធភាពនៃការប្រើប្រាស់វិធីសាស្រ្តដំណើរការដើម្បីអនុវត្តពិធីការរួមបញ្ចូលដ៏ស្មុគស្មាញរវាងកម្មវិធីផ្សេងៗគ្នាដោយប្រើអន្តរកម្មអសមកាលតាមរយៈសញ្ញា និងសារ។ វត្តមានរបស់រដ្ឋជាប់លាប់ដើរតួនាទីយ៉ាងសំខាន់ក្នុងរឿងនេះ។

ដោយផ្អែកលើចំណុចខាងលើយើងអាចសន្និដ្ឋាន: វិធីសាស្រ្តដំណើរការនៅក្នុងរចនាប័ទ្ម BPM អនុញ្ញាតឱ្យយើងដោះស្រាយកិច្ចការជាច្រើនដើម្បីធ្វើស្វ័យប្រវត្តិកម្មនៃដំណើរការអាជីវកម្មដែលស្មុគស្មាញកាន់តែខ្លាំងឡើង ធ្វើឱ្យសកម្មភាពសមាហរណកម្មមានភាពចុះសម្រុងគ្នាក្នុងដំណើរការទាំងនេះ និងរក្សាសមត្ថភាពក្នុងការបង្ហាញឱ្យឃើញនូវដំណើរការដែលបានអនុវត្តក្នុងន័យសមរម្យមួយ។

គុណវិបត្តិនៃការហៅទូរសព្ទដែលធ្វើសមកាលកម្មជាគំរូរួមបញ្ចូល

ការរួមបញ្ចូលសមកាលកម្មសំដៅទៅលើការហៅទប់ស្កាត់ដ៏សាមញ្ញបំផុត។ ប្រព័ន្ធរងមួយដើរតួជាផ្នែកខាងម៉ាស៊ីនមេ ហើយលាតត្រដាង API ជាមួយនឹងវិធីសាស្ត្រដែលត្រូវការ។ ប្រព័ន្ធរងមួយទៀតដើរតួជាភាគីអតិថិជន ហើយនៅពេលត្រឹមត្រូវធ្វើការហៅទូរសព្ទ ហើយរង់ចាំលទ្ធផល។ អាស្រ័យលើស្ថាបត្យកម្មប្រព័ន្ធ ភាគីម៉ាស៊ីនភ្ញៀវ និងម៉ាស៊ីនមេអាចមានទីតាំងនៅក្នុងកម្មវិធី និងដំណើរការដូចគ្នា ឬនៅក្នុងកម្មវិធីផ្សេងគ្នា។ ក្នុងករណីទី 2 អ្នកត្រូវអនុវត្តការអនុវត្ត RPC មួយចំនួននិងផ្តល់នូវការចាត់ថ្នាក់នៃប៉ារ៉ាម៉ែត្រនិងលទ្ធផលនៃការហៅ។

គំរូនៃការរួមបញ្ចូលនេះមានគុណវិបត្តិដ៏ធំមួយ ប៉ុន្តែវាត្រូវបានប្រើប្រាស់យ៉ាងទូលំទូលាយនៅក្នុងការអនុវត្ត ដោយសារតែភាពសាមញ្ញរបស់វា។ ល្បឿននៃការអនុវត្តទាក់ទាញ និងបង្ខំអ្នកឱ្យប្រើវាម្តងហើយម្តងទៀតនៅចំពោះមុខពេលវេលាកំណត់ ដោយកត់ត្រាដំណោះស្រាយជាបំណុលបច្ចេកទេស។ ប៉ុន្តែវាក៏កើតឡើងផងដែរដែលអ្នកអភិវឌ្ឍន៍ដែលគ្មានបទពិសោធន៍ប្រើប្រាស់វាដោយមិនដឹងខ្លួន ដោយគ្រាន់តែមិនដឹងពីផលវិបាកអវិជ្ជមាន។

បន្ថែមពីលើការកើនឡើងជាក់ស្តែងបំផុតនៅក្នុងការតភ្ជាប់ប្រព័ន្ធរង វាក៏មានបញ្ហាមិនសូវច្បាស់ជាមួយនឹងប្រតិបត្តិការ "រីកលូតលាស់" និង "ពង្រីក" ផងដែរ។ ជាការពិតណាស់ ប្រសិនបើតក្កវិជ្ជាអាជីវកម្មធ្វើការផ្លាស់ប្តូរមួយចំនួន នោះប្រតិបត្តិការមិនអាចជៀសវាងបានទេ ហើយប្រតិបត្តិការ រារាំងធនធានកម្មវិធីមួយចំនួនដែលរងផលប៉ះពាល់ដោយការផ្លាស់ប្តូរទាំងនេះ។ នោះគឺរហូតដល់ប្រព័ន្ធរងមួយរង់ចាំការឆ្លើយតបពីមួយទៀត វានឹងមិនអាចបញ្ចប់ប្រតិបត្តិការ និងដកសោចេញបានទេ។ នេះបង្កើនហានិភ័យនៃផលប៉ះពាល់ជាច្រើន៖

• ការឆ្លើយតបនៃប្រព័ន្ធត្រូវបានបាត់បង់ អ្នកប្រើប្រាស់រង់ចាំរយៈពេលយូរសម្រាប់ចម្លើយចំពោះសំណួរ។
• ជាទូទៅម៉ាស៊ីនមេឈប់ឆ្លើយតបនឹងសំណើរបស់អ្នកប្រើប្រាស់ដោយសារតែបណ្តុំខ្សែស្រឡាយដែលចង្អៀត៖ ខ្សែស្រលាយភាគច្រើនត្រូវបានចាក់សោលើធនធានដែលកាន់កាប់ដោយប្រតិបត្តិការ។
• Deadlocks ចាប់ផ្តើមលេចឡើង: លទ្ធភាពនៃការកើតឡើងរបស់វាអាស្រ័យយ៉ាងខ្លាំងទៅលើរយៈពេលនៃប្រតិបត្តិការ ចំនួននៃតក្កវិជ្ជាអាជីវកម្ម និងការចាក់សោដែលពាក់ព័ន្ធនឹងប្រតិបត្តិការ។
• កំហុសអស់ពេលប្រតិបត្តិការលេចឡើង;
• ម៉ាស៊ីនមេ "បរាជ័យ" ជាមួយ OutOfMemory ប្រសិនបើកិច្ចការតម្រូវឱ្យដំណើរការ និងផ្លាស់ប្តូរទិន្នន័យមួយចំនួនធំ ហើយវត្តមាននៃការរួមបញ្ចូលសមកាលកម្មធ្វើឱ្យមានការលំបាកក្នុងការបែងចែកដំណើរការទៅជាប្រតិបត្តិការ "ស្រាលជាងមុន" ។

តាមទស្សនៈស្ថាបត្យកម្ម ការប្រើប្រាស់រារាំងការហៅទូរសព្ទអំឡុងពេលរួមបញ្ចូលនាំឱ្យបាត់បង់ការគ្រប់គ្រងលើគុណភាពនៃប្រព័ន្ធរងនីមួយៗ៖ វាមិនអាចទៅរួចទេក្នុងការធានាបាននូវសូចនាករគុណភាពគោលដៅនៃប្រព័ន្ធរងមួយក្នុងភាពឯកោពីសូចនាករគុណភាពនៃប្រព័ន្ធរងមួយទៀត។ ប្រសិនបើប្រព័ន្ធរងត្រូវបានបង្កើតឡើងដោយក្រុមផ្សេងៗគ្នា នេះគឺជាបញ្ហាធំ។

អ្វីៗកាន់តែគួរឱ្យចាប់អារម្មណ៍ ប្រសិនបើប្រព័ន្ធរងដែលកំពុងត្រូវបានដាក់បញ្ចូលក្នុងកម្មវិធីផ្សេងៗគ្នា ហើយអ្នកត្រូវធ្វើការផ្លាស់ប្តូរសមកាលកម្មទាំងសងខាង។ តើធ្វើដូចម្តេចដើម្បីធានាបាននូវប្រតិបត្តិការនៃការផ្លាស់ប្តូរទាំងនេះ?

ប្រសិនបើការផ្លាស់ប្តូរត្រូវបានធ្វើឡើងនៅក្នុងប្រតិបត្តិការដាច់ដោយឡែក នោះអ្នកនឹងត្រូវផ្តល់នូវការដោះស្រាយករណីលើកលែង និងសំណងដែលអាចទុកចិត្តបាន ហើយនេះលុបបំបាត់ទាំងស្រុងនូវអត្ថប្រយោជន៍ចម្បងនៃការរួមបញ្ចូលសមកាលកម្ម - ភាពសាមញ្ញ។

ប្រតិបត្តិការចែកចាយក៏ចូលមកក្នុងចិត្តដែរ ប៉ុន្តែយើងមិនប្រើវានៅក្នុងដំណោះស្រាយរបស់យើងទេ៖ វាពិបាកក្នុងការធានានូវភាពជឿជាក់។

"Saga" ជាដំណោះស្រាយចំពោះបញ្ហាប្រតិបត្តិការ

ជាមួយនឹងការកើនឡើងនូវប្រជាប្រិយភាពនៃសេវាកម្មមីក្រូ តម្រូវការសម្រាប់ លំនាំសាហ្កា.

គំរូនេះដោះស្រាយយ៉ាងល្អឥតខ្ចោះនូវបញ្ហាដែលបានរៀបរាប់ខាងលើនៃប្រតិបត្តិការរយៈពេលវែង ហើយក៏ពង្រីកសមត្ថភាពគ្រប់គ្រងស្ថានភាពនៃប្រព័ន្ធពីផ្នែកខាងតក្កវិជ្ជាអាជីវកម្មផងដែរ៖ សំណងបន្ទាប់ពីប្រតិបត្តិការបរាជ័យអាចនឹងមិនធ្វើឱ្យប្រព័ន្ធត្រឡប់ទៅសភាពដើមវិញទេ ប៉ុន្តែផ្តល់ ផ្លូវដំណើរការទិន្នន័យជំនួស។ នេះក៏អនុញ្ញាតឱ្យអ្នកជៀសវាងការធ្វើឡើងវិញនូវជំហានដំណើរការទិន្នន័យដែលបានបញ្ចប់ដោយជោគជ័យ នៅពេលព្យាយាមនាំយកដំណើរការទៅកាន់ការបញ្ចប់ "ល្អ" ។

គួរឱ្យចាប់អារម្មណ៍នៅក្នុងប្រព័ន្ធ monolithic គំរូនេះក៏ពាក់ព័ន្ធផងដែរនៅពេលនិយាយអំពីការរួមបញ្ចូលប្រព័ន្ធរងដែលជាប់គ្នារលុង និងផលប៉ះពាល់អវិជ្ជមានដែលបណ្តាលមកពីប្រតិបត្តិការរយៈពេលយូរ និងការចាក់សោធនធានដែលត្រូវគ្នាត្រូវបានអង្កេត។

ទាក់ទងទៅនឹងដំណើរការអាជីវកម្មរបស់យើងនៅក្នុងរចនាប័ទ្ម BPM វាប្រែទៅជាងាយស្រួលណាស់ក្នុងការអនុវត្ត "Sagas": ជំហានបុគ្គលនៃ "Saga" អាចត្រូវបានបញ្ជាក់ជាសកម្មភាពនៅក្នុងដំណើរការអាជីវកម្ម និងស្ថានភាពជាប់លាប់នៃដំណើរការអាជីវកម្មផងដែរ។ កំណត់ស្ថានភាពផ្ទៃក្នុងនៃ "សាហ្កា" ។ នោះគឺយើងមិនទាមទារយន្តការសម្របសម្រួលបន្ថែមទេ។ អ្វីដែលអ្នកត្រូវការគឺឈ្មួញកណ្តាលសារដែលគាំទ្រការធានា "យ៉ាងហោចណាស់ម្តង" ជាការដឹកជញ្ជូន។

ប៉ុន្តែដំណោះស្រាយនេះក៏មាន "តម្លៃ" របស់វាផងដែរ៖

• តក្កវិជ្ជាអាជីវកម្មកាន់តែស្មុគស្មាញ៖ សំណងចាំបាច់ត្រូវដោះស្រាយ។
• វានឹងចាំបាច់ក្នុងការបោះបង់ចោលនូវភាពស៊ីសង្វាក់គ្នាពេញលេញ ដែលអាចមានភាពរសើបជាពិសេសសម្រាប់ប្រព័ន្ធ monolithic ។
• ស្ថាបត្យកម្មកាន់តែស្មុគស្មាញបន្តិច ហើយតម្រូវការបន្ថែមសម្រាប់ឈ្មួញកណ្តាលសារលេចឡើង។
• ឧបករណ៍ត្រួតពិនិត្យ និងរដ្ឋបាលបន្ថែមនឹងត្រូវបានទាមទារ (ទោះបីជាជាទូទៅវាល្អក៏ដោយ៖ គុណភាពនៃសេវាកម្មប្រព័ន្ធនឹងកើនឡើង)។

សម្រាប់ប្រព័ន្ធ monolithic យុត្តិកម្មសម្រាប់ការប្រើប្រាស់ "Sag" គឺមិនសូវច្បាស់ទេ។ សម្រាប់សេវាមីក្រូ និង SOA ផ្សេងទៀត ដែលភាគច្រើនទំនងជាមានឈ្មួញកណ្តាលរួចហើយ និងភាពស៊ីសង្វាក់គ្នាពេញលេញត្រូវបានលះបង់នៅពេលចាប់ផ្តើមគម្រោង អត្ថប្រយោជន៍នៃការប្រើប្រាស់គំរូនេះអាចលើសពីគុណវិបត្តិ ជាពិសេសប្រសិនបើមាន API ងាយស្រួលនៅតក្កវិជ្ជាអាជីវកម្ម។ កម្រិត។

ការបញ្ចូលតក្កវិជ្ជាអាជីវកម្មនៅក្នុងសេវាកម្មមីក្រូ

នៅពេលយើងចាប់ផ្តើមពិសោធន៍ជាមួយសេវាកម្មមីក្រូ សំណួរសមហេតុផលមួយបានកើតឡើង៖ កន្លែងដែលត្រូវដាក់តក្កវិជ្ជាអាជីវកម្មរបស់ដែនទាក់ទងនឹងសេវាកម្មដែលធានាឱ្យមានការជាប់លាប់នៃទិន្នន័យដែន?

នៅពេលក្រឡេកមើលស្ថាបត្យកម្មនៃ BPMSs ផ្សេងៗ វាហាក់ដូចជាសមហេតុផលក្នុងការបំបែកតក្កវិជ្ជាអាជីវកម្មពីការជាប់លាប់៖ បង្កើតស្រទាប់នៃវេទិកា និងសេវាកម្មមីក្រូដែលឯករាជ្យដោយដែនដែលបង្កើតបរិយាកាស និងកុងតឺន័រសម្រាប់ប្រតិបត្តិតក្កវិជ្ជាអាជីវកម្មដែន និងរចនាការជាប់លាប់នៃទិន្នន័យដែនជា ស្រទាប់ដាច់ដោយឡែកនៃសេវាមីក្រូដ៏សាមញ្ញ និងស្រាល។ ដំណើរការអាជីវកម្មក្នុងករណីនេះអនុវត្តការរៀបចំសេវាកម្មនៃស្រទាប់តស៊ូ។

វិធីសាស្រ្តនេះមានអត្ថប្រយោជន៍ធំណាស់៖ អ្នកអាចបង្កើនមុខងាររបស់វេទិកាបានច្រើនតាមដែលអ្នកចូលចិត្ត ហើយមានតែស្រទាប់ដែលត្រូវគ្នានៃសេវាកម្មមីក្រូវេទិកាប៉ុណ្ណោះដែលនឹងក្លាយទៅជា "ខ្លាញ់" ពីនេះ។ ដំណើរការអាជីវកម្មពីដែនណាមួយអាចប្រើមុខងារថ្មីរបស់វេទិកាភ្លាមៗនៅពេលវាត្រូវបានធ្វើបច្ចុប្បន្នភាព។

ការសិក្សាលម្អិតបន្ថែមទៀតបង្ហាញពីគុណវិបត្តិសំខាន់ៗនៃវិធីសាស្រ្តនេះ៖

• សេវាកម្មវេទិកាដែលប្រតិបត្តិតក្កវិជ្ជាអាជីវកម្មនៃដែនជាច្រើនក្នុងពេលតែមួយនាំមកនូវហានិភ័យដ៏អស្ចារ្យដែលជាចំណុចតែមួយនៃការបរាជ័យ។ ការផ្លាស់ប្តូរជាញឹកញាប់ចំពោះតក្កវិជ្ជាអាជីវកម្មបង្កើនហានិភ័យនៃកំហុសដែលនាំទៅដល់ការបរាជ័យនៃប្រព័ន្ធទាំងមូល។
• បញ្ហាការអនុវត្ត៖ តក្កវិជ្ជាអាជីវកម្មធ្វើការជាមួយទិន្នន័យរបស់វាតាមរយៈចំណុចប្រទាក់តូចចង្អៀត និងយឺត៖
  • ទិន្នន័យនឹងត្រូវបាន marshalled ម្តងទៀត និងបូមតាមរយៈបណ្តាញជង់។
  • សេវាដែនជាញឹកញាប់នឹងផ្តល់ទិន្នន័យច្រើនជាងតម្រូវការសម្រាប់តក្កវិជ្ជាអាជីវកម្មដើម្បីដំណើរការ ដោយសារតែសមត្ថភាពមិនគ្រប់គ្រាន់សម្រាប់ការកំណត់ប៉ារ៉ាម៉ែត្រនៅកម្រិតនៃ API ខាងក្រៅនៃសេវាកម្ម។
  • បំណែកឯករាជ្យជាច្រើននៃតក្កវិជ្ជាអាជីវកម្មអាចស្នើសុំទិន្នន័យដូចគ្នាម្តងទៀតសម្រាប់ដំណើរការ (បញ្ហានេះអាចត្រូវបានកាត់បន្ថយដោយការបន្ថែមសមាសធាតុសម័យដែលផ្ទុកទិន្នន័យ ប៉ុន្តែវាធ្វើឱ្យស្មុគស្មាញដល់ស្ថាបត្យកម្ម និងបង្កើតបញ្ហាទាក់ទងនឹងទិន្នន័យ និងការធ្វើឱ្យឃ្លាំងសម្ងាត់មិនត្រឹមត្រូវ);
• បញ្ហាប្រតិបត្តិការ៖
  • ដំណើរការអាជីវកម្មជាមួយនឹងស្ថានភាពជាប់លាប់ ដែលត្រូវបានរក្សាទុកដោយសេវាកម្មវេទិកា គឺមិនស៊ីគ្នាជាមួយនឹងទិន្នន័យដែន ហើយមិនមានវិធីងាយស្រួលដើម្បីដោះស្រាយបញ្ហានេះទេ។
  • ការដាក់ការទប់ស្កាត់ទិន្នន័យដែននៅខាងក្រៅប្រតិបត្តិការ៖ ប្រសិនបើតក្កវិជ្ជាអាជីវកម្មដែនត្រូវការធ្វើការផ្លាស់ប្តូរបន្ទាប់ពីពិនិត្យមើលភាពត្រឹមត្រូវនៃទិន្នន័យបច្ចុប្បន្នដំបូង នោះចាំបាច់ត្រូវដកចេញនូវលទ្ធភាពនៃការផ្លាស់ប្តូរប្រកួតប្រជែងនៅក្នុងទិន្នន័យដែលបានដំណើរការ។ ការទប់ស្កាត់ទិន្នន័យខាងក្រៅអាចជួយដោះស្រាយបញ្ហា ប៉ុន្តែដំណោះស្រាយបែបនេះមានហានិភ័យបន្ថែម និងកាត់បន្ថយភាពជឿជាក់ទាំងមូលនៃប្រព័ន្ធ។
• ការលំបាកបន្ថែមនៅពេលធ្វើបច្ចុប្បន្នភាព៖ ក្នុងករណីខ្លះ សេវាកម្មជាប់លាប់ និងតក្កវិជ្ជាអាជីវកម្មចាំបាច់ត្រូវធ្វើបច្ចុប្បន្នភាពស្របគ្នា ឬតាមលំដាប់លំដោយ។

ទីបំផុត យើងត្រូវត្រលប់ទៅមូលដ្ឋានវិញ៖ បញ្ចូលទិន្នន័យដែន និងតក្កវិជ្ជាអាជីវកម្មដែនទៅក្នុងសេវាមីក្រូមួយ។ វិធីសាស្រ្តនេះជួយសម្រួលដល់ការយល់ឃើញនៃសេវាមីក្រូជាធាតុផ្សំសំខាន់នៃប្រព័ន្ធ ហើយមិនបង្កឱ្យមានបញ្ហាខាងលើឡើយ។ នេះក៏មិនត្រូវបានផ្តល់ឱ្យដោយឥតគិតថ្លៃផងដែរ:

• ស្តង់ដារ API គឺត្រូវបានទាមទារសម្រាប់អន្តរកម្មជាមួយតក្កវិជ្ជាអាជីវកម្ម (ជាពិសេស ដើម្បីផ្តល់សកម្មភាពអ្នកប្រើប្រាស់ជាផ្នែកនៃដំណើរការអាជីវកម្ម) និងសេវាកម្មវេទិកា API ។ ទាមទារការយកចិត្តទុកដាក់បន្ថែមទៀតចំពោះការផ្លាស់ប្តូរ API ភាពឆបគ្នាឆ្ពោះទៅមុខ និងថយក្រោយ។
• វាចាំបាច់ក្នុងការបន្ថែមបណ្ណាល័យពេលដំណើរការបន្ថែម ដើម្បីធានាបាននូវដំណើរការនៃតក្កវិជ្ជាអាជីវកម្មជាផ្នែកនៃសេវាកម្មមីក្រូនីមួយៗ ហើយនេះផ្តល់នូវការកើនឡើងនូវតម្រូវការថ្មីសម្រាប់បណ្ណាល័យបែបនេះ៖ ពន្លឺ និងអប្បរមានៃភាពអាស្រ័យឆ្លងកាត់។
• អ្នកអភិវឌ្ឍន៍តក្កវិជ្ជាអាជីវកម្មត្រូវត្រួតពិនិត្យកំណែបណ្ណាល័យ៖ ប្រសិនបើសេវាកម្មមីក្រូមិនត្រូវបានបញ្ចប់ជាយូរមកហើយនោះ វាទំនងជាមានកំណែហួសសម័យរបស់បណ្ណាល័យ។ នេះអាចជាឧបសគ្គដែលមិននឹកស្មានដល់ក្នុងការបន្ថែមមុខងារថ្មី ហើយអាចទាមទារការផ្ទេរតក្កវិជ្ជាអាជីវកម្មចាស់នៃសេវាកម្មបែបនេះទៅកាន់កំណែថ្មីនៃបណ្ណាល័យ ប្រសិនបើមានការផ្លាស់ប្តូរមិនត្រូវគ្នារវាងកំណែ។

ស្រទាប់នៃសេវាកម្មវេទិកាក៏មានវត្តមាននៅក្នុងស្ថាបត្យកម្មបែបនេះដែរ ប៉ុន្តែស្រទាប់នេះលែងបង្កើតជាកុងតឺន័រសម្រាប់ដំណើរការតក្កវិជ្ជាអាជីវកម្មដែនទៀតហើយ ប៉ុន្តែមានតែបរិយាកាសរបស់វាប៉ុណ្ណោះដែលផ្តល់មុខងារ "វេទិកា" ជំនួយ។ ស្រទាប់បែបនេះគឺត្រូវការមិនត្រឹមតែដើម្បីរក្សាលក្ខណៈស្រាលនៃសេវាមីក្រូដែនប៉ុណ្ណោះទេប៉ុន្តែថែមទាំងធ្វើឱ្យការគ្រប់គ្រងកណ្តាលផងដែរ។

ឧទាហរណ៍ សកម្មភាពរបស់អ្នកប្រើប្រាស់ក្នុងដំណើរការអាជីវកម្មបង្កើតភារកិច្ច។ ទោះជាយ៉ាងណាក៏ដោយ នៅពេលធ្វើការជាមួយភារកិច្ច អ្នកប្រើប្រាស់ត្រូវតែមើលឃើញភារកិច្ចពីដែនទាំងអស់នៅក្នុងបញ្ជីទូទៅ ដែលមានន័យថាត្រូវតែមានសេវាចុះឈ្មោះភារកិច្ចលើវេទិកាដែលត្រូវគ្នា ជម្រះពីតក្កវិជ្ជាអាជីវកម្មដែន។ ការរក្សាការបិទបាំងនៃតក្កវិជ្ជាអាជីវកម្មក្នុងបរិបទបែបនេះពិតជាមានបញ្ហា ហើយនេះគឺជាការសម្របសម្រួលមួយផ្សេងទៀតនៃស្ថាបត្យកម្មនេះ។

ការរួមបញ្ចូលគ្នានៃដំណើរការអាជីវកម្មតាមរយៈភ្នែករបស់អ្នកបង្កើតកម្មវិធី

ដូចដែលបានរៀបរាប់ខាងលើ អ្នកបង្កើតកម្មវិធីត្រូវតែត្រូវបានដកចេញពីលក្ខណៈបច្ចេកទេស និងវិស្វកម្មនៃការអនុវត្តអន្តរកម្មនៃកម្មវិធីជាច្រើន ដូច្នេះគេអាចពឹងផ្អែកលើផលិតភាពនៃការអភិវឌ្ឍន៍ល្អ។

ចូរយើងព្យាយាមដោះស្រាយបញ្ហាសមាហរណកម្មដ៏លំបាកមួយ ដែលបង្កើតជាពិសេសសម្រាប់អត្ថបទ។ នេះនឹងក្លាយជាកិច្ចការ "ហ្គេម" ដែលពាក់ព័ន្ធនឹងកម្មវិធីចំនួនបី ដែលពួកវានីមួយៗកំណត់ឈ្មោះដែនជាក់លាក់មួយ៖ "app1", "app2", "app3" ។

នៅខាងក្នុងកម្មវិធីនីមួយៗ ដំណើរការអាជីវកម្មត្រូវបានចាប់ផ្តើមដែលចាប់ផ្តើម "លេងបាល់" តាមរយៈឡានក្រុងរួមបញ្ចូលគ្នា។ សារដែលមានឈ្មោះ "បាល់" នឹងដើរតួជាបាល់។

ច្បាប់នៃល្បែង:

• អ្នកលេងទីមួយគឺជាអ្នកចាប់ផ្តើម។ គាត់អញ្ជើញអ្នកលេងផ្សេងទៀតឱ្យចូលរួមក្នុងហ្គេម ចាប់ផ្តើមហ្គេម និងអាចបញ្ចប់វាបានគ្រប់ពេល។
• អ្នកលេងផ្សេងទៀតប្រកាសពីការចូលរួមរបស់ពួកគេនៅក្នុងហ្គេម "ស្គាល់" គ្នាទៅវិញទៅមក និងអ្នកលេងដំបូង។
• បន្ទាប់ពីទទួលបានបាល់ អ្នកលេងជ្រើសរើសអ្នកលេងដែលចូលរួមផ្សេងទៀត ហើយបញ្ជូនបាល់ទៅគាត់។ ចំនួនសរុបនៃការបញ្ជូនត្រូវបានរាប់;
• អ្នកលេងម្នាក់ៗមាន "ថាមពល" ដែលថយចុះជាមួយនឹងការបញ្ជូនបាល់នីមួយៗដោយអ្នកលេងនោះ។ នៅពេលដែលថាមពលអស់ អ្នកលេងចាកចេញពីហ្គេមដោយប្រកាសលាលែងពីតំណែង។
• ប្រសិន​បើ​កីឡាករ​ត្រូវ​បាន​គេ​ទុក​ឱ្យ​នៅ​ម្នាក់​ឯង គាត់​បាន​ប្រកាស​ភ្លាម​ការ​ចាកចេញ​របស់​គាត់;
• នៅពេលដែលអ្នកលេងទាំងអស់ត្រូវបានលុបចោល អ្នកលេងដំបូងនឹងប្រកាសថាហ្គេមបានបញ្ចប់។ ប្រសិនបើគាត់ចាកចេញពីហ្គេមទាន់ពេល គាត់នៅតែធ្វើតាមហ្គេមដើម្បីបញ្ចប់វា។

ដើម្បីដោះស្រាយបញ្ហានេះ ខ្ញុំនឹងប្រើ DSL របស់យើងសម្រាប់ដំណើរការអាជីវកម្ម ដែលអនុញ្ញាតឱ្យយើងពិពណ៌នាអំពីតក្កវិជ្ជានៅក្នុង Kotlin ដោយបង្រួមអប្បបរមាជាមួយនឹងបន្ទះ boilerplate អប្បបរមា។

ដំណើរការអាជីវកម្មរបស់អ្នកលេងដំបូង (ហៅកាត់ថាជាអ្នកផ្ដើមហ្គេម) នឹងដំណើរការនៅក្នុងកម្មវិធី app1៖

ថ្នាក់ដំបូងអ្នកលេង

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

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

class PlayersList : ArrayList<PlayerInfo>()

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

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

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

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

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

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

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

បន្ថែមពីលើការប្រតិបត្តិតក្កវិជ្ជាអាជីវកម្ម កូដខាងលើអាចបង្កើតគំរូវត្ថុនៃដំណើរការអាជីវកម្ម ដែលអាចមើលឃើញក្នុងទម្រង់ជាដ្យាក្រាម។ យើងមិនទាន់បានអនុវត្តកម្មវិធីមើលឃើញនៅឡើយទេ ដូច្នេះយើងត្រូវចំណាយពេលបន្តិចក្នុងការគូរ (នៅទីនេះខ្ញុំបានសម្រួលការសម្គាល់ BPMN បន្តិចទាក់ទងនឹងការប្រើប្រាស់ច្រកទ្វារ ដើម្បីកែលម្អភាពស៊ីសង្វាក់នៃដ្យាក្រាមជាមួយកូដខាងក្រោម)៖

app2 នឹងរួមបញ្ចូលដំណើរការអាជីវកម្មរបស់អ្នកលេងផ្សេងទៀត៖

ថ្នាក់ RandomPlayer

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

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

class PlayersList: ArrayList<PlayerInfo>()

class RandomPlayer : ProcessImpl<RandomPlayer>(randomPlayerModel) {

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

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

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

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

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

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

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

ដ្យាក្រាម៖

នៅក្នុងកម្មវិធី app3 យើងនឹងបង្កើតអ្នកលេងដែលមានអាកប្បកិរិយាខុសគ្នាបន្តិចបន្តួច៖ ជំនួសឱ្យការជ្រើសរើសអ្នកលេងបន្ទាប់ដោយចៃដន្យ គាត់នឹងធ្វើទៅតាមក្បួនដោះស្រាយជុំវិល៖

ថ្នាក់ 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}")
}

បើមិនដូច្នោះទេអាកប្បកិរិយារបស់អ្នកលេងមិនខុសពីមុនទេដូច្នេះដ្យាក្រាមមិនផ្លាស់ប្តូរទេ។

ឥឡូវនេះយើងត្រូវការការធ្វើតេស្តដើម្បីដំណើរការទាំងអស់នេះ។ ខ្ញុំនឹងផ្ដល់ឱ្យតែលេខកូដនៃការធ្វើតេស្តដោយខ្លួនឯងប៉ុណ្ណោះ ដើម្បីកុំឱ្យពង្រាយអត្ថបទជាមួយនឹងបន្ទះ boilerplate (តាមពិត ខ្ញុំបានប្រើបរិយាកាសសាកល្បងដែលបានបង្កើតមុននេះ ដើម្បីសាកល្បងការរួមបញ្ចូលនៃដំណើរការអាជីវកម្មផ្សេងទៀត)៖

ហ្គេមសាកល្បង()

@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. (ជួរសំបុត្រស្លាប់) ។ សម្រាប់គោលបំណងនេះ យើងបានបង្កើត microservice វេទិកាដាច់ដោយឡែកដែលរក្សាទុកសារបែបនេះនៅក្នុងកន្លែងផ្ទុករបស់វា ធ្វើលិបិក្រមពួកវាតាមលក្ខណៈ (សម្រាប់ការដាក់ជាក្រុម និងការស្វែងរករហ័ស) និងបង្ហាញ API សម្រាប់ការមើល បញ្ជូនបន្តទៅកាន់អាសយដ្ឋានគោលដៅ និងលុបសារ។ អ្នកគ្រប់គ្រងប្រព័ន្ធអាចធ្វើការជាមួយសេវាកម្មនេះតាមរយៈចំណុចប្រទាក់គេហទំព័ររបស់ពួកគេ។
• នៅក្នុងការកំណត់ឈ្មួញកណ្តាល អ្នកត្រូវកែតម្រូវចំនួននៃការបញ្ជូនឡើងវិញ និងការពន្យារពេលរវាងការចែកចាយ ដើម្បីកាត់បន្ថយលទ្ធភាពនៃសារចូលទៅក្នុង DLQ (វាស្ទើរតែមិនអាចទៅរួចទេក្នុងការគណនាប៉ារ៉ាម៉ែត្រដ៏ល្អប្រសើរ ប៉ុន្តែអ្នកអាចធ្វើសកម្មភាពជាក់ស្តែង និងកែតម្រូវពួកវាក្នុងអំឡុងពេលប្រតិបត្តិការ។ );
• ហាង DLQ ត្រូវតែត្រូវបានត្រួតពិនិត្យជាបន្តបន្ទាប់ ហើយប្រព័ន្ធត្រួតពិនិត្យត្រូវតែជូនដំណឹងដល់អ្នកគ្រប់គ្រងប្រព័ន្ធ ដូច្នេះនៅពេលដែលសារដែលមិនបានបញ្ជូនកើតឡើង ពួកគេអាចឆ្លើយតបបានលឿនតាមដែលអាចធ្វើទៅបាន។ វានឹងកាត់បន្ថយ "តំបន់រងផលប៉ះពាល់" នៃការបរាជ័យ ឬកំហុសតក្កវិជ្ជាអាជីវកម្ម។
• ឡានក្រុងរួមបញ្ចូលត្រូវតែមានភាពរសើបចំពោះអវត្តមានបណ្ដោះអាសន្ននៃកម្មវិធី៖ ការជាវប្រធានបទត្រូវតែប្រើប្រាស់បានយូរ ហើយឈ្មោះដែនរបស់កម្មវិធីត្រូវតែមានលក្ខណៈប្លែកពីគេ ដូច្នេះខណៈពេលដែលកម្មវិធីអវត្តមាន អ្នកផ្សេងនឹងមិនព្យាយាមដំណើរការសាររបស់វាពី ជួរ។

ធានាសុវត្ថិភាពខ្សែស្រឡាយនៃតក្កវិជ្ជាអាជីវកម្ម

ឧទាហរណ៍ដូចគ្នានៃដំណើរការអាជីវកម្មអាចទទួលបានសារ និងព្រឹត្តិការណ៍ជាច្រើនក្នុងពេលតែមួយ ដែលដំណើរការដែលនឹងចាប់ផ្តើមស្របគ្នា។ ក្នុងពេលជាមួយគ្នានេះ សម្រាប់អ្នកបង្កើតកម្មវិធី អ្វីគ្រប់យ៉ាងគួរតែសាមញ្ញ និងមានសុវត្ថិភាព។

តក្កវិជ្ជាអាជីវកម្មនៃដំណើរការដំណើរការព្រឹត្តិការណ៍ខាងក្រៅនីមួយៗ ដែលប៉ះពាល់ដល់ដំណើរការអាជីវកម្មនោះរៀងៗខ្លួន។ ព្រឹត្តិការណ៍បែបនេះអាចជា៖

• ការចាប់ផ្តើមដំណើរការអាជីវកម្ម;
• សកម្មភាពអ្នកប្រើប្រាស់ទាក់ទងនឹងសកម្មភាពនៅក្នុងដំណើរការអាជីវកម្ម;
• ការទទួលសារ ឬសញ្ញាដែលដំណើរការអាជីវកម្មត្រូវបានជាវ។
• ការកេះកម្មវិធីកំណត់ពេលកំណត់ដោយឧទាហរណ៍នៃដំណើរការអាជីវកម្ម;
• គ្រប់គ្រងសកម្មភាពតាមរយៈ API (ឧទាហរណ៍ ការរំខានដំណើរការ)។

ព្រឹត្តិការណ៍បែបនេះនីមួយៗអាចផ្លាស់ប្តូរស្ថានភាពនៃដំណើរការអាជីវកម្ម៖ សកម្មភាពមួយចំនួនអាចនឹងបញ្ចប់ ហើយសកម្មភាពផ្សេងទៀតអាចចាប់ផ្តើម ហើយតម្លៃនៃលក្ខណៈសម្បត្តិដែលជាប់លាប់អាចនឹងផ្លាស់ប្តូរ។ ការបិទសកម្មភាពណាមួយអាចបណ្តាលឱ្យមានសកម្មភាពមួយ ឬច្រើននៃសកម្មភាពខាងក្រោម។ ផ្ទុយទៅវិញ អ្នកទាំងនោះអាចឈប់រង់ចាំព្រឹត្តិការណ៍ផ្សេងទៀត ឬប្រសិនបើពួកគេមិនត្រូវការទិន្នន័យបន្ថែមណាមួយ អាចបញ្ចប់ក្នុងប្រតិបត្តិការដូចគ្នា។ មុនពេលបិទប្រតិបត្តិការ ស្ថានភាពថ្មីនៃដំណើរការអាជីវកម្មត្រូវបានរក្សាទុកក្នុងមូលដ្ឋានទិន្នន័យ ដែលវានឹងរង់ចាំព្រឹត្តិការណ៍ខាងក្រៅបន្ទាប់កើតឡើង។

ទិន្នន័យដំណើរការអាជីវកម្មជាប់លាប់ដែលរក្សាទុកក្នុងមូលដ្ឋានទិន្នន័យទំនាក់ទំនងគឺជាចំណុចងាយស្រួលបំផុតសម្រាប់ការធ្វើសមកាលកម្មដំណើរការ ប្រសិនបើអ្នកប្រើ SELECT FOR UPDATE ។ ប្រសិនបើប្រតិបត្តិការមួយបានគ្រប់គ្រងដើម្បីទទួលបានស្ថានភាពនៃដំណើរការអាជីវកម្មពីមូលដ្ឋានសម្រាប់ការផ្លាស់ប្តូរវានោះ គ្មានប្រតិបត្តិការផ្សេងទៀតដែលស្របគ្នានឹងអាចទទួលបានស្ថានភាពដូចគ្នាសម្រាប់ការផ្លាស់ប្តូរមួយផ្សេងទៀត ហើយបន្ទាប់ពីបញ្ចប់ប្រតិបត្តិការដំបូង ប្រតិបត្តិការទីពីរគឺ ធានាថានឹងទទួលបានស្ថានភាពដែលបានផ្លាស់ប្តូររួចហើយ។

ដោយប្រើសោទុទិដ្ឋិនិយមនៅផ្នែកខាង DBMS យើងបំពេញតម្រូវការចាំបាច់ទាំងអស់។ ទឹកអាស៊ីដនិងរក្សានូវសមត្ថភាពក្នុងការធ្វើមាត្រដ្ឋានកម្មវិធីជាមួយនឹងតក្កវិជ្ជាអាជីវកម្មដោយបង្កើនចំនួនករណីដែលកំពុងដំណើរការ។

ទោះជាយ៉ាងណាក៏ដោយ ការចាក់សោទុទិដ្ឋិនិយមគំរាមកំហែងយើងជាមួយនឹងភាពជាប់គាំង ដែលមានន័យថា SELECT FOR UPDATE គួរតែនៅតែត្រូវបានកំណត់ចំពោះពេលវេលាដែលសមហេតុផលមួយចំនួន ក្នុងករណីដែលការជាប់គាំងកើតឡើងលើករណីធ្ងន់ធ្ងរមួយចំនួននៅក្នុងតក្កវិជ្ជាអាជីវកម្ម។

បញ្ហាមួយទៀតគឺការធ្វើសមកាលកម្មនៃការចាប់ផ្តើមដំណើរការអាជីវកម្ម។ ខណៈពេលដែលមិនមានឧទាហរណ៍នៃដំណើរការអាជីវកម្ម នោះមិនមានរដ្ឋនៅក្នុងមូលដ្ឋានទិន្នន័យ ដូច្នេះវិធីសាស្ត្រដែលបានពិពណ៌នានឹងមិនដំណើរការទេ។ ប្រសិនបើអ្នកត្រូវការធានានូវភាពប្លែកនៃឧទាហរណ៍នៃដំណើរការអាជីវកម្មនៅក្នុងវិសាលភាពជាក់លាក់មួយ នោះអ្នកនឹងត្រូវការប្រភេទវត្ថុធ្វើសមកាលកម្មមួយចំនួនដែលទាក់ទងនឹងថ្នាក់ដំណើរការ និងវិសាលភាពដែលត្រូវគ្នា។ ដើម្បីដោះស្រាយបញ្ហានេះ យើងប្រើយន្តការចាក់សោផ្សេងគ្នាដែលអនុញ្ញាតឱ្យយើងធ្វើការចាក់សោលើធនធានបំពានដែលបានបញ្ជាក់ដោយសោនៅក្នុងទម្រង់ URI តាមរយៈសេវាកម្មខាងក្រៅ។

នៅក្នុងឧទាហរណ៍របស់យើង ដំណើរការអាជីវកម្ម InitialPlayer មានសេចក្តីប្រកាសមួយ។

uniqueConstraint = UniqueConstraints.singleton

ដូច្នេះ កំណត់ហេតុ​មាន​សារ​អំពី​ការ​ទទួល​យក និង​ការ​បញ្ចេញ​សោ​នៃ​សោដែលត្រូវ​គ្នា។ មិនមានសារបែបនេះសម្រាប់ដំណើរការអាជីវកម្មផ្សេងទៀតទេ៖ ដែនកំណត់តែមួយគត់មិនត្រូវបានកំណត់ទេ។

បញ្ហានៃដំណើរការអាជីវកម្មជាមួយរដ្ឋជាប់លាប់

ជួនកាលការមានស្ថានភាពជាប់លាប់មិនត្រឹមតែជួយប៉ុណ្ណោះទេ ប៉ុន្តែថែមទាំងរារាំងដល់ការអភិវឌ្ឍន៍ផងដែរ។
បញ្ហាចាប់ផ្តើមនៅពេលដែលការផ្លាស់ប្តូរត្រូវធ្វើចំពោះតក្កវិជ្ជាអាជីវកម្ម និង/ឬគំរូដំណើរការអាជីវកម្ម។ មិនមែនរាល់ការផ្លាស់ប្តូរបែបនេះគឺត្រូវគ្នាជាមួយនឹងស្ថានភាពចាស់នៃដំណើរការអាជីវកម្មនោះទេ។ ប្រសិនបើមានករណីបន្តផ្ទាល់ជាច្រើននៅក្នុងមូលដ្ឋានទិន្នន័យ នោះការផ្លាស់ប្តូរមិនត្រូវគ្នាអាចបណ្តាលឱ្យមានបញ្ហាជាច្រើនដែលយើងជួបប្រទះជាញឹកញាប់នៅពេលប្រើ jBPM ។

អាស្រ័យលើជម្រៅនៃការផ្លាស់ប្តូរ អ្នកអាចធ្វើសកម្មភាពតាមពីរវិធី៖

1. បង្កើត​ប្រភេទ​ដំណើរការ​អាជីវកម្ម​ថ្មី ដើម្បី​កុំ​ឱ្យ​មាន​ការ​ផ្លាស់​ប្តូរ​ដែល​មិន​ស៊ីគ្នា​នឹង​ប្រភេទ​ចាស់ ហើយ​ប្រើ​វា​ជំនួស​ឱ្យ​ប្រភេទ​ដំណើរការ​ចាស់​ពេល​បើក​ដំណើរការ​ករណី​ថ្មី។ ច្បាប់ចម្លងចាស់នឹងបន្តដំណើរការ "ដូចពីមុន";
2. ផ្លាស់ប្តូរស្ថានភាពបន្តនៃដំណើរការអាជីវកម្ម នៅពេលធ្វើបច្ចុប្បន្នភាពតក្កវិជ្ជាអាជីវកម្ម។

វិធីទីមួយគឺសាមញ្ញជាង ប៉ុន្តែមានដែនកំណត់ និងគុណវិបត្តិរបស់វា ឧទាហរណ៍៖

• ការចម្លងនៃតក្កវិជ្ជាអាជីវកម្មនៅក្នុងគំរូដំណើរការអាជីវកម្មជាច្រើន ការបង្កើនបរិមាណនៃតក្កវិជ្ជាអាជីវកម្ម;
• ជារឿយៗការផ្លាស់ប្តូរភ្លាមៗទៅកាន់តក្កវិជ្ជាអាជីវកម្មថ្មីគឺត្រូវបានទាមទារ (នៅក្នុងលក្ខខណ្ឌនៃកិច្ចការសមាហរណកម្ម - ស្ទើរតែជានិច្ចកាល);
• អ្នក​អភិវឌ្ឍន៍​មិន​ដឹង​នៅ​ចំណុច​ណា​ដែល​ម៉ូដែល​ហួស​សម័យ​អាច​ត្រូវ​បាន​លុប។

នៅក្នុងការអនុវត្ត យើងប្រើវិធីសាស្រ្តទាំងពីរ ប៉ុន្តែបានធ្វើការសម្រេចចិត្តមួយចំនួនដើម្បីធ្វើឱ្យជីវិតរបស់យើងកាន់តែងាយស្រួល៖

• នៅក្នុងមូលដ្ឋានទិន្នន័យ ស្ថានភាពជាប់លាប់នៃដំណើរការអាជីវកម្មត្រូវបានរក្សាទុកក្នុងទម្រង់ដែលអាចអានបាន និងងាយស្រួលដំណើរការ៖ ក្នុងទម្រង់ JSON ។ នេះអនុញ្ញាតឱ្យការធ្វើចំណាកស្រុកត្រូវបានអនុវត្តទាំងនៅក្នុងកម្មវិធី និងខាងក្រៅ។ ជាមធ្យោបាយចុងក្រោយ អ្នកអាចកែវាដោយដៃ (ជាពិសេសមានប្រយោជន៍ក្នុងការអភិវឌ្ឍន៍កំឡុងពេលបំបាត់កំហុស);
• តក្កវិជ្ជាអាជីវកម្មរួមបញ្ចូលមិនប្រើឈ្មោះនៃដំណើរការអាជីវកម្មទេ ដូច្នេះនៅពេលណាមួយវាអាចទៅរួចដើម្បីជំនួសការអនុវត្តមួយនៃដំណើរការដែលចូលរួមជាមួយនឹងឈ្មោះថ្មីមួយ (ឧទាហរណ៍ "InitialPlayerV2") ។ ការចងកើតឡើងតាមរយៈសារនិងឈ្មោះសញ្ញា;
• គំរូដំណើរការមានលេខកំណែ ដែលយើងបង្កើនប្រសិនបើយើងធ្វើការផ្លាស់ប្តូរមិនត្រូវគ្នាចំពោះម៉ូដែលនេះ ហើយលេខនេះត្រូវបានរក្សាទុករួមជាមួយនឹងស្ថានភាពនៃដំណើរការ។
• ស្ថានភាពជាប់លាប់នៃដំណើរការត្រូវបានអានពីមូលដ្ឋានទិន្នន័យជាមុនទៅជាគំរូវត្ថុងាយស្រួល ដែលនីតិវិធីនៃការធ្វើចំណាកស្រុកអាចដំណើរការជាមួយប្រសិនបើលេខកំណែគំរូបានផ្លាស់ប្តូរ។
• នីតិវិធីនៃការធ្វើចំណាកស្រុកត្រូវបានដាក់នៅជាប់នឹងតក្កវិជ្ជាអាជីវកម្ម ហើយត្រូវបានគេហៅថា "ខ្ជិល" សម្រាប់ឧទាហរណ៍នីមួយៗនៃដំណើរការអាជីវកម្មនៅពេលនៃការស្តារឡើងវិញពីមូលដ្ឋានទិន្នន័យ។
• ប្រសិនបើអ្នកត្រូវការធ្វើចំណាកស្រុកស្ថានភាពនៃដំណើរការទាំងអស់ឱ្យបានលឿន និងសមកាលកម្ម ដំណោះស្រាយការធ្វើចំណាកស្រុកមូលដ្ឋានទិន្នន័យបុរាណកាន់តែច្រើនត្រូវបានប្រើ ប៉ុន្តែអ្នកត្រូវធ្វើការជាមួយ JSON ។

តើអ្នកត្រូវការក្របខ័ណ្ឌផ្សេងទៀតសម្រាប់ដំណើរការអាជីវកម្មទេ?

ដំណោះស្រាយដែលបានពិពណ៌នានៅក្នុងអត្ថបទបានអនុញ្ញាតឱ្យយើងធ្វើឱ្យជីវិតរបស់យើងកាន់តែងាយស្រួល ពង្រីកជួរនៃបញ្ហាដែលបានដោះស្រាយនៅកម្រិតអភិវឌ្ឍន៍កម្មវិធី និងធ្វើឱ្យគំនិតនៃការបំបែកតក្កវិជ្ជាអាជីវកម្មទៅជាមីក្រូសេវាកម្មកាន់តែទាក់ទាញ។ ដើម្បីសម្រេចបាននូវកិច្ចការនេះ ការងារជាច្រើនត្រូវបានបញ្ចប់ ក្របខ័ណ្ឌ "ស្រាល" សម្រាប់ដំណើរការអាជីវកម្មត្រូវបានបង្កើតឡើង ក៏ដូចជាធាតុផ្សំនៃសេវាកម្ម ដើម្បីដោះស្រាយបញ្ហាដែលបានកំណត់នៅក្នុងបរិបទនៃបញ្ហាកម្មវិធីជាច្រើន។ យើង​មាន​បំណង​ចង់​ចែក​រំលែក​លទ្ធផល​ទាំង​នេះ និង​ធ្វើ​ឱ្យ​ការ​អភិវឌ្ឍ​សមាសភាគ​ទូទៅ​បើក​ការ​ចូល​ប្រើប្រាស់​ក្រោម​អាជ្ញាប័ណ្ណ​ដោយ​ឥត​គិត​ថ្លៃ។ នេះនឹងតម្រូវឱ្យមានការខិតខំប្រឹងប្រែង និងពេលវេលាមួយចំនួន។ ការយល់ដឹងអំពីតម្រូវការសម្រាប់ដំណោះស្រាយបែបនេះអាចជាការលើកទឹកចិត្តបន្ថែមសម្រាប់ពួកយើង។ នៅក្នុងអត្ថបទដែលបានស្នើឡើង ការយកចិត្តទុកដាក់តិចតួចបំផុតគឺត្រូវបានបង់ទៅលើសមត្ថភាពនៃក្របខ័ណ្ឌខ្លួនឯង ប៉ុន្តែពួកគេមួយចំនួនអាចមើលឃើញពីឧទាហរណ៍ដែលបានបង្ហាញ។ ប្រសិនបើយើងបោះផ្សាយក្របខ័ណ្ឌរបស់យើង អត្ថបទដាច់ដោយឡែកមួយនឹងត្រូវបានឧទ្ទិសដល់វា។ ក្នុងពេលនេះ យើងនឹងដឹងគុណប្រសិនបើអ្នកបញ្ចេញមតិកែលម្អបន្តិចបន្តួចដោយឆ្លើយសំណួរ៖

មានតែអ្នកប្រើប្រាស់ដែលបានចុះឈ្មោះប៉ុណ្ណោះដែលអាចចូលរួមក្នុងការស្ទង់មតិនេះ។ ចូលសូម។

តើអ្នកត្រូវការក្របខ័ណ្ឌផ្សេងទៀតសម្រាប់ដំណើរការអាជីវកម្មទេ?

• 18,8%បាទ ខ្ញុំ​បាន​ស្វែង​រក​អ្វី​មួយ​បែប​នេះ​ជា​យូរ​មក​ហើយ។

• 12,5%ខ្ញុំចាប់អារម្មណ៍ក្នុងការស្វែងយល់បន្ថែមអំពីការអនុវត្តរបស់អ្នក វាអាចមានប្រយោជន៍2

• 6,2%យើងប្រើក្របខ័ណ្ឌដែលមានស្រាប់មួយ ប៉ុន្តែកំពុងគិតអំពីការជំនួស 1

• 18,8%យើងប្រើក្របខណ្ឌដែលមានស្រាប់មួយ អ្វីៗគឺល្អ ៣

• 18,8%យើងគ្រប់គ្រងដោយគ្មានក្របខ័ណ្ឌ ៣

• 25,0%សរសេររបស់អ្នក 4

អ្នកប្រើប្រាស់ 16 នាក់បានបោះឆ្នោត។ អ្នកប្រើប្រាស់ ១៤ នាក់ត្រូវបានហាមឃាត់។

ប្រភព: www.habr.com