SAP परफ़ॉर्मेंस टेस्टिंग: IT लीडर को क्या जानना ज़रूरी है

SAP परफ़ॉर्मेंस टेस्टिंग go-live से पहले यह साबित करती है कि अहम ट्रांज़ैक्शन, बैकग्राउंड जॉब और इंटरफ़ेस प्रोडक्शन के वॉल्यूम पर तय रिस्पॉन्स टाइम को पूरा करते हैं। इसे डिज़ाइन में शुरू कीजिए, कॉन्फ़िगरेशन स्थिर होने पर Realize में वॉल्यूम और लोड टेस्ट चलाइए, यह चक्र यूज़र एक्सेप्टेंस टेस्टिंग (UAT) से पहले पूरा कीजिए, और नतीजों को कटओवर का गेट बनाइए। यह गाइड S/4HANA प्रोग्राम पर काम करने वाले CIO, प्रोग्राम डायरेक्टर और टेस्ट लीड के लिए है, RISE with SAP सहित। इसमें बताया गया है कि क्या टेस्ट करें, इसकी ज़िम्मेदारी किसकी है, स्वीकृति के मानदंड कैसे लिखें और क्लाउड में क्या बदलता है। स्वीकृति के मानदंडों की तालिका से शुरू कीजिए: अगर आप उसे भर नहीं पा रहे, तो आप टेस्ट के लिए तैयार नहीं हैं।

SAP प्रोग्राम में परफ़ॉर्मेंस की समस्याएँ लगभग हमेशा go-live के बाद पकड़ में आती हैं। शिफ़्ट बदलने पर 300 यूज़र एक साथ लॉगिन करते हैं और Fiori टाइल टाइम-आउट हो जाते हैं। किसी ने 50 मिलियन रिकॉर्ड वाली टेबल पर बिना सीमा की फ़िस्कल-ईयर क्वेरी चला दी और Z-रिपोर्ट जम गईं। month-end close के दौरान बैकग्राउंड जॉब आपस में टकराते हैं और पोस्टिंग रन बीच में ही रुक जाता है।

SAP प्रोग्राम में परफ़ॉर्मेंस की समस्याएँ शायद ही कभी अचानक आती हैं। ज़्यादातर का अनुमान लगाया जा सकता था, बस उनकी योजना नहीं बनी थी। आम पैटर्न यह है: फ़ंक्शनल टेस्टिंग गहराई से हुई। वॉल्यूम टेस्टिंग की योजना बनी, फिर टाइमलाइन सिकुड़ने पर आगे खिसका दी गई। नतीजे लाइव ऑपरेशन के पहले हफ़्तों में सामने आए।

ये अपवाद नहीं हैं। इनका अनुमान लगाया जा सकता है। सवाल सिर्फ़ यह है कि प्रोग्राम ने इनके लिए टेस्ट किया, या बिज़नेस इन्हें तब पकड़ता है जब असली ऑर्डर चल रहे होते हैं।

SAP Activate में परफ़ॉर्मेंस टेस्टिंग

1. 01

   Explore

   डिज़ाइन में ही परफ़ॉर्मेंस के जोखिम पहचानिए। कोड लिखे जाने से पहले आर्किटेक्चर और रिपोर्ट की बनावट नतीजे तय कर देते हैं।

2. 02

   Realize

   कॉन्फ़िगरेशन स्थिर होने के साथ वॉल्यूम और लोड टेस्ट चलाइए। अधूरा कॉन्फ़िगरेशन भ्रामक नतीजे देता है।

3. 03

   UAT से पहले

   परफ़ॉर्मेंस का पूरा चक्र UAT से पहले पूरा कीजिए, UAT के हिस्से के रूप में नहीं।

4. 04

   कटओवर

   कटओवर को पहले से तय स्वीकृति के मानदंडों के आधार पर मंज़ूर कीजिए, राय के आधार पर नहीं।

5. 05

   हाइपरकेयर

   लाइव KPI को 30 से 60 दिन देखते रहिए। ज़्यादातर गिरावटें पहले क्लोज़ साइकल में सामने आती हैं।

