استدعاء نقاط نهاية HTTP أو HTTPS الخارجية من مهام سير العمل في Azure Logic Apps

ينطبق على: Azure Logic Apps (Consumption + Standard)

قد تتطلب بعض السيناريوهات إنشاء سير عمل تطبيق منطقي يرسل طلبات صادرة إلى نقاط النهاية على خدمات أو أنظمة أخرى عبر HTTP أو HTTPS. على سبيل المثال، افترض أنك تريد مراقبة نقطة نهاية خدمة لموقع الويب الخاص بك عن طريق التحقق من نقطة النهاية هذه في جدول زمني محدد. عندما يحدث حدث معين في نقطة النهاية هذه، مثل تعطل موقع الويب الخاص بك، يؤدي هذا الحدث إلى تشغيل سير العمل الخاص بك وتشغيل الإجراءات في سير العمل هذا.

ملاحظة

لإنشاء سير عمل يتلقى ويستجيب لاستدعاءات HTTPS الواردة بدلا من ذلك، راجع إنشاء مهام سير عمل يمكنك الاتصال بها أو تشغيلها أو تداخلها باستخدام نقاط نهاية HTTPS في Azure Logic Apps. لاستخدام مشغل الطلب المضمن، راجع تلقي استدعاءات HTTPS الواردة والاستجابة لها إلى مهام سير العمل في Azure Logic Apps.

يوضح هذا الدليل كيفية استخدام مشغل HTTP وإجراء HTTP بحيث يمكن لسير العمل إرسال مكالمات صادرة إلى خدمات وأنظمة أخرى، على سبيل المثال:

• للتحقق من نقطة نهاية أو استقصاءها على جدول متكرر، أضف المشغل المضمن المسمى HTTP كخطوة أولى في سير العمل الخاص بك. في كل مرة يتحقق فيها المشغل من نقطة النهاية، يستدعي المشغل أو يرسل طلبا إلى نقطة النهاية. تحدد استجابة نقطة النهاية ما إذا كان سير العمل الخاص بك يعمل أم لا. يمرر المشغل أي محتوى من استجابة نقطة النهاية إلى الإجراءات في سير العمل.

• لاستدعاء نقطة نهاية من أي مكان آخر في سير العمل، أضف الإجراء المضمن المسمى HTTP. تحدد استجابة نقطة النهاية كيفية تشغيل الإجراءات المتبقية لسير العمل.

المتطلبات الأساسية

• حساب واشتراك Azure. إذا لم يكن لديك اشتراك، فقم بالتسجيل للحصول على حساب Azure مجاني.

• عنوان URL لنقطة النهاية الوجهة التي تريد الاتصال بها.

• مورد تطبيق المنطق مع سير العمل من حيث تريد استدعاء نقطة النهاية الخارجية.

  لبدء سير العمل باستخدام مشغل HTTP ، يجب أن يكون لديك سير عمل فارغ. لاستخدام إجراء HTTP ، يمكن أن يبدأ سير العمل بمشغل يناسب السيناريو الخاص بك على أفضل نحو. تستخدم أمثلة مهام سير العمل في هذه المقالة مشغل HTTP .

  إذا لم يكن لديك مورد تطبيق منطقي وسير عمل، فبادر بإنشائه الآن باتباع الخطوات الخاصة بتطبيق المنطق الذي تريده:

  • إنشاء مثال سير عمل تطبيق منطق الاستهلاك
  • إنشاء مثال لسير عمل تطبيق المنطق القياسي

مرجع تقني للموصل

للحصول على معلومات تقنية حول معلمات المشغل والإجراءات، راجع الأقسام التالية في الدليل المرجعي للمخطط:

• معلمات مشغل HTTP
• معلمات إجراء HTTP

إضافة مشغل HTTP

يقوم هذا المشغل المضمن بإجراء استدعاء HTTP إلى عنوان URL المحدد لنقطة نهاية وإرجاع استجابة.

