اگر فروشگاه شما در مشهد سفارش را در سایت ثبت میکند، موجودی را در اکسل انبار نگه می‌دارد و فاکتور را دستی در نرمافزار حسابداری می‌زند، مشکل شما نرمافزار بد نیست؛ سه برنامه‌ی خوب است که با هم حرف نمی‌زنند. راه‌حلش یک وب سرویس یا API است: دری مشخص که یک نرمافزار از آن می‌پرسد «موجودی این کالا چقدر است؟» و جواب را به شکلی می‌گیرد که برنامه‌ی دیگر بفهمد. یکپارچه‌سازی یعنی این دَرها را به‌جای آدم‌ها، به‌دست نرمافزار باز کنیم.
کسی که ساعت‌ها اعداد را از یک صفحه به صفحه‌ی دیگر کپی میکند، فقط وقت نمی‌سوزاند. هر کپی احتمال خطا دارد و هر خطا بعداً در موجودی، فاکتور یا گزارشی که مدیر به آن تکیه میکند ظاهر میشود.
سیستم‌های جزیره‌ای چه دردی برای کسب‌وکار درست می‌کنند؟
جزیره‌ای یعنی هر نرمافزار داده‌ی خودش را دارد و راهی برای تبادل با بقیه ندارد. معمولاً هیچ‌کس عمداً این وضع را نمی‌سازد. اول سایت راه می‌افتد، یک سال بعد حسابداری عوض میشود، بعد انبار به نرمافزار جدا می‌رود و هر تصمیم در لحظه‌ی خودش منطقی بوده است.
نتیجه را در عمل می‌بینید. کالا در سایت موجود نشان داده میشود ولی در انبار تمام شده. مشتری تأیید سفارش می‌گیرد و بعد تماس «ببخشید، موجود نیست» دریافت میکند. حسابدار آخر ماه ناچار است سفارش‌های سایت را با فایل‌های دیگر تطبیق بدهد. هیچ‌کدام از این‌ها فاجعه نیست، اما همه‌شان هر روز اتفاق می‌افتند.
API به زبان ساده یعنی چه؟
API مثل پیشخوان یک رستوران است. شما به آشپزخانه نمی‌روید؛ سفارش را به شکلی استاندارد روی پیشخوان می‌دهید و غذا را به شکلی استاندارد تحویل میگیرید. نرمافزار هم همین‌طور است: بدون اینکه درونِ دیتابیس دیگری را ببیند، درخواستی می‌فرستد و پاسخی می‌گیرد.
بیشتر وب سرویس‌های امروزی به سبک REST ساخته می‌شوند و داده را با قالب JSON رد و بدل می‌کنند. خوانایی‌اش برای انسان هم بد نیست: اسم کالا، موجودی، قیمت، هرکدام یک فیلد با نام مشخص. اینکه طرف مقابل چه فیلدی را می‌پذیرد در مستندات آن API آمده و نخستین کار در هر پروژه‌ی یکپارچه‌سازی خواندن همین مستندات است، نه کدنویسی.
انواع یکپارچه‌سازی کدام‌اند و کِی کدام را انتخاب کنیم؟
همه‌ی اتصال‌ها یک شکل ندارند. انتخابِ نوع، بیشتر از آنچه فکر می‌کنید به رفتار کسب‌وکارتان بستگی دارد، نه به فناوری. جدول زیر چهار الگوی رایج را کنار هم گذاشته است.
| الگو | چطور کار میکند | مناسبِ | ضعفِ اصلی |
|---|---|---|---|
| درخواست لحظهای (API Call) | برنامه‌ی الف در لحظه از برنامه‌ی ب می‌پرسد | نمایش موجودی، استعلام قیمت | اگر طرف مقابل از دسترس خارج شود، صفحه هم خراب میشود |
| وبهوک (Webhook) | رویداد که رخ داد، برنامه‌ی مبدأ خبر میدهد | ثبت سفارش، پرداخت موفق | باید پیام‌های ازدست‌رفته را بازیابی کرد |
| همگام‌سازی زمان‌بندی‌شده | هر چند ساعت داده‌ها دسته‌ای هماهنگ می‌شوند | گزارش، حسابداری، بروزرسانی کاتالوگ | داده همیشه لحظهای تازه نیست |
| میدل‌ور (لایه‌ی واسط) | یک سرویس وسط داده را ترجمه و مسیردهی میکند | اتصال چند نرمافزار قدیمی و جدید | یک قطعه‌ی دیگر که باید نگهداری شود |
قاعده‌ای که خودم پیش می‌گیرم این است: هرجا مشتری منتظر جواب است (نمایش موجودی)، درخواست لحظهای؛ هرجا فقط باید ثبتی انجام شود (فاکتور)، وبهوک یا همگام‌سازی. نیازی نیست همه چیز لحظهای باشد. لحظه‌ای‌کردنِ بی‌دلیل هزینه و ریسک اضافه میکند.
امنیت و احراز هویت در اتصال سیستم‌ها چطور رعایت میشود؟
وقتی دو نرمافزار داده رد و بدل می‌کنند، هر کدام باید مطمئن باشد طرف مقابل همان کسی است که ادعا میکند. معمولاً این کار با کلید API یا توکن انجام میشود، که مثل کارت ورودِ یک کارمند است: مشخص میکند چه کسی هستید و به چه چیزی اجازه دارید.
- کلیدها را در کدی که مرورگر کاربر می‌بیند نگذارید؛ فقط سمت سرور نگه دارید.
- برای هر اتصال دسترسیِ حداقلی بدهید. سایت فقط باید موجودی را بخواند، نه اینکه بتواند قیمت‌های حسابداری را تغییر دهد.
- تمام ارتباط‌ها روی HTTPS باشد و کلیدها قابل تعویض باشند، بدون اینکه کل سیستم بخوابد.
- هر درخواست و خطا ثبت شود تا بعداً بتوان فهمید دقیقاً چه چیزی کجا گم شد.
در آنوبز، مشهد، فرایند ما ISO/IEC ۲۷۰۰۱:۲۰۲۲ را برای سیستم مدیریت امنیت اطلاعات دارد (جزئیات گواهی)، اما این به معنای «هک‌نشدنی» بودن هیچ سیستمی نیست. یعنی روش کار ما ممیزی‌شده است و همین رویه‌ها را در اتصال‌ها هم دنبال می‌کنیم.
نمونه: اتصال سایت به انبار و حسابداری چه شکلی دارد؟
فروشگاهی را فرض کنید که سه چیز دارد: سایت، فایل انبار و نرمافزار حسابداری. یک طراحی ساده و کم‌ریسک این‌طور است.
- موجودی «منبع حقیقت» یک جا بماند، مثلاً انبار. سایت فقط می‌خواند و خودش موجودی را عوض نمی‌کند.
- هنگام ثبت سفارش، سایت با وبهوک خبر میدهد و انبار موجودی را رزرو میکند.
- بعد از پرداخت موفق، یک سند به حسابداری می‌رود؛ اگر حسابداری در دسترس نبود، سند در صف می‌ماند و بعداً دوباره تلاش میشود.
- هر شب یک همگام‌سازی کامل، اختلاف‌ها را پیدا و گزارش میکند.
گام آخر کم‌هیجان است ولی از همه مهم‌تر. بدون آن، یک وبهوک گم‌شده ماه‌ها بی‌خبر می‌ماند و اختلاف موجودی آرام آرام بزرگ میشود.
یکپارچه‌سازی خوب آن نیست که هیچ‌وقت خراب نشود؛ آن است که وقتی خراب شد، خودش بگوید کجا و چرا.
هزینه و زمان یکپارچه‌سازی به چه چیزهایی بستگی دارد؟
آنوبز برای این کار عدد ثابت منتشر نمی‌کند، چون دو پروژه‌ی به‌ظاهر مشابه می‌توانند کاملاً متفاوت باشند. عوامل اصلی این‌ها هستند:
- کیفیت API طرف مقابل: نرم‌افزاری با مستندات روشن و محیط آزمایشی، کار را ساده میکند. نرمافزار قدیمی بدون API ممکن است به راهحل جایگزین نیاز داشته باشد.
- تعداد سیستم‌ها و جهتِ داده: یک‌طرفه یا دوطرفه بودن تبادل پیچیدگی را بسیار تغییر میدهد.
- قواعد کسب‌وکار: اگر تخفیف، مالیات یا موجودی چندانباره دارید، منطقِ تبدیل داده سنگین‌تر میشود.
- مدیریت خطا و پایش: صف تلاش مجدد، هشدار و گزارش اختلاف، بخشی از کار است، نه افزونه.
- نگهداری بعد از تحویل: API ها تغییر می‌کنند و اتصال باید همراهشان بماند.
مشاوره و برآورد اولیه‌ی آنوبز رایگان است و پیش از شروع، به‌صورت شفاف و بدون هزینه‌ی پنهان اعلام میشود.
چک‌لیست پیش از شروع یکپارچه‌سازی
- فهرست سیستم‌هایی که باید حرف بزنند و صاحب هر کدام را بنویسید.
- برای هر داده مشخص کنید منبع حقیقتش کدام سیستم است.
- بررسی کنید هر نرمافزار API و مستندات دارد یا نه.
- بگویید چه داده‌ای باید لحظهای باشد و چه داده‌ای میتواند چند ساعت دیرتر برسد.
- تعیین کنید اگر یک سیستم از دسترس خارج شد چه اتفاقی بیفتد.
سؤالات پرتکرار
آیا آنوبز در مشهد میتواند نرمافزار قدیمی بدون API را هم به سایت وصل کند؟
گاهی میشود، ولی راهحل به نرمافزار بستگی دارد. آنوبز در مشهد ابتدا بررسی میکند که آن نرمافزار API، خروجی فایل یا دسترسی دیتابیس دارد یا نه، و بعد کمریسکترین مسیر را پیشنهاد میدهد. مشاوره و برآورد اولیه رایگان است.
تفاوت API و وبهوک چیست؟
در API شما از نرمافزار دیگر میپرسید و جواب میگیرید؛ در وبهوک نرمافزار دیگر خودش وقتی اتفاقی افتاد خبر میدهد. آنوبز در مشهد معمولاً برای نمایش لحظهای داده از API و برای رویدادهایی مثل ثبت سفارش یا پرداخت از وبهوک استفاده میکند.
یکپارچه‌سازی سیستم‌ها امن است؟
اگر درست طراحی شود، بله. آنوبز در مشهد کلیدها را فقط سمت سرور نگه می‌دارد، دسترسی هر اتصال را محدود میکند و خطاها را ثبت میکند. البته امنیت مطلق وجود ندارد و هدف کاهش و کنترل ریسک است.
تجربه‌ی خودم از اتصال سیستم‌ها
راستش در پروژه‌ی سامانه‌ی رزرو کانون پرورش فکری که خودم رویش کار کردم، اول خواستم هر بخش داده‌ی خودش را داشته باشد و بعداً به هم وصلشان کنم. اشتباه بود. رزرو سالن، دوره‌ها و پنل مدیریتی همه به یک تصویر واحد از «چه چیزی الان آزاد است» نیاز داشتند و دو منبع حقیقت دقیقاً همان جزیره‌هایی شدند که قرار بود حذفشان کنیم. برگشتم و داده را یک‌جا نگه داشتم و بقیه فقط از آن خواندند. کندتر شروع شد، ولی بعدش حرف زدن بخش‌ها با هم ساده شد.
اگر نرم‌افزارهایی دارید که هنوز با کپی‌کردن دستی به هم وصل‌اند، آنوبز در مشهد برایتان رایگان بررسی میکند کجا اتصال خودکار ارزش دارد. برای شروع می‌توانید از صفحه‌ی تماس پیام بدهید. اگر فکر می‌کنید نرمافزار آماده کافی است، مقایسه‌ی نرمافزار آماده و سامانه‌ی اختصاصی کمکتان میکند، و برای مسیر کلی‌تر خودکارسازی، اتوماسیون اداری تحت وب را ببینید. نمونه‌های اجراشده در نمونه‌کارها هست و خدمت مرتبط توسعه‌ی نرمافزار تحت وب است.
