BPM শৈলী ইন্টিগ্রেশন

হ্যালো, হাবর!

আমাদের কোম্পানি ইআরপি-শ্রেণির সফ্টওয়্যার সলিউশনের বিকাশে বিশেষীকরণ করে, যেখানে লেনদেনের সিস্টেমের সিংহভাগ ব্যবসায়িক যুক্তি এবং ওয়ার্কফ্লো একটি লা ইডিএমএস দ্বারা দখল করা হয়। আমাদের পণ্যগুলির আধুনিক সংস্করণগুলি JavaEE প্রযুক্তির উপর ভিত্তি করে, কিন্তু আমরা সক্রিয়ভাবে মাইক্রোসার্ভিসেস নিয়ে পরীক্ষা-নিরীক্ষা করছি। এই ধরনের সমাধানগুলির সবচেয়ে সমস্যাযুক্ত ক্ষেত্রগুলির মধ্যে একটি হল সংলগ্ন ডোমেনগুলির সাথে সম্পর্কিত বিভিন্ন সাবসিস্টেমগুলির একীকরণ। আমরা যে স্থাপত্য শৈলী, প্রযুক্তি স্ট্যাক এবং ফ্রেমওয়ার্ক ব্যবহার করি তা নির্বিশেষে ইন্টিগ্রেশন কাজগুলি সর্বদা আমাদের একটি বিশাল মাথাব্যথা দিয়ে থাকে, কিন্তু সম্প্রতি এই ধরনের সমস্যা সমাধানে অগ্রগতি হয়েছে।

আপনার নজরে আনা নিবন্ধে, আমি মনোনীত এলাকায় এনপিও ক্রিস্টা-এর অভিজ্ঞতা এবং স্থাপত্য গবেষণা সম্পর্কে কথা বলব। আমরা একটি অ্যাপ্লিকেশন বিকাশকারীর দৃষ্টিকোণ থেকে একটি ইন্টিগ্রেশন সমস্যার একটি সহজ সমাধানের উদাহরণও বিবেচনা করব এবং এই সরলতার পিছনে কী লুকিয়ে আছে তা খুঁজে বের করব।

দাবিত্যাগ

নিবন্ধে বর্ণিত স্থাপত্য এবং প্রযুক্তিগত সমাধানগুলি নির্দিষ্ট কাজের প্রসঙ্গে ব্যক্তিগত অভিজ্ঞতার ভিত্তিতে আমার দ্বারা অফার করা হয়েছে। এই সমাধানগুলি সর্বজনীন বলে দাবি করে না এবং ব্যবহারের অন্যান্য শর্তে সর্বোত্তম নাও হতে পারে।

BPM এর সাথে কি করার আছে?

এই প্রশ্নের উত্তর দেওয়ার জন্য, আমাদের সমাধানের প্রয়োগকৃত সমস্যার সুনির্দিষ্ট বিষয়ে একটু গভীরভাবে অনুসন্ধান করতে হবে। আমাদের সাধারণ লেনদেন ব্যবস্থার ব্যবসায়িক যুক্তির প্রধান অংশ হল ব্যবহারকারী ইন্টারফেসের মাধ্যমে ডাটাবেসে ডেটা প্রবেশ করানো, ম্যানুয়ালি এবং স্বয়ংক্রিয়ভাবে এই ডেটা পরীক্ষা করা, কিছু কর্মপ্রবাহের মাধ্যমে এটিকে পাস করা, এটিকে অন্য সিস্টেমে প্রকাশ করা / বিশ্লেষণাত্মক ডাটাবেস/আর্কাইভ করা, প্রতিবেদন তৈরি করা। সুতরাং, গ্রাহকদের জন্য সিস্টেমের মূল কাজ হল তাদের অভ্যন্তরীণ ব্যবসায়িক প্রক্রিয়াগুলির অটোমেশন।

সুবিধার জন্য, আমরা একটি সাধারণ কী দ্বারা একত্রিত একটি ডেটা সেটের কিছু বিমূর্ততা হিসাবে যোগাযোগে "ডকুমেন্ট" শব্দটি ব্যবহার করি, যার সাথে একটি নির্দিষ্ট ওয়ার্কফ্লো "সংযুক্ত" হতে পারে।
কিন্তু একীকরণ যুক্তি সম্পর্কে কি? সর্বোপরি, একীকরণের কাজটি সিস্টেমের আর্কিটেকচার দ্বারা উত্পন্ন হয়, যা গ্রাহকের অনুরোধে নয়, সম্পূর্ণ ভিন্ন কারণের প্রভাবের অধীনে অংশে "দেখিত" হয়:

• কনওয়ের আইনের প্রভাবে;
• অন্যান্য পণ্যের জন্য পূর্বে বিকশিত সাবসিস্টেমগুলির পুনঃব্যবহারের ফলস্বরূপ;
• অকার্যকর প্রয়োজনীয়তার উপর ভিত্তি করে স্থপতি দ্বারা সিদ্ধান্ত হিসাবে.

মূল কর্মপ্রবাহের ব্যবসায়িক যুক্তি থেকে ইন্টিগ্রেশন লজিককে আলাদা করার জন্য একটি দুর্দান্ত প্রলোভন রয়েছে যাতে ইন্টিগ্রেশন আর্টিফ্যাক্টগুলির সাথে ব্যবসায়িক যুক্তিকে দূষিত করতে না পারে এবং অ্যাপ্লিকেশন বিকাশকারীকে সিস্টেমের স্থাপত্যের ল্যান্ডস্কেপের বিশেষত্বগুলি খুঁজে বের করতে না পারে৷ এই পদ্ধতির বেশ কয়েকটি সুবিধা রয়েছে, তবে অনুশীলন তার অদক্ষতা দেখায়:

• ইন্টিগ্রেশন সমস্যাগুলি সমাধান করা সাধারণত প্রধান ওয়ার্কফ্লো বাস্তবায়নে সীমিত এক্সটেনশন পয়েন্টগুলির কারণে সিঙ্ক্রোনাস কলের আকারে সহজ বিকল্পগুলিতে স্লাইড করে (নীচে সিঙ্ক্রোনাস ইন্টিগ্রেশনের ত্রুটিগুলি সম্পর্কে আরও);
• ইন্টিগ্রেশন আর্টিফ্যাক্টগুলি এখনও মূল ব্যবসায়িক যুক্তিতে প্রবেশ করে যখন অন্য সাবসিস্টেম থেকে প্রতিক্রিয়া প্রয়োজন হয়;
• অ্যাপ্লিকেশন ডেভেলপার ইন্টিগ্রেশন উপেক্ষা করে এবং ওয়ার্কফ্লো পরিবর্তন করে সহজেই এটি ভাঙতে পারে;
• ব্যবহারকারীর দৃষ্টিকোণ থেকে সিস্টেমটি একক সম্পূর্ণ হওয়া বন্ধ করে দেয়, সাবসিস্টেমগুলির মধ্যে "সীম" লক্ষণীয় হয়ে ওঠে, অপ্রয়োজনীয় ব্যবহারকারীর ক্রিয়াকলাপগুলি প্রদর্শিত হয় যা এক সাবসিস্টেম থেকে অন্য সাবসিস্টেমে ডেটা স্থানান্তর শুরু করে।

