التعامل مع الرسائل الكبيرة في مهام سير العمل باستخدام التقطيع في تطبيقات Azure المنطقية
لدى Azure Logic Apps حدود قصوى مختلفة على حجم محتوى الرسالة الذي يمكن أن تتعامل معه عمليات التشغيل والإجراءات في مهام سير عمل التطبيق المنطقي، استنادا إلى نوع مورد التطبيق المنطقي والبيئة التي يتم تشغيل سير عمل التطبيق المنطقي فيها. تساعد هذه الحدود في تقليل أي نفقات عامة تنتج عن تخزين الرسائل الكبيرة ومعالجتها. لمزيد من المعلومات حول حدود حجم الرسالة، راجع حدود الرسائل في Azure Logic Apps.
إذا كنت تستخدم إجراءات HTTP مضمنة أو إجراءات موصل مدارة محددة، وكنت بحاجة إلى تطبيقات Azure Logic للعمل مع الرسائل الأكبر من الحدود الافتراضية، فيمكنك تمكين القطع، الذي يقسم رسالة كبيرة إلى رسائل أصغر. بهذه الطريقة ، لا يزال بإمكانك نقل الملفات الكبيرة في ظل ظروف محددة. في الواقع، عند استخدام إجراءات HTTP المضمنة هذه أو إجراءات الموصل المدار المحددة، فإن القطع هو الطريقة الوحيدة التي يمكن أن تستهلك بها تطبيقات Azure Logic الرسائل الكبيرة. يعني هذا المطلب أنه إما أن تبادل رسائل HTTP الأساسي بين تطبيقات Azure Logic والخدمات الأخرى يجب أن يستخدم القطع، أو أن الاتصالات التي تم إنشاؤها بواسطة الموصلات المدارة التي تريد استخدامها يجب أن تدعم أيضا القطع.
ملاحظة
لا تدعم تطبيقات Azure Logic Apps التقسيم على المشغلات بسبب زيادة النفقات العامة الناتجة عن تبادل رسائل متعددة. أيضا، تقوم Azure Logic Apps بتنفيذ عمليات القطع لإجراءات HTTP باستخدام البروتوكول الخاص بها كما هو موضح في هذه المقالة. لذلك ، حتى إذا كان موقع الويب أو خدمة الويب الخاصة بك تدعم القطع ، فلن تعمل مع قطع إجراء HTTP. لاستخدام إجراء HTTP مع موقع الويب أو خدمة الويب، يجب عليك تنفيذ نفس البروتوكول الذي تستخدمه تطبيقات Azure Logic Apps. وإلا، فلا تقم بتمكين التقطيع على إجراء HTTP.
توفر هذه المقالة نظرة عامة حول كيفية عمل التقطيع في تطبيقات Azure Logic وكيفية إعداد التقطيع على الإجراءات المدعومة.
ما الذي يجعل الرسائل "كبيرة"؟
الرسائل "كبيرة" استنادا إلى الخدمة التي تتعامل مع هذه الرسائل. يختلف الحد الأقصى الدقيق لحجم الرسائل الكبيرة عبر التطبيقات المنطقية والموصلات. لا يمكن لكل من التطبيقات المنطقية والموصلات استهلاك الرسائل الكبيرة مباشرة، والتي يجب أن تكون مجزأة. لمعرفة الحد الأقصى لحجم رسالة Logic Apps، راجع حدود التطبيقات المنطقية وتكوينها. لمعرفة الحد الأقصى لحجم رسالة كل موصل، راجع التفاصيل الفنية المحددة للموصل.
معالجة الرسائل المجزأة للتطبيقات المنطقية
لا يمكن للتطبيقات المنطقية استخدام المخرجات مباشرة من الرسائل المجزأة الأكبر من الحد الأقصى لحجم الرسالة. فقط الإجراءات التي تدعم القطع يمكنها الوصول إلى محتوى الرسالة في هذه المخرجات. لذلك ، يجب أن يفي الإجراء الذي يتعامل مع الرسائل الكبيرة إما بهذه المعايير:
- دعم القطع أصلا عندما ينتمي هذا الإجراء إلى موصل.
- قم بتمكين دعم القطع في تكوين وقت تشغيل هذا الإجراء.
وإلا، تحصل على خطأ وقت تشغيل عند محاولة الوصول إلى إخراج محتوى كبير. لتمكين القطع، راجع إعداد دعم التجزئة.
معالجة الرسائل المجزأة للموصلات
يمكن أن يكون للخدمات التي تتواصل مع Logic Apps حدود حجم الرسالة الخاصة بها. غالبا ما تكون هذه الحدود أصغر من حد التطبيقات المنطقية. على سبيل المثال، بافتراض أن الموصل يدعم القطع، قد يعتبر الموصل رسالة بحجم 30 ميغابايت كبيرة، بينما لا تدعم التطبيقات المنطقية. للامتثال لحد هذا الموصل، تقوم Logic Apps بتقسيم أي رسالة أكبر من 30 ميغابايت إلى أجزاء أصغر.
بالنسبة للموصلات التي تدعم القطع، يكون بروتوكول القطع الأساسي غير مرئي للمستخدمين النهائيين. ومع ذلك، لا تدعم جميع الموصلات القطع، لذلك تقوم هذه الموصلات بإنشاء أخطاء وقت التشغيل عندما تتجاوز الرسائل الواردة حدود حجم الموصلات.
بالنسبة للإجراءات التي تدعم القطع ويتم تمكينها، لا يمكنك استخدام أجسام المشغل والمتغيرات والتعبيرات مثل @triggerBody()?['Content'] لأن استخدام أي من هذه المدخلات يمنع حدوث عملية القطع. بدلا من ذلك، استخدم الإجراء إنشاء. وعلى وجه التحديد، يجب إنشاء body حقل باستخدام الإجراء إنشاء لتخزين إخراج البيانات من نص المشغل والمتغير والتعبير وما إلى ذلك، على سبيل المثال:
"Compose": {
"inputs": {
"body": "@variables('myVar1')"
},
"runAfter": {
"Until": [
"Succeeded"
]
},
"type": "Compose"
},
ثم، للإشارة إلى البيانات، في إجراء التقطيع، استخدم @body('Compose') .
"Create_file": {
"inputs": {
"body": "@body('Compose')",
"headers": {
"ReadFileMetadataFromServer": true
},
"host": {
"connection": {
"name": "@parameters('$connections')['sftpwithssh_1']['connectionId']"
}
},
"method": "post",
"path": "/datasets/default/files",
"queries": {
"folderPath": "/c:/test1/test1sub",
"name": "tt.txt",
"queryParametersSingleEncoded": true
}
},
"runAfter": {
"Compose": [
"Succeeded"
]
},
"runtimeConfiguration": {
"contentTransfer": {
"transferMode": "Chunked"
}
},
"type": "ApiConnection"
},
إعداد التقطيع عبر HTTP
في سيناريوهات HTTP العامة، يمكنك تقسيم تنزيلات المحتوى الكبير وتحميلاته عبر HTTP، بحيث يمكن لتطبيقك المنطقي ونقطة النهاية تبادل الرسائل الكبيرة. ومع ذلك، يجب عليك تقسيم الرسائل بالطريقة التي تتوقعها التطبيقات المنطقية.
إذا مكنت نقطة النهاية التقطيع للتنزيلات أو التحميلات، فإن إجراءات HTTP في تطبيقك المنطقي تقوم تلقائيا بتقطيع الرسائل الكبيرة. وإلا، يجب عليك إعداد دعم القطع على نقطة النهاية. إذا كنت لا تملك نقطة النهاية أو الموصل أو لا تتحكم فيهما، فقد لا يتوفر لك خيار إعداد القطع.
أيضا، إذا كان إجراء HTTP لا يمكن بالفعل القطع، فيجب عليك أيضا إعداد القطع في خاصية الإجراء runTimeConfiguration .
يمكنك تعيين هذه الخاصية داخل الإجراء، إما مباشرة في محرر طريقة عرض التعليمات البرمجية كما هو موضح لاحقا، أو في مصمم التطبيقات المنطقية كما هو موضح هنا:
في الزاوية العلوية اليسرى من إجراء HTTP، اختر زر علامة الحذف (...)، ثم اختر الإعدادات.