पारंपरिक डेटाबेस पर चलने वाले ECC सिस्टम में परफ़ॉर्मेंस टेस्टिंग का मतलब था एप्लिकेशन सर्वर और डेटाबेस की लोड टेस्टिंग: ABAP रनटाइम, SQL परफ़ॉर्मेंस, जॉब शेड्यूलिंग। फ़्रंट एंड SAP GUI था, जो शायद ही किसी को चौंकाता था।

Fiori फ़्रंट एंड, SAP BTP पर एक्सटेंशन और SAP Cloud Integration (CPI) के ज़रिये इंटीग्रेशन वाले S/4HANA में परफ़ॉर्मेंस एक साथ कई परतों पर निर्भर करती है। धीमा Fiori टाइल लंबी ABAP कॉल हो सकता है, गेटवे टाइम-आउट हो सकता है, ऐसी OData सर्विस हो सकती है जो एक साथ आने वाले अनुरोधों के लिए बनी ही नहीं, या हाइब्रिड सेटअप में नेटवर्क लेटेंसी। सिर्फ़ बैक एंड की टेस्टिंग से यह पकड़ में नहीं आएगा। पूरे रास्ते की टेस्टिंग से आएगा।

1. 01टाइल लॉन्चशिफ़्ट शुरू होने पर लॉगिन की बाढ़
2. 02OData कॉलगेटवे टाइम-आउट, कंकरेंसी के लिए न बनी सर्विस
3. 03ABAP प्रोसेसिंगलंबी चलने वाली ABAP कॉल
4. 04डेटाबेस रीडबड़ी टेबल पर बिना सीमा के सेलेक्शन
5. 05रेंडरिंगदूर की साइट के लिए नेटवर्क लेटेंसी अलग से

एक रिस्पॉन्स टाइम, जिसे शुरू से अंत तक मापा गया

इंटीग्रेशन फ़्लो अपना अलग जोखिम जोड़ते हैं। डेवलपमेंट और QA में एक-एक टेस्ट मैसेज के साथ चले फ़्लो प्रोडक्शन के वॉल्यूम पर कतार में फँस सकते हैं या चुपचाप फ़ेल हो सकते हैं। अगर मैसेज क्यू का आकार असली लोड के हिसाब से नहीं रखा गया, तो देरी जमा होती जाती है। लक्षण किसी और चीज़ जैसे दिखते हैं: कभी-कभार ऑर्डर का फ़ेल होना, इनवॉइस का मेल न खाना, डेटा एक सिस्टम में मौजूद और दूसरे में ग़ायब।

1. लोड टेस्टिंग अपेक्षित वॉल्यूम पर व्यवहार जाँचती है। यहाँ मुख्य शब्द है अपेक्षित। आपको असली ट्रांज़ैक्शन वॉल्यूम, यूज़र संख्या और एक साथ चल रहे सेशन चाहिए। कई लोड टेस्ट इसलिए नाकाम होते हैं कि उन्होंने ऐसे वॉल्यूम अनुमान इस्तेमाल किए जिन्हें सब पहले से आशावादी मानते थे।
2. स्ट्रेस टेस्टिंग डिज़ाइन की सीमाओं से आगे धकेलकर देखती है कि सिस्टम कहाँ टूटता है। अगर अठारह महीने में वॉल्यूम दोगुना होने वाला है, तो यह बताती है कि आर्किटेक्चर सँभाल पाएगा या नहीं, और अगले इन्फ्रास्ट्रक्चर रिव्यू से पहले साइज़िंग समस्या बनेगी या नहीं।
3. सोक टेस्टिंग लंबे समय तक एक-सा लोड चलाकर वे समस्याएँ उजागर करती है जो समय के साथ बनती हैं: मेमोरी लीक, फ़्रैगमेंटेशन और बार-बार के रन में जॉब चेन की होड़। यह वही टेस्ट है जिसे सबसे ज़्यादा छोड़ा जाता है, और यही उस month-end विफलता को पकड़ लेती जिसका ज़िक्र नीचे है।
4. एंड-टू-एंड टेस्टिंग यूज़र का पूरा रास्ता पकड़ती है: टाइल लॉन्च, OData कॉल, ABAP प्रोसेसिंग, डेटाबेस रीड, रेंडरिंग। हर परत को अलग से टेस्ट करने पर जो समस्याएँ दिखती ही नहीं, उन्हें पकड़ने का यही अकेला तरीक़ा है।