আরেকটি পন্থা হল ইন্টিগ্রেশন মিথস্ক্রিয়াকে মূল ব্যবসায়িক যুক্তি এবং কর্মপ্রবাহের অবিচ্ছেদ্য অংশ হিসাবে বিবেচনা করা। অ্যাপ্লিকেশান ডেভেলপারদের দক্ষতার প্রয়োজনীয়তাগুলিকে আকাশচুম্বী থেকে বাঁচাতে, নতুন ইন্টিগ্রেশন মিথস্ক্রিয়া তৈরি করা সহজ এবং স্বাভাবিকভাবে করা উচিত, একটি সমাধান বেছে নেওয়ার জন্য ন্যূনতম বিকল্পগুলির সাথে। এটি দেখতে তার চেয়ে বেশি কঠিন: সরঞ্জামটি ব্যবহারকারীকে এর ব্যবহারের জন্য প্রয়োজনীয় বিভিন্ন বিকল্প সরবরাহ করার জন্য যথেষ্ট শক্তিশালী হতে হবে এবং একই সাথে তাদের পায়ে গুলি করার অনুমতি দেবে না। ইন্টিগ্রেশন টাস্কের প্রেক্ষাপটে একজন প্রকৌশলীকে অবশ্যই উত্তর দিতে হবে এমন অনেক প্রশ্ন আছে, কিন্তু যেগুলি একজন অ্যাপ্লিকেশন ডেভেলপারের তাদের দৈনন্দিন কাজে চিন্তা করা উচিত নয়: লেনদেনের সীমানা, সামঞ্জস্য, পরমাণু, নিরাপত্তা, স্কেলিং, লোড এবং সম্পদ বিতরণ, রাউটিং, মার্শালিং, প্রচার এবং স্যুইচিং প্রসঙ্গ ইত্যাদি। অ্যাপ্লিকেশন বিকাশকারীদের মোটামুটি সহজ সিদ্ধান্ত টেমপ্লেট অফার করা প্রয়োজন, যেখানে এই জাতীয় সমস্ত প্রশ্নের উত্তর ইতিমধ্যেই লুকানো আছে। এই নিদর্শনগুলি যথেষ্ট সুরক্ষিত হওয়া উচিত: ব্যবসায়িক যুক্তিগুলি প্রায়শই পরিবর্তিত হয়, যা ত্রুটিগুলি প্রবর্তনের ঝুঁকি বাড়ায়, ত্রুটির মূল্য মোটামুটি নিম্ন স্তরে থাকা উচিত৷

কিন্তু এখনও, BPM এর সাথে কি করার আছে? কর্মপ্রবাহ বাস্তবায়নের জন্য অনেকগুলি বিকল্প রয়েছে ...
প্রকৃতপক্ষে, ব্যবসায়িক প্রক্রিয়াগুলির আরেকটি বাস্তবায়ন আমাদের সমাধানগুলিতে খুব জনপ্রিয় - রাষ্ট্রীয় রূপান্তর চিত্রের ঘোষণামূলক সেটিং এবং ট্রানজিশনে ব্যবসায়িক যুক্তির সাথে হ্যান্ডলারদের সংযুক্ত করার মাধ্যমে। একই সময়ে, যে রাষ্ট্র ব্যবসায়িক প্রক্রিয়ায় "নথিপত্র" এর বর্তমান অবস্থান নির্ধারণ করে তা নিজেই "নথিপত্র" এর একটি বৈশিষ্ট্য।

প্রকল্পের শুরুতে এই প্রক্রিয়াটি কেমন দেখায়

এই জাতীয় বাস্তবায়নের জনপ্রিয়তা লিনিয়ার ব্যবসায়িক প্রক্রিয়া তৈরির আপেক্ষিক সরলতা এবং গতির কারণে। যাইহোক, সফ্টওয়্যার সিস্টেমগুলি আরও জটিল হয়ে উঠলে, ব্যবসায়িক প্রক্রিয়ার স্বয়ংক্রিয় অংশ বৃদ্ধি পায় এবং আরও জটিল হয়ে ওঠে। পচন, প্রক্রিয়াগুলির অংশগুলির পুনঃব্যবহারের পাশাপাশি কাঁটাচামচ প্রক্রিয়াগুলির প্রয়োজন রয়েছে যাতে প্রতিটি শাখা সমান্তরালভাবে কার্যকর হয়। এই ধরনের অবস্থার অধীনে, টুলটি অসুবিধাজনক হয়ে ওঠে, এবং রাষ্ট্রীয় রূপান্তর চিত্রটি তার তথ্য সামগ্রী হারায় (একীকরণের মিথস্ক্রিয়াগুলি চিত্রে প্রতিফলিত হয় না)।

প্রয়োজনীয়তাগুলি স্পষ্ট করার জন্য বেশ কয়েকটি পুনরাবৃত্তির পরে প্রক্রিয়াটি কেমন দেখায়

এই পরিস্থিতি থেকে বেরিয়ে আসার উপায় ছিল ইঞ্জিনের একীকরণ jBPM সবচেয়ে জটিল ব্যবসায়িক প্রক্রিয়া সহ কিছু পণ্যের মধ্যে। স্বল্পমেয়াদে, এই সমাধানটি কিছু সাফল্য পেয়েছিল: নোটেশনে মোটামুটি তথ্যপূর্ণ এবং আপ-টু-ডেট ডায়াগ্রাম বজায় রেখে জটিল ব্যবসায়িক প্রক্রিয়াগুলি বাস্তবায়ন করা সম্ভব হয়েছিল। BPMN2.

একটি জটিল ব্যবসায়িক প্রক্রিয়ার একটি ছোট অংশ

দীর্ঘমেয়াদে, সমাধানটি প্রত্যাশা পূরণ করেনি: ভিজ্যুয়াল সরঞ্জামগুলির মাধ্যমে ব্যবসায়িক প্রক্রিয়া তৈরির উচ্চ শ্রমের তীব্রতা গ্রহণযোগ্য উত্পাদনশীলতা সূচকগুলি অর্জন করতে দেয়নি এবং টুলটি নিজেই বিকাশকারীদের মধ্যে সবচেয়ে অপছন্দের হয়ে ওঠে। ইঞ্জিনের অভ্যন্তরীণ কাঠামো সম্পর্কেও অভিযোগ ছিল, যার ফলে অনেকগুলি "প্যাচ" এবং "ক্র্যাচ" দেখা গিয়েছিল।

jBPM ব্যবহারের প্রধান ইতিবাচক দিকটি ছিল একটি ব্যবসায়িক প্রক্রিয়ার উদাহরণের জন্য নিজস্ব স্থায়ী অবস্থা থাকার সুবিধা এবং ক্ষতির উপলব্ধি। আমরা সংকেত এবং বার্তাগুলির মাধ্যমে অ্যাসিঙ্ক্রোনাস মিথস্ক্রিয়া ব্যবহার করে বিভিন্ন অ্যাপ্লিকেশনগুলির মধ্যে জটিল ইন্টিগ্রেশন প্রোটোকল বাস্তবায়নের জন্য একটি প্রক্রিয়া পদ্ধতি ব্যবহার করার সম্ভাবনাও দেখেছি। একটি স্থায়ী রাষ্ট্রের উপস্থিতি এটি একটি গুরুত্বপূর্ণ ভূমিকা পালন করে।

