إنشاء واجهات برمجة تطبيقات مخصصة يمكنك الاتصال بها من Azure Logic Apps

  • مقالة

التطبيق على:Azure Logic Apps (Consumption)

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

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

بشكل أساسي، الموصلات هي واجهات برمجة تطبيقات الويب التي تستخدم REST للواجهات القابلة للتوصيل ، وتنسيق بيانات تعريف Swagger للوثائق، وJSON بتنسيق تبادل البيانات الخاص بها. نظرًا لأن الموصلات هي واجهات برمجة تطبيقات REST التي تتصل من خلال نقاط نهاية HTTP، يمكنك استخدام أي لغة، مثل Microsoft.NET أو Java أو Python أو Node.js، لإنشاء الموصلات. يمكنك أيضًا استضافة واجهات برمجة التطبيقات الخاصة بك على Azure App Service، وهو عرض النظام الأساسي كخدمة (PaaS) الذي يوفر واحدة من أفضل الطرق وأسهلها وأكثرها قابلية للتطوير لاستضافة واجهة برمجة التطبيقات.

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

يمكنك استضافة واجهات برمجة التطبيقات الخاصة بك على Azure App Service، وهو عرض نظام أساسي كخدمة (PaaS) يوفر استضافة واجهة برمجة تطبيقات سهلة وقابلة للتطوير بدرجة كبيرة.

تلميح

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

كيف تختلف واجهات برمجة التطبيقات المخصصة عن الموصلات المخصصة؟

واجهة برمجة التطبيقات المخصصة والموصلات المخصصة هي واجهات برمجة تطبيقات الويب التي تستخدم REST للواجهات القابلة للتوصيل، وتنسيق بيانات تعريف Swagger للوثائق، وJSON بتنسيق تبادل البيانات الخاص بها. نظرًا إلى أن واجهة برمجة التطبيقات والموصلات هذه هي واجهات برمجة تطبيقات REST التي تتصل من خلال نقاط نهاية HTTP، يمكنك استخدام أي لغة، مثل .NET أو Java أو Python أو Node.js، لإنشاء واجهة برمجة التطبيقات المخصصة والموصلات.

تتيح لك واجهات برمجة التطبيقات المخصصة استدعاء واجهات برمجة التطبيقات التي ليست موصلات، وتوفر نقاط نهاية يمكنك الاتصال بها باستخدام HTTP + Swagger أو Azure API Management أو App Services. تعمل الموصلات المخصصة مثل واجهات برمجة التطبيقات المخصصة ولكن لها أيضًا هذه السمات:

  • مسجل كموارد Logic Apps Connector في Azure.
  • تظهر مع الأيقونات إلى جانب الموصلات التي تديرها Microsoft في Logic Apps Designer.
  • متوفر فقط لمؤلفي الموصلات ومستخدمي موارد التطبيق المنطقي الذين لديهم نفس مستأجر Microsoft Entra واشتراك Azure في المنطقة التي يتم فيها نشر تطبيقات المنطق.

يمكنك أيضًا ترشيح الموصلات المسجلة للحصول على شهادة Microsoft. تتحقق هذه العملية من أن الموصلات المسجلة تفي بمعايير الاستخدام العام وتجعل هذه الموصلات متاحة للمستخدمين في Power Automate وMicrosoft Power Apps.

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

أدوات مفيدة

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

أنماط الإجراءات

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

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

Standard action pattern

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

تنفيذ مهام طويلة الأمد باستخدام نمط إجراء الاستقصاء.

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

إليك النمط العام:

  1. تأكد من أن المحرك يعرف أن واجهة برمجة التطبيقات الخاصة بك قبلت الطلب وبدأت في العمل.
  2. عندما يقوم المحرك بإجراء طلبات لاحقة لحالة الوظيفة، قم بإعلام المحرك عند انتهاء واجهة برمجة التطبيقات الخاصة بك من المهمة.
  3. إرجاع البيانات ذات الصلة إلى المحرك بحيث يمكن متابعة سير العمل.

الآن قم بتطبيق القياس السابق للمخبز على نمط الاقتراع، وتخيل أنك تستدعي مخبزًا وتأمر بكعكة مخصصة للتسليم. تستغرق عملية صنع الكعكة وقتًا، ولا تريد الانتظار على الهاتف بينما يعمل المخبز على الكعكة. يؤكد المخبز طلبك ويستدعيك كل 20 دقيقة للحصول على حالة الكعكة. بعد مرور 20 دقيقة، يمكنك الاتصال بالمخبز، لكنهم يخبرونك أن الكعكة الخاصة بك لم تنته وأنه يجب عليك الاتصال في 20 دقيقة أخرى. تستمر هذه العملية ذهابًا وإيابًا حتى تتصل، ويخبرك المخبز أن طلبك جاهز ويسلم الكعكة الخاصة بك.

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

