SAP Integration Suite: फ़ैसले और प्रोडक्शन के ट्रेड-ऑफ़

SAP Integration Suite, SAP BTP पर SAP का इंटीग्रेशन प्लेटफ़ॉर्म है: Cloud Integration (पूर्व CPI) के साथ API Management, Event Mesh, Integration Advisor, Open Connectors और PI/PO से माइग्रेट करने के टूल। S/4HANA क्लाउड प्रोग्राम के लिए यह डिफ़ॉल्ट मिडलवेयर है और PI/PO से बाहर निकलने का रास्ता भी, जिसका मेनस्ट्रीम मेंटेनेंस 2027 में ख़त्म होता है। इंटरफ़ेस में देरी शायद ही कभी टेक्नोलॉजी से आती है। वह आती है अस्पष्ट ओनरशिप से, लेगेसी सिस्टम के बारे में बिना जाँची धारणाओं से, और ऐसी टेस्टिंग से जो फ़ेल होने वाली चीज़ें खोजने की जगह पास होने के लिए डिज़ाइन की गई हो। यह गाइड इंटीग्रेशन लीड, आर्किटेक्ट और प्रोग्राम मैनेजर के लिए है। इसमें बताया है कि हर कॉम्पोनेंट किस काम के लिए है, स्टैंडर्ड बनाम कस्टम कंटेंट, PI/PO माइग्रेशन, लेगेसी और टेस्टिंग के जोखिम, और go-live के बाद की गवर्नेंस।

PI/PO की घड़ी चल रही है। SAP Process Integration और Process Orchestration 7.5, 2027 के अंत तक मेनस्ट्रीम मेंटेनेंस में हैं। वैकल्पिक एक्सटेंडेड मेंटेनेंस 2030 के अंत तक चलता है, उसके बाद SAP सपोर्ट ख़त्म हो जाता है। SAP का माइग्रेशन रेफ़रेंस आर्किटेक्चर रास्ता बताता है। Integration Suite में एक Migration Assessment एप्लिकेशन है जो हर PI/PO सिनेरियो का आकार तय करता है, और Cloud Integration में विज़ार्ड-आधारित माइग्रेशन टूलिंग है। चरणों में माइग्रेट कीजिए: पहले कम जोखिम वाले SAP-से-SAP फ़्लो, बीच में B2B और EDI, और आख़िर में ज़्यादा वॉल्यूम वाले ऑर्डर फ़्लो। डेडलाइन के दबाव में जबरन कटओवर करने में ज़्यादा समय लगता है और ज़्यादा लागत आती है।

1. वेव 1कम जोखिम वाले SAP-से-SAP फ़्लोहर सिनेरियो का पहले Migration Assessment से आकलन कीजिए
2. वेव 2B2B और EDI
3. वेव 3ज़्यादा वॉल्यूम वाले ऑर्डर फ़्लो
4. 2027PI/PO 7.5 का मेनस्ट्रीम मेंटेनेंस ख़त्मसाल का अंत। वेव इससे पहले पूरी होने की योजना बनाइए
5. 2030वैकल्पिक एक्सटेंडेड मेंटेनेंस ख़त्मसाल का अंत। उसके बाद SAP सपोर्ट ख़त्म

स्रोत: SAP की मेंटेनेंस तारीख़ें और माइग्रेशन रेफ़रेंस आर्किटेक्चर, अक्टूबर 2026 में जाँचे गए

अपने क्लाउड अनुबंध में क्या शामिल है, जाँचिए। RISE और GROW अनुबंधों में आम तौर पर SAP BTP क्रेडिट शामिल होते हैं जिनसे Integration Suite का भुगतान हो सकता है। Integration Suite की MuleSoft या Boomi से सिर्फ़ फ़ीचर के आधार पर तुलना करने से पहले पक्का कर लीजिए कि आपकी एंटाइटलमेंट कौन-सा एडिशन और कितने मैसेज वॉल्यूम कवर करती है। जब प्लेटफ़ॉर्म शामिल हो, तो तुलना का अर्थशास्त्र बदल जाता है।

AI चरणों में आ रहा है। Cloud Integration 2024 के मध्य से अपने Premium एडिशन में जनरेटिव AI से फ़्लो जनरेशन देता है। वह iFlow का ढाँचा बनाता है (स्टेप, चैनल, एक्सेप्शन सबप्रोसेस), मैपिंग या स्क्रिप्ट नहीं। मार्च 2026 में लॉन्च हुआ SAP का एन्हांस्ड एडिशन टेक्स्ट-टू-फ़्लो जनरेशन और स्क्रिप्ट ऑप्टिमाइज़ेशन जोड़ता है, और SAP ने 2026 की तीसरी तिमाही में Integration Suite में Joule की जनरल अवेलेबिलिटी की योजना बनाई थी। स्टैंडर्ड फ़्लो के लिए उपयोगी है। गहरे बिज़नेस लॉजिक वाले जटिल ऑर्केस्ट्रेशन को अब भी सीनियर आर्किटेक्ट चाहिए।

