التطوير / ROBLOX
ProcessReceipt في Roblox: خطة مراجعة تسليم Developer Product
افصل نافذة الشراء عن التسليم، والشراء الجديد عن إعادة المعالجة، وتنفيذ الدالة عن نتيجتها. حدد شروطاً قابلة للمراجعة قبل بيع منتج مدفوع في اللعبة.
حدد نتيجة الشراء الموعودة #
ابدأ بوعد دقيق: حزمة افتراضية تضيف رموز تدريب إلى ملف اللاعب المحفوظ. حدد كمية الحزمة ومجال استخدامها وما يجب أن يبقى بعد الدخول مجدداً. كلمة «تم التسليم» غامضة إذا لم تر إلا رسالة مؤقتة على الشاشة.
لا يحتوي المقال على متجر عامل أو معرفات حقيقية أو شراء أو معالج جاهز. نعد خطة مراجعة للمؤلف. A وB عمليتان افتراضيتان وليستا إيصالين حقيقيين للاعبين. لا تستبدل بهذه الخطة تنفيذاً متحققاً منه للبيع، ولا تعتبرها إثباتاً لجاهزية ألعابك.
افصل النافذة عن تسليم الخادم #
عرض النافذة يبدأ المسار الظاهر للاعب فقط. تحذر الوثائق من استخدام PromptProductPurchaseFinished لمعالجة تسليم Developer Product؛ إطلاق الحدث وحده لا يثبت نجاح الشراء. راجع معالجة الإيصال بصورة مستقلة عن استجابة الزر.
سجل ملاحظات منفصلة: ظهور النافذة، واستلام الإيصال، وتأكيد الأثر، والإقرار بالمعالجة للمنصة. لا تجمعها في حدث نجاح واحد. إذا لم تظهر إلا حركة الزر، تبقى حالة الملف المحفوظ مجهولة ولا تصبح الرسالة دليلاً على النتيجة الفعلية.
ميّز المنتج عن عملية الشراء #
يشير ProductId إلى المنتج المعالج، ويميز PurchaseId عمليات الشراء المحددة. قد يكون إيصالان بالـProductId نفسه شراءين مستقلين. أما وصول PurchaseId نفسه مجدداً فهو حالة أخرى تتطلب مراجعة العملية التي عولجت سابقاً.
زوج الحالات الأول: معالجة A للمرة الأولى ثم وصول A ثانية. والثاني: معالجة A ثم وصول B جديد للمنتج نفسه. لا ينبغي أن يكرر الأول أثر A، بينما يحتاج الثاني إلى نتيجة مستقلة لـB. حظر المنتج كله بعد أول شراء يخلط بين هاتين المهمتين.
افتح الصورة بالحجم الكامل ↗لا تخلط غياب الاستثناء والتسليم #
قد تنتهي مكالمة محمية دون استثناء بينما ترفض الدالة الداخلية التسليم أو لا تمنح العنصر. لذلك تحتوي بطاقتنا المقترحة على حقلين: هل نُفذ الاستدعاء، وهل تأكد الأثر المطلوب؟ هذان ادعاءان مختلفان ولا يحل علم واحد محل كليهما.
خطط لحالة يعيد فيها المعالج false دون خطأ. ينبغي أن تعكس الاستجابة المتوقعة غياب التسليم، لا مجرد نجاح تنفيذ الدالة. افحص الاستثناء وحالة اللاعب غير المتاحة بصورة منفصلة. لا نقدم هنا شيفرة تنتج تلك النتائج تلقائياً أو معالجاً جاهزاً للنسخ.
راجع الأثر والسجل معاً #
تحتاج الرموز المستمرة إلى حقائق متسقة: أثر في الملف وسجل لعملية الشراء المعالجة. إذا تغير رصيد مؤقت ولم يُحفظ الاكتمال، فقد تجد الإعادة حالة ناقصة. وتسجيل الاكتمال قبل الأثر قد يجعل تسليماً لم يحدث يبدو منتهياً.
ارسم نقاط الفشل بين المراحل واشرح الاستعادة لكل منها. نجاح المسار الطبيعي مرة لا يختبر هذه الفجوات. وجود علم بجانب قيمة غير محفوظة لا يثبت تسليماً موثوقاً. تحتاج بنية الحفظ والإعادة إلى مراجعة مستقلة قبل بدء البيع.
سجل عقد API المختار #
يعيد ProcessReceipt قيمة من Enum.ProductPurchaseDecision. تتضمن وثائق MarketplaceService أيضاً BindReceiptHandler بأنواع إيصال منفصلة وEnum.ReceiptDecision. لا تخلط أساليب التسجيل أو قيم الإرجاع من العقدين في مثال واحد.
يخطط هذا المقال لمراجعة ProcessReceipt ولا يعلن انتقالاً إلزامياً بين الواجهات. سجل العقد المستخدم ومكان معالج الخادم ومن يسجله. تصف الوثائق تعيين ProcessReceipt مرة واحدة من سكربت خادم؛ استبداله غير المتوقع من سكربت آخر يحتاج إلى التحقيق.
أدرج الشروط غير المتاحة #
خطط لإيصال مع لاعب غائب أو منتج مجهول أو ملف لم يصبح جاهزاً. حدد لكل حالة الأدلة المطلوبة لتأكيد التسليم. غياب هذه الأدلة لا ينبغي أن يتحول إلى رسالة واثقة تقول إن كل شيء وصل، ولا يتحول الانتظار إلى اكتمال.
أدرج فشل الحفظ والدخول اللاحق أيضاً. احتفظ بأقل سياق تقني لازم وبالملاحظة الأصلية، دون نشر بيانات شخصية أو إيصالات حقيقية على الموقع. لا تعد بزمن دقيق للإعادة: نراجع منطق القرار، لا جدول معالجة المنصة أو موعد وصول مضمون.
راجع الإعادة والخوادم المتعددة #
اختبار A مرتين في جلسة واحدة مفيد، لكنه لا يغطي المعالجة المتنافسة أو الفشل بين تغيير الأثر والحفظ. يذكر مثال ProcessReceipt في مرجع API قيداً يتعلق بفشل البيانات بين الخوادم. نسخ المثال لا يحل هذا السؤال.
أدرج المحاولات المتوازية والإعادة بعد نتيجة كتابة مجهولة وتحويلات الحالة القابلة للتكرار. لا تضع آثاراً خارجية غير قابلة للعكس داخل عملية قابلة للإعادة دون بروتوكول مراجع مستقلاً. هذه أسئلة للتنفيذ وليست دليلاً على أن المتجر الافتراضي محمي بالفعل.
أنشئ مصفوفة للنتائج المتوقعة #
سجل لكل حالة الحالة الأولية ومعرف العملية والتغيير المتوقع وشرط الإقرار. ابدأ بـA ثم A المكرر وB الجديد، وأضف الملف غير الجاهز والكتابة الفاشلة. الجدول التالي أسئلة مراجعة، وليس نتائج اختبارات مدفوعة أو عمليات شراء منفذة.
يجب أن ترتبط النتيجة المتوقعة بالعملية المحددة والأثر المحفوظ. عبارة «لا توجد أخطاء في Output» لا تجيب عن منح المكافأة مرتين. بعد تعديل المعالج، كرر المسار الطبيعي والحالة التي سببت التعديل، واحتفظ بالملاحظات الخاصة بكل منهما.
| الحالة | ما يُفحص |
|---|---|
| A الأول | هل تأكد أثر واحد؟ |
| A المكرر | هل غاب أثر ثانٍ لـA؟ |
| B الجديد | هل لـB أثر مستقل؟ |
| فشل الكتابة | كيف تُستعاد نتيجة مجهولة؟ |
انقل الأدلة والأسئلة المفتوحة #
تحتوي بطاقة التسليم على نوع المنتج وAPI المختار ونموذج الملف وسيناريو الإعادة والملاحظة والقيود المتبقية. وضح إن كانت المراجعة ذهنية أو محاكاة أو منفذة في لعبة اختبار منفصلة. هذه المستويات لا يثبت أحدها الآخر تلقائياً.
قبل البيع تحتاج إلى تنفيذ متحقق منه يربط الأثر والإقرار بالشراء عند الفشل. يساعد الدليل على تحديد هذه المهمة، لكنه لا يؤكد جاهزية ألعابك للبيع. لا تشتر فعلياً لعرض نص مقال، ولا تصف فرضية بأنها نتيجة مثبتة.
افتح الصورة بالحجم الكامل ↗| الحقل | ما يُسجل |
|---|---|
| العقد | API المختار وقيمة الإرجاع |
| العملية | المنتج والشراء المحدد |
| الأثر | النتيجة المحفوظة والإعادة |
| الدليل | نوع المراجعة والملاحظة والنطاق |
المصادر الأصلية
Roblox Creator Hub — Developer ProductsRoblox Creator Hub — MarketplaceService API
