निष्पादन सिमेंटिक्स, बाधाएँ, सुरक्षा

यह पृष्ठ बताता है कि Script रनटाइम पर कैसे काम करता है (क्रम, ट्रांज़ैक्शन, एरर, लॉकिंग), सेव करते समय किन स्थैतिक बाधाओं के अधीन होता है, और इसका सुरक्षा मॉडल क्या है। सिंटैक्स के लिए Statement कैटलॉग और मान अभिव्यक्ति, और व्यावहारिक संयोजन के लिए कुकबुक देखें।

निष्पादन क्रम और मोड

• statements ऊपर से नीचे क्रमिक रूप से निष्पादित होते हैं। Return पर पहुँचते ही उसी बिंदु पर समाप्त हो जाता है।
• Sync अनुरोध को संसाधित करने वाले पथ पर, और Async बैकग्राउंड में निष्पादित होता है। यह केवल निष्पादन स्थान का भेद है; परिणाम दोनों ही स्थितियों में Return का मान होता है (कॉल की प्रतिक्रिया का स्वरूप Script अवलोकन में अनुरोध और प्रतिक्रिया और निष्पादन मोड देखें)।
• क्षमता (capability) से मोड तक: statement ट्री में ExternalIo (Http बाहरी कॉल), MediaIngest (Media फ़ाइल इंजेस्ट। fields.file का { source, encoding }। url और base64 दोनों के लिए समान), LongRunning (बड़े पैमाने का Loop आदि) में से कोई एक भी हो, तो executionMode Async अनिवार्य हो जाता है। ये तीनों अलग-अलग क्षमताएँ हैं, और नीचे स्थैतिक बाधाएँ में गिनती का दायरा अलग-अलग होता है।

निष्पादन सिमेंटिक्स

Guard (पूर्व शर्त)

कोई समर्पित guard statement नहीं है। इसे If और then:[Return] से व्यक्त किया जाता है। शर्त के उल्लंघन पर परिणाम लौटाया जाता है और इसके बाद के statement निष्पादित नहीं होते (guard रहित Script भी निश्चित रूप से संभव है)।

{ "type": "If", "condition": { "<": [ "{ /wallet/fields/balance/en-US }", "{ /payload/fields/cost }" ] },
  "then": [ { "type": "Return", "value": { "ok": false, "reason": "insufficient credit" }, "statusCode": 402 } ] }

ट्रांज़ैक्शन नहीं और best-effort क्षतिपूर्ति

Script ट्रांज़ैक्शन नहीं है। विफलता पर इंजन अब तक किए गए कार्यों की क्षतिपूर्ति (compensation) का प्रयास करता है और एरर का कारण लौटाता है, पर इसकी निम्नलिखित सीमाएँ हैं (डिज़ाइन के तहत स्वीकार्य)।

• डिलीट को पूर्ववत करना एक नया sys.id बनाता है, जिससे इसे इंगित करने वाले संदर्भ टूट जाते हैं (निर्माण का रोलबैक आसान है, और संशोधन के लिए before-image चाहिए)।
• बाहरी प्रभाव (Http) अपरिवर्तनीय है (जो कॉल पहले ही जा चुकी है और उसका शुल्क वापस नहीं लिया जा सकता)।
• प्रोसेस क्रैश होने पर अप्रतिपूरित अवस्था (orphan) रह सकती है।

यदि वास्तविक परमाणुता (atomicity) चाहिए, तो उपयोगकर्ता Script से सीधे क्षतिपूर्ति करता है, या अपरिवर्तनीय कार्यों (जैसे बाहरी कॉल) को सबसे अंत में रखता है। "जिसमें शृंखलन तो हो जाता है पर रोलबैक नहीं होता, और फिर भी जो सुरक्षित दिखता है" ऐसा क्रम सबसे खतरनाक है।

आशावादी लॉकिंग

