کارگزاران سرویس SmartObject سفارشی

شما می توانید از K2 SmartObjects به عنوان "لایه دسترسی به داده های انتزاعی" فکر کنید که داده ها و خدمات را از ارائه دهندگان (مانند بانکهای اطلاعاتی SQL ، لیست های SharePoint و غیره) در برنامه های (مانند گزارش ها ، جریان کار و رابط های کاربر) در معرض نمایش قرار می دهد. SmartObjects در اصل "لایه میانی" بین منابع داده و برنامه هایی است که به داده ها نیاز دارند. K2 تعدادی "اتصالات" استاندارد (معروف به "کارگزاران سرویس") را ارائه می دهد که می تواند سیستم های LOB مشترک (مانند پایگاه داده های SQL ، پایگاه داده های اوراکل ، دایرکتوری فعال ، شیرپوینت ، Microsoft CRM و بسیاری موارد دیگر) را به عنوان SmartObjects در معرض نمایش بگذارد ، اما این استمطمئناً با نوشتن کارگزاران خدمات سفارشی که با سایر سیستم های LOB ادغام می شوند ، می توان مجموعه استاندارد کارگزاران را گسترش داد. SmartObjects مکانیسم ارجح برای ادغام با سیستم های LOB است و بنابراین نوشتن کارگزاران خدمات سفارشی برای اتصال به سایر سیستم هایی که توسط K2 خارج از جعبه پشتیبانی نمی شوند ، بسیار معمول است.

SmartObjects به عنوان یک مترجم (یا "آداپتور") عمل می کند که "زبان" پیچیده سیستم LOB را می گیرد و داده ها و روش ها را به یک رابط کاربری ثابت و قابل درک تبدیل می کند که مصرف کنندگان می توانند درک کنند. در داخل ، این امر با استفاده از "اتصالات" خاص سیستم به نام کارگزاران سرویس و در معرض نمایش آن به عنوان اشیاء خدماتی حاصل می شود ، که می تواند برای مونتاژ SmartObjects استفاده شود که به نوبه خود در فرم ، گردش کار و گزارش ها استفاده می شود.

SmartObjects توسط سرور K2 اجرا می شود. در اصل ، سرور K2 به عنوان "موتور" عمل می کند که هنگام اجرای یک SmartObject از طریق کارگزار سرویس پرس و جو می کند. در حالی که مطمئناً می توانید در بسیاری از برنامه های مصرف کننده از SmartObjects استفاده یا "تماس بگیرید" ، این برنامه نیست که پردازش واقعی را برای بازیابی داده ها از سیستم اساسی انجام دهد: این کار توسط سرور K2 عملکرد است. سرور K2 داده های SmartObject را ذخیره نمی کند. این بدان معنی است که K2 همیشه هر زمان که SmartObject اجرا شود ، آخرین داده ها را از ارائه دهنده بازیابی می کند.

کارگزاران سرویس با ایجاد یک کتابخانه کلاس . NET اجرا می شوند که منابع منابع را ارجاع می دهد. smartobjects. service. servicesdk. dll و سپس به ارث می برد و گسترش می دهد. کتابخانه کلاس تمام منطق لازم را برای افشای اشیاء ارائه دهنده به عنوان اشیاء خدمات و رسیدگی به تمام تعامل با ارائه دهنده اجرا می کند. هنگامی که مونتاژ کدگذاری و ساخته شده است ، پرونده . DLL حاصل را برای هر یک از سرورهای فیزیکی K2 در محیط خود کپی می کنید ، و سپس از یک ابزار یا ابزار K2 برای ثبت کارگزار با محیط K2 استفاده می کنید و به عنوان مثال (ها) خدمات ایجاد می کنید. برای کارگزار

بازار K2 در سایت جامعه K2 تعدادی از کارگزاران خدمات توسعه یافته و مشترک در جامعه دارد که اغلب شامل کد منبع کامل است. در حالی که این کارگزاران توسط K2 ارائه نشده و پشتیبانی نمی شوند ، ممکن است در صورت نیاز به ادغام با یک فناوری خاص ، کارگزاران خدمات موجود را مرور کنید. شخص دیگری ممکن است قبلاً یک کارگزار نوشته باشد که می توانید بارگیری و استفاده کنید.

دو روش اصلی برای ایجاد کارگزاران سرویس وجود دارد: کارگزاران سرویس استاتیک یا پویا استاتیک (شرح داده شده)

