मॉडल-चालित ऐप्स में प्रदर्शन के लिए डिज़ाइन प्रपत्र

ऐसे अनुभवों का निर्माण करना जहां कार्यों को जल्दी और कुशलता से पूरा किया जा सकता है, उपयोगकर्ता की संतुष्टि के लिए महत्वपूर्ण है. मॉडल-चालित ऐप्स को आपके उपयोगकर्ताओं की ज़रूरतों को पूरा करने वाले अनुभव बनाने के लिए अत्यधिक अनुकूलित किया जा सकता है, लेकिन यह जानना महत्वपूर्ण है कि मॉडल-चालित ऐप्स को प्रभावी ढंग से कैसे कोड करना, बनाना और चलाना है, जो दैनिक कार्यों पर काम करते समय उपयोगकर्ता द्वारा आपके ऐप को खोलने और नेविगेट करने पर तेज़ी से लोड होते हैं. प्रदर्शन के लिए अनुकूलित नहीं होने पर प्रदर्शन को एक ऐप के असंतोष का एक मुख्य कारक दिखाया गया है.

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

यह सुनिश्चित करना भी महत्वपूर्ण है कि उपयोगकर्ता अनुशंसित और समर्थित उपकरणों और न्यूनतम आवश्यक विनिर्देशों पर हैं. अधिक जानकारी: समर्थित वेब ब्राउज़र और मोबाइल डिवाइस

डेटा और टैब के साथ काम करना

इस अनुभाग में बताया गया है कि डेटा और टैब प्रदर्शित करने वाले नियंत्रण प्रपत्र के प्रदर्शन को कैसे प्रभावित करते हैं.

डिफ़ॉल्ट टैब का महत्व

डिफ़ॉल्ट टैब किसी प्रपत्र पर पहला विस्तारित टैब होता है. यह प्रपत्र पेज को लोड करने में विशेष भूमिका निभाता है. डिज़ाइन के अनुसार, रिकॉर्ड खोलते समय डिफ़ॉल्ट टैब के नियंत्रण हमेशा रेंडर किए जाते हैं. विशेष रूप से, प्रत्येक नियंत्रण के लिए नियंत्रण आरंभीकरण तर्क, जैसे डेटा पुनर्प्राप्ति को टैब पर लागू किया जाता है.

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

हमेशा सबसे अधिक उपयोग किए जाने वाले नियंत्रणों को आपके डिफ़ॉल्ट टैब के सबसे ऊपर रखें. जब उपयोगकर्ता प्रपत्र पर डेटा के साथ इंटरैक्ट करते हैं तो लेआउट और सूचना आर्किटेक्चर न केवल प्रदर्शन के लिए बल्कि उत्पादकता में सुधार करने के लिए भी महत्वपूर्ण है. अधिक जानकारी: मॉडल-संचालित ऐप्स में उत्पादक मुख्य प्रपत्र डिज़ाइन करें

डेटा-संचालित नियंत्रण

जिन नियंत्रणों को प्राथमिक रिकॉर्ड से परे अतिरिक्त डेटा की आवश्यकता होती है, वे प्रपत्र प्रतिक्रिया और लोडिंग गति पर सबसे अधिक दबाव उत्पन्न करते हैं. ये नियंत्रण नेटवर्क पर डेटा प्राप्त करते हैं और इसमें अक्सर प्रतीक्षा अवधि (प्रगति संकेतक के रूप में देखा जाता है) शामिल होती है क्योंकि डेटा ट्रांसमिट करने में समय लग सकता है.

कुछ डेटा-संचालित नियंत्रणों में शामिल हैं:

• त्वरित दृश्य फ़ॉर्म
• सब-ग्रिड
• टाइमलाइन
• सहायक (Dynamics 365 Sales Insights की आवश्यकता है)