Integration Suite सेवाओं का समूह है। काम के लिए सही सेवा चुनने से तय होता है कि लैंडस्केप कितना टिकता है।

कॉम्पोनेंट	भूमिका	ग़लत इस्तेमाल पर क्या बिगड़ता है
Cloud Integration (CPI)	मैसेज फ़्लो, रूटिंग और ट्रांसफ़ॉर्मेशन, ज़्यादातर iFlow के लिए डिफ़ॉल्ट	API और इवेंट समेत सब कुछ CPI में ठूँस दिया जाए, तो उसे सपोर्ट और टेस्ट करना मुश्किल हो जाता है
API Management	API एक्सपोज़र को गवर्न करता है: सिक्योरिटी, रेट लिमिट, एनालिटिक्स	इसे छोड़ देंगे तो पॉइंट-टू-पॉइंट कॉल बढ़ते जाते हैं, और गवर्नेंस बाद में जोड़ना मुश्किल होता है
Event Mesh	डिकपल्ड ट्रिगर के लिए असिंक्रोनस मैसेजिंग	बिना ट्रैक की कतारें किसी को अलर्ट किए बिना चुपचाप बढ़ती जाती हैं
Integration Advisor	EDIFACT, X12 और IDoc जैसे B2B फ़ॉर्मेट के लिए मैपिंग प्रस्ताव	टीमें ऊँचा कवरेज मान लेती हैं, एक टीम को 80% की उम्मीद थी और मिला 40% के आसपास
Open Connectors	थर्ड-पार्टी क्लाउड ऐप के लिए पहले से बने कनेक्टर	कोई मॉनिटर न करे तो बाहरी API बदलने पर कनेक्टर चुपचाप टूट जाते हैं
Migration Assessment और टूलिंग	PI/PO सिनेरियो का आकार तय करता है और उन्हें माइग्रेट करता है	इसे असली माइग्रेशन प्लान की जगह एक बार का अनुमान मान लिया जाता है

जो टीमें Integration Suite को “ऐड-ऑन वाला CPI” मानती हैं, वे अक्सर API Management और Event Mesh को नज़रअंदाज़ कर देती हैं। यह तब तक चलता है जब तक जटिलता पकड़ नहीं लेती। Cloud Integration पर और गहराई के लिए मेरी SAP CPI गाइड देखिए।

प्रोसेस स्टैंडर्ड हो तो SAP का पहले से बना इंटीग्रेशन कंटेंट सचमुच उपयोगी होता है। स्टैंडर्ड प्रोसेस के साथ S/4HANA को SAP Ariba या SuccessFactors से जोड़ना अक्सर सही बैठता है। असली प्रोसेस शायद ही कभी SAP की रेफ़रेंस रेखाओं के भीतर रहते हैं।

स्टैंडर्ड कंटेंट तब चुनिए जब:

1. सिनेरियो SAP-से-SAP हो और SAP के रेफ़रेंस प्रोसेस के क़रीब हो
2. फ़्लो सरल हो और ज़्यादातर एकतरफ़ा
3. आप SAP की मैपिंग के साथ रह सकें और सिर्फ़ दिए गए एक्ज़िट के ज़रिए एक्सटेंड करें

कस्टम बिल्ड तब चुनिए जब:

1. सालों के आंतरिक फ़ैसलों ने प्रोसेस को SAP के मॉडल से दूर कर दिया हो
2. कंडीशनल रूटिंग, मल्टी-स्टेप लॉजिक या लेगेसी की अजीब आदतें शामिल हों
3. भारी बदलाव स्टैंडर्ड पैकेज के लिए SAP की सपोर्ट अलाइनमेंट तोड़ देंगे