معيار

1. في مدخل Microsoft Azure، افتح مورد تطبيق المنطق القياسي.

2. في قائمة الشريط الجانبي للمورد، ضمن Workflows، حدد Workflows، ثم حدد سير العمل الفارغ.

3. في القائمة الشريط الجانبي لسير العمل، ضمن أدوات، حدد المصمم لفتح سير العمل.

4. أضف مشغل HTTP المضمن إلى سير العمل باتباع الخطوات العامة لإضافة مشغل.

   يعيد هذا المثال تسمية المشغل إلى مشغل HTTP - استدعاء عنوان URL لنقطة النهاية بحيث يكون للمشغل اسم وصفي أكثر. علاوة على ذلك، يضيف المثال لاحقا إجراء HTTP ، ويجب أن تكون أسماء العمليات في سير العمل فريدة.

5. قم بتوفير قيم معلمات مشغل HTTP التي تريد تضمينها في الاستدعاء إلى نقطة النهاية الوجهة. قم بإعداد التكرار لمدى تكرار التحقق من نقطة نهاية الوجهة.

6. من قائمة Advanced parameters، حدد Authentication.

   إذا قمت بتحديد نوع مصادقة غير None، تختلف إعدادات المصادقة بناء على التحديد الخاص بك. لمزيد من المعلومات حول أنواع المصادقة المتوفرة ل HTTP، راجع المقالات التالية:

   • إضافة مصادقة إلى المكالمات الصادرة
   • مصادقة الوصول إلى الموارد باستخدام الهويات المدارة

7. أضف أي إجراءات أخرى تريد تشغيلها عند تشغيل المشغل.

8. عند الانتهاء، احفظ سير العمل الخاص بك. في شريط أدوات المصمم، حدد "Save".

استهلاك

1. في مدخل Microsoft Azure، افتح مورد تطبيق Consumption logic.

2. في قائمة الشريط الجانبي، ضمن أدوات التطوير، حدد المصمم لفتح سير العمل الفارغ.

3. أضف مشغل HTTP المضمن إلى سير العمل باتباع الخطوات العامة لإضافة مشغل.

   يعيد هذا المثال تسمية المشغل إلى مشغل HTTP - استدعاء عنوان URL لنقطة النهاية بحيث يكون للمشغل اسم وصفي أكثر. علاوة على ذلك، يضيف المثال لاحقا إجراء HTTP ، ويجب أن تكون أسماء العمليات في سير العمل فريدة.

4. قم بتوفير قيم معلمات مشغل HTTP التي تريد تضمينها في الاستدعاء إلى نقطة النهاية الوجهة. قم بإعداد التكرار لمدى تكرار التحقق من نقطة نهاية الوجهة.

5. من قائمة Advanced parameters، حدد Authentication.

   إذا قمت بتحديد نوع مصادقة غير None، تختلف إعدادات المصادقة بناء على التحديد الخاص بك. لمزيد من المعلومات حول أنواع المصادقة المتوفرة ل HTTP، راجع المقالات التالية:

   • إضافة مصادقة إلى المكالمات الصادرة
   • مصادقة الوصول إلى الموارد باستخدام الهويات المدارة

6. أضف أي إجراءات أخرى تريد تشغيلها عند تشغيل المشغل.

7. عند الانتهاء، احفظ سير العمل الخاص بك. في شريط أدوات المصمم، حدد "Save".

إضافة إجراء HTTP

يرسل هذا الإجراء المضمن استدعاء HTTPS أو HTTP إلى عنوان URL المحدد لنقطة نهاية ويرجع مع استجابة.

معيار

1. في مدخل Microsoft Azure، افتح مورد تطبيق المنطق القياسي.

2. في قائمة الشريط الجانبي للمورد، ضمن Workflows، حدد Workflows، ثم حدد سير العمل الخاص بك.

