بنية بيانات مخطط السماء #
قبل الغوص في السجلات الزمنية، نحتاج إلى مناقشة القليل عن بنية البيانات في Skyplanner وكيفية عمل الأشياء تحت الغطاء. كل هذا سيأتي في وقت لاحق.
إذا قمت بدمج بيانات الطلب / طلب العمل / الوظيفة في Skyplanner، فمن المرجح أنك استخدمت على الأقل نقاط نهاية واجهة برمجة التطبيقات هذه:
- الأوامر الفازر
- صفوف-ترتيب-صفوف-فيزر
- وظائف-وظائف-فيزر
بشكل فعال، يتم تمثيل البيانات التي يتم إدراجها في نقاط النهاية هذه في واجهة مستخدم Skyplanner على هذا النحو:
بعد إدراج طلباتك في Skyplanner، ستحتاج إلى تصديرها (يمكن القيام بذلك عبر واجهة المستخدم أو نقطة النهاية /phaser-orders/export-endpoint) إلى وحدة جدولة الإنتاج:
عند تصدير الأوامر يقوم Skyplanner بنسخ بيانات الطلبات بشكل فعال من جدول قاعدة بيانات إلى آخر. لذلك إذا قمت بتغيير شيء ما على سبيل المثال من خلال نقطة نهاية /phaser-orders -endpoint، فأنت بحاجة إلى تصدير البيانات مرة أخرى لتحديثها في جدولة الإنتاج. هذا يعني أيضًا أنه من أجل الوصول إلى الطلبات التي تراها في نافذة جدولة الإنتاج، يجب عليك استخدام نقاط نهاية مختلفة لواجهة برمجة التطبيقات!
تسير نقاط النهاية “المتغيرة” على النحو التالي:
- → → → الطلبات
- → → → ترتيب الصفوف ← ترتيب الصفوف
- → / وظائف/وظائف/وظائف/وظائف
من المهم معرفة ذلك، لأنه عند استخدام نقطة نهاية /timelogs -endpoint لتسجيل أحداث الإنتاج وما إلى ذلك، يجب عليك استخدام الكيانات ذات الصلة الموجودة في نقاط نهاية جدولة الإنتاج!
على سبيل المثال، تحتاج إلى معرف_وظيفة_تخطيط_الإنتاج (للتكرار: وظائف_تخطيط_الإنتاج هي الكيانات التي يتم الوصول إليها من نقطة النهاية / الوظائف) لإرسال سجل زمني جديد:
يمكنك العثور على production_planning_job_job_id الذي تحتاجه من نقطة نهاية /phaser-jobs – نقطة نهاية /phaser-jobs:
أو من نقطة النهاية /job -job -endpoint:
إنشاء السجلات الزمنية باستخدام واجهة برمجة تطبيقات REST-API #
يستخدم إنشاء السجلات الزمنية لـ Skyplanner من خلال واجهة برمجة التطبيقات نفس القواعد والأنظمة الموجودة في واجهة المستخدم. لذلك قد يكون من المفيد أن تتعرف على كيفية عمل النظام في واجهة المستخدم قبل محاولة استخدامه من خلال واجهة برمجة التطبيقات.
أساسيات السجل الزمني #
يحتوي Skyplanner على أربعة أنواع من الأحداث الزمنية:
- بداية_المناوبة
- متوقف مؤقتاً
- تابع
- نهاية_المناوبة
يتم إرسال حدث Shift_begin-event عند بدء المهمة للمرة الأولى. لا ترسل أبدًا أكثر من حدث_بدء_مناوبة_واحد لكل مهمة!
يوقف الحدث المتوقف مؤقتًا المهمة مؤقتًا.
يستأنف الحدث المستمر وظيفة متوقفة مؤقتاً.
يكمل Shift_end المهمة. لا ترسل أبدًا أكثر من حدث نهاية_مناوبة_واحد لكل مهمة!
البيانات المطلوبة للسجلات الزمنية:
- الشخص_المعرف
- يمكن العثور عليها من نقطة النهاية /الناس/الأشخاص
- ليس مثل user_id!
- معرف_محطة_العمل_المخططة
- محطة العمل التي يتم العمل بها
- يمكن العثور عليها من نقطة نهاية /محطات العمل/محطات العمل
- التاريخ_الوقت
- النقطة الزمنية التي يتم فيها الحدث
- الصيغة: 2024-01-01 10:30:11
من أجل تحديد ما هو السجل الزمني ل Skyplanner المرتبط بالسجل الزمني من أي نظام خارجي تستخدمه، يمكنك استخدام الحقل external_id . يمكنك بعد ذلك على سبيل المثال إجراء طلبات GET باستخدام هذا المعرف للعثور على سجل زمني محدد من Skyplanner.
بدء العمل #
يمكنك بدء المهام عن طريق إرسال طلب POST-طلب مثل هذا إلى واجهة برمجة التطبيقات:
عند تعيين بيانات POST للسجلات الزمنية قم بتعيين workift_id ك 0 و timelog_finalized كصحيح
إيقاف وظيفة مؤقتاً #
إيقاف المهام مؤقتًا عن طريق إرسال طلب POST مثل هذا:
في السجلات الزمنية من النوع المتوقف مؤقتًا يمكنك تعيين المبلغ والمبلغ_الخاطئ. لاحظ أيضًا نوع السجل الزمني والتاريخ_الوقت.
الاستمرار في العمل #
إليك كيفية متابعة سجل زمني متوقف مؤقتاً:
لاحظ أنه إذا حاولت متابعة مهمة تم إنهاؤها بواسطة حدث shift_end، فستحصل على خطأ.
إنهاء وظيفة #
إليك كيفية إنهاء مهمة ما بواسطة سجل زمني لـ shift_end timelog:
في shift_end-events، يمكنك إعطاء قيمتي المبلغ والمبلغ الخاطئ تمامًا كما هو الحال في الأحداث المتوقفة مؤقتًا. لاحظ أنه إذا حاولت القيام بـ shift_end-events لمهمة غير قيد التشغيل، ستحصل على خطأ.
تحديث السجلات الزمنية #
يمكنك تحديث بيانات السجل الزمني عن طريق إرسال طلبات PUT-REUT إلى نقطة نهاية /timelogs-endpoint، مثل هذا:
لاحظ أنه يجب أن يكون لديك كلاً من بيانات البدايةTimelog والنهايةTimelog من أجل إجراء تحديث. يتم تخزين السجلات الزمنية في Skyplanner على النحو التالي: كل سجل زمني “كامل” (سجل زمني يحتوي على بداية ونهاية (على سبيل المثال: بداية_المناوبة/مستمر وإيقاف مؤقت/نهاية المناوبة) له كيان منفصل للبداية والنهاية.
يتم إقرانها بقيمة start_id الموجودة في سجل النهاية. في المثال أعلاه، يكون لـ startTimelog قيمة معرف 1، وبالتالي فإن قيمة endTimelog الخاصة به هي قيمة start_id 1.
يجب عليك أيضًا إعطاء قيمتي person_id و endTimelog لكل مرة تقوم فيها بطلب تحديث حتى لو لم تكن تقوم بتغييرهما.
طرق بديلة لعمل السجلات الزمنية #
فيما يلي بعض الطرق البديلة التي يمكنك من خلالها تسجيل الدخول إلى وظائفك باستخدام واجهة برمجة التطبيقات.
لوجفول #
إذا كنت تريد إرسال كل من السجلات الزمنية للبداية والنهاية في طلب واحد، يمكنك استخدام نقطة النهاية /timelogs/log-llog-ful-lendpoint، هكذا:
لاحظ كيفية إرسال المبالغ هنا: تشير قيمة “المبلغ” الأولى إلى المبلغ المعيب والثانية إلى المبلغ. ينشئ هذا الطلب كيانات “بداية السجل” و”نهاية السجل” في طلب واحد.
التدوين السريع #
“التدوين السريع” لمهمة ما يكملها في طلب واحد، ويضبط كمية المنتجات المكتملة لتتناسب مع القيمة المحددة في عنصر الطلب. يتم إجراء التدوين السريع باستخدام نقطة النهاية /timelogs/quick-log – نقطة النهاية:
لاحظ أنك هنا تحتاج فقط إلى إعطاء معرف_مهمة_تخطيط_الإنتاج، ومعرف_محطة_العمل_المخطط لها ومعرف_الشخص. يتم ملء قيم الوقت والمبلغ تلقائيًا. لاحظ أيضًا أن المهام التي تم تسجيلها سريعًا تكتمل دائمًا بحدث نهاية المناوبة، لذلك لا يمكن إجراء المزيد من التسجيل بعد التسجيل السريع!
