استخدام متغيرات التدفق

يتم الآن عرض مستندات Apigee Edge.
انتقِل إلى مستندات Apigee X.
المعلومات

من الناحية النظرية، متغيّرات التدفق هي عناصر يمكنك الوصول إليها من خلال السياسات أو الأدوات المساعدة (مثل أداة التتبُّع). وتسمح لك هذه الإعدادات بالحفاظ على الحالة المرتبطة بمعاملة واجهة برمجة التطبيقات التي تتم معالجتها من خلال Apigee Edge.

ما هي متغيرات التدفق؟

تتوفّر متغيّرات التدفق في سياق تدفق الخادم الوكيل لواجهة برمجة التطبيقات، وهي تتتبّع الحالة في معاملة واجهة برمجة التطبيقات بالطريقة التي تتتبّع بها المتغيرات المُسمّاة الحالة في أحد البرامج. تخزّن متغيرات التدفق معلومات مثل:

  • عنوان IP والرؤوس ومسار عنوان URL والحمولة المرسلة من التطبيق الذي يرسِل الطلب
  • معلومات النظام مثل التاريخ والوقت الذي يتلقى فيه Edge طلبًا
  • يشير ذلك المصطلح إلى البيانات التي يتم الحصول عليها عند تنفيذ السياسة. على سبيل المثال، بعد تنفيذ إحدى السياسات للتحقّق من رمز OAuth المميز، ينشئ Edge متغيّرات التدفق التي تحتوي على معلومات مثل اسم التطبيق الطالب.
  • معلومات عن الاستجابة الواردة من النظام المستهدَف

تكون بعض المتغيّرات "مضمّنة" في Edge وتتم تعبئتها تلقائيًا كلما تم تلقّي طلب بيانات من واجهة برمجة التطبيقات. وتتوفر خلال معاملة واجهة برمجة التطبيقات. يمكنك أيضًا إنشاء متغيّرات مخصّصة لك باستخدام سياسات مثل AssignMessage policy أو في JavaScript وNode.js ورمز Java.

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

كيف يتم استخدام متغيرات التدفق؟

يُستخدم متغيّر التدفق في السياسات والتدفقات الشرطية:

  • يمكن للسياسات استرداد الحالة من متغيّرات التدفق واستخدامها لتنفيذ عملها.

    على سبيل المثال، يمكن أن تسترد سياسة CheckJWT الرمز المميّز ليتم إثبات ملكيته من متغيّر التدفق، ثم تنفيذ عملية إثبات الملكية عليه. كمثال آخر، يمكن لسياسة JavaScript استرداد متغيّرات التدفق وترميز البيانات المضمّنة فيها.

  • يمكن أن تشير التدفقات الشرطية إلى متغيّرات التدفق لتوجيه تدفق واجهة برمجة التطبيقات عبر Edge، تمامًا مثل طريقة عمل عبارة مفتاح التبديل في البرمجة.

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

لنلقِ نظرة على أمثلة لكيفية استخدام المتغيرات في كل سياق من هذه السياقات.

متغيّرات التدفق في السياسات

وتتعامل بعض السياسات مع متغيّرات التدفق كإدخال.

على سبيل المثال، تأخذ سياسةAssignMessage التالية قيمة متغير التدفق client.ip وتضعها في عنوان طلب يُسمى My-Client-IP. في حال إضافة هذه السياسة إلى مسار الطلب، تضبط هذه السياسة عنوانًا يتم تمريره إلى الوجهة المستهدفة في الخلفية. وفي حال ضبط العنوان على مسار الاستجابة، تتم إعادة إرسال العنوان إلى تطبيق العميل.

<AssignMessage name="set-ip-in-header">
    <AssignTo createNew="false" transport="http" type="request">request</AssignTo>
    <Set>
        <Headers>
            <Header name="My-Client-IP">{client.ip}</Header>
        </Headers>
    </Set>
    <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</AssignMessage>