update/patch की टक्कर को ResourceUpdate और ResourcePatch के version से सीमित किया जाता है। version (मान अभिव्यक्ति, Int) देने पर लक्ष्य के वर्तमान sys.version से मेल खाने पर ही अद्यतन होता है, और मेल न खाने पर वर्ज़न टकराव एरर के साथ abort हो जाता है (Try/catch से स्थानीय रूप से संभाला जा सकता है)। इसे छोड़ देने पर बिना जाँच के last-write-wins होता है। आमतौर पर ResourceRead या ResourcePageRead से पहले पढ़कर उसका sys.version पास किया जाता है (कुकबुक में आशावादी लॉकिंग CAS देखें)।

origin के आधार पर लेखन

लेखन हमेशा origin (draft) में परिलक्षित होता है, और delivery (CDA/ACDA) पर दृश्यता publish से नियंत्रित होती है (ResourceCreate/ResourceUpdate/ResourcePatch का publish, या ResourcePublish/ResourceUnpublish)।

किसे विफलता माना जाता है

• वास्तविक विफलता एक statement रनटाइम एरर है: Http का अंतिम status 400 या उससे अधिक होना (4xx·5xx; ignoreStatusCode: true होने पर विफलता नहीं) या टाइमआउट, प्रतिक्रिया body का 10MiB से अधिक होना, रिसोर्स कार्य की विफलता (लक्ष्य न मिलना, वर्ज़न टकराव, असमर्थित संक्रिया आदि)। ऐसी विफलताओं में इंजन abort करके क्षतिपूर्ति करता है, और Try/catch/finally से स्थानीय रूप से संभाला जा सकता है।
• Return कोई एरर नहीं, बल्कि एक सामान्य समय-पूर्व समाप्ति है। यह catch का लक्ष्य नहीं है (उपयोगकर्ता throw की कोई अवधारणा नहीं है)।
• catch के भीतर /error से { message, statement } को संदर्भित किया जाता है।

सर्वर-साइड एग्रीगेशन नहीं

count, sum, group-by के लिए समर्पित कोई सर्वर कार्य नहीं है। गणना ResourcePageRead से पेज-दर-पेज पढ़कर और SetVar/JsonLogic से की जाती है, इसलिए यह fetch आकार और maxIterations से बँधी होती है (कई मिलियन रिकॉर्ड के एग्रीगेशन के लिए अनुपयुक्त)।

प्रतीक्षा और विलंब नहीं

Script में Delay statement नहीं है। Script अनुरोध पथ (Sync) या बैकग्राउंड (Async) में एक बार निष्पादित होकर समाप्त हो जाता है, और बाहरी job के समाप्त होने तक भीतर प्रतीक्षा या पोलिंग नहीं करता (Async का परिणाम अलग बात है। कॉलर 202 के साथ प्राप्त requestId से पोलिंग करके Return का मान प्राप्त करता है)।

स्थैतिक बाधाएँ (सेव करते समय जाँच)

नीचे दी गई बातें Script को सेव (बनाते/संशोधित करते) करते समय जाँची जाती हैं। उल्लंघन होने पर सेव अस्वीकार कर दिया जाता है (यह रनटाइम पर नहीं, बल्कि रचना के समय की विफलता है)।

सीमाओं को सर्वर सेटिंग (weegloo.core.script.*) से समायोजित किया जा सकता है (ऊपर के मान डिफ़ॉल्ट हैं)।

Media फ़ाइल इंजेस्ट MediaIngest क्षमता है, और Http बाहरी कॉल (ExternalIo) के विपरीत maxExternalIo (3) की सीमा में शामिल नहीं होती। हालाँकि Async अनिवार्यता और Loop body निषेध Http की तरह ही लागू होते हैं।

समय बजट (रनटाइम)

प्रति प्लान संख्या सीमा

Script एक Billable रिसोर्स है, और प्रति Organization संख्या प्लान के अनुसार सीमित होती है।

सीमा तक पहुँचने पर नए Script का निर्माण अस्वीकार कर दिया जाता है (अन्य Billable रिसोर्स के समान ही मार्ग)।

सुरक्षा मॉडल

secret हेडर

Http.headers का secret:true आइटम केवल CMA (एडमिन) के लिए होता है, यह अंतिम उपयोगकर्ता (ServiceUser) को उजागर नहीं होता और केवल भेजने से ठीक पहले डिक्रिप्ट होता है। LLM API key जैसे रहस्य यहाँ रखे जाते हैं (App Bundle में पैक होते समय भी secret मान मास्क कर दिया जाता है और मूल space से बाहर नहीं जाता)।

