نقاط نهاية خدمة المكالمات عبر HTTP أو HTTPS من تطبيقات Azure Logic

هل هذه الصفحة مفيدة؟

هل لديك ملاحظات إضافية؟

سيتم إرسال الملاحظات إلى Microsoft: بالضغط على الزر «إرسال»، سيتم استخدام ملاحظاتك لتحسين منتجات Microsoft وخدماتها. نهج الخصوصية.

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

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

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

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

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

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

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

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

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

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

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

إضافة مشغل HTTP

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

1. تسجيل الدخول إلى ⁧مدخل Microsoft Azure⁧. افتح تطبيق المنطق الفارغ في Logic App Designer.

2. ضمن مربع بحث المصمم، حدد مضمن. في مربع البحث، أدخل http كفلتر. من قائمة المشغلات ، حدد مشغل HTTP .

   

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

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

   

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

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

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

5. استمر في إنشاء سير عمل تطبيق المنطق باستخدام الإجراءات التي يتم تشغيلها عند تشغيل المشغل.

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

إضافة إجراء HTTP

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

1. تسجيل الدخول إلى ⁧مدخل Microsoft Azure⁧. افتح تطبيقك المنطقي في Logic App Designer.

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

2. ضمن الخطوة التي تريد إضافة إجراء HTTP إليها، حدد خطوة جديدة.

   لإضافة إجراء بين الخطوات، حرك المؤشر فوق السهم بين الخطوات. حدد علامة الجمع (+) التي تظهر، ثم حدد إضافة إجراء.

3. ضمن اختيار إجراء، حدد مضمن. في مربع البحث، أدخل http كفلتر. من قائمة الإجراءات ، حدد إجراء HTTP .

   

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

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

   

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

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

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

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

مخرجات الزناد والإجراءات

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

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

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

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

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

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

• شهادة العميل أو مصادقة Azure Active Directory المفتوحة (Azure AD OAuth) مع نوع بيانات الاعتماد "الشهادة": أضف إعداد التطبيق، WEBSITE_LOAD_USER_PROFILEوقم بتعيين القيمة إلى 1.

مصادقة شهادة 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>",
         <...>
      }
   }
   

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

• تحرير إعدادات المضيف والتطبيق للتطبيقات المنطقية في تطبيقات Azure Logic أحادية المستأجر
• شهادات العميل الخاص - Azure App Service

شهادة العميل أو Azure AD 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",
         <...>
      }
   }
   

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

• تحرير إعدادات المضيف والتطبيق للتطبيقات المنطقية في تطبيقات Azure Logic أحادية المستأجر
• شهادات العميل الخاص - Azure App Service

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

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

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

المحتوى مع نوع التطبيق/x-www-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 متعددة المستأجرين والمستأجر الواحد، تتبع جميع الإجراءات المستندة إلى HTTP نمط التشغيل القياسي غير المتزامن كسلوك افتراضي. يحدد هذا النمط أنه بعد استدعاء إجراء HTTP أو إرسال طلب إلى نقطة نهاية أو خدمة أو نظام أو واجهة برمجة تطبيقات، يقوم المستلم على الفور بإرجاع استجابة "202 مقبولة ". يؤكد هذا الرمز أن المستلم قبل الطلب ولكنه لم ينته من المعالجة. يمكن أن تتضمن الاستجابة رأسا location يحدد عنوان URI ومعرف تحديث يمكن للمتصل استخدامه لاستقصاء أو التحقق من حالة الطلب غير المتزامن حتى يتوقف المستلم عن المعالجة ويعيد استجابة نجاح " 200 OK" أو استجابة أخرى غير 202. ومع ذلك، لا يتعين على المتصل الانتظار حتى ينتهي الطلب من المعالجة ويمكنه الاستمرار في تشغيل الإجراء التالي. لمزيد من المعلومات، راجع تكامل الخدمات المصغرة غير المتزامنة يفرض استقلالية الخدمات المصغرة.

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

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

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

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

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

     

• يتبع تعريف تدوين كائن جافا سكريبت (JSON) الأساسي لإجراء HTTP ضمنيا نمط التشغيل غير المتزامن.

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

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

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

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

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

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

   

تعطيل النمط غير المتزامن في تعريف 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"
    }
}

تعطيل التحقق من رؤوس المواقع الجغرافية

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

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

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

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

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

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

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

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

مرجع الموصل

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

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

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

• الوصول الآمن والبيانات - الوصول للمكالمات الصادرة إلى الخدمات والأنظمة الأخرى
• موصلات للتطبيقات المنطقية