উপরের উপর ভিত্তি করে, আমরা উপসংহার করতে পারি: BPM শৈলীতে প্রক্রিয়া পদ্ধতি আমাদেরকে আরও জটিল ব্যবসায়িক প্রক্রিয়াগুলিকে স্বয়ংক্রিয় করার জন্য বিস্তৃত কাজগুলি সমাধান করতে দেয়, এই প্রক্রিয়াগুলির মধ্যে সুসংগতভাবে একীকরণের ক্রিয়াকলাপগুলিকে ফিট করে এবং একটি উপযুক্ত স্বরলিপিতে বাস্তবায়িত প্রক্রিয়াটিকে দৃশ্যমানভাবে প্রদর্শন করার ক্ষমতা ধরে রাখে।

ইন্টিগ্রেশন প্যাটার্ন হিসাবে সিঙ্ক্রোনাস কলের অসুবিধা

সিঙ্ক্রোনাস ইন্টিগ্রেশন সহজতম ব্লকিং কলকে বোঝায়। একটি সাবসিস্টেম সার্ভার সাইড হিসাবে কাজ করে এবং পছন্দসই পদ্ধতির সাথে API প্রকাশ করে। আরেকটি সাবসিস্টেম একটি ক্লায়েন্ট সাইড হিসাবে কাজ করে এবং, সঠিক সময়ে, ফলাফলের প্রত্যাশার সাথে একটি কল করে। সিস্টেমের আর্কিটেকচারের উপর নির্ভর করে, ক্লায়েন্ট এবং সার্ভারের দিকগুলি একই অ্যাপ্লিকেশন এবং প্রক্রিয়াতে বা ভিন্ন ভিন্নগুলিতে হোস্ট করা যেতে পারে। দ্বিতীয় ক্ষেত্রে, আপনাকে RPC এর কিছু বাস্তবায়ন প্রয়োগ করতে হবে এবং পরামিতিগুলির মার্শালিং এবং কলের ফলাফল প্রদান করতে হবে।

এই ধরনের ইন্টিগ্রেশন প্যাটার্নের একটি মোটামুটি বড় ত্রুটি রয়েছে, তবে এটি সরলতার কারণে অনুশীলনে খুব ব্যাপকভাবে ব্যবহৃত হয়। বাস্তবায়নের গতি মোহিত করে এবং আপনাকে "বার্ন" সময়সীমার শর্তে এটিকে বারবার প্রয়োগ করতে বাধ্য করে, প্রযুক্তিগত ঋণে সমাধানটি লিখতে। তবে এটিও ঘটে যে অনভিজ্ঞ বিকাশকারীরা এটি অজ্ঞানভাবে ব্যবহার করে, কেবল নেতিবাচক পরিণতিগুলি উপলব্ধি করে না।

সাবসিস্টেমের সংযোগে সর্বাধিক সুস্পষ্ট বৃদ্ধি ছাড়াও, "প্রসারণ" এবং "প্রসারিত" লেনদেনের সাথে কম স্পষ্ট সমস্যা রয়েছে। প্রকৃতপক্ষে, যদি ব্যবসায়িক যুক্তি কোন পরিবর্তন করে, তাহলে লেনদেন অপরিহার্য, এবং লেনদেন, ঘুরে, এই পরিবর্তনগুলির দ্বারা প্রভাবিত নির্দিষ্ট অ্যাপ্লিকেশন সংস্থানগুলিকে লক করে। অর্থাৎ, যতক্ষণ না একটি সাবসিস্টেম অন্যটির কাছ থেকে প্রতিক্রিয়ার জন্য অপেক্ষা করে, ততক্ষণ এটি লেনদেন সম্পূর্ণ করতে এবং লকগুলি প্রকাশ করতে সক্ষম হবে না। এটি উল্লেখযোগ্যভাবে বিভিন্ন প্রভাবের ঝুঁকি বাড়ায়:

• সিস্টেমের প্রতিক্রিয়াশীলতা হারিয়ে গেছে, ব্যবহারকারীরা অনুরোধের উত্তরের জন্য দীর্ঘ সময় অপেক্ষা করে;
• সার্ভার সাধারণত একটি উপচে পড়া থ্রেড পুলের কারণে ব্যবহারকারীর অনুরোধে সাড়া দেওয়া বন্ধ করে দেয়: বেশিরভাগ থ্রেড লেনদেন দ্বারা দখলকৃত সম্পদের লকের উপর "স্ট্যান্ড";
• অচলাবস্থা দেখা দিতে শুরু করে: তাদের সংঘটনের সম্ভাবনা দৃঢ়ভাবে লেনদেনের সময়কাল, ব্যবসায়িক যুক্তির পরিমাণ এবং লেনদেনের সাথে জড়িত লকগুলির উপর নির্ভর করে;
• লেনদেনের সময়সীমা শেষ হওয়ার ত্রুটি দেখা দেয়;
• সার্ভারটি OutOfMemory-এ "পড়ে যায়" যদি টাস্কের জন্য প্রচুর পরিমাণে ডেটা প্রক্রিয়াকরণ এবং পরিবর্তনের প্রয়োজন হয় এবং সিঙ্ক্রোনাস ইন্টিগ্রেশনের উপস্থিতি প্রক্রিয়াকরণকে "হালকা" লেনদেনে বিভক্ত করা খুব কঠিন করে তোলে।

আর্কিটেকচারাল দৃষ্টিকোণ থেকে, ইন্টিগ্রেশনের সময় ব্লকিং কলের ব্যবহার স্বতন্ত্র সাবসিস্টেমের গুণমান নিয়ন্ত্রণের ক্ষতির দিকে পরিচালিত করে: একটি সাবসিস্টেমের গুণমান লক্ষ্যগুলি অন্য সাবসিস্টেমের গুণমান লক্ষ্য থেকে বিচ্ছিন্নভাবে নিশ্চিত করা অসম্ভব। যদি সাবসিস্টেমগুলি বিভিন্ন দল দ্বারা বিকাশ করা হয় তবে এটি একটি বড় সমস্যা।

বিষয়গুলি আরও আকর্ষণীয় হয়ে ওঠে যদি একীভূত হওয়া সাবসিস্টেমগুলি বিভিন্ন অ্যাপ্লিকেশনে থাকে এবং উভয় দিকেই সিঙ্ক্রোনাস পরিবর্তন করা প্রয়োজন। কিভাবে এই পরিবর্তন লেনদেন করতে?

যদি পৃথক লেনদেনে পরিবর্তন করা হয়, তাহলে শক্তিশালী ব্যতিক্রম পরিচালনা এবং ক্ষতিপূরণ প্রদান করতে হবে, এবং এটি সিঙ্ক্রোনাস ইন্টিগ্রেশনের প্রধান সুবিধা সম্পূর্ণভাবে বাদ দেয় - সরলতা।

বিতরণকৃত লেনদেনগুলিও মনে আসে, কিন্তু আমরা আমাদের সমাধানগুলিতে সেগুলি ব্যবহার করি না: নির্ভরযোগ্যতা নিশ্চিত করা কঠিন।

লেনদেনের সমস্যার সমাধান হিসাবে "সাগা"

মাইক্রোসার্ভিসের ক্রমবর্ধমান জনপ্রিয়তার সাথে সাথে এর চাহিদা বাড়ছে সাগা প্যাটার্ন.