शिफ़्ट बदलना और पीक लॉगिन। जब सुबह 8 बजे 200 यूज़र Fiori लॉन्चपैड खोलते हैं, तो ऑथेंटिकेशन और लॉन्चपैड रेंडरिंग पर भार बढ़ जाता है। जो सिस्टम पीक के बाहर ठीक चलता है, वह उस विंडो में बेकार हो सकता है अगर एक साथ होने वाले लॉगिन कभी टेस्ट ही नहीं किए गए। मैन्युफ़ैक्चरिंग, रिटेल और फ़ाइनेंशियल सर्विसेज़ में पहले दिन की सबसे साफ़ दिखने वाली शिकायतें लॉगिन की बाढ़ से ही आती हैं।

Month-end और year-end close। ज़्यादातर प्रोग्राम में सबसे ज़्यादा जोखिम वाला परिदृश्य: भारी वॉल्यूम की पोस्टिंग, कड़े क्रम वाली जॉब चेन और तय डेडलाइन से होड़ लगाती फ़ाइनेंस टीम। क्लोज़ की जॉब चेन को शुरू से अंत तक क्लोज़िंग-अवधि के वॉल्यूम पर चलाइए, रोज़ की औसत संख्या पर नहीं।

बैच जॉब आम तौर पर अलग-अलग टेस्ट होते हैं, जो हक़ीक़त से मेल नहीं खाता। month-end पर बैकग्राउंड प्रोसेसिंग चरम पर होती है और कई प्रोग्राम एक ही संसाधनों पर समानांतर चलते हैं। एक ख़राब ऑप्टिमाइज़ किया गया जॉब पाँच और जॉब को रोक सकता है, और क्लोज़ अपनी विंडो से बाहर निकल जाता है।

ECC से S/4HANA कन्वर्ज़न। स्थिर ECC कोड HANA पर अलग व्यवहार करता है। कई प्रोग्राम काफ़ी तेज़ हो जाते हैं; कुछ ख़ास डेटा पैटर्न पर अनपेक्षित प्रोफ़ाइल दिखाते हैं। कन्वर्ज़न-विशेष रिग्रेशन टेस्टिंग वैकल्पिक नहीं है। मेरी ECC से S/4HANA माइग्रेशन गाइड बताती है कि यह कन्वर्ज़न प्लान में कहाँ बैठता है।

कई क्षेत्रों के यूज़र। नेटवर्क लेटेंसी हर ट्रांज़ैक्शन पर असर डालती है। जो सेल्स ऑर्डर होस्टिंग वाले देश में दो सेकंड लेता है, वह 3,000 मील दूर टूटा हुआ लग सकता है अगर किसी ने वहाँ से टेस्ट नहीं किया। RISE में होस्टिंग SAP के पास चली जाती है, पर लेटेंसी फिर भी इस पर निर्भर करती है कि आप कौन सा रीजन चुनते हैं और आपके यूज़र तक रूटिंग कैसी है।

कोई भी टेस्ट चलने से पहले, Prepare फ़ेज़ में बिज़नेस के साथ मानदंडों पर सहमति बना लीजिए। हर मानदंड में ट्रांज़ैक्शन या जॉब का नाम, लोड और सीमा होनी चाहिए। ये उदाहरण ढाँचा दिखाते हैं; अपने नंबर ऑपरेशन की ज़रूरतों से तय कीजिए:

