إنشاء واجهات برمجة تطبيقات مخصصة يمكنك الاتصال بها من تطبيقات Azure Logic
على الرغم من أن Azure Logic Apps توفر مئات الموصلات التي يمكنك استخدامها في مهام سير عمل التطبيقات المنطقية، فقد ترغب في استدعاء واجهات برمجة التطبيقات والأنظمة والخدمات غير المتوفرة كموصلات. يمكنك إنشاء واجهات برمجة التطبيقات الخاصة بك التي توفر إجراءات ومشغلات لاستخدامها في التطبيقات المنطقية. فيما يلي أسباب أخرى قد تجعلك ترغب في إنشاء واجهات برمجة التطبيقات الخاصة بك والتي يمكنك الاتصال بها من مهام سير عمل التطبيق المنطقي:
- قم بتوسيع مهام سير عمل تكامل النظام وتكامل البيانات الحالية.
- ساعد العملاء على استخدام خدمتك لإدارة المهام المهنية أو الشخصية.
- وسع نطاق الوصول وإمكانية الاكتشاف والاستخدام لخدمتك.
في الأساس ، الموصلات هي واجهات برمجة تطبيقات الويب التي تستخدم REST للواجهات القابلة للتوصيل ، وتنسيق البيانات الوصفية Swagger للوثائق ، و JSON كتنسيق لتبادل البيانات الخاصة بها. نظرا لأن الموصلات هي واجهات برمجة تطبيقات REST تتصل من خلال نقاط نهاية HTTP، يمكنك استخدام أي لغة، مثل .NET أو Java أو Python أو Node.js، لإنشاء الموصلات. يمكنك أيضا استضافة واجهات برمجة التطبيقات الخاصة بك على Azure App Service، وهو عرض للنظام الأساسي كخدمة (PaaS) يوفر واحدة من أفضل الطرق وأسهلها وأكثرها قابلية للتطوير لاستضافة واجهة برمجة التطبيقات.
لكي تعمل واجهات برمجة التطبيقات المخصصة مع التطبيقات المنطقية، يمكن أن توفر واجهة برمجة التطبيقات إجراءات تؤدي مهام محددة في مهام سير عمل التطبيقات المنطقية. يمكن أن تعمل واجهة برمجة التطبيقات أيضا كمشغل يبدأ سير عمل تطبيق منطقي عندما تفي بيانات جديدة أو حدث جديد بشرط محدد. يصف هذا الموضوع الأنماط الشائعة التي يمكنك اتباعها لإنشاء الإجراءات والمشغلات في واجهة برمجة التطبيقات، استنادا إلى السلوك الذي تريد أن توفره واجهة برمجة التطبيقات.
يمكنك استضافة واجهات برمجة التطبيقات الخاصة بك على Azure App Service، وهو عرض للنظام الأساسي كخدمة (PaaS) يوفر استضافة واجهة برمجة تطبيقات سهلة وقابلة للتطوير للغاية.
تلميح
على الرغم من أنه يمكنك نشر واجهات برمجة التطبيقات الخاصة بك كتطبيقات ويب، فكر في نشر واجهات برمجة التطبيقات الخاصة بك كتطبيقات واجهة برمجة التطبيقات، والتي يمكن أن تجعل عملك أسهل عند إنشاء واجهات برمجة التطبيقات واستضافتها واستهلاكها في السحابة وفي أماكن العمل. ليس عليك تغيير أي رمز في واجهات برمجة التطبيقات الخاصة بك - ما عليك سوى نشر التعليمات البرمجية الخاصة بك على تطبيق API. على سبيل المثال، تعرف على كيفية إنشاء تطبيقات واجهة برمجة التطبيقات التي تم إنشاؤها باستخدام اللغات التالية:
للحصول على عينات تطبيقات واجهة برمجة التطبيقات المصممة للتطبيقات المنطقية، تفضل بزيارة مستودع Azure Logic Apps GitHub.
كيف تختلف واجهات برمجة التطبيقات المخصصة عن الموصلات المخصصة؟
واجهات برمجة التطبيقات المخصصة والموصلات المخصصة هي واجهات برمجة تطبيقات ويب تستخدم REST للواجهات القابلة للتوصيل وتنسيق بيانات تعريف Swagger للوثائق وJSON كتنسيق لتبادل البيانات الخاص بها. ولأن واجهات برمجة التطبيقات والموصلات هذه هي واجهات برمجة تطبيقات REST تتصل من خلال نقاط نهاية HTTP ، يمكنك استخدام أي لغة ، مثل .NET أو Java أو Python أو Node.js ، لإنشاء واجهات برمجة تطبيقات وموصلات مخصصة.
تتيح لك واجهات برمجة التطبيقات المخصصة استدعاء واجهات برمجة التطبيقات التي ليست موصلات، وتوفير نقاط نهاية يمكنك الاتصال بها باستخدام HTTP + Swagger أو إدارة واجهة برمجة تطبيقات Azure أو خدمات التطبيقات. تعمل الموصلات المخصصة مثل واجهات برمجة التطبيقات المخصصة ولكن لديها أيضا هذه السمات:
- مسجل كموارد موصل التطبيقات المنطقية في Azure.
- يمكنك الظهور مع الرموز إلى جانب الموصلات المدارة من Microsoft في مصمم التطبيقات المنطقية.
- متوفر فقط لمؤلفي الموصلات ومستخدمي التطبيقات المنطقية الذين لديهم نفس مستأجر Azure Active Directory واشتراك Azure في المنطقة التي يتم فيها نشر التطبيقات المنطقية.
يمكنك أيضا ترشيح الموصلات المسجلة لشهادة Microsoft. تتحقق هذه العملية من أن الموصلات المسجلة تفي بمعايير الاستخدام العام وتجعل هذه الموصلات متوفرة للمستخدمين في Power Automate وMicrosoft Power Apps.
لمزيد من المعلومات حول الموصلات المخصصة، راجع
- نظرة عامة على الموصلات المخصصة
- إنشاء موصلات مخصصة من واجهات برمجة تطبيقات الويب
- تسجيل الموصلات المخصصة في تطبيقات Azure Logic
أدوات مفيدة
تعمل واجهة برمجة التطبيقات المخصصة بشكل أفضل مع التطبيقات المنطقية عندما تحتوي واجهة برمجة التطبيقات أيضا على مستند Swagger يصف عمليات واجهة برمجة التطبيقات ومعلماتها. يمكن للعديد من المكتبات ، مثل Swashbuckle ، إنشاء ملف Swagger تلقائيا نيابة عنك. لإضافة تعليق توضيحي على ملف Swagger لأسماء العرض وأنواع الخصائص وما إلى ذلك، يمكنك أيضا استخدام TRex بحيث يعمل ملف Swagger بشكل جيد مع التطبيقات المنطقية.
أنماط العمل
لكي تتمكن التطبيقات المنطقية من تنفيذ المهام، يجب أن توفر واجهة برمجة التطبيقات المخصصة إجراءات. يتم تعيين كل عملية في واجهة برمجة التطبيقات الخاصة بك إلى إجراء. الإجراء الأساسي هو وحدة تحكم تقبل طلبات HTTP وترجع استجابات HTTP. على سبيل المثال، يرسل تطبيق منطقي طلب HTTP إلى تطبيق الويب أو تطبيق واجهة برمجة التطبيقات. ثم يعرض تطبيقك استجابة HTTP، إلى جانب المحتوى الذي يمكن للتطبيق المنطقي معالجته.
لإجراء قياسي، يمكنك كتابة طريقة طلب HTTP في واجهة برمجة التطبيقات ووصف هذه الطريقة في ملف Swagger. يمكنك بعد ذلك الاتصال بواجهة برمجة التطبيقات الخاصة بك مباشرة باستخدام إجراء HTTP أو إجراء HTTP+ Swagger . بشكل افتراضي، يجب إرجاع الردود ضمن حد مهلة الطلب.
لجعل تطبيق منطقي ينتظر حتى تنتهي واجهة برمجة التطبيقات من المهام التي تعمل لفترة أطول، يمكن لواجهة برمجة التطبيقات اتباع نمط الاستقصاء غير المتزامن أو نمطخطاف الويب غير المتزامن الموضح في هذا الموضوع. للحصول على تشبيه يساعدك على تصور السلوكيات المختلفة لهذه الأنماط ، تخيل عملية طلب كعكة مخصصة من مخبز. يعكس نمط الاقتراع السلوك الذي تتصل فيه بالمخبز كل 20 دقيقة للتحقق مما إذا كانت الكعكة جاهزة. يعكس نمط webhook السلوك الذي يطلب منك فيه المخبز رقم هاتفك حتى يتمكنوا من الاتصال بك عندما تكون الكعكة جاهزة.
للحصول على عينات، تفضل بزيارة مستودع GitHub التطبيقات المنطقية. تعرف أيضا على المزيد حول قياس الاستخدام للإجراءات.
تنفيذ مهام طويلة الأمد باستخدام نمط إجراء الاقتراع
لجعل واجهة برمجة التطبيقات تقوم بتنفيذ مهام يمكن أن تعمل لفترة أطول من حد مهلة الطلب، يمكنك استخدام نمط الاستقصاء غير المتزامن. يحتوي هذا النمط على واجهة برمجة التطبيقات الخاصة بك تعمل في سلسلة رسائل منفصلة ، ولكن احتفظ باتصال نشط بمحرك Logic Apps. وبهذه الطريقة، لا تنتهي مهلة التطبيق المنطقي أو يستمر في الخطوة التالية في سير العمل قبل انتهاء واجهة برمجة التطبيقات من العمل.
إليك النمط العام:
- تأكد من أن المحرك يعرف أن واجهة برمجة التطبيقات الخاصة بك قبلت الطلب وبدأت العمل.
- عندما يقدم المحرك طلبات لاحقة لحالة الوظيفة، أخبر المحرك عندما تنتهي واجهة برمجة التطبيقات من المهمة.
- قم بإرجاع البيانات ذات الصلة إلى المحرك بحيث يمكن متابعة سير عمل تطبيق المنطق.
الآن قم بتطبيق تشبيه المخبز السابق على نمط الاقتراع ، وتخيل أنك تتصل بمخبز وتطلب كعكة مخصصة للتسليم. تستغرق عملية صنع الكعكة وقتا ، ولا تريد الانتظار على الهاتف أثناء عمل المخبز على الكعكة. يؤكد المخبز طلبك ويطلب منك الاتصال كل 20 دقيقة لمعرفة حالة الكعكة. بعد مرور 20 دقيقة ، تتصل بالمخبز ، لكنهم يخبرونك أن الكعكة الخاصة بك لم تنته وأنه يجب عليك الاتصال في غضون 20 دقيقة أخرى. تستمر هذه العملية ذهابا وإيابا حتى تتصل ، ويخبرك المخبز أن طلبك جاهز ويسلم الكعكة.
لذلك دعونا نرسم خريطة لنمط الاقتراع هذا مرة أخرى. يمثل المخبز واجهة برمجة التطبيقات المخصصة الخاصة بك، بينما تمثل أنت، عميل الكعكة، محرك Logic Apps. عندما يتصل المحرك بواجهة برمجة التطبيقات الخاصة بك مع طلب، تؤكد واجهة برمجة التطبيقات الطلب وتستجيب مع الفاصل الزمني الذي يمكن للمحرك فيه التحقق من حالة الوظيفة. يستمر المحرك في التحقق من حالة الوظيفة حتى تستجيب واجهة برمجة التطبيقات الخاصة بك بأن المهمة قد انتهت وتعيد البيانات إلى تطبيقك المنطقي، والذي يستمر بعد ذلك في سير العمل.
فيما يلي الخطوات المحددة التي يجب على واجهة برمجة التطبيقات اتباعها، الموضحة من وجهة نظر واجهة برمجة التطبيقات:
عندما تتلقى واجهة برمجة التطبيقات طلب HTTP لبدء العمل، يمكنك إرجاع استجابة HTTP
202 ACCEPTEDعلى الفور مع الرأس الموضح لاحقا في هذه الخطوةlocation. تتيح هذه الاستجابة لمحرك Logic Apps معرفة أن واجهة برمجة التطبيقات الخاصة بك حصلت على الطلب وقبلت حمولة الطلب (إدخال البيانات) وتتم معالجتها الآن.202 ACCEPTEDيجب أن تتضمن الاستجابة هذه العناوين:مطلوب:
locationرأس يحدد المسار المطلق إلى عنوان URL حيث يمكن لمحرك Logic Apps التحقق من حالة الوظيفة في واجهة برمجة التطبيقاتاختياري:
retry-afterرأس يحدد عدد الثواني التي يجب أن ينتظرها المحرك قبل التحقق من عنوان URL لحالة الوظيفةlocation.بشكل افتراضي ، يتحقق المحرك كل 20 ثانية. لتحديد فاصل زمني مختلف، قم بتضمين
retry-afterالرأس وعدد الثواني حتى الاستطلاع التالي.
بعد مرور الوقت المحدد، يقوم محرك التطبيقات المنطقية باستقصاء عنوان URL للتحقق من حالة الوظيفة
location. يجب أن تقوم واجهة برمجة التطبيقات بإجراء عمليات التحقق هذه وإرجاع هذه الردود:إذا تم الانتهاء من المهمة، فقم بإرجاع استجابة HTTP
200 OK، إلى جانب حمولة الاستجابة (إدخال للخطوة التالية).إذا كانت المهمة لا تزال قيد المعالجة، فقم بإرجاع استجابة HTTP
202 ACCEPTEDأخرى، ولكن بنفس الرؤوس مثل الاستجابة الأصلية.
عندما تتبع واجهة برمجة التطبيقات هذا النمط، لن تضطر إلى القيام بأي شيء في تعريف سير عمل التطبيق المنطقي لمواصلة التحقق من حالة الوظيفة.
عندما يحصل المحرك على استجابة HTTP 202 ACCEPTED ورأس صالح location ، يحترم المحرك النمط غير المتزامن ويتحقق من location الرأس حتى تقوم واجهة برمجة التطبيقات بإرجاع استجابة غير 202.
تلميح
للحصول على مثال على نمط غير متزامن، راجع عينة استجابة وحدة التحكم غير المتزامنة هذه في GitHub.
تنفيذ مهام طويلة الأمد باستخدام نمط إجراء webhook
كبديل ، يمكنك استخدام نمط webhook للمهام طويلة الأمد والمعالجة غير المتزامنة. يحتوي هذا النمط على إيقاف التطبيق المنطقي مؤقتا وانتظر "معاودة الاتصال" من واجهة برمجة التطبيقات الخاصة بك لإنهاء المعالجة قبل متابعة سير العمل. معاودة الاتصال هذه عبارة عن منشور HTTP يرسل رسالة إلى عنوان URL عند حدوث حدث.
الآن قم بتطبيق تشبيه المخبز السابق على نمط webhook ، وتخيل أنك تتصل بمخبز وتطلب كعكة مخصصة للتسليم. تستغرق عملية صنع الكعكة وقتا ، ولا تريد الانتظار على الهاتف أثناء عمل المخبز على الكعكة. يؤكد المخبز طلبك ، ولكن هذه المرة ، تعطيهم رقم هاتفك حتى يتمكنوا من الاتصال بك عند الانتهاء من الكعكة. هذه المرة ، يخبرك المخبز عندما يكون طلبك جاهزا ويسلم الكعكة.
عندما نقوم بتعيين نمط webhook هذا مرة أخرى ، يمثل المخبز واجهة برمجة التطبيقات المخصصة الخاصة بك ، بينما تمثل أنت ، عميل الكعكة ، محرك Logic Apps. يتصل المحرك بواجهة برمجة التطبيقات الخاصة بك مع طلب ويتضمن عنوان URL "معاودة الاتصال". عند الانتهاء من المهمة، تستخدم واجهة برمجة التطبيقات عنوان URL لإعلام المحرك وإرجاع البيانات إلى تطبيقك المنطقي، والذي يستمر بعد ذلك في سير العمل.
بالنسبة لهذا النمط، قم بإعداد نقطتي نهاية على وحدة التحكم الخاصة بك: subscribe و unsubscribe
subscribeنقطة النهاية: عندما يصل التنفيذ إلى إجراء واجهة برمجة التطبيقات في سير العمل، يستدعيsubscribeمحرك Logic Apps نقطة النهاية. تتسبب هذه الخطوة في قيام التطبيق المنطقي بإنشاء عنوان URL لمعاودة الاتصال تخزنه واجهة برمجة التطبيقات ثم انتظر رد الاتصال من واجهة برمجة التطبيقات عند اكتمال العمل. ثم تتصل واجهة برمجة التطبيقات مرة أخرى باستخدام HTTP POST إلى عنوان URL وتمرر أي محتوى ورؤوس تم إرجاعها كإدخال إلى التطبيق المنطقي.unsubscribeنقطة النهاية: إذا تم إلغاء تشغيل التطبيق المنطقي، يقوم محرك Logic Apps باستدعاءunsubscribeنقطة النهاية. يمكن لواجهة برمجة التطبيقات الخاصة بك بعد ذلك إلغاء تسجيل عنوان URL لمعاودة الاتصال وإيقاف أي عمليات حسب الضرورة.
حاليا، لا يدعم مصمم تطبيقات Logic اكتشاف نقاط نهاية خطاف الويب من خلال Swagger. لذلك بالنسبة لهذا النمط ، يجب عليك إضافة إجراء Webhook وتحديد عنوان URL والرؤوس والنص الأساسي لطلبك. راجع أيضا إجراءات سير العمل والمشغلات. للحصول على مثال على نمط webhook ، راجع عينة مشغل webhook هذه في GitHub.
فيما يلي بعض النصائح والملاحظات الأخرى:
للتمرير في عنوان URL لمعاودة الاتصال، يمكنك استخدام
@listCallbackUrl()وظيفة سير العمل في أي من الحقول السابقة حسب الضرورة.إذا كنت تملك كل من تطبيق المنطق والخدمة المشتركة ، فلن تضطر إلى الاتصال
unsubscribeبنقطة النهاية بعد استدعاء عنوان URL لمعاودة الاتصال. وإلا، يحتاج وقت تشغيل Logic Apps إلى استدعاءunsubscribeنقطة النهاية للإشارة إلى عدم توقع المزيد من المكالمات والسماح بتنظيف الموارد على جانب الخادم.
أنماط الزناد
يمكن أن تعمل واجهة برمجة التطبيقات المخصصة كمشغل يبدأ تطبيقا منطقيا عندما تفي بيانات جديدة أو حدث بشرط محدد. يمكن لهذا المشغل إما التحقق بانتظام أو الانتظار والاستماع إلى البيانات أو الأحداث الجديدة في نقطة نهاية الخدمة. إذا استوفت بيانات جديدة أو حدث ما الشرط المحدد، تشغيل المشغل وبدء تشغيل تطبيق المنطق، الذي يستمع إلى هذا المشغل. لبدء تشغيل التطبيقات المنطقية بهذه الطريقة، يمكن لواجهة برمجة التطبيقات اتباع مشغل الاقتراع أو نمط مشغل webhook . تتشابه هذه الأنماط مع نظيراتها في إجراءات الاقتراع وإجراءاتwebhook. تعرف أيضا على المزيد حول قياس الاستخدام للمشغلات.
تحقق من وجود بيانات أو أحداث جديدة بانتظام باستخدام نمط مشغل الاقتراع
يعمل مشغل الاقتراع بشكل يشبه إلى حد كبير إجراء الاقتراع الموصوف سابقا في هذا الموضوع. يقوم محرك Logic Apps باستدعاء نقطة نهاية المشغل والتحقق منها بشكل دوري بحثا عن بيانات أو أحداث جديدة. إذا عثر المحرك على بيانات جديدة أو حدث يفي بالحالة المحددة، تشغيل المشغل. بعد ذلك، يقوم المحرك بإنشاء مثيل تطبيق منطقي يعالج البيانات كمدخلات.
ملاحظة
يتم احتساب كل طلب اقتراع كتنفيذ إجراء، حتى عند عدم إنشاء مثيل تطبيق منطقي. لمنع معالجة البيانات نفسها عدة مرات، يجب على المشغل تنظيف البيانات التي تمت قراءتها بالفعل وتمريرها إلى تطبيق المنطق.
فيما يلي خطوات محددة لمشغل استطلاع الرأي، موصوفة من منظور واجهة برمجة التطبيقات:
| هل عثرت على بيانات أو حدث جديد؟ | استجابة واجهة برمجة التطبيقات |
|---|---|
| تم العثور عليه | إرجاع حالة HTTP 200 OK مع حمولة الاستجابة (إدخال للخطوة التالية). تقوم هذه الاستجابة بإنشاء مثيل تطبيق منطقي وبدء سير العمل. |
| غير موجود | إرجاع حالة HTTP 202 ACCEPTED مع location رأس ورأس retry-after . بالنسبة للمشغلات ، يجب أن يحتوي الرأس أيضا على triggerState معلمة استعلام ، location والتي عادة ما تكون "طابعا زمنيا". يمكن لواجهة برمجة التطبيقات استخدام هذا المعرف لتتبع آخر مرة تم فيها تشغيل التطبيق المنطقي. |
على سبيل المثال، للتحقق بشكل دوري من الخدمة بحثا عن ملفات جديدة، يمكنك إنشاء مشغل استقصاء يحتوي على هذه السلوكيات:
يشمل الطلب triggerState؟ |
استجابة واجهة برمجة التطبيقات |
|---|---|
| لا | إرجاع حالة HTTP 202 ACCEPTED بالإضافة إلى رأس مع triggerState تعيين إلى الوقت الحالي والفاصل retry-after الزمني إلى location 15 ثانية. |
| نعم | تحقق من خدمتك بحثا عن الملفات المضافة بعد ملف DateTimetriggerState. |
| عدد الملفات التي تم العثور عليها | استجابة واجهة برمجة التطبيقات |
|---|---|
| ملف واحد | إرجاع حالة 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
مشغل webhook هو مشغل دفع ينتظر ويستمع إلى بيانات أو أحداث جديدة في نقطة نهاية الخدمة. إذا استوفت بيانات جديدة أو حدث ما الشرط المحدد، تشغيل المشغل وإنشاء مثيل تطبيق منطقي، والذي يقوم بعد ذلك بمعالجة البيانات كمدخلات.
تعمل مشغلات Webhook بشكل يشبه إلى حد كبير إجراءات webhook الموضحة سابقا في هذا الموضوع ، ويتم إعدادها باستخدام subscribe نقاط النهاية ونقاط unsubscribe النهاية.
subscribeنقطة النهاية: عند إضافة مشغل webhook وحفظه في تطبيق المنطق، يستدعيsubscribeمحرك Logic Apps نقطة النهاية. تتسبب هذه الخطوة في قيام التطبيق المنطقي بإنشاء عنوان URL لمعاودة الاتصال تخزنه واجهة برمجة التطبيقات. عندما تكون هناك بيانات جديدة أو حدث يفي بالشرط المحدد، تتصل واجهة برمجة التطبيقات مرة أخرى باستخدام منشور HTTP إلى عنوان URL. تمر حمولة المحتوى والرؤوس كإدخال إلى تطبيق المنطق.unsubscribeنقطة النهاية: إذا تم حذف مشغل webhook أو تطبيق المنطق بأكمله، يقوم محرك Logic Apps باستدعاءunsubscribeنقطة النهاية. يمكن لواجهة برمجة التطبيقات الخاصة بك بعد ذلك إلغاء تسجيل عنوان URL لمعاودة الاتصال وإيقاف أي عمليات حسب الضرورة.
حاليا، لا يدعم مصمم تطبيقات Logic اكتشاف نقاط نهاية خطاف الويب من خلال Swagger. لذلك بالنسبة لهذا النمط ، يجب عليك إضافة مشغل Webhook وتحديد عنوان URL والرؤوس والنص الأساسي لطلبك. راجع أيضا مشغل HTTPWebhook. للحصول على مثال على نمط webhook ، راجع عينة وحدة تحكم مشغل webhook هذه في GitHub.
فيما يلي بعض النصائح والملاحظات الأخرى:
للتمرير في عنوان URL لمعاودة الاتصال، يمكنك استخدام
@listCallbackUrl()وظيفة سير العمل في أي من الحقول السابقة حسب الضرورة.لمنع معالجة البيانات نفسها عدة مرات، يجب على المشغل تنظيف البيانات التي تمت قراءتها بالفعل وتمريرها إلى تطبيق المنطق.
إذا كنت تملك كل من تطبيق المنطق والخدمة المشتركة ، فلن تضطر إلى الاتصال
unsubscribeبنقطة النهاية بعد استدعاء عنوان URL لمعاودة الاتصال. وإلا، يحتاج وقت تشغيل Logic Apps إلى استدعاءunsubscribeنقطة النهاية للإشارة إلى عدم توقع المزيد من المكالمات والسماح بتنظيف الموارد على جانب الخادم.
تحسين أمان المكالمات إلى واجهات برمجة التطبيقات من التطبيقات المنطقية
بعد إنشاء واجهات برمجة التطبيقات المخصصة، قم بإعداد المصادقة لواجهات برمجة التطبيقات بحيث يمكنك الاتصال بها بأمان من التطبيقات المنطقية. تعرف على كيفية تحسين أمان المكالمات إلى واجهات برمجة التطبيقات المخصصة من التطبيقات المنطقية.
نشر واجهات برمجة التطبيقات والاتصال بها
بعد إعداد المصادقة، قم بإعداد النشر لواجهات برمجة التطبيقات. تعرف على كيفية نشر واجهات برمجة التطبيقات المخصصة واستدعاؤها من التطبيقات المنطقية.
نشر واجهات برمجة التطبيقات المخصصة إلى Azure
لجعل واجهات برمجة التطبيقات المخصصة متاحة لمستخدمي Logic Apps الآخرين في Azure، يجب عليك إضافة الأمان وتسجيلها كموصلات Logic App. لمزيد من المعلومات، راجع نظرة عامة على الموصلات المخصصة.
لجعل واجهات برمجة التطبيقات المخصصة متاحة لجميع المستخدمين في Logic Apps و Power Automate و Microsoft Power Apps، يجب عليك إضافة الأمان وتسجيل واجهات برمجة التطبيقات كموصلات Logic App وترشيح الموصلات لبرنامج Microsoft Azure المعتمد.
الحصول على الدعم
للحصول على مساعدة محددة بشأن واجهات برمجة التطبيقات المخصصة، اتصل ب customapishelp@microsoft.com.
للحصول على الأسئلة، تفضل بزيارة صفحة أسئلة Microsoft QA& الخاصة بتطبيقات Azure المنطقية.
للمساعدة في تحسين التطبيقات المنطقية، قم بالتصويت على الأفكار أو إرسالها في موقع ملاحظات مستخدمي Logic Apps.