همگام‌سازی موبایل در تیم‌های میدانی و روش‌های حل تعارض داده‌های آفلاین

مقدمه و رویکرد معماری

در شرکت‌هایی که عملیات میدانی انجام می‌دهند، جمع‌آوری داده‌ها در کارگاه‌ها یا مناطق دورافتاده‌ای که اتصال اینترنت قطع است، از نظر تداوم فعالیت اهمیت حیاتی دارد. در چنین مواردی، برای اینکه اپلیکیشن‌های موبایل بتوانند به صورت بی‌وقفه کار کنند، لازم است داده‌ها به صورت محلی ذخیره شده و پس از برقراری اتصال، به شکل امن با سرور یکپارچه شوند. Cy Logic Software در فرآیندهای توسعه زیرساخت خود، معماری‌های محکمی را برای چنین سناریوهایی با استفاده از تکنولوژی‌های مدرن وب و موبایل طراحی می‌کند.

مدیریت صف آفلاین با پایگاه داده محلی SQLite

برای جلوگیری از گم شدن عملیات کاربر هنگام قطع ارتباط، اولین قدم نگه داشتن داده‌ها در یک ساختار امن روی دستگاه است. استفاده از پایگاه داده محلی sqlite تضمین می‌کند که یکپارچگی داده‌های رابطه‌ای روی دستگاه موبایل حفظ شود.

• عملیات در یک جدول صف (الگوی outbox) ذخیره می‌شوند.
• یک UUID یکتا و یک مهر زمانی برای هر رکورد ایجاد می‌شود.
• وضعیت اتصال توسط مدیر شبکه گوش داده می‌شود؛ وقتی اینترنت وصل شد، داده‌های داخل صف به ترتیب به سرور ارسال می‌شوند.

جلوگیری از درخواست‌های تکراری با طراحی Idempotent API

در شرایط ضعیف شبکه، مواردی که یک درخواست ارسالی به سرور می‌رسد اما پاسخ به کلاینت (دستگاه موبایل) برمی‌گردد، بسیار شایع است. از آنجا که کلاینت پاسخ را دریافت نکرده، همان درخواست را دوباره ارسال می‌کند. در این حالت، طراحی idempotent api نقش بسیار مهمی ایفا می‌کند.

• در سمت سرور، هر درخواست با UUID یکتای دریافتی بررسی می‌شود.
• اگر درخواستی قبلاً با همان UUID پردازش شده باشد، سرور به جای ایجاد یک رکورد جدید، پاسخ موفق قبلی را برمی‌گرداند.
• این روش از ورود داده‌های تکراری ناشی از نوسانات شبکه جلوگیری می‌کند.

استراتژی‌های حل تعارض (Conflict Resolution)

اگر دو نفر از پرسنل میدانی مختلف به طور همزمان تغییراتی آفلاین روی یک داده مشابه انجام دهند، در سمت سرور یک تعارض (conflict) رخ می‌دهد. قانون کلاسیک «آخرین نویسنده برنده است» (last-write-wins) به دلیل اینکه می‌تواند منجر به از دست رفتن داده‌ها شود، در ساختارهای سازمانی ناکافی است.

• ادغام مبتنی بر فیلد: به جای بازنویسی کل رکورد، فقط فیلدهای تغییر یافته (مثلاً مقدار موجودی یا متن توضیحات) مقایسه می‌شوند.
• کنترل نسخه: یک شماره 'version' یا 'revision' به هر سطر داده اضافه می‌شود. اگر نسخه موجود در درخواست به‌روزرسانی قدیمی‌تر از نسخه سرور باشد، سیستم سیگنال تعارض تولید می‌کند.
• حل دستی یا مبتنی بر قوانین: در مواردی که امکان ادغام خودکار وجود ندارد، داده‌ها به تایید مدیر یا قوانین تجاری از پیش تعریف شده هدایت می‌شوند.

نتیجه‌گیری

در عملیات میدانی، مدیریت همگام‌سازی موبایل و داده‌های آفلاین زمانی قابل اعتماد می‌شود که تصمیمات معماری درستی اتخاذ شود. با ترکیب پایگاه داده محلی sqlite، یکپارچه‌سازی idempotent api و مکانیزم‌های پیشرفته conflict resolution می‌توان یکپارچگی داده‌ها را به شکل کامل حفظ کرد.

