نکات برجسته معمار انتشار بهار 26

نسخه Spring ’26 نحوه تعامل محیط های Salesforce شما با سیستم های خارجی را از طریق به روز رسانی زیرساخت و تغییرات معماری تغییر می دهد. ما در حال معرفی یک استاندارد جدید برای نحوه طراحی معماری های Salesforce ایمن و مقیاس پذیر هستیم. این تغییرات به شما کمک می کند تا خطرات امنیتی سازمانی را کاهش دهید و ثبات محیط خود را بهبود بخشید.
این نسخه بهروزرسانیهای خاصی را برای مرزهای امنیتی و مدلهای یکپارچهسازی اعمال میکند که به عنوان پشتیبانی ساختاری برای این دوره از هوش مصنوعی عاملی عمل میکنند. به عنوان معمار، ما دائماً بین حفظ سازمان های بسیار در دسترس و برنامه ریزی برای نوآوری های آینده تعادل برقرار می کنیم. انتشار Spring ’26 به شما امکان می دهد کنترل های امنیتی ایجاد کنید که نه تنها محیط های موجود را تقویت می کند، بلکه امنیت و یکپارچگی داده ها را نیز افزایش می دهد.
چه تغییراتی در انتشار بهار 26 وجود دارد که برای معماران مرتبط است؟
انتشار بهار 26 تغییرات اجباری را معرفی می کند که ایجاد برنامه های کاربردی متصل را به نفع برنامه های مشتری خارجی (ECA) محدود می کند و احراز هویت قدیمی را که مستلزم توجه هر معمار است، منسوخ می کند. این تغییرات با جداسازی و شفاف کردن مرزها و در عین حال اجتناب از نگهداری قدیمی، امنیت را افزایش میدهند.
این راهنما گامهای لازم برای ممیزی ادغامهای قدیمی، مرزهای ایمن، و مدیریت پذیرش ایمن هوش مصنوعی نسل بعدی را تشریح میکند.
ادغام های خود را با پذیرش برنامه های مشتری خارجی ایمن کنید
نسخه Spring ’26 ایجاد یک برنامه متصل را بهطور پیشفرض در APIهای رابط کاربری و ابرداده محدود میکند مگر با نصب یک بسته. فعال کردن مجدد ایجاد اکنون به یک درخواست برای پشتیبانی Salesforce نیاز دارد. ECA کاملاً با ابرداده سازگار است. ادغام های ورودی جدید باید از ECA برای بهبود امنیت، حاکمیت و مدیریت استفاده کنند. شکل 1 را در زیر ببینید:
اینها برخی از مزایا هستند:
- امنیت افزایش یافته: ECA ها فقط از جریان های OAuth مدرن پشتیبانی می کنند و پشتیبانی از الگوهای قدیمی مانند جریان نام کاربری/رمز عبور مورد استفاده توسط برنامه های متصل را حذف می کنند. این بهترین شیوههای امنیتی را اعمال میکند و با حرکت Salesforce به سمت احراز هویت مدرن و مبتنی بر استانداردها و مدلهای یکپارچهسازی ایمن بهطور پیشفرض هماهنگ میشود.
- کنترل دسترسی: ECA ها به طور پیش فرض محلی و ایمن هستند. آنها تا زمانی که نصب نشوند در سازمان هدف وجود ندارند. این یک وضعیت امنیتی بسته ایجاد می کند، بر خلاف برنامه های کاربردی متصل، که به صورت جهانی تعریف شده اند و از نظر تئوری می توانند توسط هر سازمانی استفاده شود مگر اینکه محدود شود.
- سازمانهای DX/Scratch: برای معمارانی که گردش کار توسعه دهندگان را طراحی می کنند، توانایی ایجاد ECA های محلی در سازمان های اولیه یک بهبود کیفیت زندگی است. چرخه های توسعه زیرساخت به عنوان کد واقعی را بدون تکیه بر دارایی های جهانی DevOps برای هر آزمایش فعال می کند.
معماران باید فوراً اقدامات زیر را برای انطباق با تغییرات انجام دهند:
- یک ممیزی رسمی را برنامه ریزی کنید و موجودی برای برنامه های کاربردی متصل موجود برای مهاجرت نهایی شما.
- دستور ECA: به روز رسانی استانداردهای یکپارچه سازی برای مجوز ECA برای پروژه های جدید برای اطمینان از امنیت بهبود یافته.
- فورا خطوط لوله CI/CD را به روز کنید، تهیه خودکار برنامههای مرتبط از طریق API دیگر شکست نمیخورد، مجوز «ایجاد» در سطح API مسدود شده است.
معماری مدیریت ورودی با برنامه های مشتری خارجی
با انتقال به برنامههای مشتری خارجی، ادغامها را بهبود میبخشید و محافظهای بیشتری برای جلوگیری از نقض دادهها و حملات امنیتی ارائه میکنید.