کارگزاران سرویس استاتیک (توصیف شده) هنگامی استفاده می شوند که طرح اصلی ارائه دهنده به طور مکرر تغییر نمی کند. یک کارگزار استاتیک را به عنوان چیزی که اشیاء خدمات را توصیف می کند ، فکر کنید ، زیرا همیشه می داند طرح ارائه دهنده چگونه به نظر می رسد. در اینجا مثالی آورده شده است: فرض کنید شما یک کتابخانه کلاس در سازمان خود دارید که اطلاعات منطقه زمانی را در معرض نمایش قرار می دهد. این شیء TimeZone دارای خواصی مانند نام ، Utcoffset و مخفف و روش هایی مانند Read Timezone و List Timeastones است. ما انتظار نداریم که تعریف یا طرحواره شیء منطقه زمانی تغییر کند. حال تصور کنید که ما می خواستیم یک کارگزار سرویس ایجاد کنیم که این شیء منطقه زمانی سفارشی را در معرض نمایش قرار دهد تا بتوانیم SmartObjects را برای TimeZones ایجاد کنیم. از آنجا که طرح شیء منطقه زمانی ما هرگز تغییر نمی کند ، ما می توانیم یک کارگزار سرویس استاتیک ایجاد کنیم که منطقه زمانی را به عنوان یک شیء خدمات توصیف می کند. در اصل ، توضیحات شیء سرویس در کد کارگزار سرویس کدگذاری شده است.

کارگزاران سرویس پویا (کشف شده) وقتی می خواهیم یک کارگزار قابل استفاده مجدد ایجاد کنیم که می تواند نمونه های مختلف همان فناوری را در معرض دید قرار دهد ، استفاده می شود. آنها پویا هستند زیرا کارگزار هنگام ثبت نام یا تازه کردن کارگزار ، طرح ارائه دهنده را کشف می کند. در اینجا مثالی آورده شده است: فرض کنید می خواستید یک کارگزار سرویس ایجاد کنید که بتواند با پایگاه داده های MySQL در تعامل باشد. کارگزار همیشه با همان فناوری (MySQL) تعامل خواهد داشت ، اما ما نمی توانیم پیش بینی کنیم که طرح اصلی یک نمونه خاص از یک پایگاه داده MySQL چگونه خواهد بود. بنابراین شما باید یک کارگزار سرویس پویا ایجاد کنید که در صورت ثبت یا تازه کردن نمونه خدمات ، نمونه خاصی از یک پایگاه داده MySQL را پرس و جو کند. فرآیند Discovery از نوعی پرس و جو برای تعیین جداول ، نمودارها و رویه های موجود در پایگاه داده MySQL استفاده خواهد کرد و سپس این موارد را به صورت شیء خدمات توصیف می کند.

قبل از ایجاد کارگزاران خدمات سفارشی ، بسیار مهم است که اصطلاحاتی را که در معماری SmartObject استفاده می شود ، نحوه عملکرد اجزای با هم و نقش هر مؤلفه را درک کنید.

نمودار زیر معماری مفهومی SmartObjects را نشان می دهد. به متن قرمز و ایتالیایی توجه ویژه ای داشته باشید: این اصطلاحاتی است که شما باید آنها را درک کنید. ما هر اصطلاح را با جزئیات بیشتر به دنبال نمودار شرح می دهیم.

بیایید نمودار نمونه خود را بگیریم و اجزای SmartObjects را تجزیه کنیم:

واسطه

یک کارگزار سرویس یک فایل . dll است که شامل تمام کد لازم برای تعامل با یک ارائه دهنده خاص است. به طور معمول ، این مونتاژ به API یا سرویس در معرض ارائه دهنده اشاره می کند ، و حاوی کدی است که اشیاء ارائه دهنده را به K2 به روشی ثابت کشف می کند و یا توصیف می کند. در برخی شرایط ، کارگزار خدمات همچنین ممکن است منطق را برای رسیدگی به امنیتی که توسط API ارائه دهنده مورد نیاز است ، پیاده سازی کند. در اصل ، وظیفه کارگزار سرویس "ترجمه" اشیاء بومی ارائه دهنده به اشیاء خدمات (و برعکس) و فراخوانی روشهای مختلف در API ارائه دهنده در زمان اجرا است.

از آنجا که کارگزار سرویس شامل تمام کد لازم برای تعامل با یک ارائه دهنده است ، این تنها موردی است که شما می خواهید در هنگام قرار گرفتن برخی از سیستم های دیگر به عنوان K2 SmartObjects ، باید پیاده سازی کنید. تا زمانی که کارگزار رفتار لازم مورد نیاز کلاس پایه ServiceAssemblyBase را از کارگزار سرویس SDK پیاده سازی کند ، در کلیه لایه های دیگر قابل استفاده خواهد بود (نوع خدمات ، نمونه خدمات و اشیاء خدمات)

