طُلب تكامل UETS API في دفتر الشروط: ما هو هذا التكامل وكيف يجب أن يرد في العرض؟

خدمات UETS تعمل عادةً بمعايير SOAP وWSDL بدلًا من معمارية REST القياسية. ستحتاج إلى التعامل مع توقيع XML والتحقق من شهادات X.509 وخوارزميات التشفير التي تطلبها PTT. ولأن توثيق الخدمة ليس محدثًا كثيرًا، استعد لقضاء ساعات عمل في جانب تحليل الحزم في بيئة الاختبار.

عند إعداد العرض، اكتب هذه البنود الثلاثة كشروط خاصة في العقد: 1) البروتوكول القانوني مع PTT ومتابعة التقديم تقع بالكامل على مسؤولية العميل. 2) لا يمكن تحميل الفريق البرمجي مسؤولية فقدان حقوق قانونية ناتج عن انقطاعات خدمة UETS Web أو أخطاء انتهاء المهلة. 3) تُنفَّذ اختبارات التكامل فقط عبر حساب الاختبار الذي توفره PTT.

قبل ثمانية أشهر نفذنا تكاملاً مشابهاً لشركة استشارات. أنهينا جانب البرمجة في 12 يوم عمل، لكن انتظار موافقة PTT على العقد المؤسسي وتحديد IP لبيئة الاختبار استغرق 45 يوماً كاملة. لا تربطوا تاريخ التسليم في عرضكم بهذه البيروقراطية.

في العرض لا تدمجوا هذا العمل إطلاقاً داخل الوحدات الأخرى. افتحوا بنداً منفصلاً بعنوان "وحدة التكامل الرسمي مع UETS". وحددوا سعرها على الأقل ضعف تكامل API عادي، لأنكم ستضطرون إلى إدارة معظم حركة التواصل بين العميل وPTT بأنفسكم.

هل عميلكم يستخدم حساب UETS كشخص طبيعي أم كشخص اعتباري؟ إجراءات منح صلاحية خدمة الويب مباشرة لحسابات المحامين الأفراد قد تتضمن خطوات مختلفة عن حسابات المؤسسات، هل أكدوا ذلك مسبقاً مع PTT؟

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

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

عمليات ptt api فعلاً تمشي ببطء وثقل كبير... أضيفوا إلزامياً في العقد بند "إجراءات الموافقة التي مصدرها العميل ليست ضمن مدة تسليم المشروع" وإلا راح يضغطون عليكم بحجة تأخر التسليم.

عند النظر إلى العملية ككل، تتغير الصورة. معظم إضاعة الوقت تتراكم في المهام المنتظرة للموافقة.

هذا العنوان مؤرشف. إذا لم تقم بصياغة هذا كتابيًا من البداية، فستنشأ خلافات لاحقًا.

عانيت من نفس الشيء.

مررت بهذا الطريق، دعني أشرح. يجب ربط جدول المدفوعات بمراحل العمل، وليس بالتقويم.

أتمنى أن يفيدك هذا.

هناك نقطة أثارت فضولي. وضع عملية لطلبات التغيير لا يبطئ العمل، بل يسرّعه.

هذه وجهة نظري، ولا أدعي أنها الحقيقة المطلقة.

سأجرب ذلك.

أخذت ملاحظة، شكرًا لك.

دعني أشرح كيف يتم التطبيق عملياً. معظم إضاعة الوقت تتراكم في المهام المنتظرة للموافقة.

بالتوفيق.

أنا أيضًا أوافق على هذا الرأي. كل من يستعجل في تكامل uets api يتعثر في نفس النقطة.

ابدأ بتجربة صغيرة، لا تربط كل شيء دفعة واحدة. أتمنى أن يفيدك هذا.

إذا دخلنا في التفاصيل: عند اتخاذ القرار، اكتب أسوأ سيناريو أيضًا، وليس الأفضل فقط.

أتمنى أن يفيدك هذا.