على سبيل المثال، عند تنفيذ سياسة الحصة، تتم تعبئة عدة متغيّرات التدفق بقيم متعلّقة بالسياسة. ويُطلق على أحد هذه المتغيّرات ratelimit.my-quota-policy.used.count (حيث يشير my-quota-policy إلى اسم سياسة الحصة التي تهمّك).

يمكنك في وقت لاحق تنفيذ تدفق مشروط يفيد بأنه "إذا كان عدد الحصة الحالية أقل من% 50 من الحد الأقصى، وكانت الفترة بين 9 صباحًا و5 مساءً، يمكنك فرض حصة مختلفة". وقد يعتمد هذا الشرط على قيمة عدد الحصص الحالية وعلى متغيّر التدفق يُسمى system.time، وهو أحد متغيّرات Edge المدمَجة.

متغيّرات التدفق في التدفقات الشرطية

تعمل التدفقات الشرطية على تقييم متغيّرات التدفق وتفعيل الخوادم الوكيلة بشكل ديناميكي. ويتم عادةً استخدام الشروط لتغيير سلوك التدفقات والخطوات وقواعد المسارات.

في ما يلي تدفق شرطي يقيم قيمة المتغير request.verb في خطوة تدفق الخادم الوكيل. في هذه الحالة، إذا كان فعل الطلب هو POST، يتم تنفيذ سياسة CheckAPIKey. وهذا نمط شائع الاستخدام في إعدادات الخادم الوكيل لواجهة برمجة التطبيقات.

<PreFlow name="PreFlow">
    <Request>
        <Step>
            <Condition>request.verb equals "POST"</Condition>
            <Name>VerifyApiKey</Name>
        </Step>
    </Request>
</PreFlow>

قد تتساءل أين تأتي متغيّرات مثل request.verb وclient.ip وsystem.time. متى يتم إنشاء مثيل لها وتعبئتها بقيمة؟ لمساعدتك على معرفة وقت إنشاء المتغيّرات والوقت الذي تصبح فيه متاحة لك، اطّلِع على مقالة فهم نطاق متغيّر التدفق.

متغيّرات التدفق في رمز JavaScript الذي يتم استدعاؤه باستخدام سياسة JavaScript

باستخدام سياسة JavaScript، يمكنك تنفيذ رمز JavaScript من داخل سياق تدفق الخادم الوكيل لواجهة برمجة التطبيقات. إنّ لغة JavaScript المنفَّذة من خلال هذه السياسة تستخدم نموذج عنصر JavaScript الخاص بـ Apigee، ما يوفّر إمكانية وصول الرمز المخصّص إلى كائنات الطلبات والاستجابة والسياق المرتبطة بتدفق الخادم الوكيل لواجهة برمجة التطبيقات الذي يتم من خلاله تنفيذ الرمز. على سبيل المثال، يحدّد هذا الرمز عنوان استجابة بالقيمة التي تم الحصول عليها من متغيّر التدفق target.name.

context.setVariable("response.header.X-Apigee-Target", context.getVariable("target.name"));

يشبه أسلوب استخدام JavaScript لقراءة المتغيّرات وضبطها، العمل الذي يمكنك تنفيذه باستخدام سياسة AssignMessage (الموضَّحة سابقًا). إنها مجرد طريقة أخرى لإنجاز الأنواع نفسها من الأشياء على Edge. تذكّر أنّ لغة JavaScript المنفَّذة من خلال سياسة JavaScript يمكنها الوصول إلى جميع متغيرات التدفق المتوفّرة وتقع في النطاق ضمن تدفق الخادم الوكيل لواجهة برمجة التطبيقات.

متغيرات التدفق في رمز Node.js

من خلال طلب استخدام وحدة apigee-access، يمكنك ضبط متغيّرات التدفق والوصول إليها من ضمن رمز Node.js الذي يتم نشره على Edge.

في ما يلي مثال بسيط حيث تم ضبط متغيّر يُسمى custom.foo على القيمة Bar. وبعد الضبط، يصبح هذا المتغيّر الجديد متاحًا لأي سياسات أو لأي رمز آخر يحدث في تدفق الخادم الوكيل بعد تنفيذ رمز Node.js.

