Laravel وSage. لكن أي Sage؟

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

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

السؤال الذي يحسم كل شيء

Sage Accounting، منتج الشركات الصغيرة، خدمة مستضافة بواجهة REST وOAuth 2. فإن كان هذا ما لدى العميل، بدا التكامل كأي تكامل حديث مع خدمة سحابية، وصار العمل هو قواعد العمل نفسها.

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

وSage 200 ينقسم. إصدار تستضيفه Sage وله واجهة منشورة. وإصدار يُثبَّت على خوادم العميل نفسه، وتعمل واجهته هناك، خلف ما تفعله شبكة العميل. وهذان ليسا التكامل نفسه ولا التقدير نفسه.

وSage Intacct وSage X3 منتجان آخران تمامًا، موجهان لفرق مالية أكبر، ولكل منهما واجهاته ومصادقته ومفرداته الخاصة للمفاهيم المحاسبية ذاتها.

فهذه الأسئلة تُجاب قبل أن يلتزم أحد بموعد:

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

والأخير ليس سؤالًا تقنيًا، وهو كثيرًا ما يكون أطول بند في الخطة.

حين لا يوجد على الإنترنت ما تناديه

لنفترض Sage 50 على خادم في مكتب العميل، أو Sage 200 على بنيته التحتية. تطبيق Laravel لديك على مستضيف بعنوان عام. لا طريق بينهما، ولا مكتبة تصلح ذلك.

هناك ثلاث صور نزيهة لهذا، وهي قرارات في بنية العميل التحتية بقدر ما هي قرارات في شيفرتك.

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

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

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

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

ضع كل شيء في طابور، وبجدية

مع Sage Accounting هذه نصيحة عادية. ومع تثبيت محلي هي الفرق بين نظام يعمل ونظام يسقط كل خميس بعد الظهر حين تعمل تقاريرهم الأسبوعية ويكون الخادم مشغولًا.

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

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

الضريبة، والبقاء خارجها

مع العملاء البريطانيين يظهر هذا فورًا، لأن Making Tax Digital جعل تقديم الإقرارات يتم من داخل البرمجيات بدل كتابته في موقع.

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

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

ما تفعله قبل كتابة الشيفرة

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

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

وإن كان دفتر الأستاذ في Xero لا في Sage، اختفت مسألة الوصول وحلّت محلها أخرى - دورة حياة الرموز، ولها عطل يفصل العملاء في صمت. صفحة هندسة التكامل لدينا تشرح كيف يُحدَّد نطاق النوعين.