এই প্যাটার্নটি দীর্ঘ লেনদেনের উপরোক্ত সমস্যাগুলি পুরোপুরি সমাধান করে, এবং ব্যবসায়িক যুক্তির দিক থেকে সিস্টেমের অবস্থা পরিচালনার সম্ভাবনাগুলিকেও প্রসারিত করে: একটি অসফল লেনদেনের পরে ক্ষতিপূরণ সিস্টেমটিকে তার আসল অবস্থায় ফিরিয়ে আনতে পারে না, তবে একটি বিকল্প প্রদান করে। ডেটা প্রসেসিং রুট। আপনি যখন প্রক্রিয়াটিকে একটি "ভাল" সমাপ্তিতে আনার চেষ্টা করেন তখন এটি আপনাকে সফলভাবে সম্পন্ন ডেটা প্রক্রিয়াকরণের পদক্ষেপগুলি পুনরাবৃত্তি না করার অনুমতি দেয়।

মজার বিষয় হল, একশিলা পদ্ধতিতে, এই প্যাটার্নটিও প্রাসঙ্গিক যখন এটি ঢিলেঢালাভাবে সংযুক্ত সাবসিস্টেমগুলির একীকরণের ক্ষেত্রে আসে এবং দীর্ঘ লেনদেন এবং সংশ্লিষ্ট সংস্থান লকগুলির কারণে নেতিবাচক প্রভাব রয়েছে।

বিপিএম শৈলীতে আমাদের ব্যবসায়িক প্রক্রিয়াগুলির ক্ষেত্রে, সাগাস বাস্তবায়ন করা খুব সহজ বলে প্রমাণিত হয়েছে: সাগাসের পৃথক পদক্ষেপগুলি ব্যবসায়িক প্রক্রিয়ার মধ্যে কার্যকলাপ হিসাবে সেট করা যেতে পারে এবং ব্যবসায়িক প্রক্রিয়ার স্থায়ী অবস্থা অন্যান্য বিষয়গুলির মধ্যে নির্ধারণ করে। , সাগাসের অভ্যন্তরীণ অবস্থা। অর্থাৎ, আমাদের কোনো অতিরিক্ত সমন্বয় ব্যবস্থার প্রয়োজন নেই। আপনার যা দরকার তা হ'ল একটি বার্তা ব্রোকার যা "অন্তত একবার" একটি পরিবহন হিসাবে গ্যারান্টিগুলির সমর্থন সহ।

তবে এই জাতীয় সমাধানটির নিজস্ব "দাম" রয়েছে:

• ব্যবসায়িক যুক্তি আরও জটিল হয়ে ওঠে: আপনাকে ক্ষতিপূরণের কাজ করতে হবে;
• সম্পূর্ণ সামঞ্জস্য পরিত্যাগ করা প্রয়োজন, যা একচেটিয়া সিস্টেমের জন্য বিশেষভাবে সংবেদনশীল হতে পারে;
• স্থাপত্য একটু বেশি জটিল হয়ে ওঠে, একটি বার্তা দালালের জন্য একটি অতিরিক্ত প্রয়োজন আছে;
• অতিরিক্ত মনিটরিং এবং প্রশাসনিক সরঞ্জামগুলির প্রয়োজন হবে (যদিও সাধারণভাবে এটি আরও ভাল: সিস্টেম পরিষেবার মান বাড়বে)।

মনোলিথিক সিস্টেমের জন্য, "স্যাগস" ব্যবহার করার ন্যায্যতা এতটা সুস্পষ্ট নয়। মাইক্রোসার্ভিসেস এবং অন্যান্য SOA-এর জন্য, যেখানে, সম্ভবত, ইতিমধ্যেই একজন ব্রোকার আছে, এবং প্রকল্পের শুরুতে সম্পূর্ণ সামঞ্জস্যতা বিসর্জন দেওয়া হয়েছিল, এই প্যাটার্ন ব্যবহার করার সুবিধাগুলি উল্লেখযোগ্যভাবে অসুবিধাগুলিকে ছাড়িয়ে যেতে পারে, বিশেষ করে যদি সেখানে একটি সুবিধাজনক API থাকে ব্যবসায়িক যুক্তি স্তর।

মাইক্রোসার্ভিসেসে ব্যবসায়িক যুক্তির এনক্যাপসুলেশন

যখন আমরা মাইক্রোসার্ভিস নিয়ে পরীক্ষা-নিরীক্ষা শুরু করি, তখন একটি যুক্তিসঙ্গত প্রশ্ন উঠেছিল: ডোমেন ডেটা স্থিরতা প্রদান করে এমন পরিষেবার ক্ষেত্রে ডোমেন ব্যবসার যুক্তি কোথায় রাখা যায়?

বিভিন্ন BPMS-এর আর্কিটেকচারের দিকে তাকালে, ব্যবসায়িক যুক্তিকে অধ্যবসায় থেকে আলাদা করা যুক্তিসঙ্গত বলে মনে হতে পারে: প্ল্যাটফর্ম এবং ডোমেন-স্বাধীন মাইক্রোসার্ভিসের একটি স্তর তৈরি করুন যা ডোমেন ব্যবসার লজিক কার্যকর করার জন্য পরিবেশ এবং ধারক তৈরি করে, এবং ডোমেন ডেটা অধ্যবসায়কে একটি পৃথক হিসাবে ব্যবস্থা করে। খুব সহজ এবং লাইটওয়েট মাইক্রোসার্ভিসের স্তর। এই ক্ষেত্রে ব্যবসায়িক প্রক্রিয়াগুলি অধ্যবসায় স্তরের পরিষেবাগুলিকে অর্কেস্ট্রেট করে৷

এই পদ্ধতির একটি খুব বড় প্লাস রয়েছে: আপনি যতটা খুশি প্ল্যাটফর্মের কার্যকারিতা বাড়াতে পারেন এবং শুধুমাত্র প্ল্যাটফর্ম মাইক্রোসার্ভিসের সংশ্লিষ্ট স্তর এটি থেকে "চর্বি পাবে"। যেকোনো ডোমেইন থেকে ব্যবসায়িক প্রক্রিয়াগুলি আপডেট হওয়ার সাথে সাথেই প্ল্যাটফর্মের নতুন কার্যকারিতা ব্যবহার করার সুযোগ পায়।

একটি আরও বিশদ গবেষণা এই পদ্ধতির উল্লেখযোগ্য ত্রুটিগুলি প্রকাশ করেছে:

• একটি প্ল্যাটফর্ম পরিষেবা যা একযোগে অনেক ডোমেনের ব্যবসায়িক যুক্তি সম্পাদন করে ব্যর্থতার একক পয়েন্ট হিসাবে বড় ঝুঁকি বহন করে। ব্যবসায়িক যুক্তিতে ঘন ঘন পরিবর্তনগুলি বাগগুলির ঝুঁকি বাড়ায় যা সিস্টেম-ব্যাপী ব্যর্থতার দিকে পরিচালিত করে;
• কর্মক্ষমতা সমস্যা: ব্যবসায়িক যুক্তি একটি সংকীর্ণ এবং ধীর ইন্টারফেসের মাধ্যমে তার ডেটার সাথে কাজ করে:
  • ডেটা আবার মার্শাল করা হবে এবং নেটওয়ার্ক স্ট্যাকের মাধ্যমে পাম্প করা হবে;
  • পরিষেবার বাহ্যিক API স্তরে অপর্যাপ্ত ক্যোয়ারী প্যারামিটারাইজেশন ক্ষমতার কারণে ডোমেন পরিষেবা প্রায়শই ব্যবসায়িক যুক্তির প্রক্রিয়াকরণের জন্য প্রয়োজনের চেয়ে বেশি ডেটা ফেরত দেয়;
  • ব্যবসায়িক লজিকের বেশ কয়েকটি স্বাধীন টুকরা প্রক্রিয়াকরণের জন্য একই ডেটা বারবার পুনরায় অনুরোধ করতে পারে (আপনি সেশন বিন যোগ করে এই সমস্যাটি প্রশমিত করতে পারেন যা ডেটা ক্যাশে করে, তবে এটি আর্কিটেকচারকে আরও জটিল করে তোলে এবং ডেটা সতেজতা এবং ক্যাশে অবৈধ হওয়ার সমস্যা তৈরি করে);