برای بازنشستگی پروتکل های احراز هویت قدیمی آماده شوید
نسخه Spring ’26 به حذف تدریجی فراخوانی () SOAP API قدیمی پلتفرم ادامه میدهد و آن را به طور پیشفرض در سازمانهای جدید (از جمله سازمانهای scratch و sandbox) غیرفعال میکند تا از اشتراکگذاری مستقیم اعتبارنامه جلوگیری شود. استفاده از اسکریپت ها SOAP.login() شکست نمی خورد مگر اینکه به صورت دستی و دلهره آور دوباره فعال شود. در تابستان 27 SOAP.login() تماس در نسخه های API 31.0 تا 64.0 دیگر پشتیبانی نخواهد شد و دیگر در دسترس نخواهد بود.
شناسههای جلسه در پیامهای خروجی در 23 فوریه 2026 منسوخ میشوند. این امر نیاز به انتقال به احراز هویت ECA و OAuth را برای امنیت بیشتر برجسته میکند.
چرخه عمر گواهی به دلیل استانداردهای صنعت کوتاه شده است. از مارس 2026، گواهینامههای جدید امضا شده توسط CA به 6.5 ماه (200 روز) محدود میشوند و در سال 2027 به 100 روز کاهش مییابد. گواهیهای SSO داخلی که خودامضا میشوند معاف هستند. استراتژی مدیریت گواهینامه و اتوماسیون خود را برای چرخش های بیشتر مرور کنید. باید ادغامهای قدیمی را برای ارائه احراز هویت مبتنی بر OAuth برای جلوگیری از وقفه در سرویس و ارتقای امنیت قویتر منتقل کنید.
معماران باید چه استراتژی های مدیریتی را برای پروتکل بافت مدل پیاده سازی کنند؟
همانطور که ما به سمت دنیای اول هوش مصنوعی پیش می رویم، Salesforce همچنین به عوامل Agentforce این امکان را می دهد تا با استقلال بی سابقه با ابرداده ها تعامل داشته باشند. ما به این تغییر دامن می زنیم سرویس Agentforce DX Model Context Protocol (MCP). یک استاندارد باز که قابلیت های عامل Agentforce را فعال می کند.
MCP یک پروتکل باز است که توسط Anthropic تعریف شده است و نحوه دسترسی یک نماینده به ابزارها، منابع داده و سیستم ها را استاندارد می کند و به Agentforce اجازه می دهد به راحتی به خدمات (مانند پایگاه داده ها و ابزارهای سازمانی) دسترسی داشته باشد. شکل 2 را ببینید:

Salesforce MCP را برای استاندارد کردن تعاملات هوش مصنوعی اتخاذ کرد و دو لایه مدیریتی را برای معماران معرفی کرد:
- لایه یکپارچه سازی (زمان اجرا): کاتالوگ API صفحه کنترل جدید شماست. با معرفی MuleSoft sync، اکنون می توانید به طور صریح سرورها را برای مدیریت دسترسی نماینده به داده های سازمانی فعال یا غیرفعال کنید.
- این سرورها مجوزهای کاربر را به ارث می برند زیرا معمار اجرای “حداقل امتیاز” برای جلوگیری از اصلاح غیرمجاز داده ضروری است.
- یک لایه بسازیدr (توسعه دهنده): سرور جدید Salesforce DX MCP ( شکل 3 را ببینید) تعامل زبان طبیعی با ابرداده های سازمانی را از طریق یک IDE امکان پذیر می کند.
ما یک حصار امنیتی سخت را در بهار 2026 پیادهسازی کردیم، توجه داشته باشید که Agentforce Vibes (IDE مبتنی بر وب) اکنون فقط در Sandboxes در دسترس خواهد بود، دسترسی در سازمانهای تولیدی ممنوع است.

معماران باید به طور فعال یکپارچگی سیستم را با ایجاد پروتکل های مدیریت داخلی حفظ کنند. ما استفاده اجباری را توصیه می کنیم حالت برنامه ریزی برای هر گونه تغییرات پرخطر، مانند منطق Apex یا محرک های پیچیده داده، برای اطمینان از اینکه “انسان در حلقه” طرح معماری را قبل از اجرا یا استقرار هر کدی تایید می کند.
Agentic Enterprise: معماری فناوری اطلاعات برای آینده مبتنی بر هوش مصنوعی
لایه امنیت و حاکمیت، اعتماد و ایمنی را در کل معماری ایجاد میکند، از داراییهای شرکت در برابر تهدیدات محافظت میکند، ریسک را مدیریت میکند و از انطباق با مقررات اطمینان میدهد.