इन नियंत्रणों में से केवल सबसे अधिक उपयोग किए जाने वाले नियंत्रणों को डिफ़ॉल्ट टैब पर रखें. शेष डेटा-चालित नियंत्रणों को माध्यमिक टैब में वितरित किया जाना चाहिए, ताकि डिफ़ॉल्ट टैब शीघ्रता से लोड हो सके. इसके अलावा, यह लेआउट रणनीति अप्रयुक्त होने वाले डेटा को प्राप्त करने की संभावना को कम करती है.

ऐसे अन्य नियंत्रण हैं जो डेटा-संचालित नियंत्रणों की तुलना में कम प्रभावशाली हैं लेकिन फिर भी सर्वोत्तम प्रदर्शन प्राप्त करने के लिए उपरोक्त लेआउट रणनीति में भाग ले सकते हैं. इन नियंत्रणों में शामिल हैं:

• लुकअप
• iFrame
• वेब संसाधन

वेब ब्राउज़र

इस अनुभाग में वेब ब्राउज़र के साथ उपयोग करने के लिए अच्छे अभ्यास शामिल हैं.

नई विंडो न खोलें

openForm क्लाइंट API विधि एक पैरामीटर विकल्प को एक नई विंडो में एक प्रपत्र दिखाने देती है. इस पैरामीटर का उपयोग न करें या इसे गलत पर सेट न करें. इसे गलत पर सेट करने से यह सुनिश्चित होगा कि openForm विधि मौजूदा विंडो का उपयोग करके प्रपत्र को दिखाने का डिफ़ॉल्ट व्यवहार करती है. कस्टम स्क्रिप्ट या किसी अन्य एप्लिकेशन से सीधे window.open JavaScript फ़ंक्शन को कॉल करना भी संभव है; हालांकि, इससे भी बचना चाहिए. एक नई विंडो खोलने का अर्थ है कि सभी पृष्ठ संसाधनों को लाने और शुरू से लोड करने की आवश्यकता है, क्योंकि पृष्ठ पहले से लोड किए गए प्रपत्र और एक नई विंडो में प्रपत्र के बीच इन-मेमोरी डेटा कैशिंग क्षमताओं का लाभ उठाने में असमर्थ है. नई विंडो खोलने के विकल्प के रूप में, बहुसत्र अनुभव का उपयोग करने पर विचार करें जो क्लाइंट कैशिंग के प्रदर्शन लाभों को अधिकतम करते हुए रिकॉर्ड को कई टैब में खोलने देता है.

आधुनिक ब्राउज़र का उपयोग करें

सबसे आधुनिक वेब ब्राउज़र का उपयोग करना यह सुनिश्चित करने के लिए महत्वपूर्ण है कि आपका मॉडल-चालित ऐप यथासंभव तेज़ चलता रहे. इसका कारण यह है कि कई प्रदर्शन सुधार केवल नए आधुनिक ब्राउज़रों में ही उपयोग किए जा सकते हैं.

उदाहरण के लिए, यदि आपके संगठन के पास Firefox, गैर-Chromium-आधारित ब्राउज़र आदि के पुराने संस्करण हैं, तो मॉडल-चालित ऐप में निर्मित कई प्रदर्शन लाभ पुराने ब्राउज़र संस्करणों में उपलब्ध नहीं होंगे क्योंकि वे उन विशेषताओं का समर्थन नहीं करते हैं जिन पर ऐप तेज़ी से और आसानी से चलने के लिए निर्भर करता है.

ज्यादातर मामलों में, आप केवल Microsoft Edge पर स्विच करके, पुराने संस्करण से नवीनतम मौजूदा ब्राउज़र संस्करण में अपडेट करके, या आधुनिक Chromium-आधारित ब्राउज़र पर जाकर पेज लोड सुधार देखने की उम्मीद कर सकते हैं.

JavaScript अनुकूलन