यह फ़ैसला ब्लूप्रिंट फ़ेज़ में लीजिए। देर से लिया जाए, तो टीमें प्रोजेक्ट के बीच में पाती हैं कि “स्टैंडर्ड” iFlow में इतना बदलाव हो चुका है कि वह सपोर्ट अलाइनमेंट खो बैठा है, और go-live के दबाव में उसे दोबारा बनाना पड़ता है। मैंने ऐसे प्रोजेक्ट देखे हैं जिनके हफ़्ते इसलिए गए कि टीमों ने मान लिया था कि स्टैंडर्ड कंटेंट कस्टम मास्टर डेटा स्ट्रक्चर, अतिरिक्त फ़ील्ड और लेगेसी ऑथेंटिकेशन, सब एक साथ सोख लेगा। उसने नहीं सोखा। जो विश्लेषण डिज़ाइन में होना था, वह UAT में हुआ।

बड़े SAP प्रोग्राम में इंटीग्रेशन अक्सर सबसे पहले वर्कस्ट्रीम के बीच की दरार में गिरता है। इंटरफ़ेस टीम की सीमाएँ लाँघते हैं, पर तालमेल का मालिक कोई नहीं होता। मैंने दो प्रोजेक्ट टीमों को एक ही बिज़नेस पार्टनर के लिए अलग-अलग इंटीग्रेशन बनाते देखा है, एक ही एंडपॉइंट की ओर इशारा करते हुए, एक-दूसरे की ख़बर के बिना। दोनों को UAT तक पता नहीं चला। यह ढाँचागत विफलता है, तकनीकी नहीं।

सेंट्रल इंटीग्रेशन गवर्नेंस जल्दी बनाइए:

1. एक साझा इंटीग्रेशन बैकलॉग जो हर वर्कस्ट्रीम को दिखे
2. हर इंटरफ़ेस का एक नामित मालिक, जिसे डिलीवरी में ट्रैक किया जाए
3. हर बड़े डिप्लॉयमेंट से पहले वर्कस्ट्रीम के बीच तालमेल के चेकपॉइंट
4. किसी भी go-live की प्रतिबद्धता से पहले इंटरफ़ेस निर्भरताओं की समीक्षा, जिसमें साझा एंडपॉइंट और कतारें कटओवर प्लान में क्रम से रखी गई हों
5. एनवायरनमेंट के बीच ऑटोमेटेड डिप्लॉयमेंट, हर लैंडस्केप के लिए दर्ज क्रेडेंशियल के साथ

सबसे कठिन इंटीग्रेशन समस्याएँ शायद ही कभी आधुनिक प्लेटफ़ॉर्म की होती हैं। वे पुराने सिस्टम की होती हैं जो अहम प्रोसेस के बीच में बैठे हैं।

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

प्रोटोकॉल का बेमेल होना आम है और देर से पता चलता है। आप OAuth2 और REST के साथ डिज़ाइन करते हैं, और लेगेसी सिस्टम SOAP बोलता है जिसमें 30 सेकंड का हार्डकोडेड टाइमआउट है और जो टोकन रिफ़्रेश ठीक से नहीं सँभालता।

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

टेबल में वे जोखिम हैं जिन्हें डिज़ाइन फ़्रीज़ से पहले जाँचना चाहिए।

जोखिम	आम समस्या	डिज़ाइन में क्या करें
सिंक्रोनस सीमाएँ	पैरेलल कॉल पर लेगेसी लॉक हो जाता है	असिंक्रोनस मैसेजिंग इस्तेमाल कीजिए, Event Mesh या Cloud Integration से कॉल अलग-अलग समय पर भेजिए
प्रोटोकॉल बेमेल	लेगेसी REST या OAuth ठुकरा देता है, या SOAP पर टाइमआउट हो जाता है	डिज़ाइन शुरू होने से पहले प्रोटोकॉल और टाइमआउट पक्के कर लीजिए
API रेट लिमिट	बैच जॉब थर्ड-पार्टी की थ्रॉटलिंग से ऊपर चले जाते हैं	API Management में थ्रॉटल कीजिए, iFlow में वेट लॉजिक जोड़िए
टोकन एक्सपायरी	ऑफ़-पीक विंडो में फ़्लो चुपचाप फ़ेल हो जाते हैं	रिफ़्रेश साइकिल शेड्यूल कीजिए और एक्सपायरी मॉनिटर कीजिए
कठोर फ़ॉर्मेट	डायनैमिक पेलोड लेगेसी की पार्सिंग तोड़ देते हैं	असली प्रोडक्शन सैंपल से वैलिडेट कीजिए
फ़ॉलबैक नहीं	फ़ाइल ट्रांसफ़र बिना रीट्राई के फ़ेल होते हैं और डेटा अटक जाता है	मिडलवेयर में बफ़र कीजिए, iFlow में रीट्राई और अलर्टिंग बनाइए