• লেনদেন সংক্রান্ত সমস্যা:
  • প্ল্যাটফর্ম পরিষেবা দ্বারা সংরক্ষিত অবিরাম অবস্থা সহ ব্যবসায়িক প্রক্রিয়াগুলি ডোমেন ডেটার সাথে অসঙ্গতিপূর্ণ, এবং এই সমস্যাটি সমাধান করার কোন সহজ উপায় নেই;
  • লেনদেনের বাইরে ডোমেন ডেটার লক সরানো: যদি ডোমেন ব্যবসার যুক্তিতে পরিবর্তন করতে হয়, প্রথমে প্রকৃত ডেটার সঠিকতা পরীক্ষা করার পরে, প্রক্রিয়াকৃত ডেটাতে প্রতিযোগিতামূলক পরিবর্তনের সম্ভাবনা বাদ দেওয়া প্রয়োজন। ডেটার বাহ্যিক ব্লকিং সমস্যা সমাধানে সাহায্য করতে পারে, তবে এই জাতীয় সমাধান অতিরিক্ত ঝুঁকি বহন করে এবং সিস্টেমের সামগ্রিক নির্ভরযোগ্যতা হ্রাস করে;
• আপডেট করার সময় অতিরিক্ত জটিলতা: কিছু ক্ষেত্রে, আপনাকে সিঙ্ক্রোনাস বা কঠোর ক্রমানুসারে অধ্যবসায় পরিষেবা এবং ব্যবসায়িক যুক্তি আপডেট করতে হবে।

শেষ পর্যন্ত, আমাকে মূল বিষয়গুলিতে ফিরে যেতে হয়েছিল: ডোমেন ডেটা এবং ডোমেন ব্যবসার যুক্তিকে একটি মাইক্রোসার্ভিসে এনক্যাপসুলেট করুন। এই পদ্ধতিটি সিস্টেমের একটি অবিচ্ছেদ্য উপাদান হিসাবে মাইক্রোসার্ভিসের উপলব্ধি সহজ করে এবং উপরের সমস্যাগুলির জন্ম দেয় না। এটিও বিনামূল্যে নয়:

• ব্যবসায়িক যুক্তি (বিশেষত, ব্যবসায়িক প্রক্রিয়ার অংশ হিসাবে ব্যবহারকারীর কার্যক্রম প্রদানের জন্য) এবং API প্ল্যাটফর্ম পরিষেবাগুলির সাথে মিথস্ক্রিয়া করার জন্য API মানককরণ প্রয়োজন; এপিআই পরিবর্তনের প্রতি আরো সতর্ক মনোযোগ, ফরোয়ার্ড এবং পশ্চাদগামী সামঞ্জস্য প্রয়োজন;
• এই ধরনের প্রতিটি মাইক্রোসার্ভিসের অংশ হিসাবে ব্যবসায়িক যুক্তির কার্যকারিতা নিশ্চিত করার জন্য অতিরিক্ত রানটাইম লাইব্রেরি যোগ করা প্রয়োজন, এবং এটি এই ধরনের লাইব্রেরির জন্য নতুন প্রয়োজনীয়তার জন্ম দেয়: হালকাতা এবং সর্বনিম্ন ট্রানজিটিভ নির্ভরতা;
• ব্যবসায়িক লজিক ডেভেলপারদের লাইব্রেরি সংস্করণগুলির ট্র্যাক রাখতে হবে: যদি একটি মাইক্রোসার্ভিস দীর্ঘ সময়ের জন্য চূড়ান্ত না হয়, তবে সম্ভবত এটিতে লাইব্রেরির একটি পুরানো সংস্করণ থাকবে। এটি একটি নতুন বৈশিষ্ট্য যোগ করার জন্য একটি অপ্রত্যাশিত বাধা হতে পারে এবং সংস্করণগুলির মধ্যে অসামঞ্জস্যপূর্ণ পরিবর্তন থাকলে লাইব্রেরির নতুন সংস্করণে স্থানান্তরিত করার জন্য এই ধরনের পরিষেবার পুরানো ব্যবসায়িক যুক্তির প্রয়োজন হতে পারে৷

এই ধরনের আর্কিটেকচারে প্ল্যাটফর্ম পরিষেবাগুলির একটি স্তরও উপস্থিত থাকে, তবে এই স্তরটি আর ডোমেন ব্যবসার যুক্তি সম্পাদনের জন্য একটি ধারক তৈরি করে না, তবে শুধুমাত্র এর পরিবেশ, সহায়ক "প্ল্যাটফর্ম" ফাংশন প্রদান করে। এই ধরনের একটি স্তর প্রয়োজন শুধুমাত্র ডোমেইন মাইক্রোসার্ভিসের হালকাতা বজায় রাখার জন্য, কিন্তু ব্যবস্থাপনাকে কেন্দ্রীভূত করতেও।

উদাহরণস্বরূপ, ব্যবসায়িক প্রক্রিয়াগুলিতে ব্যবহারকারীর কার্যকলাপগুলি কাজ তৈরি করে। যাইহোক, কাজগুলির সাথে কাজ করার সময়, ব্যবহারকারীকে অবশ্যই সাধারণ তালিকায় সমস্ত ডোমেন থেকে কাজগুলি দেখতে হবে, যার অর্থ হল একটি উপযুক্ত টাস্ক রেজিস্ট্রেশন প্ল্যাটফর্ম পরিষেবা থাকতে হবে, ডোমেন ব্যবসার যুক্তি থেকে মুক্ত। এই প্রসঙ্গে ব্যবসায়িক যুক্তির এনক্যাপসুলেশন রাখা বেশ সমস্যাযুক্ত, এবং এটি এই আর্কিটেকচারের আরেকটি আপস।

একটি অ্যাপ্লিকেশন বিকাশকারীর চোখের মাধ্যমে ব্যবসায়িক প্রক্রিয়াগুলির একীকরণ

ইতিমধ্যে উপরে উল্লিখিত হিসাবে, অ্যাপ্লিকেশন বিকাশকারীকে ভাল বিকাশ উত্পাদনশীলতার উপর নির্ভর করতে সক্ষম হওয়ার জন্য বেশ কয়েকটি অ্যাপ্লিকেশনের মিথস্ক্রিয়া বাস্তবায়নের প্রযুক্তিগত এবং প্রকৌশল বৈশিষ্ট্যগুলি থেকে বিমূর্ত হতে হবে।

আসুন একটি বরং কঠিন একীকরণ সমস্যা সমাধান করার চেষ্টা করি, বিশেষভাবে নিবন্ধটির জন্য উদ্ভাবিত। এটি তিনটি অ্যাপ্লিকেশন জড়িত একটি "গেম" টাস্ক হবে, যেখানে তাদের প্রত্যেকটি কিছু ডোমেন নাম সংজ্ঞায়িত করে: "app1", "app2", "app3"।