Polling action pattern

فيما يلي الخطوات المحددة التي يجب اتباعها لواجهة برمجة التطبيقات، الموضحة من منظور واجهة برمجة التطبيقات:

  1. عندما تحصل واجهة برمجة التطبيقات على طلب HTTP لبدء العمل، قم فورا بإرجاع استجابة HTTP 202 ACCEPTED بالعنوان الموضح location لاحقًا في هذه الخطوة. تتيح هذه الاستجابة لمحرك Azure Logic Apps معرفة أن واجهة برمجة التطبيقات حصلت على الطلب وقبلت حمولة الطلب (إدخال البيانات) وهي الآن قيد المعالجة.

    يجب أن تتضمن الاستجابة 202 ACCEPTED هذه العناوين:

    • مطلوب: عنوان location يحدد المسار المطلق إلى عنوان URL حيث يمكن لمحرك Azure Logic Apps التحقق من حالة وظيفة واجهة برمجة التطبيقات

    • اختياري: retry-after عنوان يحدد عدد الثواني التي يجب أن ينتظرها المحرك قبل التحقق من location عنوان URL لحالة المهمة.

      بشكل افتراضي، يستقصي location المحرك عنوان URL بعد ثانية واحدة. لتحديد فاصل زمني مختلف، قم بتضمين retry-after العنوان وعدد الثواني حتى الاستقصاء التالي.

  2. بعد مرور الوقت المحدد، يستقصي محرك Azure Logic Apps عنوان URL لـ location للتحقق من حالة الوظيفة. يجب أن تقوم واجهة برمجة التطبيقات بإجراء عمليات التحقق هذه وإرجاع هذه الاستجابات:

    • إذا تم إنجاز المهمة، فقم بإرجاع استجابة HTTP 200 OK، بالإضافة إلى حمولة الاستجابة (إدخال للخطوة التالية).

    • إذا كانت المهمة لا تزال قيد المعالجة، فسترجع استجابة HTTP 202 ACCEPTED أخرى، ولكن بنفس العناوين مثل الاستجابة الأصلية.

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

تلميح

على سبيل المثال، نمط غير متزامن، راجع نموذج استجابة وحدة التحكم غير المتزامنة هذا في GitHub.

تنفيذ المهام طويلة الأمد باستخدام نمط إجراء خطاف الويب

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

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

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

لهذا النمط، قم بإعداد نقطتَي نهاية على وحدة التحكم الخاصة بك: subscribe وunsubscribe

  • subscribe نقطة النهاية: عندما يصل التنفيذ إلى إجراء واجهة برمجة التطبيقات في سير العمل، فإن محرك Azure Logic Apps يستدعي نقطة النهاية subscribe. تتسبب هذه الخطوة في قيام سير العمل بإنشاء عنوان URL لرد الاتصال الذي تُخزِنه واجهة برمجة التطبيقات، ثم انتظار رد الاتصال من واجهة برمجة التطبيقات عند اكتمال العمل. ثم تستدعي واجهة برمجة التطبيقات الخاصة بك مرة أخرى مع HTTP POST إلى عنوان URL وتمرر أي محتوى ورؤوس تم إرجاعها كإدخال إلى تطبيق المنطق.

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

Webhook action pattern

حاليًا، لا يدعم مُصمم سير العمل اكتشاف نقاط نهاية إخطار على الويب من خلال Swagger. لذلك لهذا النمط، يجب عليك إضافة إجراء Webhook وتحديد عنوان URL والرؤوس والنص الأساسي لطلبك. راجع أيضًا إجراءات ومشغلات سير العمل. للحصول على مثال على نمط خطاف الويب، راجع نموذج مشغل خطاف الويب هذا في GitHub.

فيما يلي بعض التلميحات والملاحظات الأخرى:

  • لتمرير عنوان URL لرد الاتصال، يمكنك استخدام دالة @listCallbackUrl() سير العمل في أي من الحقول السابقة حسب الضرورة.

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

أنماط المشغل

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

تحقق من البيانات أو الأحداث الجديدة بانتظام باستخدام نمط إجراء الاستطلاع

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

Polling trigger pattern

إشعار

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

فيما يلي خطوات محددة لمشغل الاستقصاء، الموضحة من منظور واجهة برمجة التطبيقات:

هل وجدت بيانات أو حدثًا جديدًا؟ استجابة واجهة برمجة التطبيقات
تم العثور عليه إرجاع حالة HTTP 200 OK مع حمولة الاستجابة (إدخال للخطوة التالية).
تُنشئ هذه الاستجابة مثيل سير العمل وتبدأ سير العمل.
غير موجود إرجاع حالة HTTP 202 ACCEPTED مع رأس location ورأس retry-after .
بالنسبة إلى المُشغلات، يجب أن يحتوي العنوان location أيضًا على معلمة استعلام triggerState، والتي عادة ما تكون "طابعًا زمنيًا". يمكن لواجهة برمجة التطبيقات استخدام هذا المعرّف لتتبع آخر مرة اشتغل بها سير العمل.

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