شما می توانید به همان اندازه کارگزاران سرویس در یک محیط K2 مطابق نیاز داشته باشید ، اما توجه داشته باشید که پرونده فیزیکی . dll (و هرگونه وابستگی که قبلاً در سرور K2 هدف وجود ندارد) باید در آن کپی شودهر یکسرور K2 فیزیکی در محیط شما.

کارگزاران خدمات معمولاً برای افشای یک فناوری خاص نوشته می شوند. در نمودار مثال ما ، ما دو واسطه خدمات مختلف داریم: SQL Broker. dll شامل تمام منطق لازم برای تعامل با پایگاه داده های Microsoft SQL است ، در حالی که Ad Broker. dll می داند که چگونه با API های دایرکتوری فعال مایکروسافت تعامل داشته باشد.

سرویس کارگزار DLL در [پرونده های برنامه] K2 Blackpearl ServiceBroker Directory در سرورهای برنامه K2 ساکن است. تصویر زیر محل کارگزاران را نشان می دهد

نوع سرویس

تنها هدف از نوع سرویس ثبت یک کارگزار سرویس . dll در یک محیط K2 است تا بتواند از آن برای ثبت نمونه های خدمات استفاده شود. مدیران K2 از ابزارهایی مانند فضای کاری K2 یا ابزار SmartObject Tester برای ثبت یک کارگزار سرویس . dll با یک محیط K2 استفاده می کنند. به طور معمول ، هر کارگزار سرویس . dll فقط یک نوع خدمات مرتبط با آن را دارد.

توجه داشته باشید که فقط لازم است یک کارگزار . dll یک بار با هر محیط منطقی K2 ثبت شود ، زیرا ثبت نام نوع سرویس در پایگاه داده K2 ذخیره می شود ، سایر سرورهای فیزیکی K2 که به همان پایگاه داده مراجعه می کنند ، به طور خودکار در مورد کارگزار خدمات می دانند. قبل از شروع اضافه کردن نمونه های خدماتی از آن نوع ، باید نوع سرویس را با یک محیط K2 ثبت کنید.

تصویر زیر یک لیست معمولی از انواع خدمات در یک محیط K2 را نشان می دهد ، در این حالت ما از ابزار تستر سرویس SmartObject برای کشف انواع خدمات موجود استفاده کردیم.

نمونه خدمت

هنگامی که یک کارگزار خدمات به عنوان یک نوع سرویس ثبت شد ، مدیران K2 می توانند یک یا چند نمونه خدمات را برای آن نوع سرویس ایجاد کنند. یک نمونه خدمات در اصل یک نمونه پیکربندی شده از یک کارگزار است و حاوی مقادیر مختلف پیکربندی است که توسط کارگزار مورد نیاز است. مقادیر پیکربندی می تواند شامل مقادیری باشد که کارگزار برای اتصال به ارائه دهنده (به عنوان مثال ، نام سرور یا URL) و شاید مقادیر پیکربندی اضافی که توصیف می کند که چگونه کارگزار باید رفتار کند. یکی دیگر از تنظیمات مهم برای یک نوع سرویس ، تنظیم حالت تأیید اعتبار است: این اعتبار کاربر را تعیین می کند که به کارگزار سرویس زیرین منتقل می شود.

در نمودار ، توجه داشته باشید که دو مورد خدمات برای نوع خدمات SQL وجود دارد. هر نمونه خدمات حاوی مقادیر پیکربندی لازم برای کارگزار به ترتیب با پایگاه داده های HR و مالی SQL است.

تصویر زیر نمونه های خدمات و پیکربندی نمونه خدمات را نشان می دهد ، در این حالت ما از ابزار تستر سرویس SmartObject برای کشف نمونه های خدمات موجود استفاده کردیم.

هنگامی که یک نمونه خدمات ثبت شده یا پیکربندی شده است ، اقدامات زیر انجام می شود:

1. نام و توضیحات مناسب برای نمونه خدمات ارائه شده است.
2. نمونه به یک شناسه GUID اختصاص داده می شود
3. پیکربندی خدمات مناسب مانند نام سرور ، جزئیات اتصال و جزئیات امنیتی ارائه شده است.
4. کارگزار سرویس طرحواره ارائه دهنده اصلی را کشف یا توصیف می کند و طرحواره را به عنوان اشیاء خدمات به پلت فرم K2 توصیف می کند.