প্রতিটি অ্যাপ্লিকেশনের ভিতরে, ব্যবসায়িক প্রক্রিয়াগুলি চালু করা হয় যা ইন্টিগ্রেশন বাসের মাধ্যমে "বল খেলতে" শুরু করে। "বল" নামের বার্তাগুলো বল হিসেবে কাজ করবে।

খেলার নিয়ম:

• প্রথম খেলোয়াড় হল সূচনাকারী। তিনি অন্য খেলোয়াড়দের খেলায় আমন্ত্রণ জানান, খেলা শুরু করেন এবং যে কোনো সময় এটি শেষ করতে পারেন;
• অন্যান্য খেলোয়াড়রা খেলায় তাদের অংশগ্রহণ ঘোষণা করে, একে অপরের সাথে এবং প্রথম খেলোয়াড়ের সাথে "পরিচিত হন";
• বল পাওয়ার পর, খেলোয়াড় অন্য অংশগ্রহণকারী খেলোয়াড়কে বেছে নেয় এবং তার কাছে বল পাস করে। পাসের মোট সংখ্যা গণনা করা হয়;
• প্রতিটি খেলোয়াড়ের "শক্তি" থাকে, যা সেই খেলোয়াড়ের বলের প্রতিটি পাসের সাথে হ্রাস পায়। যখন শক্তি ফুরিয়ে যায়, খেলোয়াড়কে খেলা থেকে বাদ দেওয়া হয়, তাদের অবসর ঘোষণা করে;
• যদি খেলোয়াড়কে একা ছেড়ে দেওয়া হয়, তিনি অবিলম্বে তার প্রস্থান ঘোষণা করেন;
• যখন সমস্ত খেলোয়াড়কে বাদ দেওয়া হয়, প্রথম খেলোয়াড় খেলার সমাপ্তি ঘোষণা করে। যদি তিনি আগে গেমটি ছেড়ে যান, তবে এটি সম্পূর্ণ করার জন্য গেমটি অনুসরণ করতে হবে।

এই সমস্যাটি সমাধান করার জন্য, আমি ব্যবসায়িক প্রক্রিয়াগুলির জন্য আমাদের ডিএসএল ব্যবহার করব, যা আপনাকে ন্যূনতম একটি বয়লারপ্লেট সহ কোটলিনে সংক্ষিপ্তভাবে যুক্তি বর্ণনা করতে দেয়।

অ্যাপ1 অ্যাপ্লিকেশনে, প্রথম খেলোয়াড়ের ব্যবসায়িক প্রক্রিয়া (তিনিও গেমের সূচনাকারী) কাজ করবে:

ক্লাস ইনিশিয়াল প্লেয়ার

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

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

class PlayersList : ArrayList<PlayerInfo>()

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

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

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

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

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

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

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

ব্যবসায়িক যুক্তি সম্পাদনের পাশাপাশি, উপরের কোডটি একটি ব্যবসায়িক প্রক্রিয়ার একটি অবজেক্ট মডেল তৈরি করতে পারে যা একটি ডায়াগ্রাম হিসাবে কল্পনা করা যেতে পারে। আমরা এখনও ভিজ্যুয়ালাইজারটি প্রয়োগ করিনি, তাই আমাদের কিছু সময় অঙ্কন করতে হয়েছিল (এখানে আমি উপরের কোডের সাথে ডায়াগ্রামের সামঞ্জস্যতা উন্নত করতে গেটগুলির ব্যবহার সম্পর্কিত BPMN স্বরলিপিটি সামান্য সরলীকৃত করেছি):

app2 অন্য খেলোয়াড়ের ব্যবসা প্রক্রিয়া অন্তর্ভুক্ত করবে:

ক্লাস র্যান্ডম প্লেয়ার

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;
• ইনকামিং মেসেজ এবং ইভেন্টগুলির হ্যান্ডলারদের অবশ্যই ব্যবসায়িক প্রক্রিয়ার অবস্থা পরিবর্তনের লেনদেনের সাথে কাজ করতে হবে: যদি এই ধরনের লেনদেন ফিরিয়ে দেওয়া হয়, তাহলে বার্তার প্রাপ্তিও বাতিল করতে হবে;
• ত্রুটির কারণে বিতরণ করা যায়নি এমন বার্তাগুলি একটি পৃথক দোকানে সংরক্ষণ করা উচিত ডিএলকিউ (ডেড লেটার কিউ)। এটি করার জন্য, আমরা একটি পৃথক প্ল্যাটফর্ম মাইক্রোসার্ভিস তৈরি করেছি যা এই ধরনের বার্তাগুলিকে এর স্টোরেজে সঞ্চয় করে, এগুলিকে বৈশিষ্ট্যগুলির দ্বারা সূচী করে (দ্রুত গ্রুপিং এবং অনুসন্ধানের জন্য), এবং দেখার জন্য, গন্তব্য ঠিকানায় পুনরায় পাঠানো এবং বার্তাগুলি মুছে ফেলার জন্য API প্রকাশ করে৷ সিস্টেম অ্যাডমিনিস্ট্রেটররা তাদের ওয়েব ইন্টারফেসের মাধ্যমে এই পরিষেবাটির সাথে কাজ করতে পারে;
• ব্রোকার সেটিংসে, ডিএলকিউতে বার্তা আসার সম্ভাবনা কমাতে আপনাকে ডেলিভারির পুনঃপ্রচারের সংখ্যা এবং ডেলিভারির মধ্যে বিলম্ব সামঞ্জস্য করতে হবে (অনুকূল পরামিতিগুলি গণনা করা প্রায় অসম্ভব, তবে আপনি অভিজ্ঞতার সাথে কাজ করতে পারেন এবং সেগুলি সামঞ্জস্য করতে পারেন অপারেশন);
• DLQ স্টোরটি ক্রমাগত নিরীক্ষণ করা উচিত, এবং মনিটরিং সিস্টেমটি সিস্টেম অ্যাডমিনিস্ট্রেটরদেরকে অবহিত করা উচিত যাতে তারা অবিলম্বিত বার্তাগুলি ঘটলে যত তাড়াতাড়ি সম্ভব প্রতিক্রিয়া জানাতে পারে। এটি একটি ব্যর্থতা বা ব্যবসায়িক যুক্তি ত্রুটির "ক্ষতি অঞ্চল" হ্রাস করবে;
• ইন্টিগ্রেশন বাসটি অবশ্যই অ্যাপ্লিকেশনগুলির অস্থায়ী অনুপস্থিতিতে সংবেদনশীল হতে হবে: বিষয়ের সদস্যতা অবশ্যই টেকসই হতে হবে এবং অ্যাপ্লিকেশনটির ডোমেন নামটি অবশ্যই অনন্য হতে হবে যাতে অন্য কেউ আবেদনের অনুপস্থিতির সময় সারি থেকে এর বার্তা প্রক্রিয়া করার চেষ্টা না করে।

ব্যবসায়িক যুক্তির থ্রেড নিরাপত্তা নিশ্চিত করা

একটি ব্যবসায়িক প্রক্রিয়ার একই উদাহরণ একবারে বেশ কয়েকটি বার্তা এবং ইভেন্ট পেতে পারে, যার প্রক্রিয়াকরণ সমান্তরালভাবে শুরু হবে। একই সময়ে, একটি অ্যাপ্লিকেশন বিকাশকারীর জন্য, সবকিছু সহজ এবং থ্রেড-নিরাপদ হওয়া উচিত।