आइटम	लोड की शर्त	पास होने की सीमा	ज़िम्मेदार
सेल्स ऑर्डर बनाना (VA01 या Fiori ऐप)	ऑर्डर एंट्री करने वाले 150 यूज़र एक साथ	95% ट्रांज़ैक्शन 3 सेकंड से कम में	ऑर्डर-टू-कैश प्रोसेस ओनर
शिफ़्ट की शुरुआत में Fiori लॉन्चपैड का पहला लोड	सबसे बड़ी शिफ़्ट के पीक कंकरेंट लॉगिन	95% यूज़र के लिए 5 सेकंड से कम	IT ऑपरेशंस लीड
Month-end close जॉब चेन	क्लोज़िंग-अवधि का वॉल्यूम, पूरा क्रम	तय क्लोज़ विंडो के भीतर पूरी, बिना किसी रुकावट के	फ़ाइनेंशियल कंट्रोलर
इनबाउंड ऑर्डर इंटरफ़ेस	प्रति घंटे के पीक मैसेज वॉल्यूम	15 मिनट से पुराना कोई क्यू बैकलॉग नहीं	इंटीग्रेशन लीड
ज़्यादा वॉल्यूम वाली कस्टम रिपोर्ट	पूरा प्रोडक्शन डेटा वॉल्यूम, सामान्य सेलेक्शन	60 सेकंड से कम; बिना सीमा वाले सेलेक्शन ब्लॉक	रिपोर्ट ओनर

“सिस्टम बिज़नेस ऑपरेशन के लिए पर्याप्त तेज़ होना चाहिए” को न टेस्ट किया जा सकता है, न स्वीकार। नतीजे आने के बाद मानदंड बदलना मानदंड रखने का मक़सद ही ख़त्म कर देता है।

इनमें से हर चीज़ नाम लेकर माँगिए:

अपेक्षा	क्या मिलना चाहिए	यह क्यों मायने रखता है
परफ़ॉर्मेंस सर्विस लेवल	हर ट्रांज़ैक्शन, इंटरफ़ेस और जॉब की सीमाएँ, पास और फ़ेल के साथ	UAT की राय को सबूत पर हावी होने से रोकता है
जोखिम पर आधारित स्कोप	यूज़र वॉल्यूम, इंटीग्रेशन पॉइंट और डेटा निर्भरता के हिसाब से प्राथमिकता	टेस्ट चक्र उन वर्कलोड पर लगाता है जो मायने रखते हैं
टीमों की साझा भागीदारी	रन के दौरान Basis, इन्फ्रास्ट्रक्चर, फ़ंक्शनल, सिक्योरिटी और इंटीग्रेशन की टीमें मौजूद	गैप निकलने पर एक-दूसरे पर दोष डालने से रोकता है
टूल और एनवायरनमेंट तैयार	लोड जनरेटर (OpenText LoadRunner, Tricentis NeoLoad, Apache JMeter), मॉनिटरिंग और डेटा रीफ़्रेश चक्र शुरू होने से पहले तैयार	सिमुलेशन को असलियत के क़रीब बनाता है
यथार्थवादी टेस्ट डेटा	प्रोडक्शन वॉल्यूम का मास्टर डेटा, असली इंटरफ़ेस कॉल, प्रतिनिधि ट्रांज़ैक्शन मिक्स	नतीजों को go-live के व्यवहार का सही अनुमान बनाता है
परफ़ॉर्मेंस रिपोर्टिंग	लोड मिक्स, रिस्पॉन्स टाइम, CPU और मेमोरी, जॉब रनटाइम, एरर रेट	कटओवर की मंज़ूरी को सबूत का आधार देता है
go-live के बाद की मॉनिटरिंग योजना	पहले 30 से 60 दिन देखने के KPI	पुष्टि करता है कि लाइव सिस्टम टेस्ट की गई सीमाओं में रहता है

चार गलतियाँ सबसे ज़्यादा सामने आती हैं, बड़े एंटरप्राइज़ में भी जिनका डिलीवरी मॉडल परिपक्व है।

