SharePoint में इवेंट रिसीवर को साइकिल चलाना और अस्थायी रूप से अक्षम करना

जैसा कि आप जानते हैं, SharePoint में कई ईवेंट रिसीवर (EventReceiver) होते हैं जो आपको SharePoint ऑब्जेक्ट्स के साथ मानक संचालन करते समय कस्टम कोड को कॉल करने की अनुमति देते हैं, उदाहरण के लिए, सूची आइटम जोड़ना / हटाना / बदलना। ईवेंट रिसीवर्स के साथ काम करना एक अलग लेख का हकदार है, लेकिन इस विषय पर उनमें से बहुत सारे हैं, उदाहरण के लिए यहां ।



आज हम समस्याओं के 2 विशेष मामलों को देखते हैं जो एक नौसिखिया SharePoint डेवलपर को रिसीवर के साथ काम करते समय हो सकते हैं:



1. घटनाओं का चक्रीय कॉल।



ऐसी स्थिति की कल्पना करना काफी आसान है जहां रिसीवर एक अंतहीन चक्र में खुद को "ड्राइव" कर सकता है। एक उदाहरण के रूप में, आइटम आइटम "अपडेट के बाद" (ItemUpdated) के लिए ईवेंट रिसीवर लें। आपका कोड इस तत्व के साथ अतिरिक्त क्रिया करता है (उदाहरण के लिए, उपयोगकर्ता द्वारा दर्ज किए गए डेटा के आधार पर, अतिरिक्त गणना करें और उन्हें आवश्यक फ़ील्ड पर लिखें), और फिर, निश्चित रूप से, डेटा को बचाने के लिए अपडेट कॉल करें। कॉल के बाद, क्या होना चाहिए? बेशक। रिसीवर में वर्णित आपका कोड फिर से कॉल किया जाएगा। और इतनी अंतहीन।

