معالجة أنواع المحتويات في Azure Logic Apps

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

يدعم Azure Logic Apps جميع أنواع المحتويات مثل JSON وXML والملفات المسطحة والبيانات الثنائية. في حين أن بعض أنواع المحتوى لها دعم أصلي ، مما يعني أنها لا تحتاج إلى إرسال أو تحويل ، فإن أنواع المحتوى الأخرى تحتاج إلى بعض العمل لمنحك التنسيق المطلوب.

للمساعدة في تحديد أفضل طريقة للتعامل مع المحتوى أو البيانات في مهام سير العمل، يستخدم Azure Logic Apps قيمة Content-Type الرأس في طلبات HTTP التي تحصل عليها مهام سير العمل من المتصلين الخارجيين.

تتضمن القائمة التالية بعض الأمثلة Content-Type على القيم التي يمكن أن يواجهها سير العمل:

• application/json (النوع الأصلي)
• نص / عادي (النوع الأصلي)
• application/XML والتطبيق/ثماني بتات التدفق
• أنواع المحتوى الأخرى

يصف هذا الدليل كيفية تعامل Azure Logic Apps مع أنواع المحتويات المختلفة ويوضح كيفية إرسال هذه الأنواع أو تحويلها بشكل صحيح عند الضرورة.

تطبيق/json

بالنسبة لطلب HTTP حيث Content-Type تكون قيمة الرأس هي application/json، تخزن Azure Logic Apps المحتوى وتعالج ككائن JavaScript Object Notation (JSON). بشكل افتراضي ، يمكنك تحليل محتوى JSON بدون أي إرسال أو تحويل. يمكنك أيضا تحليل هذا المحتوى باستخدام تعبير.

على سبيل المثال، يستخدم التعبير التالي الدالة body() مع My_action، وهو اسم JSON لإجراء سابق في سير العمل:

body('My_action')['client']['animal-type'][0]

توضح الخطوات التالية كيفية عمل التعبير بدون إرسال أو تحويل:

1. body() تحصل الدالة على body كائن الإخراج من الإجراءMy_action.

2. من الكائن الذي تم إرجاعه body ، تصل الوظيفة إلى client الكائن.

   يحتوي الكائن client على الخاصية animal-type ، التي تم تعيينها إلى مصفوفة.

3. تصل الدالة إلى العنصر الأول في المصفوفة وترجع القيمة مباشرة دون الإرسال أو التحويل.

إذا كنت تعمل مع بيانات JSON التي لا تستخدم Content-Type رأسا، فيمكنك تحويل هذه البيانات يدويا إلى JSON باستخدام الدالة json()، على سبيل المثال:

json(triggerBody())['client']['animal-type']

1. triggerBody() تحصل الدالة على الكائن body من إخراج مشغل سير العمل. عادة ما يكون هذا الكائن كائن JSON.

   ينشأ مصدر الكائن body من طلب HTTP الوارد أو الحدث الذي يتلقاه مشغل سير العمل.

2. json() تقوم body الدالة بتحليل الكائن الذي تم إرجاعه من الدالة triggerBody() ككائن JSON بشكل صريح.

   يكون هذا السلوك مفيدا، على سبيل المثال، عندما يكون نص المشغل عبارة عن سلسلة تتطلب التعامل معها ك JSON.

يشبه سلوك التعبير المتبقي المثال السابق.

إنشاء الرموز المميزة لخصائص JSON

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

توضح القائمة التالية عمليات سير العمل الشائعة والطرق المقابلة التي يمكنك من خلالها إنشاء رموز مميزة للخصائص في محتوى JSON:

• مشغل الطلب المسمى عند تلقي طلب HTTP

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

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

  توضح الخطوات التالية كيف يمكنك تقديم مثال على حمولة لإنشاء مخطط JSON:

  1. في المصمم، حدد مشغل الطلب لفتح جزء المعلومات.

  2. في علامة التبويب المعلمات ، ضمن مربع مخطط JSON نص الطلب ، حدد استخدام حمولة عينة لإنشاء مخطط.

  3. في المربع إدخال نموذج حمولة JSON أو الصقه ، أدخل حمولة عينات، ثم حدد تم.

     

     يظهر المخطط الذي تم إنشاؤه الآن في المشغل الخاص بك.

     

     في محرر عرض التعليمات البرمجية، يمكنك مراجعة تعريف JSON الأساسي لمشغل الطلب :

     "triggers": { 
        "When_an_HTTP_request_is_received": {
           "type": "Request",
           "kind": "Http",
           "inputs": { 
              "schema": {
                 "type": "object",
                 "properties": {
                    "client": {
                       "type": "object",
                       "properties": {
                          "animal-type": {
                             "type": "array",
                             "items": {
                                "type": "string"
                             },
                          },
                          "name": {
                             "type": "string"
                          }
                       }
                    }
                 }
              }
           }
        }
     }
     

  4. لتشغيل سير العمل، احصل على عنوان URL لسير العمل أو عنوان URL الخاص بالمشغل، والذي يتم إنشاؤه بعد حفظ سير العمل لأول مرة.

  5. لاختبار سير العمل، استخدم أداة أو تطبيق عميل يمكنك من خلاله إرسال طلب HTTP إلى عنوان URL لسير العمل أو عنوان URL للمشغل. تأكد من أن الطلب يتضمن عنوانا باسم Content-Type وأن قيمة الرأس معينة إلى application/json.

• توزيع إجراء JSON

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

  على غرار مشغل الطلب، يمكنك توفير أو إنشاء مخطط JSON الذي يصف محتوى JSON الذي تريد تحليله. بهذه الطريقة، يمكنك بسهولة استهلاك البيانات من Azure Service Bus وAzure Cosmos DB وما إلى ذلك.

  

رسالة نصية/نص عادي

إذا كان سير العمل يتلقى طلبات HTTP حيث Content-Type تكون قيمة الرأس نصا/عاديا. يقوم Azure Logic Apps بتخزين المحتوى ومعالجته في شكل أولي. إذا قمت بالإشارة إلى هذا المحتوى أو استخدامه في إجراءات سير العمل اللاحقة بدون إرسال أو تحويل، فإن Content-Type قيمة الرأس للطلبات الصادرة يتم تعيينها أيضا على text/plain.

على سبيل المثال، لنفترض أنك تعمل مع ملف ثابت، وتم Content-Type تعيين قيمة الرأس في طلب HTTP الوارد إلى text/plain:

Date,Name,Address
Oct-1,Frank,123 Ave

إذا قمت بإرسال هذا الطلب إلى إجراء لاحق يستخدم نص الطلب لإرسال طلب آخر، فإن الطلب الثاني يحتوي Content-Type أيضا على قيمة الرأس التي تم تعيينها إلى text/plain. إذا كنت تعمل مع البيانات في نص عادي ولكنك لم تحدد رأسا، فيمكنك إرسال هذه البيانات يدويا إلى نص باستخدام الدالةstring()، على سبيل المثال:

string(triggerBody())

application/XML والتطبيق/ثماني بتات التدفق

تحتفظ Content-Type Azure Logic Apps دائما بقيمة الرأس في طلب أو استجابة HTTP واردة. إذا تلقى سير العمل محتوى مع Content-Type تعيين إلى application/victet-stream، وقمت بتضمين هذا المحتوى في إجراء لاحق دون إرسال، يتم تعيين Content-Type الطلب الصادر أيضا إلى application/octet-stream. يضمن هذا النهج عدم ضياع البيانات أثناء التنقل خلال سير العمل. في مهام سير العمل ذات الحالة، يتم تخزين حالة الإجراء اللاحق والمدخلات والمخرجات في كائن JSON بينما تنتقل الحالة عبر سير العمل.

دالات المحول

