شما در حال مشاهده اسناد Apigee Edge هستید.
به مستندات Apigee X بروید . اطلاعات
در روز چهارشنبه، 29 ژانویه 2014، نسخه جدیدی از Apigee Edge را منتشر کردیم.
اگر سؤالی دارید، به پشتیبانی مشتری Apigee بروید.
این نسخه حاوی ویژگی ها و رفع اشکال از نسخه های ابری زیر است:
ویژگی ها و پیشرفت های جدید
- OAuth 2.0 ویژگی های سفارشی را در توکن ها به روز می کند
یک خط مشی جدید "Set OAuth v2.0 Info" به شما امکان می دهد ویژگی های سفارشی را در نشانه های OAuth 2.0 به روز کنید.
http://apigee.com/docs/api-services/content/set-oauth-tokens-attributes-using-setoauthv2info - به روز رسانی خط مشی OAuth 1.0a
این نسخه شامل به‌روزرسانی‌های زیر برای خط‌مشی OAuth 1.0a است:- همانند توکن‌های OAuth 2.0، اکنون می‌توانید ویژگی‌های سفارشی را روی نشانه‌های OAuth 1.0a تنظیم کنید.
- یک عملیات GenerateVerifier جدید به شما امکان می‌دهد یک تأییدکننده OAuth 1.0a (شبیه به کد مجوز در OAuth 2.0) ایجاد و برگردانید.
- اطلاعات SSL در متغیرهای جریان
Apigee Edge اکنون به شما امکان انتشار و دسترسی به اطلاعات SSL در متغیرهای جریان را می دهد. با تنظیم یک ویژگی جدید "propagate.additional.ssl.headers" در یک ProxyEndpoint، به همان اطلاعات SSL موجود در وب سرور آپاچی دسترسی خواهید داشت.
http://apigee.com/docs/api-services/api/variables-reference - هدرهای JMS به عنوان هدر HTTP
همه سرصفحه‌های JMS اکنون به عنوان سرصفحه HTTP برای پردازش پایین‌دست منتشر می‌شوند. - به روز رسانی ماژول Node.js
ماژول داخلی Node.js Apigee برای شامل ماژول های زیر به روز شده است: argo 0.4.9، async 0.2.9، express 3.4.8، underscore 1.5.2، usergrid 0.10.7، volos-cache-memory 0.0.3 ، volos-oauth-apigee 0.0.2، volos-quota-apigee 0.0.2. - نقش های سفارشی در رابط کاربری مدیریت - بتا
علاوه بر نقش‌های کاربری موجود «کاربر تجاری»، «مدیر عملیات»، «مدیر سازمان» و «کاربر»، این نسخه شامل یک ویژگی بتا است که به شما امکان می‌دهد نقش‌های سفارشی را در رابط کاربری مدیریت ایجاد کنید. با استفاده از نقش های سفارشی می توانید دسترسی به ویژگی های مختلف Edge را کنترل کنید. - نصب کننده Advanced API Services (App Services سابق).
Apigee Edge Advanced API Services (که قبلاً App Services بود) اکنون برای استفاده در محل در دسترس است. نصب کننده Edge موجود به شما امکان می دهد خدمات API پیشرفته را در محیط داخلی خود مستقر و پیکربندی کنید. - نصب کننده کسب درآمد از خدمات توسعه دهنده (که قبلاً خدمات درآمدزایی نامیده می شد).
قابلیت کسب درآمد بخشی از خدمات توسعه دهنده Edge است. نصب کننده داخلی Edge اکنون دارای یک نصب کننده افزایش یافته و یکپارچه کسب درآمد است. کسب درآمد به یک مجوز پولی اضافی نیاز دارد. - چند پردازنده پیام در یک میزبان واحد - نصب بی صدا
این پیشرفت از توپولوژی استقرار چندین پردازنده پیام نصب شده بر روی یک میزبان پشتیبانی می کند، که نیاز به اتصال هر پردازشگر پیام به یک آدرس IP خاص دارد. اکنون می‌توانید یک تنظیم ویژگیBIND_ON_ALL_INTERFACES=nرا در فایل پیکربندی نصب بی‌صدا اضافه کنید، که باعث می‌شود یک پردازشگر پیام به آدرس IP خاصی که توسط ویژگیHOSTIPدر همان فایل مشخص شده است گوش دهد. برای اطلاعات بیشتر درباره این ویژگی، و درباره پیکربندی نصب بی‌صدا، راهنمای نصب و پیکربندی کیت استقرار Apigee در محل را ببینید. - به روز رسانی JMS
این نسخه شامل به روز رسانی های مختلف برای پشتیبانی از JMS Apigee است، از جمله:- همه سرصفحه‌های JMS اکنون به عنوان سرصفحه HTTP برای پردازش پایین‌دست منتشر می‌شوند.
- اکنون می توانید ExpiryTime و DeliveryMode را برای پیام های قرار داده شده در ResponseQueue که توسط پراکسی JMS استفاده می شود، مشخص کنید. تمام سرصفحه‌های HTTP که با سرصفحه‌های استاندارد JMS مطابقت دارند «همانطور که هست» تنظیم می‌شوند و سایر سرصفحه‌های HTTP به‌عنوان ویژگی‌های JMS در پیام پاسخ مورد استفاده توسط پراکسی JMS تنظیم می‌شوند.
اشکالات رفع شد
| موضوع | توضیحات |
|---|---|
| مجوزهای نقش سفارشی | مجوزهایی که با استفاده از نقش های سفارشی تنظیم شده اند اکنون همانطور که انتظار می رود کار می کنند. |
| تجزیه و تحلیل تاخیر API | در یک جریان پراکسی API، زمانی که تماس با سیستم هدف منجر به مهلت زمانی می‌شود (مانند مهلت زمانی خواندن HTTP)، زمان‌های تأخیر هدف در تجزیه و تحلیل API گنجانده می‌شود. |
| ویژگی «نوع» روی خط‌مشی‌ها | ویژگی "type" اکنون در همه سیاست های Apigee به درستی عمل می کند. |
| OAuth 2.0 توکن ها را باطل می کند | عملکرد توکن‌های باطل‌کننده برای خط‌مشی‌های Apigee OAuth 2.0 اکنون با مشخصات OAuth مطابقت دارد. هنگام تنظیم پارامتر "token" دیگر نیازی به ارائه "نوع" ندارید. |
| RBAC با نقشه های کلید/مقدار | کنترل دسترسی مبتنی بر نقش اکنون برای نقشه های کلید/مقدار ایجاد شده در سطح محیط کار می کند. |
| فرمت پاسخ خط مشی OAuth 1.0a | هنگام درخواست به یک API با خط مشی OAuth 1.0a، پاسخ اکنون در قالب سرصفحه Accept برگردانده می شود. |
مسائل شناخته شده
| موضوع | توضیحات |
|---|---|
| درخواست HTTP 1.0، پاسخ HTTP 1.1 | این مشکل شامل سناریویی است که در آن یک کلاینت با استفاده از HTTP 1.0 درخواستی را با ویژگی content-length در هدر ارسال می کند، اما سرویس backend برای استفاده از HTTP 1.1 پیکربندی شده است و به جای آن یک ویژگی transfer-encoding را برای رمزگذاری تکه ای برمی گرداند. برای مدیریت موفقیت آمیز این سناریو، می توانید با استفاده از خط مشی AssignMessage، ویژگی transfer-encoding را از پاسخ HTTP 1.1 حذف کنید. در خط مشی زیر، که به جریان پاسخ پراکسی API متصل می شود، ویژگی transfer-encoding از هدر HTTP حذف می شود، که به مشتری امکان می دهد پاسخ را بدون تکه دریافت کند. <AssignMessage name="RemoveChunkedEncoding"> <AssignTo createNew="false" type="response"></AssignTo> <حذف> <سرصفحه ها> <Header name="Transfer-Encoding"/> <Header name="transfer-encoding"/> </Headers> </Remove> <IgnoreUnresolvedVariables>نادرست</IgnoreUnresolvedVariables> </AssignMessage> |