প্রক্রিয়া ব্যবসায়িক যুক্তি প্রতিটি বাহ্যিক ইভেন্টকে প্রক্রিয়া করে যা এই ব্যবসার প্রক্রিয়াটিকে পৃথকভাবে প্রভাবিত করে। এই ঘটনাগুলি হতে পারে:

• একটি ব্যবসায়িক প্রক্রিয়া উদাহরণ চালু করা;
• একটি ব্যবসায়িক প্রক্রিয়ার মধ্যে একটি কার্যকলাপ সম্পর্কিত একটি ব্যবহারকারীর কর্ম;
• একটি বার্তা বা সংকেতের প্রাপ্তি যেখানে একটি ব্যবসায়িক প্রক্রিয়া উদাহরণ সাবস্ক্রাইব করা হয়েছে;
• ব্যবসায়িক প্রক্রিয়া দৃষ্টান্ত দ্বারা সেট করা টাইমারের মেয়াদ শেষ;
• API এর মাধ্যমে ক্রিয়া নিয়ন্ত্রণ করুন (যেমন প্রক্রিয়া বাতিল)।

এই জাতীয় প্রতিটি ঘটনা একটি ব্যবসায়িক প্রক্রিয়ার উদাহরণের অবস্থা পরিবর্তন করতে পারে: কিছু ক্রিয়াকলাপ শেষ হতে পারে এবং অন্যগুলি শুরু হতে পারে, স্থায়ী বৈশিষ্ট্যের মানগুলি পরিবর্তিত হতে পারে। কোনো কার্যকলাপ বন্ধ করার ফলে নিম্নলিখিত এক বা একাধিক কার্যকলাপ সক্রিয় হতে পারে। তারা, পরিবর্তে, অন্যান্য ইভেন্টের জন্য অপেক্ষা করা বন্ধ করতে পারে, অথবা, যদি তাদের কোন অতিরিক্ত ডেটার প্রয়োজন না হয়, তারা একই লেনদেনে সম্পূর্ণ করতে পারে। লেনদেন বন্ধ করার আগে, ব্যবসায়িক প্রক্রিয়ার নতুন অবস্থা ডাটাবেসে সংরক্ষণ করা হয়, যেখানে এটি পরবর্তী বাহ্যিক ইভেন্টের জন্য অপেক্ষা করবে।

একটি রিলেশনাল ডাটাবেসে সংরক্ষিত ক্রমাগত ব্যবসায়িক প্রক্রিয়া ডেটা একটি খুব সুবিধাজনক প্রক্রিয়াকরণ সিঙ্ক্রোনাইজেশন পয়েন্ট যখন আপডেটের জন্য নির্বাচন করুন। যদি একটি লেনদেন এটি পরিবর্তন করার জন্য ডাটাবেস থেকে ব্যবসায়িক প্রক্রিয়ার অবস্থা পেতে পরিচালিত হয়, তবে সমান্তরালভাবে অন্য কোনও লেনদেন অন্য পরিবর্তনের জন্য একই অবস্থা পেতে সক্ষম হবে না এবং প্রথম লেনদেনটি শেষ হওয়ার পরে, দ্বিতীয়টি হল ইতিমধ্যে পরিবর্তিত অবস্থা পাওয়ার নিশ্চয়তা।

ডিবিএমএস সাইডে হতাশাবাদী লক ব্যবহার করে, আমরা সমস্ত প্রয়োজনীয় প্রয়োজনীয়তা পূরণ করি ACID, এবং চলমান দৃষ্টান্তের সংখ্যা বাড়িয়ে ব্যবসায়িক যুক্তি সহ অ্যাপ্লিকেশন স্কেল করার ক্ষমতাও ধরে রাখে।

যাইহোক, হতাশাবাদী লকগুলি আমাদের অচলাবস্থার হুমকি দেয়, যার মানে হল যে ব্যবসায়িক যুক্তিতে কিছু গুরুতর ক্ষেত্রে অচলাবস্থার ক্ষেত্রে আপডেটের জন্য নির্বাচন করুন এখনও কিছু যুক্তিসঙ্গত সময়সীমার মধ্যে সীমাবদ্ধ হওয়া উচিত।

আরেকটি সমস্যা হল ব্যবসায়িক প্রক্রিয়া শুরু করার সিঙ্ক্রোনাইজেশন। যদিও কোনও ব্যবসায়িক প্রক্রিয়ার উদাহরণ নেই, ডাটাবেসে কোনও অবস্থা নেই, তাই বর্ণিত পদ্ধতিটি কাজ করবে না। আপনি যদি একটি নির্দিষ্ট সুযোগে একটি ব্যবসায়িক প্রক্রিয়া উদাহরণের স্বতন্ত্রতা নিশ্চিত করতে চান, তাহলে আপনার প্রক্রিয়া শ্রেণী এবং সংশ্লিষ্ট সুযোগের সাথে যুক্ত কিছু ধরণের সিঙ্ক্রোনাইজেশন অবজেক্ট প্রয়োজন। এই সমস্যাটি সমাধান করার জন্য, আমরা একটি ভিন্ন লকিং প্রক্রিয়া ব্যবহার করি যা আমাদেরকে একটি বহিরাগত পরিষেবার মাধ্যমে URI বিন্যাসে একটি কী দ্বারা নির্দিষ্ট করা একটি নির্বিচারী সংস্থানে একটি লক নিতে দেয়৷

আমাদের উদাহরণে, InitialPlayer ব্যবসায়িক প্রক্রিয়ায় একটি ঘোষণা রয়েছে

uniqueConstraint = UniqueConstraints.singleton

অতএব, লগটিতে সংশ্লিষ্ট কীটির লক নেওয়া এবং ছেড়ে দেওয়ার বিষয়ে বার্তা রয়েছে। অন্যান্য ব্যবসায়িক প্রক্রিয়ার জন্য এই ধরনের কোনো বার্তা নেই: অনন্য সীমাবদ্ধতা সেট করা নেই।

ক্রমাগত রাষ্ট্র সঙ্গে ব্যবসা প্রক্রিয়া সমস্যা

কখনও কখনও একটি অবিচল অবস্থা শুধুমাত্র সাহায্য করে না, কিন্তু সত্যিই উন্নয়ন বাধা দেয়.
যখন আপনাকে ব্যবসায়িক যুক্তি এবং/অথবা ব্যবসায়িক প্রক্রিয়া মডেলে পরিবর্তন করতে হবে তখন সমস্যা শুরু হয়। ব্যবসায়িক প্রক্রিয়াগুলির পুরানো অবস্থার সাথে সামঞ্জস্যপূর্ণ এমন কোনো পরিবর্তন পাওয়া যায় না। যদি ডাটাবেসে অনেকগুলি "লাইভ" দৃষ্টান্ত থাকে, তাহলে বেমানান পরিবর্তনগুলি অনেক সমস্যার কারণ হতে পারে, যা আমরা প্রায়শই jBPM ব্যবহার করার সময় সম্মুখীন হই।

পরিবর্তনের গভীরতার উপর নির্ভর করে, আপনি দুটি উপায়ে কাজ করতে পারেন:

1. একটি নতুন ব্যবসায়িক প্রক্রিয়ার ধরন তৈরি করুন যাতে পুরানোটির সাথে বেমানান পরিবর্তন না হয় এবং নতুন দৃষ্টান্ত শুরু করার সময় পুরানোটির পরিবর্তে এটি ব্যবহার করুন। পুরানো দৃষ্টান্ত "পুরাতন উপায়" কাজ চালিয়ে যাবে;
2. ব্যবসায়িক যুক্তি আপডেট করার সময় ব্যবসায়িক প্রক্রিয়াগুলির স্থায়ী অবস্থা স্থানান্তর করুন।