ضمن نقل المحتوى، اضبط السماح بالتقطيع على تشغيل.

لمتابعة إعداد التقسيم للتنزيلات أو التحميلات، تابع الأقسام التالية.
تنزيل المحتوى في أجزاء
ترسل العديد من نقاط النهاية تلقائيا رسائل كبيرة في أجزاء عند تنزيلها من خلال طلب HTTP GET. لتنزيل رسائل مجزأة من نقطة نهاية عبر HTTP، يجب أن تدعم نقطة النهاية طلبات المحتوى الجزئي أو التنزيلات المقطعة. عندما يرسل تطبيقك المنطقي طلب HTTP GET إلى نقطة نهاية لتنزيل المحتوى، وتستجيب نقطة النهاية برمز حالة "206"، تحتوي الاستجابة على محتوى مجزأ. لا يمكن للتطبيقات المنطقية التحكم فيما إذا كانت نقطة النهاية تدعم الطلبات الجزئية أم لا. ومع ذلك، عندما يحصل تطبيقك المنطقي على أول استجابة "206"، يرسل تطبيقك المنطقي تلقائيا طلبات متعددة لتنزيل كل المحتوى.
للتحقق مما إذا كانت نقطة النهاية يمكن أن تدعم المحتوى الجزئي، أرسل طلب HEAD. يساعدك هذا الطلب في تحديد ما إذا كانت الاستجابة تحتوي على Accept-Ranges الرأس أم لا.
وبهذه الطريقة، إذا كانت نقطة النهاية تدعم التنزيلات المجزأة ولكنها لا ترسل محتوى مجزأ، فيمكنك اقتراح هذا الخيار عن طريق تعيين Range الرأس في طلب HTTP GET.
تصف هذه الخطوات العملية التفصيلية التي تستخدمها التطبيقات المنطقية لتنزيل المحتوى المجزأ من نقطة نهاية إلى تطبيقك المنطقي:
يرسل تطبيقك المنطقي طلب HTTP GET إلى نقطة النهاية.
يمكن أن يتضمن رأس الطلب اختياريا حقلا
Rangeيصف نطاق بايت لطلب أجزاء المحتوى.تستجيب نقطة النهاية برمز الحالة "206" ونص رسالة HTTP.
تظهر تفاصيل حول المحتوى الموجود في هذه القطعة في رأس الاستجابة
Content-Range، بما في ذلك المعلومات التي تساعد Logic Apps على تحديد البداية والنهاية للقطعة، بالإضافة إلى الحجم الإجمالي للمحتوى بأكمله قبل القطع.يرسل تطبيقك المنطقي تلقائيا طلبات HTTP GET للمتابعة.
يرسل تطبيقك المنطقي طلبات GET للمتابعة حتى يتم استرداد المحتوى بأكمله.
على سبيل المثال، يعرض تعريف الإجراء هذا طلب HTTP GET الذي يعين Range الرأس.
يقترح الرأس أن تستجيب نقطة النهاية بمحتوى مجزأ:
"getAction": {
"inputs": {
"headers": {
"Range": "bytes=0-1023"
},
"method": "GET",
"uri": "http://myAPIendpoint/api/downloadContent"
},
"runAfter": {},
"type": "Http"
}
يقوم طلب GET بتعيين رأس "النطاق" إلى "bytes=0-1023"، وهو نطاق البايتات. إذا كانت نقطة النهاية تدعم طلبات المحتوى الجزئي، فستستجيب نقطة النهاية بجزء محتوى من النطاق المطلوب. استنادا إلى نقطة النهاية، يمكن أن يختلف التنسيق الدقيق لحقل رأس "النطاق".
Upload المحتوى في أجزاء
لتحميل محتوى مجزأ من إجراء HTTP، يجب أن يكون الإجراء قد مكن دعم القطع من خلال خاصية الإجراء runtimeConfiguration .
يسمح هذا الإعداد للإجراء ببدء تشغيل بروتوكول التجزئة.
يمكن لتطبيقك المنطقي بعد ذلك إرسال رسالة POST أو PUT أولية إلى نقطة النهاية المستهدفة.
بعد أن تستجيب نقطة النهاية بحجم قطعة مقترح، يتابع تطبيقك المنطقي عن طريق إرسال طلبات HTTP PATCH التي تحتوي على أجزاء المحتوى.
تصف الخطوات التالية العملية التفصيلية التي تستخدمها Logic Apps لتحميل المحتوى المجزأ من تطبيقك المنطقي إلى نقطة نهاية:
يرسل تطبيقك المنطقي طلب HTTP POST أو PUT أولي مع نص رسالة فارغ. يتضمن رأس الطلب المعلومات التالية حول المحتوى الذي يريد تطبيقك المنطقي تحميله على أجزاء صغيرة:
حقل رأس طلب التطبيقات المنطقية القيمة النوع الوصف x-ms-transfer-mode المقسم سلسلة يشير إلى أنه تم تحميل المحتوى في أجزاء x-ms-content-length <طول المحتوى> عدد صحيح حجم المحتوى بالكامل بالبايت قبل التقطيع تستجيب نقطة النهاية برمز حالة النجاح "200" والمعلومات التالية:
حقل رأس استجابة نقطة النهاية النوع مطلوب الوصف الموقع سلسلة نعم موقع عنوان URL لإرسال رسائل HTTP PATCH x-ms-قطعة-الحجم عدد صحيح لا حجم القطعة المقترحة بالبايت يقوم تطبيقك المنطقي بإنشاء رسائل HTTP PATCH للمتابعة وإرسالها - تحتوي كل منها على المعلومات التالية:
جزء محتوى يستند إلى حجم القطعة x-ms-chunk أو بعض الحجم المحسوب داخليا حتى يتم تحميل كل المحتوى الذي يبلغ إجمالي طول محتوى x-ms-بشكل متسلسل
معلومات الرأس التالية حول جزء المحتوى المرسل في كل رسالة PATCH:
حقل رأس طلب التطبيقات المنطقية القيمة النوع الوصف نطاق المحتوى <نطاق> سلسلة نطاق البايت لجزء المحتوى الحالي، بما في ذلك قيمة البداية والقيمة النهائية وإجمالي حجم المحتوى، على سبيل المثال: "bytes=0-1023/10100" نوع المحتوى <نوع المحتوى> سلسلة نوع المحتوى المجزأ طول المحتوى <طول المحتوى> سلسلة طول الحجم بالبايت من القطعة الحالية
بعد كل طلب PATCH، تؤكد نقطة النهاية استلام كل جزء من خلال الاستجابة باستخدام رمز الحالة "200" ورؤوس الاستجابة التالية:
حقل رأس استجابة نقطة النهاية النوع مطلوب الوصف النطاق سلسلة نعم نطاق البايت للمحتوى الذي تم استلامه بواسطة نقطة النهاية، على سبيل المثال: "bytes=0-1023" x-ms-قطعة-الحجم عدد صحيح لا حجم القطعة المقترحة بالبايت
على سبيل المثال، يعرض تعريف الإجراء هذا طلب HTTP POST لتحميل محتوى مجزأ إلى نقطة نهاية. في خاصية الإجراء، contentTransfer يتم تعيين transferMode الخاصية runTimeConfiguration إلىchunked:
"postAction": {
"runtimeConfiguration": {
"contentTransfer": {
"transferMode": "chunked"
}
},
"inputs": {
"method": "POST",
"uri": "http://myAPIendpoint/api/action",
"body": "@body('getAction')"
},
"runAfter": {
"getAction": ["Succeeded"]
},
"type": "Http"
}