فرض کنید یک سازمان سه سامانه مستقل دارد: ServiceDesk Plus برای ITSM، یک ERP برای اطلاعات مالی و قراردادها، و یک ابزار Monitoring برای زیرساخت. هر بار که یک درخواست مهم ثبت میشود، کارشناس باید بخشی از اطلاعات را دستی وارد ERP کند؛ هر بار که یک Change تأیید میشود، تیم عملیات باید جداگانه Pipeline یا ابزار مانیتورینگ را مطلع کند؛ و وقتی وضعیت یک Incident تغییر میکند، سیستمهای دیگر تا زمانی که دوباره داده را Poll نکنند از آن باخبر نمیشوند.
این مدل در مقیاس کوچک قابل تحمل است، اما با افزایش تعداد تیکت، سرویس و سامانه به یک مسئله عملیاتی تبدیل میشود: داده تکراری، تأخیر، خطای انسانی و Integrationهایی که به Cron و Polling وابستهاند. یکی از راههای تمیزتر برای حل این مسئله، استفاده از Webhook در ServiceDesk Plus در کنار REST API و Custom Function است.
Webhook به ServiceDesk Plus اجازه میدهد وقتی یک رویداد یا شرط مشخص رخ میدهد، بدون انتظار برای Poll شدن از سمت سامانه دیگر، یک فراخوانی HTTP به Endpoint مقصد انجام دهد. اما Webhook پاسخ همه سناریوها نیست. گاهی REST API انتخاب درستتری است و در سناریوهای پیچیدهتر باید Custom Function یا یک Middleware میان سیستمها قرار بگیرد. در این راهنما این سه مدل را از دید معماری، امنیت و عملیات واقعی بررسی میکنیم.
Webhook در ServiceDesk Plus دقیقاً چه کاری انجام میدهد؟
Webhook یک فراخوانی Event-driven به یک URL یا API خارجی است. بهجای اینکه ERP هر پنج دقیقه از ServiceDesk Plus سؤال کند «تیکت جدیدی داری؟»، خود ServiceDesk Plus پس از رخداد موردنظر میتواند داده لازم را برای ERP ارسال کند.
در ServiceDesk Plus، Webhook در فضای Automation و Developer Space قرار میگیرد و میتواند همراه Triggerها و Custom Actionها استفاده شود. مستندات و Release Noteهای فعلی ManageEngine نشان میدهند Webhookها در ماژولهای مختلفی از جمله Request، Problem، Change، Project، Task، Release و چند موجودیت دیگر در دسترس یا توسعه داده شدهاند. دامنه دقیق قابلیت به Cloud/On-Premises و Build نصبشده بستگی دارد؛ بنابراین قبل از طراحی Integration باید نسخه واقعی سازمان بررسی شود.
Webhook، REST API و Custom Function چه تفاوتی دارند؟
| روش | بهترین کاربرد | نقطه قوت | محدودیت اصلی |
|---|---|---|---|
| Webhook | ارسال رویداد از ServiceDesk Plus به سامانه خارجی | Event-driven، ساده و بدون Polling | برای منطق چندمرحلهای پیچیده مناسب نیست |
| REST API | خواندن/نوشتن داده ServiceDesk Plus توسط سیستم دیگر | کنترل کاملتر روی CRUD و Workflow | نیازمند Authentication، Error Handling و مدیریت Token |
| Custom Function | منطق سفارشی، تبدیل داده، چند API Call یا تصمیمگیری | انعطاف بالا و امکان اجرای Business Logic | نیازمند طراحی، تست، نگهداری و Governance کد |
| Middleware | یکپارچهسازی چند سامانه یا Integration حیاتی | Retry، Queue، Mapping، Observability و Isolation بهتر | پیچیدگی و هزینه عملیاتی بیشتر |
اگر هنوز تفاوت مفهومی API، Webhook و Connection برایتان مبهم است، مقاله تفاوت Connections، Webhook و API میتواند نقطه شروع خوبی باشد. مقاله حاضر یک گام جلوتر میرود و روی طراحی اجرایی این قابلیتها در ServiceDesk Plus تمرکز دارد.
چرا Event-driven Integration از Polling بهتر است؟
Polling یعنی سیستم مقصد در بازههای زمانی مشخص از ServiceDesk Plus داده بخواند. این روش همیشه بد نیست، اما وقتی هدف واکنش به یک Event مشخص است، چند مشکل رایج ایجاد میکند:
- بین رخداد و مشاهده آن تأخیر ایجاد میشود.
- بخش بزرگی از Requestها ممکن است پاسخ «هیچ تغییری نیست» داشته باشند.
- با افزایش تعداد Integrationها، بار API و پیچیدگی Scheduling افزایش پیدا میکند.
- تشخیص اینکه یک رکورد قبلاً پردازش شده یا نه سختتر میشود.
Webhook مدل Push را جایگزین میکند: وقتی شرط برقرار شد، Event ارسال میشود. البته در Integrationهای حیاتی نباید تصور کرد Webhook بهتنهایی تضمین تحویل میدهد. برای سناریوهای حساس، طراحی Retry، Idempotency و ثبت وضعیت تحویل همچنان لازم است.
سناریوی اول: ارسال Incident مهم به سامانه NOC یا SOC
فرض کنید Incidentهایی با Priority بالا باید در سامانه عملیاتی دیگری نیز ثبت شوند. میتوان Trigger را روی شرایطی مثل Priority، Category، Site یا Support Group تنظیم کرد و Webhook را به Endpoint مقصد فرستاد.
Payload میتواند فقط اطلاعات ضروری را منتقل کند: شناسه Request، Subject، Priority، Site، Requester و URL رکورد. بهتر است همه Description یا Attachmentها بدون نیاز واقعی منتقل نشوند؛ کمینهسازی داده هم Security را بهتر میکند و هم Integration را پایدارتر.
اگر Monitoring منبع اولیه رخداد باشد، جهت ارتباط میتواند برعکس باشد: ابزار Monitoring با REST API یک Request در ServiceDesk Plus ایجاد کند و سپس ServiceDesk Plus در تغییر Status یا Assignment از Webhook برای اطلاعرسانی برگشتی استفاده کند. این معماری دوطرفه از Email Parsing قابل کنترلتر است، بهخصوص زمانی که شناسه مرجع در هر دو سیستم نگهداری شود.
سناریوی دوم: اتصال ServiceDesk Plus به ERP
فرض کنید درخواست خرید تجهیزات پس از Approval باید وارد ERP شود. یک طراحی ساده این است:
- کاربر درخواست را در Service Catalog ثبت میکند.
- Approvalهای سازمانی در ServiceDesk Plus انجام میشوند.
- پس از تأیید نهایی، Trigger اجرا میشود.
- Webhook اطلاعات لازم را به Integration Endpoint ارسال میکند.
- ERP سند یا درخواست خرید را ایجاد میکند.
- شناسه ERP به ServiceDesk Plus برگردانده و در Additional Field ذخیره میشود.
اگر مرحله پنجم و ششم به Authentication پیچیده، Token Renewal یا چند API Call نیاز داشته باشند، بهتر است Webhook مستقیم جای خود را به Middleware یا Custom Function بدهد. Webhook باید تا حد امکان ساده و قابل پیشبینی بماند.
سناریوی سوم: اتصال CRM و Service Desk بدون کپی دستی
در سازمانی که مشتریان در CRM مدیریت میشوند، تیم پشتیبانی ممکن است بخواهد وضعیت Ticketهای خاص را در CRM هم ببیند. راه اشتباه این است که Technician بعد از هر Update یک فیلد را دستی در CRM اصلاح کند.
میتوان ServiceDesk Plus را طوری طراحی کرد که فقط تغییرهای مهم مانند ایجاد Request، تغییر Owner، Escalation و Closure را به CRM ارسال کند. در مقابل، CRM برای ایجاد Ticket یا خواندن وضعیت میتواند از REST API استفاده کند. نتیجه، تفکیک روشن نقشهاست: Webhook برای Event، API برای Query و Command.
REST API V3 در ServiceDesk Plus چه نقشی دارد؟
ManageEngine اکنون API V3 را مسیر اصلی Integrationهای جدید ServiceDesk Plus قرار داده است. مستندات ServiceDesk Plus Cloud میگویند REST API پلی میان ServiceDesk Plus و سایر Applicationهاست و طیف وسیعی از عملیات روی Request، Note، Approval، Task، Worklog، Problem و سایر Moduleها را ارائه میدهد.
در Cloud، API V3 از OAuth 2.0 استفاده میکند و Endpointها با توجه به Data Center سازمان متفاوت هستند. در محیطهای ESM که چند Portal دارید، نام Portal نیز بخشی از مسیر API است. بنابراین hard-code کردن URL بدون درنظرگرفتن Data Center و Portal یکی از خطاهای رایج Integration است.
در On-Premises نیز V3 API در دسترس است و Authentication مبتنی بر API Key/Authtoken با سطح دسترسی User یا Technician انجام میشود. نکته مهم این است که Token باید با حداقل Role موردنیاز ساخته شود؛ Token یک Administrator همهکاره برای یک Integration ساده، نقض اصل Least Privilege است.
از API V1 برای Integration جدید استفاده نکنید
ManageEngine پیشتر پایان عمر Change V1 API را اعلام کرده و برای Integrationهای Change توصیه کرده است به V3 API مهاجرت شوند. این موضوع یک درس معماری مهم دارد: Integration سفارشی نباید فقط «امروز کار کند»، بلکه باید Versioning و Upgrade محصول را هم تحمل کند.
اگر سازمان اسکریپت قدیمی، Add-in یا برنامه Desktop دارد که هنوز از Endpointهای قدیمی استفاده میکند، قبل از Upgrade ServiceDesk Plus باید Dependencyهای API فهرست شوند. بخشی از شکستهای Upgrade نه از خود محصول، بلکه از Integrationهایی میآید که سالها بدون Documentation باقی ماندهاند.
Webhook Security در ServiceDesk Plus Cloud در ۲۰۲۶ چه تغییر کرده است؟
در Release Notes رسمی ServiceDesk Plus Cloud، در ۱۶ ژوئن ۲۰۲۶ چند بهبود مهم برای Webhook معرفی شده است:
- پشتیبانی از Encryption برای Headerهای Webhook جهت حفاظت از اطلاعات حساس؛
- امکان استفاده از متغیرهای داینامیک با
$در Header Value؛ - برای Cloud Endpointها، امکان انتخاب DRE Connection Link برای اجرای امن Webhook از طریق DRE.
همچنین Intranet Webhook که قبلاً Beta بود، از ۲۹ اوت ۲۰۲۵ برای کاربران Cloud بهصورت عمومی فعال شده است. این قابلیت برای سازمانهایی مهم است که ServiceDesk Plus Cloud دارند اما Endpoint مقصد داخل شبکه خصوصی سازمان قرار گرفته است.
DRE در معماری Webhook چه مسئلهای را حل میکند؟
یکی از چالشهای Integration Cloud-to-On-Premises این است که API داخلی ERP یا سامانه سازمانی نباید برای دریافت Webhook مستقیماً روی Internet باز شود. DRE یا Data/Deployment-related relay mechanism در معماری ServiceDesk Plus Cloud میتواند مسیر کنترلشدهتری برای دسترسی به Endpointهای داخلی ایجاد کند.
اصل معماری این است: برای اینکه Cloud بتواند با یک API داخلی صحبت کند، اولین راهحل نباید Port Forwarding مستقیم از Internet به ERP باشد. باید مسیر امن، Authentication، Network Segmentation و Logging در نظر گرفته شود.
Secret و Token را کجا نگه داریم؟
ServiceDesk Plus قابلیت Global Variables دارد. طبق مستند فعلی ManageEngine، Global Variableها زیر Admin > Developer Space > Global Variables تعریف میشوند و میتوان Value آنها را Encrypt کرد. این Variableها در بخشهایی مانند Notification و Webhook با علامت $ قابل فراخوانی هستند.
این طراحی بهتر از قرار دادن Secret در متن Script یا URL است. OWASP نیز توصیه میکند Password، Token و API Key در URL قرار نگیرند، چون URL میتواند در Logهای Web Server، Proxy و ابزارهای Monitoring ثبت شود. اطلاعات حساس باید در Header یا Body مناسب و فقط از طریق HTTPS منتقل شوند.
چکلیست امنیت Webhook و API
| کنترل | پیشنهاد اجرایی |
|---|---|
| Transport | فقط HTTPS/TLS؛ Endpoint غیررمزشده برای داده سازمانی قابل قبول نیست |
| Secret Storage | Global Variable رمزشده، Vault یا Secret Manager؛ نه Token داخل URL |
| Least Privilege | Token و User اختصاصی با حداقل Role لازم |
| Payload | فقط فیلدهای لازم؛ از ارسال Description یا PII غیرضروری خودداری شود |
| Logging | Request ID، زمان، مقصد، Status Code و Correlation ID ثبت شوند |
| Retry | برای Timeout و خطای موقت Retry کنترلشده تعریف شود |
| Idempotency | تکرار یک Event نباید رکورد تکراری ایجاد کند |
| Timeout | Integration نباید Workflow اصلی ITSM را برای API کند متوقف کند |
| Versioning | نسخه API و Dependencyها مستند و قبل از Upgrade تست شوند |
Idempotency؛ نکتهای که اغلب فراموش میشود
فرض کنید Webhook به ERP ارسال شده، ERP سند را ساخته اما پاسخ بهدلیل Timeout به ServiceDesk Plus نرسیده است. اگر Integration دوباره همان Event را بفرستد، ممکن است سند دوم ساخته شود.
راهحل این است که یک شناسه یکتا مانند Request ID + Event Type یا Correlation ID به مقصد ارسال شود. ERP یا Middleware باید قبل از ایجاد رکورد جدید بررسی کند آیا این Event قبلاً پردازش شده است یا نه. این جزئیات کوچک تفاوت میان Integration آزمایشی و Integration قابل اتکا در Production است.
چه زمانی Middleware لازم است؟
Webhook مستقیم زمانی مناسب است که Mapping ساده باشد و مقصد پاسخ سریع و پایدار بدهد. اما اگر یکی از شرایط زیر وجود دارد، Middleware ارزشمند میشود:
- چند سیستم مقصد وجود دارد؛
- Transformation داده پیچیده است؛
- Retry و Queue تضمینشده نیاز دارید؛
- Token مقصد باید مرتب Refresh شود؛
- Rate Limit یا Throttling دارید؛
- باید Eventها Order مشخص داشته باشند؛
- Audit Trail مستقل از ServiceDesk Plus لازم است.
Middleware میتواند یک Integration Service اختصاصی، iPaaS یا سرویس داخلی سازمان باشد. هدف اضافه کردن یک لایه بیدلیل نیست؛ هدف جدا کردن پیچیدگی Integration از Workflow اصلی ServiceDesk Plus است.
Custom Function چه زمانی از Webhook بهتر است؟
اگر قبل از Call باید تصمیمگیری یا محاسبه انجام شود، Custom Function انتخاب مناسبتری است. برای مثال:
- بر اساس Site و Category، Endpoint مقصد عوض شود؛
- قبل از ارسال، داده از چند Field ترکیب و Normalize شود؛
- ابتدا Token گرفته شود و سپس Call دوم انجام شود؛
- پاسخ API مقصد تحلیل و فیلدی در ServiceDesk Plus بهروزرسانی شود؛
- در صورت خطا، Note یا Task مشخص ایجاد شود.
ManageEngine برای Request Custom Function نمونههای مختلفی ارائه کرده و در نسخههای جدید Automation، Custom Function و Webhook را در Moduleهای بیشتری گسترش داده است. اما هر Function باید مانند یک قطعه Software واقعی Version Control، Test و Owner داشته باشد.
یک معماری پیشنهادی برای Integration سازمانی
برای یک محیط متوسط یا بزرگ میتوان معماری را به چهار لایه تقسیم کرد:
- Event Source: Request، Change، Problem، Asset یا Workflow در ServiceDesk Plus؛
- Automation: Business Rule، Trigger، Webhook یا Custom Function؛
- Integration Layer: Endpoint مستقیم یا Middleware؛
- Target System: ERP، CRM، Monitoring، IAM، PAM، HR یا سامانه اختصاصی.
این تفکیک باعث میشود Business Rule با Integration Code مخلوط نشود. مثلاً «Change تأیید شد» یک Event تجاری است، اما نحوه دریافت Token از ERP یک مسئله Integration است و بهتر است در لایه مناسب خودش مدیریت شود.
نمونه Integration با محصولات دیگر ManageEngine
در اکوسیستم ManageEngine بخشی از Integrationها Native هستند، اما سازمانها معمولاً Use Caseهای خاص خود را هم دارند. ممکن است پس از یک Request خاص، عملیات در ADManager Plus اجرا شود؛ پس از Alarm مانیتورینگ، Ticket ساخته شود؛ یا نتیجه یک Workflow امنیتی به ServiceDesk Plus برگردد.
برای درک مسیرهای Integration آماده در اکوسیستم میتوانید مقاله یکپارچهسازی محصولات ManageEngine با ServiceDesk Plus را ببینید. اگر نیاز خارج از Integrationهای آماده باشد، صفحه افزونهها و توسعههای سفارشی ServiceDesk Plus مدانت مسیر تجاری مناسب برای طراحی Add-in، API Connector و Automation اختصاصی است.
Outlook Plus یک نمونه از Integration سفارشی در لایه کاربر است
همه Integrationها Server-to-Server نیستند. گاهی هدف این است که کاربر بدون خروج از ابزار روزمره خود، داده ساختاریافته در ServiceDesk Plus ثبت کند. نمونه آن OutlookPlus Add-in مدانت است که ثبت Request را از محیط Outlook به فرم ساختاریافته ServiceDesk Plus نزدیک میکند.
تفاوت مهم اینجاست: Add-in تجربه کاربری را توسعه میدهد، Webhook واکنش Event-driven را پیاده میکند و API مسیر Programmatic Access را فراهم میکند. یک معماری سازمانی ممکن است هر سه را همزمان داشته باشد.
ServiceDesk Plus Cloud و On-Premises را یکسان فرض نکنید
Cloud و On-Premises از نظر Integration قابلیتهای مشترک زیادی دارند، اما Authentication، مسیر API، قابلیتهای جدید Webhook و سرعت انتشار Feature یکسان نیست. برای مثال:
- Cloud API V3 از OAuth 2.0 و Data Center-specific domain استفاده میکند؛
- در ESM Cloud، Portal در URL API مشخص میشود؛
- Cloud در ۲۰۲۶ Webhook Header Encryption و DRE Support جدید گرفته است؛
- On-Premises API V3 از Authtoken/API Key استفاده میکند و Build نصبشده روی Availability Featureها اثر دارد.
پس Configuration را از یک Environment کپی نکنید و فرض نکنید در Environment دیگر بدون تغییر کار میکند.
Sandbox و محیط Test چرا برای Integration حیاتی است؟
Integrationی که میتواند Ticket را ببندد، Change را Update کند یا ERP را فراخوانی کند، نباید اولینبار روی Production تست شود. حداقل باید این سناریوها آزمایش شوند:
- پاسخ 200 و 201؛
- Timeout؛
- 401/403 و Token منقضی؛
- 429 یا Rate Limit؛
- 500 از مقصد؛
- Payload ناقص؛
- Event تکراری؛
- قطع شبکه و بازیابی بعدی.
ServiceDesk Plus Cloud در Sandbox خود از تست بخشی از Customizationها و قابلیتهای مرتبط پشتیبانی میکند. برای Integrationهای On-Premises نیز داشتن Test Instance یا حداقل Endpoint آزمایشی توصیه میشود.
Monitoring خود Integration را فراموش نکنید
یکی از بدترین حالتها این است که Integration ماهها Fail شود و کسی متوجه نشود. حداقل این KPIها باید قابل مشاهده باشند:
| KPI | هدف |
|---|---|
| Success Rate | درصد Callهای موفق |
| Error Rate | تعداد 4xx/5xx و Failureهای Business Logic |
| Latency | زمان پاسخ Endpoint مقصد |
| Retry Count | تعداد Eventهایی که نیازمند Retry شدهاند |
| Duplicate Prevention | تعداد Eventهای تکراری که مهار شدهاند |
| Queue Age | اگر Middleware دارید، قدیمیترین Event منتظر |
Governance تغییرات Integration
Webhook و API بخشی از Production Architecture هستند؛ پس تغییر آنها باید Change Management داشته باشد. تغییر URL مقصد، Token Scope، Mapping Field یا نسخه API میتواند روی چند تیم اثر بگذارد.
برای Integrationهای مهم یک Inventory ساده داشته باشید: نام Integration، Owner، Source، Target، Trigger، Authentication، API Version، Secret Location، Data Classification و Recovery Procedure. این Inventory هنگام Upgrade یا Incident بسیار ارزشمند است. برای مطالعه بیشتر درباره Governance فرآیندهای ITSM نیز میتوانید به مجموعه ITIL برای همه مراجعه کنید.
چکلیست طراحی Webhook در ServiceDesk Plus
- ابتدا مشخص کنید Webhook واقعاً بهتر از API Polling یا Custom Function است.
- Trigger را تا حد امکان دقیق تعریف کنید.
- Payload را کمینه کنید و PII غیرضروری نفرستید.
- فقط HTTPS استفاده کنید.
- Secret را در URL قرار ندهید.
- از Global Variable رمزشده یا Secret Store مناسب استفاده کنید.
- Token اختصاصی با Least Privilege بسازید.
- Correlation ID و Idempotency را طراحی کنید.
- Timeout و Retry Policy داشته باشید.
- خطاهای Integration باید Alert و Owner مشخص داشته باشند.
- API Version را مستند کنید و V1 Dependency قدیمی را حذف کنید.
- قبل از Upgrade ServiceDesk Plus Integration Regression Test اجرا کنید.
- در Cloud-to-Intranet از معماری امن مانند DRE استفاده کنید و API داخلی را بیدلیل Public نکنید.
نکات کلیدی
- Webhook برای Event مناسب است؛ API برای Query و Command.
- در Workflowهای پیچیده، Custom Function یا Middleware از Webhook مستقیم قابل اتکاتر است.
- ServiceDesk Plus Cloud در ژوئن ۲۰۲۶ Header Encryption و DRE Support را برای Webhook تقویت کرده است.
- Global Variable میتواند Secretها را رمزشده نگه دارد و در Webhook استفاده کند.
- Integration جدید باید روی API V3 طراحی شود؛ Dependencyهای قدیمی V1 باید شناسایی و مهاجرت شوند.
- HTTPS، Least Privilege، Idempotency و Observability بخشی از طراحی هستند، نه گزینههای بعدی.
منابع
- ManageEngine ServiceDesk Plus Cloud — What’s New
- ManageEngine ServiceDesk Plus — Global Variables
- ServiceDesk Plus Cloud REST API V3
- ServiceDesk Plus On-Premises REST API V3
- ServiceDesk Plus On-Premises Release Notes
- ManageEngine — Change V1 API EOL Announcement
- OWASP REST Security Cheat Sheet
سخن پایانی
یکپارچهسازی خوب یعنی ServiceDesk Plus به جزیرهای جدا از ERP، CRM، Monitoring و سامانههای سازمانی تبدیل نشود. Webhook برای واکنش سریع به Eventها، REST API V3 برای دسترسی برنامهنویسیشده و Custom Function برای منطق پیچیده، سه ابزار مکمل هستند. انتخاب درست میان آنها میتواند Integration را ساده و پایدار کند؛ انتخاب اشتباه میتواند مجموعهای از Scriptهای شکننده، Tokenهای پراکنده و Failureهای نامرئی بسازد.
اگر سازمان شما نیاز دارد ServiceDesk Plus را به ERP، CRM، Monitoring، Active Directory، PAM، سامانه منابع انسانی یا نرمافزار اختصاصی متصل کند، مدانت خدمات طراحی Integration، توسعه API Connector و Add-in، Custom Function، Automation، تست Upgrade و پشتیبانی را ارائه میکند. برای بررسی سناریوی اختصاصی میتوانید از صفحه افزونهها و توسعههای ServiceDesk Plus مدانت یا تماس با مدانت استفاده کنید.