क्रॉस-क्लाउड रूप में इन समस्याओं के लिए Salesforce के साथ ERP इंटीग्रेशन क्यों फ़ेल होता है और उसे कैसे ठीक करें पर मेरा लेख देखिए।

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

इंटरफ़ेस टेस्टिंग में ये कवर होने चाहिए:

1. असली डेटा वॉल्यूम, एक साथ काम करते यूज़र के साथ
2. सेवा में रुकावट और रिकवरी का व्यवहार
3. मिडलवेयर और बैक एंड में टाइमआउट और रीट्राई
4. रियल-टाइम कॉल के साथ चलते बैच जॉब
5. महीने का अंत और दूसरे पीक पीरियड

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

Integration Advisor स्ट्रक्चर्ड B2B फ़ॉर्मेट के लिए मैपिंग प्रस्ताव देता है। जो पार्टनर सख़्त परंपराओं का पालन करते हैं, उनके लिए यह सेटअप का असली समय बचाता है। लेगेसी सिस्टम, कस्टम फ़ील्ड, कंडीशनल लॉजिक और बिना दर्ज नियमों वाले एंटरप्राइज़ इंटीग्रेशन के लिए यह शुरुआती बिंदु है।

मेरे साथ काम करने वाली एक टीम को 80% मैपिंग कवरेज की उम्मीद थी। असल कवरेज 40% के आसपास था। बाक़ी को कस्टमाइज़ करना, बिज़नेस के साथ वैलिडेट करना और मैनुअली टेस्ट करना पड़ा।

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

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

हर इंटरफ़ेस को, कम वॉल्यूम वाले को भी, मॉनिटरिंग, एस्केलेशन और लाइफ़साइकल बदलावों के लिए एक नामित मालिक चाहिए। इसके बिना, बिज़नेस इंतज़ार करता रहता है और विफलताएँ Basis, मिडलवेयर और फ़ंक्शनल टीमों के बीच टकराती रहती हैं। हाइपरकेयर के बाद मॉनिटरिंग धीमी पड़ने लगती है। नियमित एरर लॉग रिव्यू, प्रोजेक्ट से सपोर्ट को औपचारिक हैंडओवर और बिज़नेस तथा IT के बीच तय सर्विस लेवल बनाइए। उपेक्षित इंटीग्रेशन देरी से हुई कई पोस्टिंग, ग़ायब इनवॉइस और बेमेल फ़ाइनेंशियल रिपोर्ट के पीछे है, जो go-live के हफ़्तों बाद सामने आती हैं।

SAP Integration Suite क्या है और यह CPI से कैसे अलग है?

Cloud Integration, जिसे पहले SAP Cloud Platform Integration (CPI) कहा जाता था, Integration Suite के भीतर एक क्षमता है। सूट गवर्न्ड API एक्सपोज़र के लिए API Management और असिंक्रोनस मैसेजिंग के लिए Event Mesh जोड़ता है। इसमें B2B मैपिंग प्रस्तावों के लिए Integration Advisor, थर्ड-पार्टी क्लाउड ऐप के लिए Open Connectors, और PI/PO के लिए आकलन और माइग्रेशन टूल भी हैं। जो टीमें इसे नए नाम वाला CPI मानती हैं, वे अक्सर API Management और Event Mesh छोड़ देती हैं, और बाद में गवर्नेंस के गैप के रूप में क़ीमत चुकाती हैं।

SAP PI/PO का सपोर्ट कब ख़त्म होता है?

SAP Process Integration और Process Orchestration 7.5, 2027 के अंत तक मेनस्ट्रीम मेंटेनेंस में हैं। ग्राहक 2030 के अंत तक वैकल्पिक एक्सटेंडेड मेंटेनेंस ले सकते हैं, उसके बाद SAP सपोर्ट ख़त्म हो जाता है। Integration Suite में हर सिनेरियो का आकार तय करने के लिए Migration Assessment एप्लिकेशन और आर्टिफ़ैक्ट को अर्ध-स्वचालित रूप से ले जाने के लिए माइग्रेशन टूलिंग है। डेडलाइन का इंतज़ार करने की जगह वेव प्लान से शुरू कीजिए।

SAP इंटीग्रेशन में स्टैंडर्ड कंटेंट कब इस्तेमाल करें और कस्टम डेवलपमेंट कब?

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

जटिल प्रोग्राम में SAP इंटीग्रेशन विफलताओं की वजह क्या होती है?

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

SAP Integration Suite के लिए इंटीग्रेशन टेस्टिंग कैसे संरचित हो?

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

go-live के बाद SAP इंटीग्रेशन की गवर्नेंस कैसी हो?

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