3. في القائمة الشريط الجانبي لسير العمل، ضمن أدوات، حدد المصمم لفتح سير العمل.

   يستخدم هذا المثال مشغل HTTP المضاف في القسم السابق.

4. أضف الإجراء المضمن HTTP إلى سير العمل باتباع الخطوات العامة لإضافة إجراء.

   يعيد هذا المثال تسمية الإجراء إلى إجراء HTTP - استدعاء عنوان URL لنقطة النهاية بحيث يكون للإجراء اسم وصفي أكثر. أيضا، يجب أن تكون أسماء العمليات في سير العمل الخاص بك فريدة من نوعها.

5. قم بتوفير قيم معلمات إجراء HTTP التي تريد تضمينها في الاستدعاء إلى نقطة النهاية الوجهة.

6. من قائمة Advanced parameters، حدد Authentication.

   إذا قمت بتحديد نوع مصادقة غير None، تختلف إعدادات المصادقة بناء على التحديد الخاص بك. لمزيد من المعلومات حول أنواع المصادقة المتوفرة ل HTTP، راجع المقالات التالية:

   • إضافة مصادقة إلى المكالمات الصادرة
   • مصادقة الوصول إلى الموارد باستخدام الهويات المدارة

7. أضف أي إجراءات أخرى تريد تشغيلها عند تشغيل المشغل.

8. عند الانتهاء، احفظ سير العمل الخاص بك. في شريط أدوات المصمم، حدد "Save".

استهلاك

1. في مدخل Microsoft Azure، افتح تطبيق منطق الاستهلاك وسير العمل في المصمم.

   يستخدم هذا المثال مشغل HTTP المضاف في القسم السابق كخطوة أولى.

2. أضف الإجراء المضمن HTTP إلى سير العمل باتباع الخطوات العامة لإضافة إجراء.

   يعيد هذا المثال تسمية الإجراء إلى إجراء HTTP - استدعاء عنوان URL لنقطة النهاية بحيث يكون للإجراء اسم وصفي أكثر. أيضا، يجب أن تكون أسماء العمليات في سير العمل الخاص بك فريدة من نوعها.

3. قم بتوفير قيم معلمات إجراء HTTP التي تريد تضمينها في الاستدعاء إلى نقطة النهاية الوجهة.

4. من قائمة Advanced parameters، حدد Authentication.

   إذا قمت بتحديد نوع مصادقة غير None، تختلف إعدادات المصادقة بناء على التحديد الخاص بك. لمزيد من المعلومات حول أنواع المصادقة المتوفرة ل HTTP، راجع المقالات التالية:

   • إضافة مصادقة إلى المكالمات الصادرة
   • مصادقة الوصول إلى الموارد باستخدام الهويات المدارة

5. أضف أي إجراءات أخرى تريد تشغيلها عند تشغيل المشغل.

6. عند الانتهاء، احفظ سير العمل الخاص بك. في شريط أدوات المصمم، حدد "Save".

مخرجات المشغلات والإجراءات

مشغل HTTP أو إجراء إخراج المعلومات التالية:

الخاصية	نوع	‏‏الوصف
headers	كائن JSON	الرؤوس من الطلب
body	كائن JSON	الكائن الذي يحتوي على محتوى النص الأساسي من الطلب
status code	العدد الصحيح	رمز الحالة من الطلب

كود الحالة	‏‏الوصف
200	موافق
202	مقبول
400	طلب غير صالح
401	غير مصرح به
403	محظور
404	غير موجود
500	خطأ خادم داخلي. حدث خطأ غير معروف.

أمان عنوان URL للمكالمات الصادرة

للحصول على معلومات حول التشفير والأمان والتخويل للمكالمات الصادرة من سير العمل، مثل أمان طبقة النقل (TLS) أو الشهادات الموقعة ذاتيا أو مصادقة Microsoft Entra ID المفتوحة، راجع الوصول إلى المكالمات الصادرة إلى الخدمات والأنظمة الأخرى.