public override void ItemUpdated(SPItemEventProperties properties) { base.ItemUpdated(properties); SPListItem Item = properties.ListItem; Item["Title"] = DateTime.Today.ToString("dd.MM.yyyy"); Item.Update(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

मेरे लिए समझ से बाहर के कारणों के लिए, कुछ डेवलपर्स का मानना ​​है कि घटना संचालकों के निष्पादन को अक्षम करने के लिए, यह ऑब्जेक्ट पर अपडेट के बजाय SystemUpdate को कॉल करने के लिए पर्याप्त है। लेकिन ऐसा है नहीं। न केवल msdn का कहना है कि यह विधि आपको संशोधित, संशोधित फ़ील्ड्स को अद्यतन किए बिना और आइटम के संस्करण को बढ़ाए बिना सूची आइटम को अपडेट करने की अनुमति देती है, लेकिन इसके विपरीत प्रयोगात्मक रूप से साबित होता है।



यही है, ईवेंट हैंडलर की कॉल को अक्षम करने के लिए SystemUpdate का उपयोग करना पर्याप्त नहीं होगा, हालांकि मैं मानता हूं कि उपरोक्त उदाहरण में उपरोक्त फ़ील्ड में परिवर्तनों को बाहर करने के लिए SystemUpdate को कॉल करना बेहतर है और यदि संस्करण सक्षम है तो तत्व का एक नया संस्करण बनाएं।



यह समस्या हमें SPEventReceiverBase (या यहां तक ​​कि SPEventReceiverBase से वर्तमान विरासत में मिली वस्तु) की EventFiringEnabled संपत्ति को हल करने में मदद करेगी।



यह संपत्ति आपको वर्तमान थ्रेड में SPEventReceiverBase वर्ग से विरासत में मिली किसी भी घटना संचालकों को कॉल करने की क्षमता को नियंत्रित करने की अनुमति देती है। यही है, आपके कोड में आप ईवेंट हैंडलर के कॉल पर और बंद कर सकते हैं और इस बात से डरे नहीं कि अन्य कोड या एक साधारण उपयोगकर्ता ऑपरेशन (जिसे रिसीवर्स भी कहते हैं) आपके विशिष्ट विधि में हैंडलर को बंद या बंद करके क्लाउड किया जाएगा।

 public override void ItemUpdated(SPItemEventProperties properties) { base.ItemUpdated(properties); SPListItem Item = properties.ListItem; this.EventFiringEnabled = false; Item["Title"] = DateTime.Today.ToString("dd.MM.yyyy"); Item.Update(); this.EventFiringEnabled = true; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

जब आप विधि को निष्पादित करते समय निर्दिष्ट कोड कहते हैं, तो रिसीवर को कॉल अक्षम हो जाएगा। यह इस तथ्य पर ध्यान देने योग्य है कि SPEventReceiverBase से विरासत में प्राप्त सभी रिसीवर अक्षम हो जाएंगे, जब EventFiringEnabled संपत्ति को गलत पर सेट किया जाता है, और आपको इस बात का ध्यान रखना होगा। यही है, अगर, रिसीवर कॉल को बंद करने और इसे चालू करने के बीच के अंतराल में, आप एक और सूची को अपडेट करने की कोशिश करते हैं जिसमें अपडेट ईवेंट हैंडलर संलग्न है, तो यह विफल हो जाएगा (क्यों? इसके बारे में थोड़ा नीचे)। जिस कोड को निष्पादित किया जाना था, उसे लागू किया जाना चाहिए।



यदि आप उपरोक्त कोड पर ध्यान देते हैं, तो यह तुरंत स्पष्ट हो जाएगा कि यह इष्टतम नहीं है। कम-से-कम इसे अंत में ट्राइ-कैच में लपेटना अधिक तर्कसंगत है (अच्छी तरह से, या कम से कम अभी-अंत में प्रयास करें)। क्या आप जानते हैं कि यह या वह क्या है ?



परिणाम निम्न कोड है, जो आउटपुट की परवाह किए बिना, ईवेंट हैंडलर के निष्पादन को सक्षम करेगा

 public override void ItemUpdated(SPItemEventProperties properties) { base.ItemUpdated(properties); try { SPListItem Item = properties.ListItem; this.EventFiringEnabled = false; Item["Title"] = DateTime.Today.ToString("dd.MM.yyyy"); Item.Update(); } finally { this.EventFiringEnabled = true; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

पाठ में नीचे दिए गए कथन के साथ वियोग का एक और संभावित विकल्प प्रस्तुत किया जाएगा।



2. रिसीवर के बाहर कुछ संचालन करते समय घटनाओं को अक्षम करने की आवश्यकता।



रिसीवर के अंदर रिसीवर के निष्पादन को कैसे अक्षम किया जाए, हम समझ गए। लेकिन बहुत हिस्सा रिसीवर के बाहर रिसीवर के निष्पादन को अक्षम करने की आवश्यकता है। अर्थात्, आप, उदाहरण के लिए, एक कंसोल एप्लिकेशन में सूची आइटम को अपडेट करना चाहते हैं, लेकिन नहीं चाहते हैं कि रिसीवर को बुलाया जाए, जो इसमें डेटा को संसाधित करेगा और इसे अधिलेखित कर देगा, आइटम के साथ आवश्यक हेरफेर करेगा और फिर इसे रिसीवर के साथ अपडेट करेगा।



इसके मूल में, कार्य पिछले एक के समान है, लेकिन हमारे पास एक SPEventReceiverBase ऑब्जेक्ट नहीं है और रिसीवर के कॉल को अक्षम करने के लिए कुछ भी नहीं है। यहां परावर्तक की ओर मुड़ना और यह देखना आवश्यक है कि यह वर्ग क्या है और हमें किस तरह से रहना चाहिए।

 protected bool EventFiringEnabled { get { return !SPEventManager.EventFiringDisabled; } set { SPEventManager.EventFiringDisabled = !value; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

यह कोड से देखा जा सकता है कि वर्ग के पास EventFiringEnabled संपत्ति है (हमने इसे इवेंट कॉल को अक्षम करने के लिए थोड़ा पहले इस्तेमाल किया था) और इसकी मदद से हम स्थैतिक संपत्ति SPEventManager.EventFiringDabled से संपत्ति प्राप्त या सेट करते हैं। इस संपत्ति का कोड नीचे प्रस्तुत किया गया है:

 internal static bool EventFiringDisabled { get { SPEventManager.EnsureTlsEventFiringDisabled(); object data = Thread.GetData(SPEventManager.m_tlsEventFiringDisabled); return data != null && (bool) data; } set { SPEventManager.EnsureTlsEventFiringDisabled(); Thread.SetData(SPEventManager.m_tlsEventFiringDisabled, (object) (bool) (value ? 1 : 0)); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

चूंकि विधि स्थिर है, और आंतरिक कार्य पहले से ही थ्रेड्स पर आधारित है, इसलिए यह पता चलता है कि SPEventReceiverBase से विरासत में मिला प्रत्येक वर्ग वर्तमान वस्तु के संदर्भ में काम नहीं करता है। आवश्यक जानकारी हमारे स्ट्रीम के लिए आवंटित मेमोरी सेल्स में पढ़ी और लिखी गई है। यह पता चला है कि यह इतना महत्वपूर्ण नहीं है कि किस रिसीवर से अन्य हैंडलर को कॉल काट दी जाए या चालू कर दिया जाए, लेकिन यह महत्वपूर्ण है कि यह किस थ्रेड में किया गया है। इस प्रकार, अपनी विशिष्ट स्थिति के लिए SPEventReceiverBase (या हमारे विशेष मामले के लिए SPItemEventReceiver से विरासत में मिली अपनी श्रेणी बनाना पर्याप्त है, जो कि उदाहरण के लिए कोड में आवश्यक जगह पर पहले से मौजूद इंट्रोड्यूस करने में सक्षम है और पहले से मौजूद EventFiringEnabled संपत्ति के साथ काम करता है।

 public class DisableItemEvents : SPItemEventReceiver { public bool CustomEventFiringEnabled { get { return base.EventFiringEnabled; } set { base.EventFiringEnabled = value; } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

और उदाहरण के लिए, कॉल करें:

 var EventsDisable = new DisableItemEvents(); try { Item["Title"] = DateTime.Today.ToString("dd.MM.yyyy"); EventsDisable.CustomEventFiringEnabled = false; Item.Update(); } finally { EventsDisable.CustomEventFiringEnabled = true; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

यह पता चला कि हमें क्या उम्मीद थी। जब रिसीवर को अपडेट करने से काम नहीं हुआ। और जैसा कि मैंने पहले कहा, इस दृष्टिकोण को जीवन का अधिकार है, और कई इसका उपयोग करते हैं, लेकिन मैं इस डिजाइन को थोड़ा अलग तरीके से वर्णन करूंगा। मुझे वास्तव में पैटर्न का उपयोग करना पसंद है। कम से कम इस तथ्य के लिए कि इस कार्यक्षमता का उपयोग करके आप यह सुनिश्चित कर सकते हैं कि निर्देश के अंदर त्रुटियों की परवाह किए बिना, डिस्पोज़ हमेशा कहा जाएगा।



मैंने अपनी कक्षा का वर्णन इस प्रकार किया:

 public class DisableItemEvents : SPItemEventReceiver, IDisposable { private bool _EventStatus; public DisableItemEvents() { _EventStatus = base.EventFiringEnabled; base.EventFiringEnabled = false; } public void Dispose() { base.EventFiringEnabled = _EventStatus; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

इस वर्ग के साथ काम निम्नानुसार है:

 using (new DisableItemEvents()) { Item.Update(); //     } Item.Update(); //   
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

यहाँ टिप्पणियाँ शानदार हैं, लेकिन फिर भी। DisableItemEvents ऑब्जेक्ट को आरंभीकृत करते समय , EventFiringEnabled संपत्ति का मूल मान सहेजा जाएगा और झूठे में सेट किया जाएगा। और जब ऑब्जेक्ट अनलोड किया जाता है, तो EventFiringEnabled संपत्ति वापस कर दी जाएगी।



इस प्रकार, हमने रिसीवर्स के अंदर और बाहर दोनों से इवेंट हैंडलर्स से कॉल डिस्कनेक्ट करने के संभावित विकल्पों की जांच की।