প্রথম উপায়টি সহজ, তবে এর সীমাবদ্ধতা এবং অসুবিধা রয়েছে, উদাহরণস্বরূপ:

• অনেক ব্যবসায়িক প্রক্রিয়া মডেলে ব্যবসায়িক যুক্তির নকল, ব্যবসায়িক যুক্তির পরিমাণ বৃদ্ধি;
• প্রায়শই একটি নতুন ব্যবসায়িক যুক্তিতে একটি তাত্ক্ষণিক রূপান্তর প্রয়োজন হয় (প্রায় সর্বদা ইন্টিগ্রেশন কাজের ক্ষেত্রে);
• বিকাশকারী জানেন না কোন সময়ে অপ্রচলিত মডেলগুলি মুছে ফেলা সম্ভব।

অনুশীলনে, আমরা উভয় পন্থা ব্যবহার করি, কিন্তু আমাদের জীবনকে সহজ করার জন্য অনেকগুলি সিদ্ধান্ত নিয়েছি:

• ডাটাবেসে, ব্যবসায়িক প্রক্রিয়ার স্থায়ী অবস্থা একটি সহজে পঠনযোগ্য এবং সহজে প্রক্রিয়াকৃত আকারে সংরক্ষণ করা হয়: একটি JSON ফর্ম্যাট স্ট্রিং-এ। এটি আপনাকে অ্যাপ্লিকেশনের ভিতরে এবং বাইরে উভয় স্থানান্তর করতে দেয়। চরম ক্ষেত্রে, আপনি এটিকে হ্যান্ডেলগুলির সাথেও পরিবর্তন করতে পারেন (বিশেষত ডিবাগিংয়ের সময় বিকাশে দরকারী);
• ইন্টিগ্রেশন বিজনেস লজিক ব্যবসায়িক প্রক্রিয়ার নাম ব্যবহার করে না, যাতে যে কোনো সময়ে অংশগ্রহণকারী প্রসেসের বাস্তবায়নকে একটি নতুন নাম দিয়ে প্রতিস্থাপন করা সম্ভব হয় (উদাহরণস্বরূপ, "InitialPlayerV2")। বাঁধাই বার্তা এবং সংকেত নামের মাধ্যমে ঘটে;
• প্রসেস মডেলের একটি ভার্সন নম্বর আছে, যা আমরা বৃদ্ধি করি যদি আমরা এই মডেলে বেমানান পরিবর্তন করি, এবং এই নম্বরটি প্রসেস ইনস্ট্যান্সের অবস্থার সাথে সংরক্ষিত থাকে;
• প্রক্রিয়াটির স্থায়ী অবস্থা বেস থেকে প্রথমে একটি সুবিধাজনক বস্তুর মডেলে পড়া হয় যে মডেলটির সংস্করণ নম্বর পরিবর্তিত হলে মাইগ্রেশন পদ্ধতিটি কাজ করতে পারে;
• মাইগ্রেশন পদ্ধতিটি ব্যবসায়িক যুক্তির পাশে রাখা হয় এবং ডাটাবেস থেকে পুনরুদ্ধারের সময় ব্যবসায়িক প্রক্রিয়ার প্রতিটি উদাহরণের জন্য "অলস" বলা হয়;
• আপনি যদি দ্রুত এবং সিঙ্ক্রোনাসভাবে সমস্ত প্রক্রিয়া দৃষ্টান্তের অবস্থা স্থানান্তর করতে চান তবে আরও ক্লাসিক ডাটাবেস মাইগ্রেশন সমাধান ব্যবহার করা হয়, তবে আপনাকে সেখানে JSON এর সাথে কাজ করতে হবে।

ব্যবসায়িক প্রক্রিয়ার জন্য আমার কি অন্য কাঠামো দরকার?

নিবন্ধে বর্ণিত সমাধানগুলি আমাদের জীবনকে উল্লেখযোগ্যভাবে সরল করতে, অ্যাপ্লিকেশন ডেভেলপমেন্ট স্তরে সমাধান করা সমস্যাগুলির পরিসরকে প্রসারিত করতে এবং মাইক্রোসার্ভিসে ব্যবসায়িক যুক্তিকে আলাদা করার ধারণাটিকে আরও আকর্ষণীয় করে তুলতে দেয়। এর জন্য, প্রচুর কাজ করা হয়েছে, ব্যবসায়িক প্রক্রিয়াগুলির জন্য একটি খুব "হালকা" কাঠামো তৈরি করা হয়েছে, সেইসাথে প্রয়োগ করা কাজের বিস্তৃত পরিসরে চিহ্নিত সমস্যাগুলি সমাধানের জন্য পরিষেবা উপাদানগুলি তৈরি করা হয়েছে। আমাদের এই ফলাফলগুলি ভাগ করে নেওয়ার ইচ্ছা আছে, সাধারণ উপাদানগুলির বিকাশকে একটি বিনামূল্যের লাইসেন্সের অধীনে উন্মুক্ত অ্যাক্সেসে আনতে। এটি কিছু প্রচেষ্টা এবং সময় প্রয়োজন হবে. এই ধরনের সমাধানের চাহিদা বোঝা আমাদের জন্য একটি অতিরিক্ত উদ্দীপক হতে পারে। প্রস্তাবিত নিবন্ধে, ফ্রেমওয়ার্কের নিজস্ব ক্ষমতাগুলির দিকে খুব কম মনোযোগ দেওয়া হয়, তবে তাদের মধ্যে কয়েকটি উপস্থাপিত উদাহরণ থেকে দৃশ্যমান। তবুও যদি আমরা আমাদের কাঠামো প্রকাশ করি, তবে একটি পৃথক নিবন্ধ এটির জন্য উত্সর্গীকৃত হবে। এই সময়ের মধ্যে, আপনি প্রশ্নের উত্তর দিয়ে একটু প্রতিক্রিয়া জানালে আমরা কৃতজ্ঞ থাকব:

শুধুমাত্র নিবন্ধিত ব্যবহারকারীরা জরিপে অংশগ্রহণ করতে পারবেন। সাইন ইন করুনকরুন।

ব্যবসায়িক প্রক্রিয়ার জন্য আমার কি অন্য কাঠামো দরকার?

• 18,8%হ্যাঁ, আমি অনেক দিন ধরে এরকম কিছু খুঁজছি।

• 12,5%এটি আপনার বাস্তবায়ন সম্পর্কে আরো জানতে আকর্ষণীয়, এটি দরকারী হতে পারে2

• 6,2%আমরা বিদ্যমান ফ্রেমওয়ার্কগুলির মধ্যে একটি ব্যবহার করি, কিন্তু আমরা এটি 1 প্রতিস্থাপন করার কথা ভাবছি

• 18,8%আমরা বিদ্যমান ফ্রেমওয়ার্কগুলির একটি ব্যবহার করি, সবকিছুই স্যুট3

• 18,8%ফ্রেমওয়ার্ক ছাড়াই মোকাবিলা করা3

• 25,0%আপনার নিজের লিখুন4

16 জন ব্যবহারকারী ভোট দিয়েছেন। 7 জন ব্যবহারকারী বিরত ছিলেন।

উত্স: www.habr.com