var http = require('http');
var apigee = require('apigee-access');

http.createServer(function (request, response) {
  apigee.setVariable(request, "custom.foo", "Bar");
  response.writeHead(200, {'Content-Type': 'text/plain'});
  response.end('Hello World\n');
}).listen(8124);

console.log('Server running at http://127.0.0.1:8124/');

يمكنك قراءة المزيد من المعلومات عن استخدام apigee-access للتعامل مع المتغيّرات في الوصول إلى متغيّرات التدفق في Node.js.

فهم نطاق متغير التدفق

يرتبط النطاق المتغيّر بتدفق البيانات أو "دورة الحياة" الإجمالية لطلب بيانات من الخادم الوكيل لواجهة برمجة التطبيقات.

عرض تدفق الخادم الوكيل لواجهة برمجة التطبيقات

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

ويوضح الشكل التالي هذا التسلسل من التدفقات. لاحِظ كيف تتألف المسارات من أربعة أقسام رئيسية، وهي: ProxyEndpoint request وTargetEndpoint request وTargetEndpoint response و ProxyEndpoint Response.

يُرجى وضع بنية التدفق هذه في الاعتبار عندما نبدأ في استكشاف متغيّرات التدفق خلال بقية هذا الموضوع.

كيفية ارتباط نطاق المتغيّر بتدفق الخادم الوكيل

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

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

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

نطاق المتغير أماكن تعبئة هذه المتغيّرات
طلب خادم وكيل مقطع طلب ProxyEndpoint
الطلب المستهدف شريحة طلب نقطة النهاية المستهدفة
الاستجابة المستهدَفة شريحة استجابة TargetEndpoint
استجابة الخادم الوكيل شريحة استجابة ProxyEndpoint
متوفر دائمًا فور استلام الخادم الوكيل طلبًا. وتتوفر هذه المتغيّرات خلال دورة حياة تدفق الخادم الوكيل بالكامل.

على سبيل المثال، هناك متغيّر Edge مدمَج يُسمى client.ip. يحتوي هذا المتغيّر على نطاق "طلب الخادم الوكيل". تتم تعبئته تلقائيًا بعنوان IP للعميل الذي استدعى الخادم الوكيل. تتم تعبئته عندما يصل الطلب إلى ProxyEndpoint لأول مرة ويظل متاحًا خلال دورة حياة الخادم الوكيل بالكامل.

هناك متغيّر آخر مضمّن يسمى target.url. نطاق هذا المتغير هو "target request". وتتم تعبئته في مقطع طلب TargetEndpoint مع عنوان URL للطلب الذي تم إرساله إلى الوجهة المستهدفة في الخلفية. إذا حاولت الوصول إلى target.url في مقطع طلب ProxyEndpoint، ستتلقّى قيمة فارغة. وإذا حاولت ضبط هذا المتغيّر قبل أن يكون في نطاقه، لن يؤدي الخادم الوكيل إلى أي تغيير، ولن يؤدي إلى إنشاء خطأ أو ضبط المتغيّر.

فيما يلي مثال بسيط يوضح كيفية التفكير في النطاق المتغير. لنفترض أنك تريد نسخ محتوى كائن الطلب بالكامل (الرؤوس والمَعلمات والنص) وتعيينه إلى حمولة الاستجابة المطلوب إرسالها مرة أخرى إلى تطبيق الاتصال. يمكنك استخدام سياسة AssignMessage لتنفيذ هذه المهمة. يظهر رمز السياسة على النحو التالي:

<AssignMessage name="CopyRequestToResponse">
    <AssignTo type="response" createNew="false">response</AssignTo>
    <Copy source="request"/>
</AssignMessage>

تنسخ هذه السياسة العنصر request وتخصِّصه إلى العنصر response. ولكن أين يجب وضع هذه السياسة في تدفق الخادم الوكيل؟ والجواب هو أنه يجب وضعها ضمن استجابة TargetEndpoint، لأنّ نطاق متغيّر الاستجابة هو "targetResponse".