المصادقة لبيئة المستأجر الفردي

إذا كان لديك مورد تطبيق منطق قياسي في Azure Logic Apps أحادي المستأجر، وتريد استخدام عملية HTTP مع أي من أنواع المصادقة التالية، فتأكد من إكمال خطوات الإعداد الإضافية لنوع المصادقة المقابل. وإلا، يفشل الاستِدعاء.

• شهادة TLS: إضافة إعداد WEBSITE_LOAD_ROOT_CERTIFICATESالتطبيق ، وتعيين القيمة إلى بصمة الإبهام لشهادة TLS.

• شهادة العميل أو مصادقة Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth) مع نوع بيانات اعتماد الشهادة: إضافة إعداد WEBSITE_LOAD_USER_PROFILEالتطبيق ، وتعيين القيمة إلى 1.

مصادقة شهادة TLS

1. في إعدادات تطبيق مورد تطبيق المنطق، أضف أو حدث إعداد التطبيق المسمى WEBSITE_LOAD_ROOT_CERTIFICATES. للحصول على خطوات محددة، راجع إدارة إعدادات التطبيق - local.settings.json.

2. بالنسبة لقيمة الإعداد، قم بتوفير بصمة الإبهام لشهادة TLS كشهادة الجذر المراد الوثوق بها.

   "WEBSITE_LOAD_ROOT_CERTIFICATES": "<thumbprint-for-TLS-certificate>"

على سبيل المثال، إذا كنت تعمل في Visual Studio Code، فاتبع الخطوات التالية:

1. افتح ملف local.settings.json لمشروع تطبيق المنطق الخاص بك.

2. في Values كائن JSON، أضف الإعداد أو حدثه WEBSITE_LOAD_ROOT_CERTIFICATES :

   {
      "IsEncrypted": false,
      "Values": {
         <...>
         "AzureWebJobsStorage": "UseDevelopmentStorage=true",
         "WEBSITE_LOAD_ROOT_CERTIFICATES": "<thumbprint-for-TLS-certificate>",
         <...>
      }
   }
   

ملاحظة

للعثور على بصمة الإبهام، اتبع الخطوات التالية:

• في قائمة موارد تطبيق المنطق، ضمن Settings، حدد Certificates.
• حدد إحضار الشهادات الخاصة بك (.pfx) أو شهادات المفتاح العام (.cer).
• ابحث عن الشهادة التي تريد استخدامها، وانسخ بصمة الإبهام.

لمزيد من المعلومات، راجع البحث عن بصمة الإبهام - Azure App Service.

لمزيد من المعلومات، راجع إدارة إعدادات التطبيق - local.settings.json.

شهادة العميل أو Microsoft Entra ID OAuth مع مصادقة نوع بيانات اعتماد الشهادة

1. في إعدادات تطبيق مورد تطبيق المنطق، أضف أو حدث إعداد التطبيق المسمى WEBSITE_LOAD_USER_PROFILE. للحصول على خطوات محددة، راجع إدارة إعدادات التطبيق - local.settings.json

2. بالنسبة لقيمة الإعداد، حدد 1.

   "WEBSITE_LOAD_USER_PROFILE": "1"

على سبيل المثال، إذا كنت تعمل في Visual Studio Code، فاتبع الخطوات التالية:

1. افتح ملف local.settings.json لمشروع تطبيق المنطق الخاص بك.

2. في Values كائن JSON، أضف الإعداد أو حدثه WEBSITE_LOAD_USER_PROFILE :

   {
      "IsEncrypted": false,
      "Values": {
         <...>
         "AzureWebJobsStorage": "UseDevelopmentStorage=true",
         "WEBSITE_LOAD_USER_PROFILE": "1",
         <...>
      }
   }
   

