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

أنت تطّلع على مستندات Apigee Edge.
انتقِل إلى مستندات Apigee X. المعلومات

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

فيديو

يوفّر الفيديو التالي مقدّمة عن متغيّرات المسارات:

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

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

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

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

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

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

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

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

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

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

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

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

متغيّرات مسار الإحالة الناجحة في السياسات

تأخذ بعض السياسات متغيّرات مسار العميل كمدخلات.

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

<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، يتم تنفيذ سياسة VerifyAPIKey. وهذا نمط شائع مُستخدَم في إعدادات الخادم الوكيل لواجهة برمجة التطبيقات.

<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.

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

يرتبط المتغيّر scope بالمسار أو "دورة الحياة" العامة لطلب data من واجهة برمجة التطبيقات.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

الإشارة إلى متغيّرات المسار

تتبع جميع المتغيّرات المضمّنة في 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 وJava. يمكنك الاطّلاع على ما يلي للحصول على مزيد من المعلومات:

• العمل مع المتغيّرات في JavaScript
• الوصول إلى متغيّرات مسار الإحالة الناجحة في Node.js
• سياسة JavaScript

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

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

تعتمد المتغيّرات التي تنشئها يدويًا على النوع المحدّد عند إنشائها، وتكون تابعة لأنواع القيم المسموح بها. على سبيل المثال، تقتصر المتغيّرات التي تم إنشاؤها في رمز Node.js على Number أو String أو Boolean أو null أو undefined.

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

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

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

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

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

في المثال التالي، تُحلِّل ميزة "استخراج المتغيّرات" رسالة استجابة وتخزِّن بيانات محدّدة يتم أخذها من الاستجابة. تنشئ السياسة متغيّرَين مخصّصَين، 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، يمكنك استدعاء طرق الحصول/الضبط على أيّ من هذه الكائنات:

• 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. ما عليك سوى "طلب" وحدة apigee-access في الرمز. لمعرفة التفاصيل، يُرجى الاطّلاع على الوصول إلى متغيّرات مسار الإحالة الناجحة في Node.js.

معلومات يجب تذكّرها

في ما يلي بعض النقاط المهمة التي يجب تذكرها عن متغيّرات مسار الإحالة الناجحة:

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

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

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

تشمل عيّنات الخوادم الوكيلة التي تعرض استخدام المتغيّرات ومعالجتها ما يلي:

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

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

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