इस अनुभाग में बताया गया है कि जब आप JavaScript का उपयोग करते हैं तो वे इंटेलीजेंट अनुकूलन कैसे करें जो आपको मॉडल-चालित ऐप में प्रदर्शन करने वाले प्रपत्र और पेज बनाने में मदद करता है.

प्रपत्रों के साथ JavaScript का उपयोग करना

प्रपत्रों को JavaScript द्वारा अनुकूलित करने की क्षमता पेशेवर डेवलपर्स को इस बात पर बहुत लचीलापन प्रदान करती है कि एक प्रपत्र कैसा दिखता है और व्यवहार करता है. इस लचीलेपन का अनुचित उपयोग प्रपत्र के प्रदर्शन को नकारात्मक रूप से प्रभावित कर सकता है. JavaScript अनुकूलन को लागू करते समय डेवलपर्स को प्रपत्र प्रदर्शन को अधिकतम करने के लिए निम्नलिखित रणनीतियों का उपयोग करना चाहिए.

डेटा का अनुरोध करते समय एसिंक्रोनस नेटवर्क अनुरोधों का उपयोग करें

अनुकूलन के लिए अतिरिक्त डेटा आवश्यक होने पर डेटा को सिंक्रोनाइज़ के बजाय एसिंक्रोनस रूप से अनुरोध करें. ऐसे इवेंट के लिए जो प्रपत्र OnLoad जैसे एसिंक्रोनस कोड की प्रतीक्षा का समर्थन करते हैं और प्रपत्र OnSave इवेंट बनाते हैं, इवेंट हैंडलर्स को एक Promise लौटाना चाहिए ताकि प्लेटफ़ॉर्म Promise के निपटारे तक प्रतीक्षा कर सके. जब उपयोगकर्ता इवेंट के पूरा होने की प्रतीक्षा करता है, तो प्लेटफ़ॉर्म एक उचित UI दिखाएगा.

एसिंक्रोनस कोड की प्रतीक्षा का समर्थन नहीं करने वाले इवेंट के लिए, जैसे प्रपत्र OnChange इवेंट, आप एक प्रपत्र के साथ इंटरैक्शन को रोकने के लिए वर्कअराउंड का उपयोग कर सकते हैं, जबकि कोड showProgressIndicator का उपयोग करके एसिंक्रोनस अनुरोध कर रहा है. यह सिंक्रोनस अनुरोधों का उपयोग करने से बेहतर है, क्योंकि जैसे ही प्रगति संकेतक प्रदर्शित किया जाता है वैसे ही उपयोगकर्ता अभी भी अनुप्रयोग के अन्य हिस्सों के साथ इंटरैक्ट करने में सक्षम होंगे.

सिंक्रोनस एक्सटेंशन बिंदुओं में एसिंक्रोनस कोड का उपयोग करने का एक उदाहरण यहां दिया गया है.

//Only do this if an extension point does not yet support asynchronous code
try {
    await Xrm.WebApi.retrieveRecord("settings_entity", "7333e80e-9b0f-49b5-92c8-9b48d621c37c");
    //do other logic with data here
} catch (error) {
    //do other logic with error here
} finally {
    Xrm.Utility.closeProgressIndicator();
}

// Or using .then/.finally
Xrm.Utility.showProgressIndicator("Checking settings...");
Xrm.WebApi.retrieveRecord("settings_entity", "7333e80e-9b0f-49b5-92c8-9b48d621c37c")
    .then(
        (data) => {
            //do other logic with data here
        },
        (error) => {
            //do other logic with error here
        }
    )
    .finally(Xrm.Utility.closeProgressIndicator);