للاحتفاظ ببعض أنواع البيانات، يقوم Azure Logic Apps بتحويل المحتوى إلى سلسلة ثنائية مشفرة base64. تحتوي هذه السلسلة على بيانات التعريف المناسبة التي تحافظ على كل من $content الحمولة و ، $content-typeوالتي يتم تحويلها تلقائيا.

توضح القائمة التالية كيفية تحويل Azure Logic Apps للمحتوى عند استخدام وظائف معينة:

• json()يلقي البيانات إلى application/json:
• xml()يلقي البيانات إلى application/xml:
• binary()يلقي البيانات إلى application/octet-stream:
• string()يلقي البيانات إلى text/plain:
• base64()تحويل المحتوى إلى سلسلة مشفرة ب base64.:
• base64toString()تحويل سلسلة مشفرة بقاعدة 64 إلى text/plain.
• base64toBinary()تحويل سلسلة مشفرة بقاعدة 64 إلى application/octet-stream.
• dataUri()تحويل سلسلة إلى عنوان URI للبيانات.:
• dataUriToBinary()تحويل عنوان URI للبيانات إلى سلسلة ثنائية.:
• dataUriToString()تحويل عنوان URI للبيانات إلى سلسلة.:

على سبيل المثال، افترض أن مشغل سير العمل الخاص بك يتلقى طلب HTTP حيث Content-Type تم تعيينه إلى application/xml المكان الذي يبدو فيه المحتوى مثل العينة التالية:

<?xml version="1.0" encoding="UTF-8" ?>
<CustomerName>Frank</CustomerName>

يمكنك إرسال هذا المحتوى باستخدام التعبير التالي، والذي يستخدم الدالات xml() و:triggerBody()

xml(triggerBody())

يمكنك بعد ذلك استخدام المحتوى الناتج مع الإجراءات اللاحقة في سير العمل. أو يمكنك استخدام التعبير التالي الذي يستخدم الدالات xpath() و xml() بدلا من ذلك:

xpath(xml(triggerBody()), '/CustomerName')

أنواع المحتوى الأخرى

يدعم Azure Logic Apps أنواع المحتويات الأخرى ولكن قد يتطلب منك الحصول يدويا على نص الرسالة من طلب HTTP عن طريق فك تشفير المتغير $content .

على سبيل المثال، لنفترض أن سير العمل الخاص بك يتلقى طلب HTTP حيث Content-Type تم تعيينه على application/x-www-url-formencoded. للاحتفاظ بجميع البيانات، يتضمن نص الطلب المتغير $content حيث يتم ترميز الحمولة كسلسلة base64:

CustomerName=Frank&Address=123+Avenue

نوع المحتوى هذا ليس بنص عادي أو تنسيق JSON، لذلك يخزن CustomerName=Frank&Address=123+Avenue Azure Logic Apps باستخدام المتغيرات التالية $content-type$content :

"body": {
   "$content-type": "application/x-www-url-formencoded",
   "$content": "AAB1241BACDFA=="
}

يتضمن Azure Logic Apps أيضا وظائف أصلية للتعامل مع بيانات النماذج، على سبيل المثال:

• triggerFormDataValue()
• triggerFormDataMultiValues()
• formDataValue()
• formDataMultiValues()

أو يمكنك الوصول إلى البيانات يدويا باستخدام تعبير مثل المثال التالي:

string(body('formdataAction'))

لجعل الطلب الصادر يستخدم application/x-www-url-formencoded كقيمة Content-Type الرأس، أضف محتوى الطلب إلى نص الإجراء دون أي إرسال باستخدام تعبير مثل body('formdataAction'). تعمل هذه الطريقة فقط إذا كان نص الإجراء هو المعلمة الوحيدة في body كائن الإدخالات. إذا كنت تستخدم التعبير body('formdataAction') في طلب حيث يكون application/jsonنوع المحتوى ، فستحصل على خطأ في وقت التشغيل لأنه يتم إرسال النص الأساسي مشفرا.