معماری با Lightning Out 2.0 برای عملکرد بالا در بهار 26
Lightning Out 2.0 که اکنون بر روی Lightning Web Runtime (LWR) ساخته شده است، استاندارد جدیدی را برای Salesforce embedding (LWC) در میزبان های خارجی (به عنوان مثال شیرپوینت یا پورتال) ایجاد می کند. برخلاف نسخههای قدیمی، Lightning Out 2.0 جداسازی دقیق iframe را اعمال میکند و تبادل توکن OAuth را اعمال میکند و الگوهای شناسایی جلسه پرخطر را حذف میکند. این نشان دهنده یک تغییر اجباری به یک مدل اعتماد صفر است.
معماری اکنون “Default Deny” است. باید ادغامهای موجود را بررسی کنید و دامنههای میزبان را صریحاً به آن اضافه کنید دامنه های مورد اعتماد لیست مجاز در تنظیمات جلسه برای جلوگیری از قطع خدمات فوری.
در اینجا چند پیشرفت وجود دارد که باید برای بهبود مدیریت داده ها نیز در نظر بگیرید:
- مکان نماهای اوج (GA): این ویژگی به گروهبندی سمت سرور اجازه میدهد تا مجموعه دادههای بزرگ را در یک تراکنش واحد و در تکههای قابل مدیریت پردازش کند و جایگزین میراث قدیمی شود. جابجایی بند و بهبود فراتر از حد رکورد 2000 مکان نما صفحه کلاس (برای LWC) صفحهبندی بدون حالت، صفحهبندی سمت سرور، حل مشکلات عملکرد (مثلاً خطاهای بزرگ) را در رابطهای کاربری سفارشی با جستارهای پیچیده و بزرگ فعال میکند. این برای عناصر UI مانند لیست رکوردها در چندین صفحه طراحی شده است، و می توانید از طریق مجموعه نتایج به جلو و عقب بروید. شما باید برای افزایش عملکرد در پردازش با حجم بالا و منابع بالا آزمایش کنید و محدودیت های تنظیم کننده پیچیده SOQL را برطرف کنید.
- نشانگر + صف: علاوه بر صفحهبندی رابط کاربری، مکاننماهای Apex یک جایگزین کارآمد برای Batch Apex برای پردازش مجموعههای نتایج بزرگ را باز میکنند. با ترکیب مکاننماها با یک Apex صفبندیشده زنجیرهای، میتوانید مجموعههای داده عظیم با اندازههای تکه پویا را پردازش کنید، و به طور موثر از محدودیتهای اندازه دستهای ثابت در Batch Apex استاندارد دور بزنید.
هنگام طراحی این الگوها، به یاد داشته باشید که حداکثر تعداد ردیف های مکان نما در یک دوره 24 ساعته 100 میلیون است.
Hyperforce، Data Residency، Compliance
هایپرفورس در حال گسترش به 17 کشور، ژاپن و هند است. این برنامه افزودنی به مشتریان اجازه می دهد تا داده ها را به صورت محلی ذخیره کنند و نیازهای اقامت و انطباق داده های محلی را برآورده کنند.
در این نسخه، برنامه پشتیبانگیری جدید احراز هویت با پیکربندی صفر را ارائه میکند و نیاز به جریان فعال OAuth 2.0 یا برنامه مرتبط را از بین میبرد. دیگر نیازی به مدیریت اعتبارنامه یا گواهینامه های مشتری برای این ابزار انطباق خاص ندارید.
از آنجا که برنامه Archive بر روی یک بستر Hyperforce قابل اعتماد اجرا می شود (به ویژه در مناطق جدید مانند ژاپن و هند)، می تواند اعتماد پلت فرم داخلی را افزایش دهد. هر چیزی که یک برنامه بومی نیست (به عنوان مثال ERP یا پورتال سفارشی شما) به این معنی است که باید با استفاده از ECA به سمت مدیریت OAuth سختتر بروید. شکل 4 را در زیر ببینید:

به عنوان یک معمار، باید لیست های سفید IP را به روز کنید تا محدوده های IP عمومی Hyperforce ورودی را شامل شود که از IPv6 پشتیبانی می کند تا از مسدود کردن ترافیک قانونی جلوگیری شود. برای استفاده از برنامه Archive برای ناشناس کردن PII، پشتیبانی از RTBF و مطابقت با GDPR، خط مشی حفظ داده را مرور کنید. جریان های OAuth فعلی خود را مشاهده و به ECA منتقل کنید.
چرا موضوع بهار 26 برای معماران مهم است؟
نسخه Spring ’26 امنیت Salesforce را با محدود کردن ایجاد برنامههای کاربردی متصل و با حذف احراز هویت قدیمی بهبود میبخشد. علاوه بر این، این نسخه نوآوری های هیجان انگیزی را در مورد پشتیبانی MCP، Hyperforce و به روز رسانی های اساسی مانند Apex Cursor معرفی می کند که قابلیت اطمینان، ثبات و عملکرد سیستم را بهبود می بخشد.