फ़ंक्शनल टेस्टिंग को परफ़ॉर्मेंस टेस्टिंग मान लेना। फ़ंक्शनल टेस्ट साबित करते हैं कि ट्रांज़ैक्शन सही नतीजा देता है। 150 लोग उसे एक साथ चलाएँ तो क्या होगा, इस बारे में वे कुछ नहीं बताते।

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

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

ज़िम्मेदारी सिर्फ़ QA को दे देना। QA टेस्ट चलाता है और नतीजे बताता है। परफ़ॉर्मेंस की समस्याएँ पैदा करने वाले फ़ैसले डिज़ाइन में फ़ंक्शनल, टेक्निकल और Basis टीमें लेती हैं। प्रोग्राम-स्तर के टेस्ट लीड या आर्किटेक्ट के पास उन फ़ैसलों को शुरू में ही चुनौती देने का अधिकार होना चाहिए, और RACI में लिखा होना चाहिए कि परफ़ॉर्मेंस के आधार पर go-live कौन रोक सकता है।

RISE में ज़िम्मेदारी बँट जाती है

RISE with SAP में इन्फ्रास्ट्रक्चर SAP का है: साइज़िंग, हाइपरस्केलर रीजन, नेटवर्क और प्लेटफ़ॉर्म की उपलब्धता। एप्लिकेशन परत क्लाइंट और पार्टनर की है। SAP का RISE की भूमिकाओं और ज़िम्मेदारियों वाला दस्तावेज़ यह बात साफ़ कहता है: महँगे SQL स्टेटमेंट ढूँढना और ट्यून करना ग्राहक के पास ही रहता है, जब तक आप SAP की अतिरिक्त एप्लिकेशन सर्विसेज़ न ख़रीदें।

RISE प्रोग्राम में एक आम चूक यह धारणा है कि SAP परफ़ॉर्मेंस की समस्याएँ पकड़ लेगा क्योंकि इन्फ्रास्ट्रक्चर वही चलाता है। वह इन्फ्रास्ट्रक्चर की समस्याएँ पकड़ेगा। वह ख़राब डिज़ाइन की OData सर्विस, अकुशल ABAP जॉब या ऐसा इंटीग्रेशन फ़्लो नहीं पकड़ेगा जो स्केल नहीं करता। यह बँटवारा चार्टर और टेस्ट प्लान में लिख दीजिए:

1. SAP: इन्फ्रास्ट्रक्चर की उपलब्धता और प्लेटफ़ॉर्म-स्तर का रिस्पॉन्स
2. पार्टनर: तय लोड पर एप्लिकेशन की परफ़ॉर्मेंस, एक्सटेंशन और इंटीग्रेशन फ़्लो समेत
3. क्लाइंट: प्रक्रिया-स्तर के नतीजे, जैसे क्लोज़ का रनटाइम और ऑर्डर थ्रूपुट, और स्वीकृति का फ़ैसला

Public Edition और GROW दायरा सीमित कर देते हैं

S/4HANA Cloud Public Edition पर, जो आम तौर पर GROW with SAP के ज़रिये ख़रीदा जाता है, SAP अपने मल्टी-टेनेंट प्लेटफ़ॉर्म पर अपने प्रोडक्ट स्टैंडर्ड के हिस्से के तौर पर परफ़ॉर्मेंस टेस्टिंग करता है और ग्राहकों से साझा सिस्टम की लोड टेस्टिंग की उम्मीद नहीं रखता। आपकी टेस्टिंग उस पर आ जाती है जो आपका है: कस्टम इंटीग्रेशन, एक्सटेंशन, ज़्यादा वॉल्यूम वाली रिपोर्ट और एनालिटिक्स, क्लोज़ और कंसोलिडेशन का क्रम, और आपकी साइटों से नेटवर्क का रास्ता। प्लेटफ़ॉर्म की अपनी परफ़ॉर्मेंस समस्याएँ SAP सपोर्ट के पास जाती हैं।

AI स्क्रिप्ट में मदद करता है, आर्किटेक्चर में नहीं