سناریوی فرضی: مدیریت انبار و لجستیک

در این سناریو، دو نفر از پرسنل انبار را در نظر بگیرید که در انبارهای زیرزمینی کار می‌کنند و دسترسی به اینترنت تقریباً وجود ندارد. هر دو پرسنل همزمان در حالت آفلاین روی محصولی تغییر ایجاد می‌کنند که موجودی فعلی آن در سیستم ۵۰ عدد است. پرسنل اول با شمارش موجودی در محل، آن را به ۳۰ عدد به‌روزرسانی می‌کند، در حالی که پرسنل دوم یادداشت حمل‌ونقل جدیدی به همان آیتم اضافه کرده و فیلد توضیحات را تغییر می‌دهد. وقتی اتصال اینترنت دوباره برقرار می‌شود، هر دو دستگاه موبایل در صف ارسال داده‌های موجود در صف SQLite به سرور قرار می‌گیرند. اگر سیستم از استراتژی «آخرین نویسنده برنده است» استفاده می‌کرد، آخرین درخواستی که به سرور می‌رسید، به‌روزرسانی حیاتی پرسنل دیگر را کاملاً بازنویسی می‌کرد و باعث از دست رفتن داده می‌شد. به جای آن، مکانیزم‌های ادغام مبتنی بر فیلد و کنترل نسخه وارد عمل می‌شوند. سرور تشخیص می‌دهد که پرسنل اول مقدار موجودی را به‌روز کرده و پرسنل دوم فقط متن توضیحات را تغییر داده است. از آنجا که این دو فیلد مختلف با یکدیگر تداخل ندارند، سیستم داده‌ها را به صورت خودکار ترکیب می‌کند. اما اگر دو مقدار عددی مختلف روی یک فیلد موجودی مشابه وارد شده بود، تراکنش به صف حل مبتنی بر قاعده منتقل شده و برای تأیید مدیر ارائه می‌شد تا از خطاهای مالی احتمالی جلوگیری گردد.

چک‌لیست پیاده‌سازی تفصیلی و مدیریت خطا

برای اینکه همگام‌سازی داده‌ها در اپلیکیشن‌های میدانی بی‌نقص کار کند، باید مراحل و سناریوهای خطا به دقت مدیریت شوند. در فرآیندهای توسعه و استقرار اپلیکیشن، این چک‌لیست باید دنبال شود: اولاً، باید تأیید شود که برای هر عملیات در صف outbox مبتنی بر SQLite، یک UUID یکتا و یک شماره نسخه صعودی تولید می‌شود. دوماً، با راه‌گذاری شنوندگان وضعیت شبکه (connectivity) در سمت کلاینت، بازخوردهای بصری روشنی به کاربر در هنگام قطع ارتباط ارائه شود و تضمین گردد که صف هنگام اتصال مجدد به طور خودکار در پس‌زمینه راه‌اندازی می‌شود. سوماً، با تست‌های بار اثبات شود که نقاط پایانی سرور دارای ساختار idempotent هستند، یعنی در درخواست‌های تکراری، رکوردهای تکراری تولید نمی‌کنند. در مرحله چهارم، الگوریتم‌های ادغام مبتنی بر فیلد برای مدیریت تعارض نوشته شده و یک جدول استثنا (exception) برای تداخلاتی که به صورت خودکار حل نمی‌شوند، ایجاد شود. در سمت مدیریت خطا، پاسخ‌های 409 Conflict برگشتی از سرور باید در دستگاه موبایل گرفته شوند؛ بدون اینکه داده‌ها دور ریخته شوند، باید در پایگاه داده محلی به وضعیت «دارای تعارض» تغییر یافته و به کاربر اعلان ارسال شود. تمام این فرآیندها توسط ساختارهای حرفه‌ای مانند Cy Logic Software در راهکارهای سازمانی موبایل از ابتدا تا انتها تست و راه‌اندازی می‌شوند.

منابع

• برنامه‌های وب و موبایل — Cy Logic Software