किसी ऐसे इवेंट हैंडलर में एसिंक्रोनस कोड का उपयोग करते समय आपको सावधान रहना चाहिए जो एसिंक्रोनस कोड की प्रतीक्षा का समर्थन नहीं करता है. यह कोड के लिए विशेष रूप से सच है जिसे एसिंक्रोनस कोड के समाधान पर कार्रवाई करने या संभालने की आवश्यकता होती है. यदि समाधान हैंडलर को यह उम्मीद है कि अनुप्रयोग का संदर्भ वैसा ही रहेगा जैसा कि एसिन्क्रॉनस कोड शुरू होने पर था, तो एसिन्क्रॉनस कोड समस्याएँ पैदा कर सकता है. आपके कोड को यह जांचना चाहिए कि प्रत्येक एसिंक्रोनस निरंतरता बिंदु के बाद उपयोगकर्ता एक ही संदर्भ में है.

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

OnLoad प्रपत्र और OnSave प्रपत्र इवेंट्स में Async समर्थन

प्रपत्र OnLoad और OnSave इवेंट्स वादों को लौटाने वाले हैंडलर का समर्थन करते हैं. एक टाइमआउट अवधि तक इवेंट हल करने के लिए हैंडलर द्वारा लौटाए गए किसी भी वादे की प्रतीक्षा करेंगे. यह समर्थन ऐप सेटिंग के माध्यम से सक्षम किया जा सकता है.

और जानकारी:

• प्रपत्र OnLoad
• प्रपत्र OnSave
• HTTP और HTTPS संसाधनों के साथ एसिन्क्रॉनस रूप में इंटरैक्ट करता है

प्रपत्र लोड के दौरान अनुरोधित डेटा की मात्रा सीमित करें

केवल उस न्यूनतम मात्रा में डेटा का अनुरोध करें जो किसी प्रपत्र पर व्यावसायिक तर्क निष्पादित करने के लिए आवश्यक है. जितना संभव हो सके अनुरोध किए गए डेटा को कैशे करें, विशेष रूप से उस डेटा के लिए जो अक्सर नहीं बदलता है या जिसे रीफ़्रेश करने की आवश्यकता नहीं है. उदाहरण के लिए, कल्पना करें कि एक प्रपत्र है जो सेटिंग तालिका से डेटा का अनुरोध करता है. सेटिंग तालिका में डेटा के आधार पर, प्रपत्र के किसी अनुभाग को छिपाने का विकल्प प्रपत्र चुन सकता है. इस मामले में, JavaScript डेटा को sessionStorage में कैशे कर सकता है ताकि डेटा का प्रति सत्र (onLoad1) केवल एक बार के लिए अनुरोध किया जा सके. एक पुरानी-जबकि-पुनर्मूल्यांकन (stale-while-revalidate) रणनीति का भी उपयोग किया जा सकता है जहां JavaScript अगले नेविगेशन के लिए प्रपत्र (onLoad2) में डेटा का अनुरोध करते समय sessionStorage से डेटा का उपयोग करता है. अंत में, यदि एक हैंडलर को एक पंक्ति में कई बार (onLoad3) कॉल किया जाता है, तो डीडुप्लीकेशन रणनीति का उपयोग किया जा सकता है.

const SETTING_ENTITY_NAME = "settings_entity";
const SETTING_FIELD_NAME = "settingField1";
const SETTING_VALUE_SESSION_STORAGE_KEY = `${SETTING_ENTITY_NAME}_${SETTING_FIELD_NAME}`;

// Retrieve setting value once per session
async function onLoad1(executionContext) {
    let settingValue = sessionStorage.getItem(SETTING_VALUE_SESSION_STORAGE_KEY);

    // Ensure there is a stored setting value to use
    if (settingValue === null || settingValue === undefined) {
        settingValue = await requestSettingValue();
    }

    // Do logic with setting value here
}

// Retrieve setting value with stale-while-revalidate strategy
async function onLoad2(executionContext) {
    let settingValue = sessionStorage.getItem(SETTING_VALUE_SESSION_STORAGE_KEY);

    // Revalidate, but only await if session storage value is not present
    const requestPromise = requestSettingValue();

    // Ensure there is a stored setting value to use the first time in a session
    if (settingValue === null || settingValue === undefined) {
        settingValue = await requestPromise;
    }
    
    // Do logic with setting value here
}