लोड-टेस्टिंग वेंडर स्क्रिप्ट के रखरखाव और नतीजों के विश्लेषण के लिए AI जोड़ रहे हैं, जो उन प्रोग्राम में काम आता है जहाँ चक्रों के बीच एप्लिकेशन बदलता रहता है। इसके लिए पैसे देने से पहले उनके दावों को अपने ही लैंडस्केप पर परखिए। SAP Cloud ALM टेस्ट केस और ज़रूरतें बनाने में मदद कर सकता है, और AI असिस्टेंट प्रक्रिया के विवरण से परिदृश्यों की रूपरेखा का मसौदा तैयार कर सकते हैं।

इनमें से कुछ भी आर्किटेक्चर नहीं सुधारता। AI यह नहीं बताएगा कि OData सर्विस अलग ढंग से डिज़ाइन होनी चाहिए थी, या कि कोई रिपोर्ट अपने वॉल्यूम के लिए बहुत भारी है। ये फ़ैसले अब भी लोग लेते हैं, डिज़ाइन में, किसी भी टेस्ट के चलने से पहले।

प्रोडक्शन में परफ़ॉर्मेंस की समस्या झेलने वाले ज़्यादातर प्रोग्राम ने टेस्टिंग पूरी तरह छोड़ी नहीं थी। उन्होंने बिना तय मानदंडों के टेस्ट किया, या टेस्ट करके शेड्यूल के दबाव में कमियों को “ज्ञात समस्याएँ” मानकर स्वीकार कर लिया। अनुशासन मानदंडों में और उन्हें लागू करने में है, टूल में नहीं। दूसरे टेस्ट प्रकारों के बीच परफ़ॉर्मेंस कहाँ बैठती है, यह जानने के लिए मेरी SAP टेस्टिंग और वैलिडेशन टूल्स की तुलना और SAP क्वालिटी गेट पर मेरी गाइड देखिए।

SAP परफ़ॉर्मेंस टेस्टिंग क्या है और यह क्यों मायने रखती है?

यह जाँचती है कि यथार्थवादी लोड में SAP कैसा व्यवहार करता है: यूज़र ट्रांज़ैक्शन का रिस्पॉन्स टाइम, बैकग्राउंड जॉब का रनटाइम, इंटरफ़ेस का थ्रूपुट और एक साथ चल रहे काम में संसाधनों का उपयोग।

फ़ंक्शनल रूप से सही होना और परफ़ॉर्मेंस अलग-अलग गुण हैं। जो ट्रांज़ैक्शन एक यूज़र के लिए सही है, वह 200 यूज़र के लिए टाइम-आउट हो सकता है। जो जॉब टेस्ट डेटा पर दस मिनट में चलता है, वह प्रोडक्शन वॉल्यूम पर घंटों चल सकता है। यह बात go-live के बाद पता चले तो ऑपरेशन बिगड़ता है, आपातकालीन बदलाव करने पड़ते हैं और यूज़र का भरोसा तब टूटता है जब अपनाने का दौर सबसे नाज़ुक होता है।

SAP प्रोग्राम में परफ़ॉर्मेंस टेस्टिंग कब शुरू होनी चाहिए?

जोखिम की पहचान Explore में शुरू होती है, क्योंकि आर्किटेक्चर के चुनाव परफ़ॉर्मेंस के नतीजे तय करते हैं। असली टेस्टिंग Realize में शुरू होती है, जब कॉन्फ़िगरेशन इतना स्थिर हो कि नतीजों का कोई मतलब बने। अधूरा कॉन्फ़िगरेशन भ्रामक आँकड़े देता है।

आख़िरी चक्र UAT से पहले पूरा कीजिए, UAT के दौरान नहीं। UAT में मिले परफ़ॉर्मेंस डिफ़ेक्ट बचे हुए शेड्यूल को निचोड़ देते हैं और उन्हें “ज्ञात समस्याएँ” मानकर स्वीकार कर लेने का दबाव बनाते हैं।

SAP परफ़ॉर्मेंस टेस्टिंग की ज़िम्मेदारी किसकी होनी चाहिए?

