SharePoint + रिपोर्टिंग सेवाएँ = बारीकियाँ

मेरे सहकर्मी और मैं Microsoft SharePoint प्लेटफ़ॉर्म, साथ ही रूसी EDMS पर आधारित लागू आंतरिक कॉर्पोरेट समाधानों के विकास और कार्यान्वयन में लगे हुए हैं, जिन्हें लागू करना वर्षों से प्राप्त अनुभव से उचित है और कुछ मामलों में उचित है।

अपनी परियोजनाओं पर मैं रिपोर्ट और प्रिंट रूपों के त्वरित कार्यान्वयन के लिए Microsoft रिपोर्टिंग सेवा (इसके बाद - SSRS) का उपयोग करना पसंद करता हूं जिन्हें जटिल गतिशीलता की आवश्यकता नहीं होती है।

DBMS टेबल संरचना में डेटा की उपलब्धता के साथ, और, परिणामस्वरूप, रिपोर्ट डेटासेट की, SSRS के साथ सब कुछ आसान और सरल है, यदि तुच्छ नहीं है (बेशक सभी मामलों के लिए नहीं)। लेकिन क्या होगा यदि डेटाबेस तक कोई पहुँच नहीं है या यह लाइसेंसिंग नीति द्वारा निषिद्ध है या यहां तक ​​कि इसे लागू करने के लिए तकनीकी रूप से कठिन बनाने के प्रयास किए जाते हैं? ईटीएल टूल्स का उपयोग करके डेटा शोकेस तैयार करना आवश्यक है। लेकिन क्या होगा अगर परियोजना की स्थिति, बजट और शर्तें इसकी अनुमति नहीं देते हैं? आपको उपलब्ध डेटा स्रोतों (डेटा स्रोत) का उपयोग करना चाहिए।

जैसा कि आपने अनुमान लगाया होगा, हम SharePoint सूचियों के डेटा का उपयोग करके SSRS रिपोर्ट बनाने पर ध्यान केंद्रित करेंगे।

यद्यपि उपलब्ध SSRS डेटा स्रोतों का शस्त्रागार बड़ा है, व्यवहार में आप उन बारीकियों में "डुबकी" लगा सकते हैं जो हमेशा स्पष्ट नहीं होती हैं।

इसलिए, हम समस्या के बयान को पास करते हैं।
स्रोत डेटा:

• Microsoft SharePoint 2010 फाउंडेशन पर आधारित सूचना प्रणाली;
• Microsoft SQL Server 2008 R2 (इसके अलावा, R2 एक मूलभूत स्थिति है);
• Microsoft SQL सर्वर रिपोर्टिंग सेवाएँ SharePoint एकीकृत मोड में।

समस्या कथन:

• कई अलग-अलग SharePoint सूचियों में वितरित डेटा का उपयोग करके एक कस्टम रिपोर्ट लागू करें।
• डेटा मौसा या अनुकूलित वेब सेवाओं का उपयोग न करें (वे निश्चित रूप से उपयोग किए जा सकते हैं, लेकिन अतिरिक्त विकास अब कार्य और श्रम के दायरे में फिट नहीं होता है)।

ऐसा लगता है कि यह आसान हो सकता है? व्यवहार में, यह दुखी हो सकता है।

वैसे, SharePoint के लिए, डेटाबेस में डेटा तक सीधे पहुंच तकनीकी रूप से संभव है, हाँ, लेकिन मुश्किल है, और लाइसेंस नीति द्वारा अनुमति नहीं है। और, ईमानदारी से, SharePoint डेटाबेस ऑब्जेक्ट्स को सीधे एक्सेस करने की कोशिश न करना भी बेहतर है, मेरा विश्वास करो।

ठीक है, चलो जारी रखें। SQL Server 2008, संस्करण R2 से शुरू होकर, हमें SharePoint सूचियों के रूप में एक नए डेटा स्रोत के साथ प्रस्तुत किया। क्या यह अद्भुत है? हाँ, हमेशा की तरह नहीं!

समस्या यह है:

• एक ही DataSet में शामिल होना चाहते हैं? इसे भूल जाओ।
• सूची में फ़ोल्डर संरचना से डेटा प्राप्त करना चाहते हैं? इसे भूल जाओ।