// Retrieve setting value with stale-while-revalidate and deduplication strategy
let requestPromise;
async function onLoad3(executionContext) {
    let settingValue = sessionStorage.getItem(SETTING_VALUE_SESSION_STORAGE_KEY);

    // Request setting value again but don't wait on it
    // In case this handler fires twice, don’t make the same request again if it is already in flight
    // Additional logic can be added so that this is done less than once per page
    if (!requestPromise) {
        requestPromise = requestSettingValue().finally(() => {
            requestPromise = undefined;
        });
    }

    // Ensure there is a stored setting value to use the first time in a session
    if (settingValue === null || settingValue === undefined) {
        settingValue = await requestPromise;
    }
    
    // Do logic with setting value here
}

async function requestSettingValue() {
    try {
        const data = await Xrm.WebApi.retrieveRecord(
            SETTING_ENTITY_NAME,
            "7333e80e-9b0f-49b5-92c8-9b48d621c37c",
            `?$select=${SETTING_FIELD_NAME}`);
        try {
            sessionStorage.setItem(SETTING_VALUE_SESSION_STORAGE_KEY, data[SETTING_FIELD_NAME]);
        } catch (error) {
            // Handle sessionStorage error
        } finally {
            return data[SETTING_FIELD_NAME];
        }
    } catch (error) {
        // Handle retrieveRecord error   
    }
}

अनुरोध करने के बजाय क्लाइंट API में उपलब्ध जानकारी का उपयोग करें. उदाहरण के लिए, प्रपत्र लोड पर उपयोगकर्ता की सुरक्षा भूमिकाओं का अनुरोध करने के बजाय, आप getGlobalContext.userSettings.roles का उपयोग कर सकते हैं.

कोड तभी लोड करें जब इसकी आवश्यकता हो

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

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

उत्पादन कोड में कंसोल एपीआई का उपयोग हटाएं

प्रोडक्शन कोड में कंसोल API तरीके जैसे console.log का इस्तेमाल न करें. कंसोल में डेटा लॉगिंग करने से मेमोरी की मांग में काफी वृद्धि हो सकती है और डेटा को मेमोरी में साफ होने से रोका जा सकता है. इससे ऐप समय के साथ धीमा हो सकता है और अंततः क्रैश हो सकता है.

मेमोरी लीक से बचें

आपके कोड में मेमोरी लीक होने से समय के साथ प्रदर्शन धीमा हो सकता है और अंततः आपके ऐप के क्रैश होने का कारण बन सकता है. मेमोरी लीक तब होती है जब एप्लिकेशन मेमोरी को रिलीज़ करने में विफल रहता है जब इसकी आवश्यकता नहीं होती है. आपके फॉर्म पर सभी अनुकूलन और कोड घटकों के साथ, आपको चाहिए:

• स्मृति को साफ करने के लिए जिम्मेदार किसी भी चीज के लिए पूरी तरह से विचार करें और परिदृश्यों का परीक्षण करें, जैसे कि वस्तुओं के जीवनचक्र के प्रबंधन के लिए जिम्मेदार कक्षाएं.
• सभी ईवेंट श्रोताओं और सब्सक्रिप्शन को साफ़ करें, विशेष रूप से यदि यह window ऑब्जेक्ट पर है.
• setInterval जैसे सभी टाइमर साफ़ करें.
• वैश्विक या स्थैतिक वस्तुओं के संदर्भों से बचें, सीमित करें और सफाई करें.

कस्टम नियंत्रण के लिए, में सफाई की जा सकती है नष्ट करना तरीका.

मेमोरी समस्याओं को ठीक करने के बारे में अधिक जानकारी के लिए, इस एज डेवलपर दस्तावेज़ीकरण पर जाएँ.