الإشارة إلى متغيرات التدفق

تتبع كل المتغيرات المضمَّنة في Apigee Edge اصطلاح تسمية من ناحية الترميز النقطي. ويسهّل هذا الاصطلاح تحديد الغرض من المتغيّر. على سبيل المثال، system.time.hour وrequest.content.

تحتفظ Apigee ببادئات مختلفة لتنظيم المتغيرات ذات الصلة بشكل مناسب. وتشمل هذه البادئات ما يلي:

  • request
  • response
  • system
  • target

للإشارة إلى متغير في سياسة، ضعه بين أقواس معقوفة. على سبيل المثال، تأخذ سياسةAssignMessage التالية قيمة المتغيّر client.ip وتضعها في عنوان طلب يُسمى Client-IP.

<AssignMessage name="set-ip-in-header">
    <AssignTo createNew="false" transport="http" type="request">request</AssignTo>
    <Set>
        <Headers>
            <Header name="Client-IP">{client.ip}</Header>
        </Headers>
    </Set>
    <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</AssignMessage>

في التدفقات الشرطية، الأقواس المعقوفة ليست ضرورية. يقيّم الشرط التالي المتغيّر request.header.accept:

<Step>
    <Condition>request.header.accept = "application/json"</Condition>
    <Name>XMLToJSON</Name>
</Step>

يمكنك أيضًا الإشارة إلى متغيرات التدفق في رمز JavaScript وJavaScript. يمكنك الاطّلاع على ما يلي للحصول على مزيد من المعلومات:

نوع بيانات متغيّرات التدفق

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

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

استخدام متغيّرات التدفق في السياسات

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

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

ويمكن الاستفادة من بعض متغيرات السياسة في تصحيح الأخطاء. ويمكنك مثلاً استخدام أداة التتبُّع لمعرفة المتغيّرات التي تم ضبطها في مثيل معيّن في تدفق الخادم الوكيل.

تتيح لك سياسة استخراج المتغيّرات تعبئة المتغيّرات المخصّصة بالبيانات المستخلصة من الرسائل. ويمكنك استخراج مَعلمات طلب البحث والعناوين والبيانات الأخرى. على سبيل المثال، يمكنك تحليل رسائل الطلب والردّ باستخدام الأنماط لاستخراج بيانات معيّنة من الرسائل.

في المثال التالي، تحلِّل أداة "استخراج المتغيّرات" رسالة الردّ وتخزِّن بيانات محدّدة مأخوذة من الاستجابة. تنشئ السياسة متغيّرَين مخصّصَين، geocoderesponse.latitude وgeocoderesponse.longitude، وتحدّد قيمًا لهما.

<ExtractVariables name="ParseGeocodingResponse">
  <Source>response</Source>
  <VariablePrefix>geocoderesponse</VariablePrefix>
  <JSONPayload>
    <Variable name="latitude">
      <JSONPath>$.results[0].geometry.location.lat</JSONPath>
    </Variable>
    <Variable name="longitude">
      <JSONPath>$.results[0].geometry.location.lng</JSONPath>
    </Variable>
  </JSONPayload>
</ExtractVariables>

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

العمل مع متغيرات التدفق في رمز JavaScript

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

للوصول إلى المتغيرات في رمز JavaScript، يمكنك استدعاء طرق getter/setter على أي من هذه الكائنات:

  • context
  • proxyRequest
  • proxyResponse
  • targetRequest
  • targetResponse

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

يتوافق الكائن context مع المتغيّرات المتاحة "بشكل عام"، مثل متغيّرات النظام. على سبيل المثال، يمكنك استدعاء الدالة getVariable() على الكائن context للحصول على السنة الحالية:

var year = context.getVariable('system.time.year');

وبالمثل، يمكنك استدعاء setVariable() لضبط قيمة متغيّر مخصّص أو لأي متغيّرات قابلة للكتابة غير جاهزة. بعد ذلك، ننشئ متغيّرًا مخصّصًا باسم organization.name.myorg ونعيّن قيمة له.