एक डेटासेट के भीतर विभिन्न सूचियों के संयोजन के बारे में। हां, यह संभव नहीं है। SharePoint सूची से डेटा पुनर्प्राप्त करने वाला डेटासेट में एकल सूची से केवल डेटा हो सकता है। एक तरीके के रूप में, प्रत्येक सूची के लिए एक अलग डेटासेट बनाएं, SSRS रिपोर्ट सिस्टम मापदंडों के माध्यम से निर्भरता से डेटासेट फ़िल्टर करें ताकि सभी मर्ज किए गए सूचियों से संपूर्ण डेटा सरणी एकत्र न करें, और SSSS (लुकअप, लुकअपसेट) का उपयोग करके विभिन्न सूचियों से डेटा सम्मिलित करें। मल्टीलुकअप) रिपोर्ट में खुद को, उदाहरण के लिए, एक तालिका में देखें।

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

हम ऐसी सूची के साथ काम कर रहे हैं, जहां कई तत्व हैं, सब कुछ फ़ोल्डर्स में है, डेटा जिसने अपना जीवन चक्र पार कर लिया है, लेकिन सूची में रहता है और रिपोर्ट के लिए आवश्यक है।

ऐसा लगेगा कि CAML RSSharePointList वेब सेवा में बनाया गया है, जहाँ से डेटा प्राप्त होता है और पर्याप्त मात्रा में /> बायपास को बायपास करता है, लेकिन, दुर्भाग्यवश, SharePoint List Datasource को एकीकृत नहीं किया गया है। बस यह है कि आप डेटा स्रोत SharePoint सूची का उपयोग करके ऐसा डेटा प्राप्त नहीं कर सकते।

लेकिन डेटा की जरूरत है और कुछ करने की जरूरत है, जबकि स्टोरफ्रंट नहीं, समय नहीं। हम जड़ों पर लौटते हैं और SharePoint वेब सेवाओं के माध्यम से डेटा प्राप्त करने की दिशा में देखते हैं, लेकिन ऊपर वर्णित नहीं। हम एक डेटा स्रोत बनाते हैं, XML कनेक्शन प्रकार का उपयोग करते हैं, कनेक्शन स्ट्रिंग में लिखते हैं "SharePoint साइट्स के संग्रह के लिए पथ" + "/ _ vti_bin / Lists.asmx", रिपोर्ट के लिए सेवा उपयोगकर्ता के क्रेडेंशियल्स निर्दिष्ट करें। और अधिक दिलचस्प - हम ऊपर वर्णित स्रोत और एक क्वेरी समानता के साथ एक डेटासेट बनाते हैं:

 <Query> <SoapAction>http://schemas.microsoft.com/sharepoint/soap/GetListItems</SoapAction> <Method Namespace='http://schemas.microsoft.com/sharepoint/soap/' Name='GetListItems'> <Parameters> <Parameter Name='listName'> <DefaultValue>{A4AA15E5-D722-4583-AA7D-C51C86A384F4}</DefaultValue> </Parameter> <Parameter Name='viewName'> <DefaultValue>{231A273A-DDA2-4CA1-B8FC-54B3DC4B0816}</DefaultValue> </Parameter> <Parameter Name='query' Type='xml'> <DefaultValue> <Query> <Where> ... </Where> </Query> </DefaultValue> </Parameter> </Parameters> </Method> <ElementPath IgnoreNamespaces='True'>*</ElementPath> </Query> 

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

डेटा प्राप्त करने और कार्य की शर्तों के समान स्थितियों में खुद को खोजने की कुछ चालों में महारत हासिल करने के बाद, आप SQL सर्वर की पहुंच नहीं होने और SharePoint फ़ार्म व्यवस्थापक तक नहीं पहुंचने पर भी सीमित ग्राहक की स्थिति में एक जटिल रिपोर्ट को लागू कर सकते हैं और इसे एक कार्यात्मक ग्राहक के लिए लागू कर सकते हैं। ।

शायद, एक लेख के ढांचे में, सब कुछ। आइए देखें कि क्या यह विषय हब्बर पाठकों के लिए दिलचस्प है। यदि ऐसा है, तो एक उदाहरण के रूप में एक विशिष्ट रिपोर्ट का उपयोग करके इस पद के कार्य के कार्यान्वयन का वर्णन करना संभव है, रिपोर्ट मापदंडों के आधार पर तार्किक रूप से एकीकृत डेटासेट को लागू करने की तकनीकी बारीकियों का खुलासा करते हुए, गतिशील रूप से वेब सेवाओं की सूची बनाने के लिए अनुरोध करते हुए, रिपोर्ट तालिकाओं में लुकअप का उपयोग करने के उदाहरण।