کارمند فرم درخواست تجهیز را تکمیل میکند. درخواست در پورتال ثبت میشود، اما ارتباط با سامانه دارایی در میانه کار قطع میشود. کاربر دوباره دکمه ارسال را میزند و چند دقیقه بعد، دو درخواست تحویل برای یک نیاز ایجاد شده است. ظاهر فرم درست کار میکند؛ مشکل در قراردادی است که میان دو سامانه تعریف نشده است.
اتصال فرم به سامانه فقط ارسال چند فیلد از یک صفحه به صفحه دیگر نیست. باید روشن باشد کدام سامانه مالک داده است، موفقیت چه معنایی دارد و پس از خطا چه اتفاقی میافتد. در این راهنما، یک الگوی اجرایی برای توسعه اتصالهای سازمانی با ManageEngine AppCreator ارائه میکنیم. جدول وضعیتها و کنترلهای تکرار، پیشنهاد معماری هستند؛ وجود خودکار آنها در هر اتصال آماده محصول فرض نشده است.
از نتیجه کسبوکار شروع کنید، نه از دکمه ارسال
برای درخواست تجهیز، نتیجه مطلوب ممکن است ایجاد یک درخواست تأییدشده در میز خدمت باشد، نه ساخت فوری رکورد تحویل دارایی. برای درخواست دسترسی نیز ثبت فرم نباید خودبهخود مجوز حساب مدیریتی ایجاد کند. ابتدا مرحلهای را مشخص کنید که اجرای عملیات در آن مجاز میشود و مسئول تصمیم را تعیین کنید.
اگر تأیید چندمرحلهای لازم است، آن را از منطق انتقال داده جدا نگه دارید. راهنمای گردش تأیید در AppCreator به این بخش میپردازد. تأیید درخواست و موفقیت فنی انتقال، دو وضعیت متفاوتاند؛ یک درخواست میتواند تأیید شده باشد اما هنوز در سامانه مقصد ثبت نشده باشد.
قابلیت آماده را با توسعه اختصاصی اشتباه نگیرید
معرفی رسمی AppCreator این محصول را یک بستر توسعه کمکد نصبشونده در زیرساخت سازمان معرفی میکند که برای ساخت برنامه، گردش کار و اتصال سامانهها به کار میرود. در یادداشت نسخه ۲.۳.۰ نیز اتصالهای تازه برای محصولاتی مانند AssetExplorer، Endpoint Central و PAM360 ذکر شدهاند.
این معرفی به معنی پشتیبانی آماده از همه عملیات هر محصول نیست. در مرحله ارزیابی، نسخه مبدا و مقصد، روش احراز هویت، فیلدهای قابل انتقال و عملیات واقعی اتصال را آزمایش کنید. اگر نیاز از پوشش اتصال آماده فراتر است، دامنه توسعه رابط برنامهنویسی باید در پیشنهاد فنی مشخص شود.
قرارداد داده را پیش از اتصال بنویسید
| داده | قاعده پیشنهادی | خطایی که کاهش میدهد |
|---|---|---|
| شناسه درخواست | برای هر نیاز کسبوکاری یکتا و پایدار باشد | ایجاد دوباره همان درخواست |
| شناسه کاربر | از هویت معتبر و مجاز استخراج شود | ثبت درخواست به نام شخص دیگر |
| شناسه دارایی | با رکورد معتبر مقصد تطبیق داده شود | انتخاب دستگاه همنام یا اشتباه |
| تاریخ و زمان | قالب و منطقه زمانی مشخص داشته باشد | جابجایی روز یا ساعت تحویل |
| مقدار و واحد | نوع داده و واحد صریح باشد | اشتباه میان تعداد، مبلغ و ظرفیت |
| شناسه نتیجه در مقصد | پس از تأیید ثبت، نگهداری شود | گم شدن ارتباط دو رکورد |
برای داده مشترک، یک مرجع اصلی تعیین کنید. اگر شماره سریال در سامانه دارایی نگهداری میشود، فرم نباید بدون قاعده آن را بازنویسی کند. کیفیت این مرجع نیز مهم است؛ انبارگردانی دقیق تجهیزات فناوری کمک میکند ارتباط فرم با رکورد دارایی به اطلاعات نامعتبر متکی نباشد.
مجوز اتصال از مجوز کاربر گستردهتر نشود
ممکن است حساب فنی اتصال اختیار ایجاد رکورد در مقصد را داشته باشد، اما هر کاربر فرم مجاز به ایجاد هر نوع رکورد نباشد. بنابراین پیش از فراخوانی مقصد، اعتبار درخواست و دامنه اختیار کاربر باید در سمت قابل اعتماد سامانه بررسی شود. پنهان کردن یک فیلد در صفحه، بهتنهایی یک کنترل دسترسی نیست.
راهنمای رسمی طراحی AppCreator توصیه میکند مجوزها محدود شوند، اطلاعات احراز هویت رابطها در دادههای عادی برنامه ذخیره نشوند و در صورت امکان از OAuth استفاده شود. برای پروژه، حساب اتصال با مسئول مشخص، دامنه محدود و روش تعویض اعتبارنامه تعریف کنید. رمز یا کلید اتصال نباید در پاسخ فرم، مرورگر یا گزارش عمومی ظاهر شود.
نشانی مقصد را نیز از تنظیمات مورد اعتماد بگیرید، نه از ورودی دلخواه کاربر. مجاز بودن یک فرم برای کارمند، مجوز فراخوانی هر نشانی داخلی سازمان نیست. مقصدهای مجاز، گواهی ارتباط و سیاست دسترسی شبکه باید پیش از تحویل بررسی شوند.
چرا قطع ارتباط مساوی شکست عملیات نیست؟
درخواست ممکن است در مقصد اجرا شده باشد، اما پاسخ آن به مبدا نرسد. در این حالت، وضعیت صحیح «نتیجه نامعلوم» است، نه الزاماً «ثبت ناموفق». ارسال مجدد بدون بررسی میتواند عملیات را تکرار کند.
استاندارد HTTP درباره تلاش مجدد خودکار برای عملیات غیرهمتوان هشدار میدهد؛ مگر اینکه سازوکار مشخصی برای اطمینان از ایمن بودن تکرار یا اجرا نشدن درخواست قبلی وجود داشته باشد. همتوان بودن یعنی تکرار درخواست یکسان، اثر مورد نظر اضافهای در مقصد ایجاد نکند.
شناسه یکتا باید در مقصد هم معنا داشته باشد
پیشنهاد معماری ما این است که هر عملیات، شناسه کسبوکاری پایدار داشته باشد و مقصد بتواند همان شناسه را شناسایی کند. اگر رابط مقصد از کلید جلوگیری از تکرار پشتیبانی میکند، طبق قرارداد خودش از آن استفاده کنید. در غیر این صورت، کنترل یکتایی یا میانافزار مناسب باید طراحی شود.
صرفاً جستوجو کردن پیش از ایجاد رکورد، در اجرای همزمان تضمین کافی نیست؛ دو درخواست ممکن است هر دو نتیجه خالی بگیرند و سپس دو رکورد بسازند. کنترل نهایی باید در نقطهای اعمال شود که ایجاد همزمان را واقعاً محدود میکند. قابلیت «عدم تکرار» یک فیلد در فرم هم بهتنهایی تضمین تراکنش سراسری میان دو سامانه نیست.
وضعیتها را برای کاربر و پشتیبان قابل فهم کنید
| وضعیت پیشنهادی | معنا | اقدام بعدی |
|---|---|---|
| ثبتشده در مبدا | داده فرم ذخیره شده است | بررسی مجوز و آمادهسازی ارسال |
| در انتظار انتقال | اجرای مقصد هنوز تأیید نشده است | پردازش طبق برنامه کنترلشده |
| ثبت تأییدشده در مقصد | شناسه و نتیجه معتبر دریافت شده است | نمایش پیگیری به کاربر |
| نتیجه نامعلوم | پاسخ قابل اتکا دریافت نشده است | تطبیق با مقصد پیش از ارسال دوباره |
| نیازمند اصلاح | داده یا مجوز پذیرفته نشده است | ارجاع به مسئول با شرح روشن |
این جدول، مدل پیشنهادی توسعه است و نام وضعیتهای آماده محصول نیست. پیام موفقیت فرم باید با همین تفکیک سازگار باشد. وقتی فقط ثبت اولیه انجام شده، نوشتن «تجهیز تخصیص یافت» کاربر را درباره مرحله واقعی فرایند گمراه میکند.
تلاش مجدد باید محدود و قابل ردیابی باشد
خطای اعتبارسنجی داده با اختلال موقت ارتباط یکسان نیست. تکرار همان ورودی نامعتبر معمولاً فقط بار و نویز ایجاد میکند. برای خطای موقت، پس از احراز ایمن بودن تکرار، فاصله و سقف تلاش مشخص کنید و پس از عبور از سقف، مسئول رسیدگی داشته باشید.
در مسیرهای پرتعداد، صف پردازش میتواند اتصال را از زمان انتظار کاربر جدا کند؛ اما خود صف نیز نیاز به پایش و مالک دارد. این انتخاب بخشی از معماری پروژه است، نه وعده آماده همه اتصالها. برای طراحی سنجش تأخیر، راهنمای رفع کندی صف پیام برنامهها مکمل مناسبی است.
آزمونهایی که قبل از تحویل لازماند
ارسال موفق یک فرم کافی نیست. دوبار کلیک کردن، اجرای همزمان، قطع پاسخ پس از ثبت مقصد، انقضای اعتبارنامه و رد یک فیلد اجباری را در محیط آزمایشی بررسی کنید. برای هر حالت، شمار رکوردهای مقصد و وضعیت قابل مشاهده کاربر باید با انتظار از پیش نوشتهشده تطبیق داشته باشد.
در آزمون امنیت، کاربر غیرمجاز نباید با تغییر شناسه در درخواست بتواند دارایی یا حساب دیگری را انتخاب کند. در آزمون بازیابی نیز رکورد نامعلوم باید بدون ایجاد نسخه تکراری با مقصد تطبیق داده شود. سوابق فنی باید شناسه پیگیری، زمان، نوع خطا و نتیجه را داشته باشند، اما حاوی راز اتصال یا اطلاعات شخصی غیرضروری نباشند.
موفقیت را با نتیجه نهایی گزارش کنید
شمار فراخوانی موفق، تمام ارزش یکپارچهسازی نیست. درخواستهای تأییدشده بدون نتیجه، مدت انتظار انتقال، موارد نیازمند تطبیق و رکوردهای تکراری را هم گزارش کنید. افزایش «ارسالها» در کنار افزایش کار دستی پشتیبانی، نشانه بهبود فرایند نیست.
برای نگهداری، مسئول هر دو سمت اتصال و روش آزمون پس از ارتقا را ثبت کنید. تغییر یک فیلد اجباری در مقصد میتواند فرمی را که مدتها کار کرده از کار بیندازد. ارتباط سالم امروز، جای قرارداد تغییر و پایش فردا را نمیگیرد.
نکات کلیدی
- ثبت فرم، تأیید درخواست و اجرای مقصد را سه مرحله جدا ببینید.
- پس از قطع ارتباط، نتیجه را پیش از تکرار عملیات مشخص کنید.
- کنترل یکتایی باید اجرای همزمان و سمت مقصد را نیز پوشش دهد.
- اعتبارنامه، مجوز، گزارش خطا و مسئول نگهداری بخشی از طراحی اتصالاند.
سخن پایانی
یکپارچهسازی قابل اعتماد، از ارسال داده فراتر میرود: باید بتوان توضیح داد درخواست چه زمانی مجاز شد، در مقصد چه اثری گذاشت و پس از خطا چگونه بازیابی شد. با قرارداد داده روشن و آزمون مسیرهای ناموفق، فرم سازمانی به بخشی قابل اتکا از فرایند خدمت تبدیل میشود.
مدانت خدمات انتخاب، لایسنس و پیادهسازی AppCreator و توسعه اتصال به سامانههای تخصصی سازمان را ارائه میدهد. برای اتصال به سرویس دسک پلاس یا سامانه دارایی، دامنه فیلدها، مجوزها و معیارهای پذیرش را در جلسه فنی مدانت مشخص کنید.
منابع
- معرفی رسمی AppCreator
- یادداشتهای نسخه و اتصالهای محصول
- اصول رسمی طراحی و امنیت برنامه
- استاندارد HTTP و تکرار عملیات
