يقدّم كل مورّد RFID تطبيق عرض يقرأ وسمًا في تسعين ثانية. ثم يقضي كل نشر ثلاثة أشهر ليكتشف أن ذلك العرض لم يجب عن أي سؤال يهم في الرابعة عصرًا على أرض المستودع: لماذا توقف الزناد عن الاستجابة، ولماذا نفدت البطارية في الساعة السادسة، ولماذا تمر القائمة ببطء حتى كفّ المشغّلون عن الثقة بها.
هذا المقال عن الفجوة بين هذين التطبيقين. والـ SDK جزء صغير منها.
مشهد SDK: ما الذي تدمجه فعلًا
ثلاث واجهات API وثلاث فرضيات تصميم مختلفة، وخلطها هو الخطأ الأول.
- الـ SDK الخاص بـ RFID مكتبة أصلية مغلّفة بجافا: تملك هوائيًا وخيط قارئ وواجهة استدعاء.
- واجهة الباركود (DataWedge أو EMDK) نظام فرعي منفصل بقواعد دورة حياة منفصلة، حتى على الجهاز نفسه.
- تصل أحداث الباركود وأحداث RFID عبر استدعاءات مختلفة، ويجب دمجها في نموذج مسح واحد قبل أن ترى الواجهة شيئًا.
- تختلف SDKs المصنّعين في ضمانات الخيوط؛ وإذا لم تذكر الوثائق سلامة الخيوط فافترض عدم وجودها.
- ثبّت إصدار الـ SDK لكل طراز جهاز، وعامل الترقية كإصدار، لأن السلوك يتغير بين الإصدارات الفرعية.
الخيوط والاستدعاءات والزناد
الزناد هو أكثر جزء يُلمس في التطبيق وأكثر مصدر شيوعًا لـ«توقف عن العمل».
- تصل استدعاءات القارئ على خيط الـ SDK؛ لا تلمس الواجهة أو قاعدة البيانات منه أبدًا، بل سلّم العمل إلى قائمة.
- ضغط الزناد يبدأ جلسة قراءة، وإفلاته ينهيها؛ اجعل الاثنين عاطلين عن التكرار، لأن أحداث العتاد تتكرر.
- إذا بدأت جلسة وأخرى تعمل، لا تفتح ثانية؛ ادمجهما، وإلا سيرجع القارئ أخطاء ستطاردها أسابيع.
- كل جلسة تحتاج حارسًا: إن لم يصل حدث خلال N ثانية، فكّك القارئ وأعد تهيئته بدل الانتظار الأبدي.
- أعد التهيئة بعد كل عودة للتطبيق، لأن حالة القارئ لا تنجو من قتل العملية أو إعادة تشغيل الجهاز.
إعداد القراءة ليس كإعداد قارئ ثابت
القيم الافتراضية للأجهزة المحمولة مضبوطة لعرض على مكتب، والمستودع ليس مكتبًا.
- يجب أن تتبع قدرة الإرسال سير العمل: قدرة منخفضة لدقة الرف، وعالية لرف مرتفع، ولا تكون القصوى افتراضًا أبدًا.
- اختيار الجلسة أهم من البوابة الثابتة: الجلسة الأولى تُبقي الوسوم صامتة بين القراءات، وهو ما يناسب جرد الرف نفسه مرارًا.
- الترشيح ببادئة EPC قبل التفريد أرخص وسيلة للتوقف عن قراءة مخزون الممر المجاور.
- نافذة إزالة تكرار قصيرة في التطبيق أمر طبيعي؛ والطويلة تخفي وسومًا مكررة حقيقية.
- وضع الدفعات يحسّن الإنتاجية لكنه يؤخر أول نتيجة؛ ويجب أن تُظهر الواجهة أن القراءة جارية، وإلا ضغط المشغّل بقوة أكبر.
تصميم الواجهة للقراءة الجماعية
شاشة القراءة الجماعية ليست قائمة، بل عرض تقدم مع استثناءات.
- أظهر عدّادًا جاريًا كرقم رئيسي، لا قائمة تتمرر؛ فالعدّاد هو ما يحاول المشغّل إثباته.
- أظهر آخر القراءات لبناء الثقة، لكن حدّد الصفوف المرئية، فقائمة بألف صف شاشة متجمدة.
- ميّز بصريًا ثلاث حالات: يقرأ، خامل، خلل؛ فالمشغّلون يشخّصون باللون قبل أن يقرأوا رسالة بوقت طويل.
- ضع الاستثناء في المقدمة: وسم مجهول، موقع خاطئ، سبق جرده، ليتمكن المشغّل من التصرف لحظة المسح.
- اجعل الزناد وزر الشاشة يفعلان الشيء نفسه، لأن القفازات والشمس يكسران أي افتراض عن اللمس.
أولًا بلا اتصال، ثم المزامنة
للمستودعات مناطق ميتة، وجرد لا يمكن حفظه هو جرد سيُعاد.
- خزّن كل قراءة محليًا أولًا، في مخزن خاص بالجلسة، ثم زامن؛ ولا تُقفل حلقة المسح بنداء شبكة أبدًا.
- اجعل وحدة المزامنة الجلسة لا الوسم، ليُستأنف الرفع الجزئي دون تكرار.
- استخدم رقم تسلسل محليًا متزايدًا ومعرّف جهاز لتحقيق العطالة على الخادم.
- أظهر حالة المزامنة صراحةً: معلّقة، جارية، فاشلة مع عدد المحاولات، حتى لا يفترض أحد علامة خضراء لم تحدث.
- احسم التعارضات على الخادم بقاعدة يعرفها الفريق الميداني، لا بقاعدة «آخر كتابة تفوز» على الجهاز.
البطارية والحرارة وواقع وردية من ثماني ساعات
RFID ميزة شرهة للطاقة، وتُضاف عادة إلى تطبيق كان على الحد الأدنى أصلًا.
- القراءة المستمرة بقدرة عالية قد تُنصّف عمر البطارية؛ اعمل ميزانية للوردية لا للعرض.
- أبقِ القارئ مغذّى فقط أثناء الجلسة وحرّره عند الخمول، فالهوائي النشط يستهلك حتى لو لم يمسح أحد.
- راقب الحرارة: القراءة المستمرة على جهاز دافئ تسبب خفض الأداء، وهو يبدو كمشكلة مدى.
- أوقف تحديد الموقع في الخلفية وأي راديوهات لا تحتاجها؛ فراديو RFID ليس المستهلك الوحيد في التطبيق.
- أعطِ المشغّل عتبة بطارية مرئية وإنذارًا مبكرًا، حتى لا يضيع جرد عند تسعين بالمائة.
إدارة الأسطول: تطبيق واحد وأجهزة كثيرة
يتحرك أسطول الأجهزة المحمولة، والانحراف غير مرئي حتى يُبلغ موقع عن أرقام مختلفة.
- ثبّت إصدار التطبيق وإصدار SDK وملف الإعداد لكل طراز، وسجّلها في حمولة المسح.
- أرسل الإعداد من الخادم لا من شاشة إعدادات، حتى لا يستمر مستوى قدرة خاطئ أشهرًا.
- استخدم MDM لدفع التحديثات ولمنع المشغّلين من تثبيت نسخة أخرى «للاختبار».
- سجّل هوية الجهاز في كل جلسة؛ وعندما تبدو أرقام موقع غريبة، فالسؤال الأول هو أي بناء كان يعمل.
- أسقط الأجهزة صراحةً وأبطل بيانات اعتمادها، حتى لا يواصل جهاز مفقود كتابة المخزون.
الاختبار على رفوف حقيقية، لا على مكتب
العرض ينجح على المكتب. والإصدار يجب أن ينجح على رف معدني بمئة قطعة ملابس.
- اختبر بالوسم الحقيقي وبموضع الوسم الحقيقي، فالوسم المنسوج المطوي يُقرأ مختلفًا عن الرقاقة المسطحة.
- اختبر في أسوأ نقطة في المبنى: الزاوية البعيدة، والرف المعدني، والممر الملاصق لبوابة الرصيف.
- اختبر الوردية كاملة: ابدأ ببطارية منخفضة، واقرأ ساعتين، ثم أرسل التطبيق للخلفية وأعده، وتأكد أن الجلسة نجت.
- اختبر بالقفازات وتحت الشمس، لأن كليهما يغيّر طريقة استخدام الزناد والشاشة فعليًا.
- احتفظ بعدّ انحدار لرف معروف: الرف نفسه والعدد المتوقع نفسه، قبل كل إصدار.
النمط في كل هذا غير براق: عامل القارئ كملحق غير موثوق، والشبكة كغائبة، والبطارية كمنتهية، والمشغّل كشخص بقفازات وإضاءة سيئة. التطبيقات المبنية على هذه الفروض تنجو من أول اثنين؛ والمبنية على العرض لا تنجو.
