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

ينطبق على: Azure Logic Apps (الاستهلاك + قياسي)

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

إشعار

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

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

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

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

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

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

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

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

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

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

إضافة مشغل HTTP

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

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

  2. اتبع هذه الخطوات العامة لإضافة المشغل المضمن المسمى HTTP إلى سير العمل الخاص بك.

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

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

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

  4. لإضافة معلمات أخرى متوفرة، افتح قائمة المعلمات المتقدمة، وحدد المعلمات التي تريدها.

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

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

إضافة إجراء HTTP

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

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

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

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

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

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

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

  4. لإضافة معلمات أخرى متوفرة، افتح قائمة المعلمات المتقدمة، وحدد المعلمات التي تريدها.

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

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

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

الخاصية نوع ‏‏الوصف
headers كائن JSON الرؤوس من الطلب
body كائن JSON الكائن الذي يحتوي على محتوى النص الأساسي من الطلب
status code رقم صحيح رمز الحالة من الطلب
كود الحالة ‏‏الوصف
200 موافق
202 مقبول
400 طلب غير صالح
401 غير مصرح به
403 محظور
404 غير موجود
500 خطأ خادم داخلي. حدث خطأ غير معروف.

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

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

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

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

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

  1. في إعدادات تطبيق مورد تطبيق المنطق، أضف إعداد التطبيق أو حدثه، WEBSITE_LOAD_ROOT_CERTIFICATES.

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

    "WEBSITE_LOAD_ROOT_CERTIFICATES": "<thumbprint-for-TLS/SSL-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/SSL-certificate>",
          <...>
       }
    }
    

    إشعار

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

    1. في قائمة موارد تطبيق المنطق، ضمن الإعدادات، حدد إعدادات>TLS/SSL شهادات المفتاح الخاص (.pfx) أو شهادات المفتاح العام (.cer).

    2. ابحث عن الشهادة التي تريد استخدامها، وانسخ بصمة الإبهام.

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

لمعرفة مزيد من المعلومات، راجع الوثائق التالية:

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

  1. في إعدادات تطبيق مورد تطبيق المنطق، أضف إعداد التطبيق أو حدثه، WEBSITE_LOAD_USER_PROFILE.

  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",
          <...>
       }
    }
    

لمعرفة مزيد من المعلومات، راجع الوثائق التالية:

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

لمعالجة المحتوى الذي يحتوي على 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 النوع. يوضح النموذج التالي كيفية ظهور هذا الإجراء:

سير عمل قياسي

تظهر لقطة الشاشة سير العمل القياسي مع إجراء HTTP وبيانات النموذج متعددة الأحزاب.

سير عمل الاستهلاك

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

إليك نفس المثال الذي يظهر تعريف 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 النوع. إليك كيف قد يبدو هذا الإجراء:

سير عمل قياسي

لقطة شاشة تعرض سير العمل القياسي مع تعيين طلب HTTP ورأس نوع المحتوى إلى application/x-www-form-urlencoded.

سير عمل الاستهلاك

لقطة شاشة تعرض سير عمل Consumption مع تعيين طلب HTTP ورأس نوع المحتوى إلى application/x-www-form-urlencoded.

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

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

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

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

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

    للعثور على إعداد النمط غير المتزامن، اتبع هذه الخطوات، استنادا إلى ما إذا كان لديك سير عمل قياسي أو استهلاكي:

    سير عمل قياسي*

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

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

    سير عمل الاستهلاك

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

    2. ابحث عن إعداد Asynchronous Pattern.

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

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

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

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

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

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

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

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

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

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

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

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

لتحديد عدد الثوان بين محاولات إعادة المحاولة، يمكنك إضافة 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 تحترم أي قيمة تحددها باستخدام خاصية ملف تعريف الارتباط .
  • 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 الداخلي.

الخطوات التالية