निष्पादन पहचान और प्राधिकरण

• निष्पादन पहचान: निष्पादन के दौरान सभी रिसोर्स कार्य उस उपयोगकर्ता की पहचान से किए जाते हैं जिसने /execute को कॉल किया। बनाए या संशोधित होने वाले रिसोर्स के createdBy/updatedBy कॉलर होते हैं, और createdBy: ":self" स्कोप भी कॉलर के आधार पर हल होता है।
• प्राधिकरण की सीमाएँ दो हैं, और रनटाइम पर हर statement के लिए रिसोर्स अनुमति की पुनः जाँच नहीं होती।
  1. रचना के समय (सेव): Script को सेव करते समय जाँच होती है कि रचयिता के पास उन statement द्वारा उपयोग किए जाने वाले रिसोर्स और एक्शन की अनुमति वास्तव में है या नहीं। एक भी न हो, तो सेव अस्वीकार हो जाता है (WGL403015)। यानी, बिना अनुमति वाले कार्य वाला Script शुरू से ही सेव नहीं होता।
  2. कॉल के समय (/execute): केवल कॉलर की Script Execute अनुमति की जाँच होती है। अनुमति न हो, तो 403 मिलता है। पास होने पर हर statement की रिसोर्स अनुमति रनटाइम पर दोबारा जाँचे बिना निष्पादित होती है। यह प्रोग्रामिंग में किसी फ़ंक्शन को निष्पादित करने की अनुमति जैसा ही तरीका है। फ़ंक्शन को निष्पादित करने की अनुमति भर होने पर, उसके भीतर के अलग-अलग कार्यों की अनुमति दोबारा नहीं पूछी जाती।
• स्वामित्व स्कोप: where फ़िल्टर का createdBy: ":self" का अर्थ है "केवल वही जो वर्तमान कॉलर ने बनाया" (उदाहरण: केवल अपना वॉलेट देखना)।
• प्रत्यायोजित अनुमति (रचना में सावधानी): ऊपर की दोनों सीमाओं को मिलाने पर, Script का निष्पादन रचयिता की अनुमति प्रत्यायोजित रूप में पाकर किए जाने जैसा है। कॉलर के पास केवल Execute भर होना चाहिए, और Script के भीतर के statement रचयिता को सेव के समय अधिकृत दायरे में ही निष्पादित होते हैं। इसलिए ऐसे रिसोर्स कार्य भी, जो कॉलर स्वयं नहीं कर सकता, Script के माध्यम से हो सकते हैं। रचयिता को दी गई अनुमति ही उस Script का प्रभाव-क्षेत्र है, इसलिए Script में शामिल किए जाने वाले कार्य सावधानी से तय किए जाते हैं।

सारांश चेकलिस्ट

सेव करने से पहले निम्नलिखित की पुष्टि करें।

• बाहरी कॉल (Http) या Media फ़ाइल इंजेस्ट होने पर executionMode "Async" है।
• Loop body के भीतर कोई बाहरी कॉल नहीं डाली है।
• बाहरी कॉल 3 या उससे कम, SetVar 5 या उससे कम, कुल statement 15 या उससे कम हैं।
• secret मान केवल Http.headers के secret:true से ही डाले हैं।
• अपरिवर्तनीय कार्य (बाहरी कॉल) यथासंभव बाद में रखे हैं।
• update/patch की टक्कर की चिंता हो, तो ResourceUpdate या ResourcePatch के version का उपयोग करते हैं।
• परिणाम लौटाना हो, तो Return.value निर्दिष्ट किया है।

संबंधित दस्तावेज़

• मान अभिव्यक्ति: मान और शर्त के नियम।
• Statement कैटलॉग: प्रत्येक statement के फ़ील्ड और परिणाम।
• कुकबुक: पूर्ण उदाहरणों का संग्रह।
• Script रिसोर्स और एंडपॉइंट: Script रिसोर्स संरचना और /execute जैसे HTTP एंडपॉइंट।
• Script अवलोकन: शीर्ष-स्तरीय संरचना और निष्पादन मोड।