प्रोग्राम की, सिर्फ़ QA की नहीं। QA टेस्ट चलाता है और रिपोर्ट करता है, पर परफ़ॉर्मेंस तय करने वाले फ़ैसले डिज़ाइन में फ़ंक्शनल, टेक्निकल और Basis टीमों में लिए जाते हैं। किसी केंद्रीय आर्किटेक्ट या प्रोग्राम टेस्ट लीड के पास उन फ़ैसलों को शुरू में ही चुनौती देने का अधिकार होना चाहिए।

RACI में इसे साफ़ लिखिए: स्वीकृति के मानदंड कौन मंज़ूर करता है, मानदंड फ़ेल होने पर सुधार की ज़िम्मेदारी किसकी है, और परफ़ॉर्मेंस के आधार पर go-live कौन रोक सकता है।

RISE with SAP परफ़ॉर्मेंस टेस्टिंग की ज़िम्मेदारी को कैसे बदलता है?

इन्फ्रास्ट्रक्चर SAP का है: साइज़िंग, रीजन, नेटवर्क और प्लेटफ़ॉर्म की उपलब्धता। एप्लिकेशन की परफ़ॉर्मेंस क्लाइंट और पार्टनर की है: कॉन्फ़िगरेशन, एक्सटेंशन, OData और Fiori डिज़ाइन, इंटीग्रेशन फ़्लो और प्रक्रिया के KPI। SAP का RISE की भूमिकाओं और ज़िम्मेदारियों वाला दस्तावेज़ SQL ट्यूनिंग ग्राहक के पास ही छोड़ता है, जब तक SAP की अतिरिक्त सर्विसेज़ न ख़रीदी जाएँ।

यह बँटवारा स्वीकृति के मानदंडों में लिख दीजिए, ताकि हर सीमा का एक मालिक हो।

SAP Fiori की सबसे आम परफ़ॉर्मेंस समस्याएँ कौन सी हैं?

चार पैटर्न ज़्यादातर मामलों को समेट लेते हैं। शिफ़्ट शुरू होने पर लॉगिन की बाढ़, जब ऑथेंटिकेशन और लॉन्चपैड रेंडरिंग पर भार चढ़ता है। ऐसी OData सर्विस जो बड़े रिज़ल्ट सेट लौटाती हैं या हर इंटरैक्शन पर कई बैक-एंड कॉल करती हैं। गेटवे परत का अपने-आप में बॉटलनेक बन जाना, इसलिए टेस्ट के दौरान उसकी मॉनिटरिंग ज़रूरी है। और कस्टम या भारी बदलाव वाले ऐप, जहाँ स्टैंडर्ड परफ़ॉर्मेंस की धारणाएँ लागू नहीं होतीं।

SAP के लिए परफ़ॉर्मेंस की स्वीकृति के मानदंड कैसे तय करें?

ट्रांज़ैक्शन, लोड और सीमा का नाम लीजिए। जैसे: “ऑर्डर एंट्री रोल के 150 यूज़र एक साथ हों तो 95% ट्रांज़ैक्शन में ऑर्डर बनाना 3 सेकंड से कम में पूरा हो।” यह टेस्ट किया जा सकता है।

“सिस्टम पर्याप्त तेज़ होना चाहिए” टेस्ट नहीं किया जा सकता। Prepare फ़ेज़ में असली ऑपरेशन की ज़रूरतों के आधार पर बिज़नेस के साथ मानदंड तय कीजिए, और नतीजे आने के बाद उन्हें मत बदलिए।

परफ़ॉर्मेंस टेस्टिंग छोड़ दी जाए या दबा दी जाए तो क्या होता है?

समस्याएँ प्रोडक्शन में सामने आती हैं: जॉब अपनी विंडो पार कर दूसरों को रोकते हैं, पीक पर Fiori ऐप टाइम-आउट होते हैं, month-end close दोगुना समय लेकर रिपोर्टिंग की डेडलाइन चूक जाता है, इंटरफ़ेस क्यू जमा होने लगती हैं।

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