چالش‌های Integration با راهکاران

۱. نبود قرارداد داده مشترک

نام مشتری، کد کالا، واحد سنجش، شماره سفارش، وضعیت پرداخت و ساختار شعب ممکن است در دو سیستم معنای متفاوت داشته باشد.

راه‌حل لازم: Canonical Data Model، Data Dictionary، mapping versioned و مالک مشخص برای هر فیلد.

۲. تعیین مالک هر موجودیت

اگر مشتری در Dynamics ایجاد و در راهکاران اصلاح شود، باید روشن باشد کدام تغییر معتبر است. بدون System of Record برای هر entity، دو سیستم به‌تدریج از هم جدا می‌شوند.

موجودیت	پیشنهاد اولیه
Customer / Contact	Dynamics در هدف نهایی
Product / Variant	Dynamics یا SCM، با کد مرجع مشترک
Price / Promotion	Dynamics Commerce در سناریوی Retail
Invoice / Ledger	راهکاران تا زمان تأیید Finance و Localization
Payment / Settlement	مالک مشخص و idempotent در Integration

۳. روش دریافت تغییرات از راهکاران

اولویت روش‌ها:

1. API رسمی و مستند
2. Queue یا Service Integration پایدار
3. Export زمان‌بندی‌شده با کنترل checksum و watermark
4. CDC یا خواندن کنترل‌شده دیتابیس، فقط با تأیید vendor و DBA
5. Chrome Extension به‌عنوان آخرین گزینه و فقط برای جریان محدود

۴. Chrome Extension چه مشکلاتی دارد؟

• با تغییر HTML، selector یا framework صفحه ممکن است از کار بیفتد.
• مشاهده مقدار در DOM تضمین نمی‌کند تراکنش در سرور commit شده است.
• ثبت دوباره event، refresh یا timeout می‌تواند رکورد تکراری بسازد.
• اطلاعات حساس ممکن است ناخواسته در log یا payload قرار بگیرد.
• نصب، update، امضای Extension و مدیریت policy سازمانی نیازمند Governance است.
• فرایندهای بدون کاربر، batch، اصلاح سند و خطاهای مالی با Extension پوشش خوبی ندارند.

اگر Extension استفاده شود، باید فقط event حداقلی را به Adapter بفرستد؛ نه credential، HTML کامل یا اطلاعات غیرضروری.

۵. خطا، تکرار و سازگاری

Integration باید برای این حالت‌ها طراحی شود:

• timeout و قطع شبکه
• retry با backoff
• idempotency key برای سفارش و مشتری
• Dead Letter Queue برای پیام‌های ناموفق
• reconciliation روزانه بین دو سیستم
• audit trail شامل source، timestamp، correlation ID و نتیجه پردازش

۶. چالش‌های مالی و بومی‌سازی

ریال/تومان، گرد کردن، مالیات، سامانه مؤدیان، شماره‌گذاری اسناد، مرجوعی، تسویه کارت‌خوان و تفاوت تقویم می‌توانند باعث اختلاف مبلغ یا وضعیت سند شوند. این موارد باید با مثال واقعی و تأیید تیم مالی تست شوند.

۷. امنیت و دسترسی

• استفاده از Service Account حداقلی و Secret Vault
• رمزنگاری کانال و امضای پیام‌های حساس
• RBAC جداگانه برای کاربران، Adapter و Integration Service
• عدم ذخیره رمز عبور راهکاران در Extension
• محدودسازی دامنه و مجوزهای Extension
• ثبت audit بدون افشای داده حساس

معیار پذیرش Integration

معیار	انتظار
عدم تکرار	هر event با idempotency قابل بازپردازش باشد
ردیابی	هر رکورد correlation ID و audit داشته باشد
بازیابی	پیام ناموفق بدون ورود دستی قابل retry باشد
سازگاری مالی	مبلغ و وضعیت سند در هر دو سیستم قابل تطبیق باشد
تغییر UI	Integration اصلی به DOM وابسته نباشد
عملیات	داشبورد خطا، صف و lag در دسترس باشد