در هنگام ثبت نام ، نمونه های خدماتی به یک راهنما اختصاص داده می شوند. SmartObjects به این راهنماها اشاره خواهد کرد ، بنابراین هنگامی که شما نیاز به انتقال SmartObject از یک محیط K2 به محیط دیگر دارید (به عنوان مثال توسعه به تولید) بسیار مهم است که نمونه خدمات برای نمونه خدمات که SmartObject از آن استفاده می کند در هر دو محیط یکسان باشد، حتی اگر پیکربندی نمونه سرویس بین محیط ها متفاوت باشد.

موضوع خدمات

اشیاء خدمات در اصل بازنمایی های "ترجمه" از نهادها در ارائه دهنده اساسی هستند. تحت پوشش ، اشیاء خدمات فقط بازنمایی XML از اشخاص موجود در ارائه دهنده هستند و هیچ منطق پردازش ندارند.

اشیاء خدمات خصوصیات و روشهای اشیاء را در یک ارائه دهنده به عنوان انواع روش SmartObject سازگار و انواع خاصیت در معرض دید قرار می دهند. این وظیفه کارگزار سرویس است که نقشه برداری لازم را بین انواع ارائه دهنده و انواع مورد استفاده SmartObjects انجام دهد.

اشیاء خدمات همیشه به یک نمونه خدمات گره خورده اند ، زیرا نمونه خدمات طرحواره ای را که توصیف شیء خدمات است ، در معرض دید قرار می دهد. توجه داشته باشید که اشیاء خدمات به طور خودکار توسط یک کارگزار سرویس ایجاد می شوند و نمی توانند به صورت دستی اصلاح شوند. علاوه بر این ، اشیاء خدماتی فقط توسط SmartObjects قابل مصرف هستند: طراحان باید قبل از مصرف سرویس در یک گردش کار ، گزارش یا رابط کاربری ، SmartObjects ایجاد کنند که به یک یا چند سرویس خدمات گره خورده باشند.

یک نمونه سرویس معمولاً شامل یک یا چند شیء سرویس است. به عنوان بخشی از ترجمه، کارگزار خدمات، اشیاء موجود در ارائه دهنده را به Objects خدمات تبدیل می کند. ویژگی های اشیاء به ویژگی های شیء سرویس و متدهای موجود در اشیاء ارائه دهنده به روش های شیء سرویس تبدیل می شوند. بخش بزرگی از پیاده سازی یک کارگزار خدمات مشتری، نوشتن کدی است که این «ترجمه» را انجام می دهد تا مصنوعات سیستم زیربنایی را به عنوان اشیاء خدمات نشان دهد.

نمونه تصویر زیر را در نظر بگیرید. در اینجا یک Service Object به نام [Denallix].[Assets] داریم که نشان دهنده جدول Assets در پایگاه داده Denallix است. Service Broker ستون های جدول پایگاه داده SQL را به Properties تبدیل کرد و روش های شیء سرویس را برای عملیات معمولی CRUD ایجاد کرد که ممکن است در برابر جدول پایگاه داده SQL انجام شود. در زمان اجرا، Service Broker متدهای شیء سرویس را به عبارات معادلی تبدیل می کند که می توانند روی یک سرور SQL اجرا شوند و اطلاعات را از سرور SQL در قالبی برمی گرداند که بتواند توسط سرویس های آبجکت مصرف شود. از این رو یک کارگزار سرویس به عنوان «آداپتور» یا «مترجم» توصیف می شود: روش ها و ویژگی های شیء سرویس را به عباراتی ترجمه می کند که برای تعامل با APIهای سیستم زیربنایی استفاده می شوند.

Smart Object

آخرین مرحله برای نمایش یک ارائه دهنده در معرض مصرف کنندگان، ایجاد SmartObject هایی است که به یک یا چند شیء خدماتی ارجاع می دهند. این کار را می توان توسط مدیران K2 یا طراحان/توسعه دهندگان K2 با استفاده از ابزارهای K2 مانند Service Object Tester یا ابزارهای طراحی مانند K2 Studio و K2 Designer انجام داد. در نهایت، این SmartObject ها در مصرف کنندگان مورد استفاده قرار می گیرند، و شما متوجه خواهید شد که مصرف کننده برای استفاده از SmartObject نیازی به دانستن چیزی در مورد ارائه دهنده اصلی ندارد.

ایجاد SmartObject در K2 Studio و ارجاع به روش Service Object: