इस श्रृंखला के पहले भाग ने डेटाबेस में किसी भी इकाई के जीवनचक्र के प्रबंधन के लिए कुछ बुनियादी कदम पेश किए। हमारा दूसरा और अंतिम भाग आपको दिखाएगा कि अतिरिक्त कॉन्फ़िगरेशन तालिकाओं का उपयोग करके वास्तविक वर्कफ़्लो को कैसे परिभाषित किया जाए। यह वह जगह है जहां उपयोगकर्ता को हर कदम पर स्वीकार्य विकल्पों के साथ प्रस्तुत किया जाता है। हम सामग्री के बिल संरचना में 'असेंबली' और 'सब-असेंबली' के सख्त पुन:उपयोग के आसपास काम करने के लिए एक तकनीक का भी प्रदर्शन करेंगे।
विकल्पों को परिभाषित करना
भाग 1 ने मुख्य कार्यप्रवाह तालिकाओं का परिचय दिया और इन्हें आसानी से आपके डेटाबेस में कैसे शामिल किया जा सकता है। अब हमें जो कुछ चाहिए वह उपयोगकर्ता को अगली तार्किक स्थिति का चयन करने में मार्गदर्शन करने के लिए है - कुछ ऐसा जो एक तार्किक कार्यप्रवाह को परिभाषित करता है ।
नीचे दिया गया आरेख वर्कफ़्लो डेटाबेस मॉडल के सभी घटकों को परिभाषित करता है:
दो कॉन्फ़िगरेशन टेबल, workflow_state_option और workflow_state_context , मॉडल में जोड़ा गया है। हम विकल्प तालिका से शुरू करेंगे, जो स्वीकार्य अगले राज्यों . को परिभाषित करती है . एक बार इसके कार्य को समझ लेने के बाद, हम संदर्भ तालिका पर लौटेंगे और इसकी भूमिका की व्याख्या करेंगे।
अगले राज्यों की अनुमति है
अनुसरण करने वाली तालिकाएँ कुछ हद तक हमारी कॉन्फ़िगरेशन तालिकाओं में SQL दृश्य की तरह हैं। यहां हमने टेबल जॉइन को छिपाया है और हम सिर्फ type_keys के कॉम्बिनेशन को देख रहे हैं। . तो आइए प्रत्येक STATE.OUTCOME . पर विचार करें संयोजन और परिभाषित करें विकल्प उपयोगकर्ता के लिए उपलब्ध:
| STATE.OUTCOME युग्म (राज्य पदानुक्रम से) | राज्य संदर्भ | बच्चा अक्षम | <थ>विकल्प 1विकल्प 2 | |
|---|---|---|---|---|
| APPLICATION_RECEIVED .स्वीकृत | STANDARD_JOB _APPLICATION | N | APPLICATION_REVIEW | |
| APPLICATION_RECEIVED .ReJECTED | STANDARD_JOB _APPLICATION | N | APPLICATION_CLOSED .NOT_HIRED | |
| APPLICATION_REVIEW .PASSED | STANDARD_JOB _APPLICATION | N | INVITED_TO_INTERVIEW | |
| APPLICATION_REVIEW .FAILED | STANDARD_JOB _APPLICATION | N | APPLICATION_CLOSED .NOT_HIRED | |
| INVITED_TO_INTERVIEW .स्वीकार किया | STANDARD_JOB _APPLICATION | N | साक्षात्कार | |
| INVITED_TO_INTERVIEW .DECLINED | STANDARD_JOB _APPLICATION | N | APPLICATION_CLOSED .NOT_HIRED | |
| साक्षात्कार . उत्तीर्ण | STANDARD_JOB _APPLICATION | N | MAKE_OFFER | SEEK_REFERENCES |
| साक्षात्कार.विफल | STANDARD_JOB _APPLICATION | N | APPLICATION_CLOSED | |
| साक्षात्कार .CANDIDATE_CANCELLED | STANDARD_JOB _APPLICATION | N | APPLICATION_CLOSED | INVITED_TO_INTERVIEW |
| साक्षात्कार .NO_SHOW | STANDARD_JOB _APPLICATION | N | APPLICATION_CLOSED | |
| MAKE_OFFER.ACCEPTED | STANDARD_JOB _APPLICATION | N | SEEK_REFERENCES | |
| MAKE_OFFER.DECLINED | STANDARD_JOB _APPLICATION | N | APPLICATION_CLOSED | |
| SEEK_REFERNCES .PASSED | STANDARD_JOB _APPLICATION | N | APPLICATION_CLOSED .HIRED | |
| SEEK_REFERENCES .FAILED | STANDARD_JOB _APPLICATION | N | APPLICATION_CLOSED | |
| APPLICATION_CLOSED .HIRED | STANDARD_JOB _APPLICATION | N | ||
| APPLICATION_CLOSED .NOT_HIRED | STANDARD_JOB _APPLICATION | N |
चूंकि हम अभी के लिए संदर्भ को अनदेखा कर रहे हैं, राज्य संदर्भ और बच्चा अक्षम है? धूसर हो गए हैं। मैंने संक्षिप्तता के लिए इस उदाहरण में विकल्पों की संख्या को दो तक सीमित कर दिया है, हालांकि व्यवहार में इसकी कोई सीमा नहीं है।
तो यह कैसे काम करता है?
कल्पना कीजिए कि साक्षात्कार अभी आयोजित किया गया है और साक्षात्कारकर्ता परिणाम रिकॉर्ड कर रहा है। अद्यतन की जा रही अंतर्निहित तालिका managed_entity_state है . दो तार्किक परिणाम हैं:PASSED और FAILED। तो वर्तमान managed_entity_state चयनित परिणाम के साथ अपडेट किया जाता है (wf_state_type_outcome_id ) उदाहरण मॉडल में, साक्षात्कारकर्ता साक्षात्कार के बारे में कुछ नोट्स भी शामिल कर सकता है।
यदि साक्षात्कारकर्ता PASSED का चयन करता है, तो उन्हें दो और विकल्प प्रस्तुत किए जाते हैं:MAKE_OFFER और SEEK_REFERENCES। ये हैं अगले राज्य हमारे कार्यप्रवाह में। वे go to . के समान हैं प्रोग्रामिंग में बयान। किसी भी विकल्प के लिए, managed_entity_state . में एक नई पंक्ति डाली जाती है , कार्यप्रवाह प्रक्रिया में कार्य आवेदन को अगली स्थिति में ले जाना। उपयोगकर्ता इसके लिए एक due_date . दर्ज करके एक समय सीमा निर्धारित कर सकता है ।
दूसरी ओर, यदि साक्षात्कारकर्ता FAILED का चयन करता है, तो केवल एक विकल्प है:APPLICATION_CLOSED। तो एक नया managed_entity_state पंक्ति को APPLICATION_CLOSED स्थिति (wf_state_type_state_id) का उपयोग करके सम्मिलित किया गया है )।
आप देखेंगे कि APPLICATION_CLOSED स्थिति के लिए कोई विकल्प उपलब्ध नहीं है। यह दर्शाता है कि कार्यप्रवाह प्रक्रिया का अंत आ गया है।
संदर्भ तालिका
आइए तकनीकी नौकरी आवेदन प्रक्रिया के कॉन्फ़िगरेशन को देखें कि संदर्भ तालिका . की क्या भूमिका है नाटक:
| STATE.OUTCOME युग्म (राज्य पदानुक्रम से) | राज्य संदर्भ | बच्चा अक्षम | <थ>विकल्प 1विकल्प 2 | |
|---|---|---|---|---|
| APPLICATION_RECEIVED .स्वीकृत | TECHNICAL_JOB _APPLICATION | N | आवेदन _समीक्षा | |
| APPLICATION_RECEIVED .ReJECTED | TECHNICAL_JOB _APPLICATION | N | आवेदन _CLOSED | |
| APPLICATION_REVIEW .PASSED | TECHNICAL_JOB _APPLICATION | N | INVITED_TO _INTERVIEW | |
| APPLICATION_REVIEW .FAILED | TECHNICAL_JOB _APPLICATION | N | आवेदन _CLOSED | |
| INVITED_TO_INTERVIEW .स्वीकार किया | TECHNICAL_JOB _APPLICATION | N | TEST_APTITUDE | |
| INVITED_TO_INTERVIEW .DECLINED | TECHNICAL_JOB _APPLICATION | N | आवेदन _CLOSED | |
| TEST_APTITUDE .PASSED | TECHNICAL_JOB _APPLICATION | N | साक्षात्कार | खोज _संदर्भ |
| TEST_APTITUDE .FAILED | TECHNICAL_JOB _APPLICATION | N | आवेदन _CLOSED | |
| साक्षात्कार . उत्तीर्ण | TECHNICAL_JOB _APPLICATION | N | MAKE_OFFER | खोज _संदर्भ |
| साक्षात्कार .विफल | TECHNICAL_JOB _APPLICATION | N | आवेदन _CLOSED | |
| साक्षात्कार .CANDIDATE_CANCELLED | TECHNICAL_JOB _APPLICATION | Y | - | - |
| साक्षात्कार .NO_SHOW | TECHNICAL_JOB _APPLICATION | N | आवेदन _CLOSED | INVITED_TO _INTERVIEW |
| MAKE_OFFER .स्वीकार करें | TECHNICAL_JOB _APPLICATION | N | खोज _संदर्भ | |
| MAKE_OFFER .DECLINED | TECHNICAL_JOB _APPLICATION | N | आवेदन _CLOSED | |
| SEEK_REFERNCES .PASSED | TECHNICAL_JOB _APPLICATION | N | आवेदन _CLOSED.SUCCESS | |
| SEEK_REFERENCES .FAILED | TECHNICAL_JOB _APPLICATION | N | आवेदन _CLOSED | |
| APPLICATION_CLOSED .HIRED | TECHNICAL_JOB _APPLICATION | N | ||
| APPLICATION_CLOSED .NOT_HIRED | TECHNICAL_JOB _APPLICATION | N | अपर्याप्त _EXPERIENCE | ओवर _QUALIFIED |
यहां संदर्भ TECHNICAL_JOB_APPLICATION है। यह महत्वपूर्ण क्यों है? क्योंकि यह हमें परिणामों को ओवरराइड करने की अनुमति देता है। याद रखें, हमने पहले कहा था कि हम सामग्री के बिल (बीओएम) संरचना में 'असेंबली' और 'सब-असेंबली' का पुन:उपयोग कर सकते हैं। यह तब उपयोगी होता है जब हम किसी चीज को एक बार परिभाषित करते हैं और उसका पुन:उपयोग करते हैं, लेकिन यह बहुत कठोर भी हो सकता है। क्या होगा यदि हम सब कुछ पुन:उपयोग नहीं करना चाहते हैं?
workflow_state_context डालने से workflow_state_hierarchy . के बीच और workflow_state_option , हम परिणामों का पुन:उपयोग और ओवरराइड दोनों कर सकते हैं। इस मॉडल में, हम परिभाषित कर सकते हैं कि परिणाम विभिन्न प्रक्रियाओं के लिए सक्षम या अक्षम है या नहीं।
उपरोक्त उदाहरण में, INTERVIEW.CANDIDATE_CANCELLED संयोजन अक्षम है। दूसरे शब्दों में, हम कह रहे हैं कि यह तकनीकी नौकरी के आवेदनों के लिए स्वीकार्य परिणाम नहीं है। नतीजतन, तकनीकी नौकरी साक्षात्कार के परिणाम रिकॉर्ड करते समय साक्षात्कारकर्ता इसका चयन नहीं कर पाएगा क्योंकि हमारी क्वेरी केवल उन विकल्पों का चयन करती है जहां workflow_state_context.child_disabled = ‘N’ ।
क्योंकि workflow_state_option workflow_state_hierarchy . का सीधा बच्चा नहीं है , हमें हर बार किसी राज्य का उपयोग करने पर विकल्पों के एक अलग सेट को परिभाषित करना होगा। लेकिन यह ट्रेड-ऑफ हमें प्रत्येक प्रक्रिया के लिए विकल्पों को बारीक रूप से ट्यून करने की अनुमति देता है।
योग्यता परिणाम
हमारे पास अधिक विस्तृत क्वालिफायर . को परिभाषित करने का विकल्प भी है परिणामों के लिए। ऐसा करने के दो तरीके हैं:
- आप पदानुक्रम में परिणामों के तहत क्वालिफायर को परिभाषित करने के लिए अपने बीओएम में चौथा स्तर बना सकते हैं। इस दृष्टिकोण के साथ उचित परिश्रम किया जाना चाहिए। उदाहरण के लिए, FAILED परिणाम का उपयोग विभिन्न राज्यों के लिए किया जाता है। क्या आप अलग-अलग FAILED राज्यों के लिए समान क्वालिफायर रखना चाहते हैं? शायद नहीं।
- आप अपने क्वालिफायर को
workflow_state_type. में परिभाषित कर सकते हैं लेकिन उन्हें किसी पदानुक्रम से न बांधें; वे स्वतंत्र हैं। फिर आपworkflow_state_option. का उपयोग करें विशिष्ट परिणाम संदर्भ के लिए क्वालीफायर सूचीबद्ध करने के लिए। उपरोक्त कॉन्फ़िगरेशन यही दिखाता है, जहां OVER_QUALIFIED और INSUFFICIENT_EXPERIENCE क्वालिफायर APPLICATION_CLOSED.NOT_HIRED परिणाम के विकल्प के रूप में सूचीबद्ध हैं।
किसी भी मामले में, एप्लिकेशन को यह पहचानना होगा कि एक राज्य या परिणाम के बजाय एक क्वालीफायर का चयन किया गया है - workflow_level_type यह इंगित करेगा - और managed_entity_state.wf_state_type_qual_id को अपडेट करेगा चयनित मान के साथ।
कुछ तालिका कॉन्फ़िगरेशन डेटा
आप अंतर्निहित कॉन्फ़िगरेशन डेटा, तालिका दर तालिका देखना पसंद कर सकते हैं। यहाँ हमारे पास ids है और type_keys वे कोष्ठक में संदर्भित करते हैं। संक्षिप्तता के लिए, केवल लेख से संबंधित मूल्य प्रस्तुत किए जाते हैं।
कार्यप्रवाह_स्तर_प्रकार
| आईडी | <थ>टाइप_की|
|---|---|
| 1 | प्रक्रिया |
| 2 | राज्य |
| 3 | परिणाम |
| 4 | क्वालिफायर |
workflow_state_type
| आईडी | <थ>टाइप_कीवर्कफ़्लो_लेवल_टाइप_आईडी | |
|---|---|---|
| 1 | STANDARD_JOB_APPLICATION | 1 (प्रक्रिया) |
| 2 | TECHNICAL_APPLICATION | 1 (प्रक्रिया) |
| 3 | साक्षात्कार | 2 (राज्य) |
| 4 | पास | 3 (परिणाम) |
| 5 | विफल | 3 (परिणाम) |
| 6 | MAKE_OFFER | 2 (STATE) |
| 7 | SEEK_REFERENCES | 2 (STATE) |
| 8 | APPLICATION_CLOSED | 2 (STATE) |
| 9 | किराए पर लिया गया | 3 (OUTCOME) |
| 10 | NOT_HIRED | 3 (OUTCOME) |
| 11 | INSUFFICIENT_EXPERIENCE | 4 (QUALIFIER) |
| 12 | OVER_QUALIFIED | 4 (QUALIFIER) |
कार्यप्रवाह_राज्य_पदानुक्रम
| आईडी | state_type_parent_id | state_type_child_id |
|---|---|---|
| 1 | 1 (STANDARD_JOB_APPLICATION) | 3 (साक्षात्कार) |
| 2 | 2 (TECHNICAL_JOB_APPLICATION) | 3 (साक्षात्कार) |
| 3 | 3 (साक्षात्कार) | 4 (पास) |
| 4 | 3 (इंटरव्यू) | 5 (FAILED) |
| 5 | 1 (STANDARD_JOB_APPLICATION) | 8 (APPLICATION_CLOSED) |
| 6 | 2 (TECHNICAL_JOB_APPLICATION) | 8 (APPLICATION_CLOSED) |
| 7 | 8 (APPLICATION_CLOSED) | 9 (किराए पर) |
| 8 | 8 (APPLICATION_CLOSED) | 10 (NOT_HIRED) |
workflow_state_context
| आईडी | state_type_id | state_hierarchy_id | बच्चे_अक्षम |
|---|---|---|---|
| 1 | 1 (STANDARD_JOB_ आवेदन) | 3 (साक्षात्कार.पास) | एन |
| 2 | 1 (STANDARD_JOB_ आवेदन) | 4 (साक्षात्कार विफल) | एन |
| 3 | 1 (STANDARD_JOB_ आवेदन) | 7 (APPLICATION_CLOSED. HIRED) | एन |
| 4 | 1 (STANDARD_JOB_ आवेदन) | 5 (APPLICATION_CLOSED. NOT_HIRED) | एन |
| 5 | 2 (TECHNICAL_APPLICATION) | 6 (APPLICATION_CLOSED. NOT_HIRED) | एन |
workflow_state_option
| आईडी | state_context_id | state_type_id |
|---|---|---|
| 1 | 1 (STANDARD_JOB_ APPLICATION. INTERVIEW. PASSED) | 6 (MAKE_OFFER) |
| 2 | 1 (STANDARD_JOB_ APPLICATION. INTERVIEW. PASSED) | 7 (SEEK_REFERENCES) |
| 3 | 2 (STANDARD_JOB_ APPLICATION. INTERVIEW. FAILED) | 8 (APPLICATION_CLOSED) |
| 4 | 5 (TECHNICAL_JOB_ APPLICATION. APPLICATION_CLOSED. NOT_HIRED) | 11 (INSUFFICIENT_EXPERIENCE) |
| 5 | 5 (तकनीकी _JOB_ APPLICATION. APPLICATION_CLOSED. NOT_HIRED) | 12 (OVER_QUALIFIED) |
जाहिर है, इसे सेट करना काफी मुश्किल है। इसे उपयोगकर्ता के अनुकूल इंटरफेस वाले एप्लिकेशन के माध्यम से अधिमानतः प्रशासित किया जाना चाहिए।
वैकल्पिक अनुक्रम
आप देखेंगे कि कई तालिकाओं में alt_sequence . नामक एक कॉलम होता है . इसका उपयोग उपयोगकर्ता को प्रस्तुत किए गए विभिन्न चयनों के लिए मूल्यों की सूची को ऑर्डर करने के लिए किया जाता है। आमतौर पर यह उपयोग के आधार पर अवरोही क्रम में होगा, जिसके शीर्ष पर सबसे अधिक बार उपयोग किए जाने वाले विकल्प होंगे।
जबकि इस लेख में नौकरी के अनुप्रयोगों का वर्णन किया गया है, मॉडल का उपयोग कई प्रकार के वर्कफ़्लोज़ के लिए किया जा सकता है जहाँ एक इकाई की स्थिति को समय के साथ प्रबंधित करने की आवश्यकता होती है। वैकल्पिक रूप से, मॉडल आपकी अपनी विशेष आवश्यकताओं के लिए अनुकूलित करने के लिए एक पैटर्न के रूप में काम कर सकता है।