هل يشمل الطلب triggerState؟ استجابة واجهة برمجة التطبيقات
لا إرجاع حالة HTTP 202 ACCEPTED بالإضافة إلى location عنوان مع triggerState تعيين إلى الوقت الحالي والفاصل retry-after الزمني إلى 15 ثانية.
‏‏نعم‬ تحقق من الخدمة بحثًا عن الملفات المضافة بعد DateTime لـ triggerState.
عدد الملفات التي تم العثور عليها استجابة واجهة برمجة التطبيقات
ملف واحد إرجاع حالة HTTP 200 OK وحمولة المحتوى، والتحديث triggerState إلى DateTime للملف الذي تم إرجاعه، وتعيين retry-after الفاصل الزمني إلى 15 ثانية.
ملفات متعددة إرجاع ملف واحد في كل مرة وحالة HTTP 200 OK، وتحديث triggerState، وتعيين الفاصل الزمني retry-after إلى 0 ثانية.
تتيح هذه الخطوات للمشغل معرفة توفر المزيد من البيانات، وأنه يجب على المحرك طلب البيانات على الفور من عنوان URL في العنوان location.
لا توجد ملفات إرجاع حالة HTTP 202 ACCEPTED، ولا تقم بتغيير triggerState، وتعيين الفاصل الزمني retry-after إلى 15 ثانية.

تلميح

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

انتظر واستمع إلى البيانات أو الأحداث الجديدة باستخدام نمط المشغل للخطاف على الويب

مشغل خطاف الويب هو مشغل دفع ينتظر ويستمع إلى بيانات أو أحداث جديدة في نقطة نهاية الخدمة. إذا كانت البيانات الجديدة أو الحدث يلبي الشرط المحدد، يعمل المُشغّل وينشئ مثيل سير العمل، والذي يعالج البيانات بعد ذلك كإدخال. تعمل مشغلات Webhook إلى حد كبير مثل إجراءات الإخطار على الويب الموضحة سابقًا في هذا الموضوع، ويتم إعدادها باستخدام subscribe ونقاط النهاية unsubscribe .

  • subscribe نقطة النهاية: عند إضافة مُشغّل إخطار على الويب وحفظه في تطبيق المنطق، فإن محرك Azure Logic Apps يستدعي نقطة النهاية subscribe. تتسبب هذه الخطوة في قيام سير العمل بإنشاء عنوان URL لرد الاتصال الذي تُخزِنه واجهة برمجة التطبيقات. عند وجود بيانات جديدة أو حدث يلبي الشرط المحدد، تستدعي واجهة برمجة التطبيقات الخاصة بك مرة أخرى مع HTTP POST إلى عنوان URL. تمر حمولة المحتوى ورؤوسه كإدخال إلى تطبيق المنطق.

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

Webhook trigger pattern

حاليًا، لا يدعم مُصمم سير العمل اكتشاف نقاط نهاية إخطار على الويب من خلال Swagger. لذلك لهذا النمط، يجب عليك إضافة مشغل Webhook وتحديد عنوان URL والرؤوس والنص الأساسي لطلبك. راجع أيضًا مشغل HTTPWebhook. للحصول على مثال على نمط خطاف الويب، راجع نموذج مشغل وحدة تحكم خطاف الويب هذا في GitHub.

فيما يلي بعض التلميحات والملاحظات الأخرى:

  • لتمرير عنوان URL لرد الاتصال، يمكنك استخدام دالة @listCallbackUrl() سير العمل في أي من الحقول السابقة حسب الضرورة.

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

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

تحسين أمان المكالمات إلى واجهات برمجة التطبيقات من تطبيقات المنطق

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

نشر واجهات برمجة التطبيقات الخاصة بك واستدعاؤها

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

نشر واجهات برمجة التطبيقات المخصصة إلى Azure

لجعل واجهات برمجة التطبيقات المخصصة متاحة لمستخدمي Azure Logic Apps الآخرين، يجب إضافة الأمان وتسجيل الواجهات على أنها موصلات Azure Logic Apps. لمزيد من المعلومات راجع نظرة عامة على الموصلات المخصصة.

لجعل واجهات برمجة التطبيقات المخصصة متاحة لجميع المستخدمين في Logic Apps وPower Automate وMicrosoft Power Apps، يجب إضافة الأمان وتسجيل واجهات برمجة التطبيقات كموصلات Azure Logic Apps واختيار الموصلات لبرنامج Microsoft Azure Certified.

الحصول على الدعم

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