إذا كنت تعمل في مدخل Microsoft Azure، فافتح تطبيق المنطق الخاص بك. ضمن Settings في قائمة الشريط الجانبي، حدد Environment variables. ضمن إعدادات التطبيق، أضف الإعداد أو حرره.

محتوى ذو نوع بيانات متعدد الأحزاب/النموذج

لمعالجة المحتوى الذي يحتوي على multipart/form-data نوع في طلبات HTTP، يمكنك إضافة كائن JSON يتضمن $content-type السمتين و $multipart في نص طلب HTTP باستخدام هذا التنسيق.

"body": {
   "$content-type": "multipart/form-data",
   "$multipart": [
      {
         "body": "<output-from-trigger-or-previous-action>",
         "headers": {
            "Content-Disposition": "form-data; name=file; filename=<file-name>"
         }
      }
   ]
}

على سبيل المثال، افترض أن لديك سير عمل يرسل طلب HTTP POST لملف Excel إلى موقع ويب باستخدام واجهة برمجة تطبيقات هذا الموقع، والتي تدعم multipart/form-data النوع. يوضح النموذج التالي كيفية ظهور هذا الإجراء:

إليك نفس المثال الذي يظهر تعريف JSON لإجراء HTTP في تعريف سير العمل الأساسي:

"HTTP_action": {
   "inputs": {
      "body": {
         "$content-type": "multipart/form-data",
         "$multipart": [
            {
               "body": "@trigger()",
               "headers": {
                  "Content-Disposition": "form-data; name=file; filename=myExcelFile.xlsx"
               }
            }
         ]
      },
      "method": "POST",
      "uri": "https://finance.contoso.com"
   },
   "runAfter": {},
   "type": "Http"
}

محتوى مع نوع application/x-www-form-urlencoded

لتوفير بيانات form-urlencoded في النص الأساسي لطلب HTTP، يجب عليك تحديد أن البيانات تحتوي على application/x-www-form-urlencoded نوع المحتوى. في مشغل أو إجراء HTTP، أضف content-type العنوان. تعيين قيمة العنوان إلى application/x-www-form-urlencoded.

على سبيل المثال، افترض أن لديك تطبيقا منطقيا يرسل طلب HTTP POST إلى موقع ويب، والذي يدعم application/x-www-form-urlencoded النوع. إليك كيف قد يبدو هذا الإجراء:

سلوك استجابة طلب غير متزامن

بالنسبة إلى مهام سير العمل ذات الحالة في كل من تطبيقات Azure Logic Apps متعددة المستأجرين والمستأجر الواحد، تتبع جميع الإجراءات المستندة إلى HTTP نمط العملية القياسي غير المتزامن باعتباره السلوك الافتراضي. يحدد هذا النمط أنه بعد استدعاء إجراء HTTP أو إرسال طلب إلى نقطة نهاية أو خدمة أو نظام أو واجهة برمجة تطبيقات، يقوم المتلقي بإرجاع استجابة 202 ACCEPTED على الفور. تؤكد هذه التعليمة البرمجية أن المتلقي قبل الطلب ولكنه لم ينته من المعالجة. يمكن أن تتضمن الاستجابة عنوانا location يحدد URI ومعرف تحديث يمكن للمتصل استخدامه للاستقصاء أو التحقق من حالة الطلب غير المتزامن حتى يتوقف المتلقي عن المعالجة ويرجع استجابة نجاح 200 OK أو استجابة أخرى غير 202. ومع ذلك، لا يتعين على المتصل الانتظار حتى ينتهي الطلب من المعالجة ويمكنه المتابعة لتشغيل الإجراء التالي. لمزيد من المعلومات، راجع المراسلة المتزامنة مقابل المراسلة غير المتزامنة.