var org = context.setVariable('organization.name.myorg', value);

بما أنّه يتم إنشاء هذا المتغيّر باستخدام الكائن context، سيكون متاحًا لجميع أقسام التدفق (يشبه ذلك بشكل أساسي إنشاء متغيّر عمومي).

يمكنك أيضًا الحصول على/ضبط متغيّرات تدفق الخادم الوكيل في رمز Java الذي يتم تنفيذه باستخدام سياسة JavaCallout.

الوصول إلى متغيرات التدفق في تطبيقات Node.js

يمكنك الحصول على متغيرات التدفق وتعيينها وحذفها من رمز Node.js الذي تم نشره على Edge. ما عليك سوى "طلب" وحدة الوصول إلى واجهة برمجة التطبيقات في رمزك. لمعرفة التفاصيل، يُرجى الاطّلاع على الوصول إلى متغيرات التدفق في Node.js.

معلومات تحتاج إلى تذكُّرها

فيما يلي بعض الأشياء المهمة التي يجب تذكرها حول متغيرات التدفق:

  • يتم إنشاء مثيل لبعض المتغيرات الجديدة وتتم تعبئتها تلقائيًا بواسطة الخادم الوكيل نفسه. ويتم توثيقها في مرجع متغيرات التدفق.
  • يمكنك إنشاء متغيّرات مخصَّصة تكون متاحة للاستخدام في تدفق الخادم الوكيل. من الممكن إنشاء متغيّرات باستخدام سياسات مثل سياسة AssignMessage وسياسة JavaScript ورمز Node.js.
  • المتغيرات لها نطاق. على سبيل المثال، تتم تعبئة بعض المتغيّرات تلقائيًا عندما يتلقّى الخادم الوكيل الأول طلبًا من أحد التطبيقات. وتتم تعبئة المتغيرات الأخرى في مقطع تدفق الاستجابة للخادم الوكيل. تظل متغيّرات الاستجابة هذه غير معرَّفة إلى أن يتم تنفيذ شريحة الاستجابة.
  • وعند تنفيذ السياسات، يمكنها إنشاء متغيرات خاصة بالسياسات وتعبئتها. تتضمّن مستندات كل سياسة جميع هذه المتغيّرات الخاصة بالسياسة ذات الصلة.
  • عادةً ما تقيِّم التدفقات الشرطية متغيرًا واحدًا أو أكثر. وعليك فهم المتغيّرات إذا كنت تريد إنشاء تدفقات شرطية.
  • تستخدم العديد من السياسات المتغيرات كإدخال أو مخرج. من المحتمل أن يتم لاحقًا استخدام متغيّر تم إنشاؤه من خلال إحدى السياسات بواسطة سياسة أخرى.
  • يمكنك الحصول على العديد من متغيّرات التدفق وإعدادها من داخل Node.js باستخدام JavaScript مباشرةً (ونموذج عنصر JavaScript) أو سياسة JavaCallout التي تنفّذ الترميز على Edge.

نماذج التعليمات البرمجية ذات الصلة

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

تشمل نماذج الخوادم الوكيلة التي تتميز باستخدام المتغيرات ومعالجة المتغيرات ما يلي:

  • المتغيّرات - توضّح كيفية استخراج المتغيّرات وضبطها استنادًا إلى محتوى النقل ومحتوى رسالة JSON وXML.
  • Policy-mashup-cookbook: هو تطبيق كامل يستخدم تصميم السياسة من أجل استدعاء واجهتَي برمجة تطبيقات متاحتَين للجميع ويدمج النتائج وإنشاء استجابة مفصّلة لتطبيق العميل. للمزيد من المعلومات حول هذا النموذج، يُرجى الاطّلاع على استخدام تركيب السياسة.
  • conditional-policy: تنفيذ سياسة شرطية بسيطة استنادًا إلى القيم المتغيّرة

مواضيع ذات صلة

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