वे टूल जिनका उपयोग आप ऐप्स को प्रदर्शन योग्य बनाने में मदद के लिए कर सकते हैं

यह अनुभाग उन टूल का वर्णन करता है जो प्रदर्शन संबंधी समस्याओं को समझने में आपकी सहायता कर सकते हैं और मॉडल-चालित ऐप्स में अपने अनुकूलन को अनुकूलित करने के तरीके के बारे में सिफारिशें प्रदान कर सकते हैं.

प्रदर्शन इनसाइट्स

प्रदर्शन इनसाइट्स एंटरप्राइज़ ऐप निर्माताओं के लिए एक स्वयं-सेवा टूल है जो रनटाइम टेलीमेट्री डेटा का विश्लेषण करती है और मॉडल-चालित ऐप्स के प्रदर्शन को बेहतर बनाने में सहायता के लिए सिफारिशों की प्राथमिकता सूची प्रदान करती है. यह सुविधा सिफारिशों और कार्रवाई योग्य वस्तुओं के साथ Power Apps मॉडल-संचालित या ग्राहक संलग्नता ऐप के प्रदर्शन से संबंधित विश्लेषणात्मक इनसाइट का एक दैनिक सेट प्रदान करती है, जैसे Dynamics 365 Sales या Dynamics 365 सेवा. एंटरप्राइज़ ऐप निर्माता Power Apps में ऐप-स्तर पर विस्तृत प्रदर्शन इनसाइट्स देख सकते हैं. अधिक जानकारी: प्रदर्शन इनसाइट्स क्या हैं? (पूर्वावलोकन)

समाधान चेकर

समाधान जांचकर्ता एक शक्तिशाली टूल है जो प्रदर्शन या विश्वसनीयता के मुद्दों के लिए क्लाइंट और सर्वर अनुकूलन का विश्लेषण कर सकता है. यह क्लाइंट-साइड JavaScript को पार्स कर सकता है, XML, and .NET सर्वर-साइड प्लग-इन बना सकता है और लक्षित इनसाइट्स प्रदान कर सकता है जो अंतिम उपयोगकर्ताओं को धीमा कर सकता है. हम सिफारिश करते हैं कि जब भी आप विकास परिवेश में परिवर्तन प्रकाशित करते हैं, तो आप समाधान जांचकर्ता चलाएँ, ताकि अंतिम उपयोगकर्ताओं तक पहुँचने से पहले प्रदर्शन संबंधी कोई भी चिंताएँ सामने आ जाएँ. अधिक जानकारी: Power Apps में अपने मॉडल-संचालित अनुप्रयोगों को सत्यापित करने के लिए समाधान परीक्षक का उपयोग करें

समाधान जांचकर्ता के साथ मिले प्रदर्शन-संबंधी समस्याओं के कुछ उदाहरण:

• il-निर्दिष्ट-स्तंभ. Dataverse क्वेरी API के माध्यम से सभी स्तंभों को चुनने से बचें.
• web-use-async. HTTP और HTTPS संसाधनों के साथ एसिन्क्रॉनस रूप में सहभागिता करता है.
• web-avoid-ui-refreshribbon. refreshRibbon को प्रपत्र OnLoad और EnableRule के रूप में उपयोग करने से बचें.

ऑब्ज़ेक्ट चेकर

ऑब्जेक्ट चेकर आपके समाधान में घटक ऑब्जेक्ट पर वास्तविक समय निदान चलाता है. यदि समस्याओं का पता लगाया जाता है, तो सुझाव दिया जाता है जो बताता है कि समस्या को कैसे ठीक किया जाए. अधिक जानकारी: समाधान कंपोनेंट को डायग्नोस करने के लिए ऑब्जेक्ट जांचकर्ता का उपयोग करें (पूर्वावलोकन)

अगले कदम

मॉडल-संचालित ऐप्स में उत्पादक मुख्य प्रपत्र डिज़ाइन करना