بالنسبة إلى مهام سير العمل عديمة الحالة في Azure Logic Apps أحادية المستأجر، لا تستخدم الإجراءات المستندة إلى HTTP نمط العملية غير المتزامن. بدلا من ذلك، يتم تشغيلها بشكل متزامن فقط، وإرجاع استجابة 202 ACCEPTED as-is، ثم انتقل إلى الخطوة التالية في تنفيذ سير العمل. إذا كانت الاستجابة تتضمن عنوانا location ، فلا يقوم سير العمل عديم الحالة باستطلاع URI المحدد للتحقق من الحالة. لاتباع نمط العملية القياسي غير المتزامن، استخدم سير عمل ذي حالة بدلا من ذلك.

• يتبع تعريف JSON الأساسي لإجراء HTTP ضمنيا نمط العملية غير المتزامن.

• يحتوي إجراء HTTP، ولكن ليس المشغل، على إعداد نمط غير متزامن ، والذي يتم تمكينه افتراضيا. يحدد هذا الإعداد أن المتصل لا ينتظر انتهاء المعالجة ويمكنه الانتقال إلى الإجراء التالي ولكنه يستمر في التحقق من الحالة حتى تتوقف المعالجة. إذا تم تعطيله، فإن هذا الإعداد يحدد أن المتصل ينتظر انتهاء المعالجة قبل الانتقال إلى الإجراء التالي.

  للعثور على إعداد النمط غير المتزامن :

  1. في مصمم سير العمل، حدد إجراء HTTP .
  2. في جزء المعلومات الذي يفتح، حدد الإعدادات.
  3. ضمن Networking، ابحث عن إعداد النمط غير المتزامن .

تعطيل العمليات غير المتزامنة

في بعض الأحيان، قد تحتاج إلى تعطيل السلوك غير المتزامن لإجراء HTTP في سيناريوهات معينة، على سبيل المثال، عندما تريد:

• تجنب انتهاء مهلات HTTP للمهام طويلة الأمد
• تعطيل التحقق من رؤوس المواقع

إيقاف تشغيل إعداد النمط غير المتزامن

1. في مصمم سير العمل، حدد إجراء HTTP، وفي جزء المعلومات الذي يفتح، حدد الإعدادات.

2. ضمن Networking، ابحث عن إعداد النمط غير المتزامن . قم بإيقاف تشغيل الإعداد إذا تم تمكينه.

تعطيل النمط غير المتزامن في تعريف JSON للإجراء

في تعريف JSON الأساسي لإجراء HTTP، أضف DisableAsyncPattern خيار العملية إلى تعريف الإجراء بحيث يتبع الإجراء نمط العملية المتزامن بدلا من ذلك. لمزيد من المعلومات، راجع أيضا تشغيل الإجراءات في نمط عملية متزامن.

تجنب مهلات HTTP للمهام طويلة الأمد

طلبات HTTP لها حد مهلة. إذا كان لديك إجراء HTTP طويل الأمد تنتهي مهلته بسبب هذا الحد، فلديك هذه الخيارات:

• قم بتعطيل نمط العملية غير المتزامن لإجراء HTTP بحيث لا يقوم الإجراء باستمرار باستطلاع أو التحقق من حالة الطلب. بدلا من ذلك، ينتظر الإجراء حتى يستجيب المتلقي بالحالة والنتائج بعد انتهاء الطلب من المعالجة.

• استبدل إجراء HTTP بإجراء HTTP Webhook، الذي ينتظر استجابة المتلقي بالحالة والنتائج بعد انتهاء الطلب من المعالجة.

إعداد الفاصل الزمني بين محاولات إعادة المحاولة باستخدام عنوان Retry-After

لتحديد عدد الثوان بين محاولات إعادة المحاولة، يمكنك إضافة Retry-After العنوان إلى استجابة إجراء HTTP. على سبيل المثال، إذا كانت نقطة النهاية الوجهة 429 - Too many requests ترجع رمز الحالة، يمكنك تحديد فاصل زمني أطول بين عمليات إعادة المحاولة. Retry-After يعمل العنوان أيضا مع 202 - Accepted رمز الحالة.

إليك نفس المثال الذي يظهر استجابة إجراء HTTP التي تحتوي على Retry-After:

{
    "statusCode": 429,
    "headers": {
        "Retry-After": "300"
    }
}

دعم ترقيم الصفحات

في بعض الأحيان، تستجيب خدمة الوجهة عن طريق إرجاع النتائج صفحة واحدة في كل مرة. إذا كانت الاستجابة تحدد الصفحة التالية مع الخاصية nextLink أو @odata.nextLink ، يمكنك تشغيل إعداد ترقيم الصفحات في إجراء HTTP . يؤدي هذا الإعداد إلى اتباع إجراء HTTP لهذه الارتباطات تلقائيا والحصول على الصفحة التالية. ومع ذلك، إذا كانت الاستجابة تحدد الصفحة التالية مع أي علامة أخرى، فقد تحتاج إلى إضافة حلقة إلى سير العمل الخاص بك. اجعل هذه الحلقة تتبع تلك العلامة والحصول على كل صفحة يدويا حتى تصبح العلامة خالية.

تعطيل التحقق من رؤوس المواقع

تقوم بعض نقاط النهاية أو الخدمات أو الأنظمة أو واجهات برمجة التطبيقات بإعادة استجابة 202 ACCEPTED لا تحتوي على location عنوان. لتجنب وجود إجراء HTTP يتحقق باستمرار من حالة الطلب عندما location لا يكون العنوان موجودا، يمكنك الحصول على هذه الخيارات:

• قم بتعطيل نمط العملية غير المتزامن لإجراء HTTP بحيث لا يقوم الإجراء باستمرار باستطلاع أو التحقق من حالة الطلب. بدلا من ذلك، ينتظر الإجراء حتى يستجيب المتلقي بالحالة والنتائج بعد انتهاء الطلب من المعالجة.

• استبدل إجراء HTTP بإجراء HTTP Webhook، الذي ينتظر استجابة المتلقي بالحالة والنتائج بعد انتهاء الطلب من المعالجة.

المشكلات المعروفة

رؤوس HTTP المحذفة

إذا كان مشغل HTTP أو إجراء يتضمن هذه العناوين، فإن Azure Logic Apps يزيل هذه الرؤوس من رسالة الطلب التي تم إنشاؤها دون إظهار أي تحذير أو خطأ:

• Accept-* الرؤوس باستثناء Accept-version
• Allow
• Content-* العناوين باستثناء Content-Dispositionو Content-Encodingو Content-Typeوالتي يتم تكريمها عند استخدام عمليات POST و PUT. ومع ذلك، يقوم Azure Logic Apps بإسقاط هذه الرؤوس عند استخدام GET العملية.
• Cookie رأس الصفحة، ولكن Azure Logic Apps تحترم أي قيمة تحددها باستخدام الخاصية Cookie .
• Expires
• Host
• Last-Modified
• Origin
• Set-Cookie
• Transfer-Encoding

على الرغم من أن Azure Logic Apps لا تمنعك من حفظ تطبيقات المنطق التي تستخدم مشغل HTTP أو إجراء مع هذه العناوين، فإن Azure Logic Apps تتجاهل هذه العناوين.

لا يتطابق محتوى الاستجابة مع نوع المحتوى المتوقع

يطرح إجراء HTTP خطأ BadRequest إذا كان إجراء HTTP يستدعي واجهة برمجة تطبيقات الواجهة الخلفية مع Content-Type تعيين العنوان إلى application/json، ولكن الاستجابة من الخلفية لا تحتوي فعليا على محتوى بتنسيق JSON، والذي يفشل في التحقق من صحة تنسيق JSON الداخلي.

المحتويات ذات الصلة

• الموصلات المدارة لموصلات Azure Logic Apps
• الموصلات المدمجة لـ Azure Logic Apps