RowSet rowSet = (RowSet)row.getAttribute("GuaranteeLOV1");
rowSet.setNamedWhereClauseParam("Bind_CustomerId", new Number(customerId));
منبع : AdfTips.com (نویسنده : مورالی پاپانا)
نکات مربوط به این فرم عبارتند از :
1.پیاده سازی متدها در VO مربوطه بجای AM برای کوچک تر شدن سایز AM
2.پیاده سازی LOV های مرتبط (cascade lov) , با استفاده از راهنمایی وبلاگ آرامامو
3.گرفتن confirmedId از instance قراردادی که از روی defenition مربوطه در کنسول حرفه ای وبلاجیک ایجاد شده است.
4.در اپلیکیشن نوع A که اینترفیس آن فاقد بی پی ام می باشد,پارامتر ورودی (confirmedId) بصورت دستی مقداردهی میشود.
5.در اپلیکیشن نوع B که اینترفیس آن مبتنی بی پی ام می باشد,پارامتر ورودی (confirmedId) از payload دریافت میشود.
UI اولیه مربوط به فرم قرارداد بصورت زیر می باشد:
بالاخره بعد از 4 روز تونستم یکی از مشکلات OracleBPM رو حل کنم و علتش هم این بود که علیرغم حذف شدن لایه مدل در اپلیکشن BPM , فایلهای اون بر روی سیستم فایل موجود بود و فایل با پسوند CPX که وظیفه Bind کردن رو داشت میرفت و به لایه مدل حذف شده رفرنس میداد. اینجوری بود که میرفت UI رو از لایبراری adf-jar میگرفت و model رو از پروژه مدل حذف شده. در صورتیکه باید model رو هم از adf-jar همین مسأله باعث شد که کار پیدا کردن خطا اینقدر طولانی باشد. در خاتمه با حذف کردن لایه مدل حذف شده از روی سیستم فایل , کل پروژه با موفقیت deploy شد.
البته پیدا شدن این باگ یه خوبی دیگه هم داشت و اون اینکه , پروسه تولید اپلیکیشن رو واسه خودم استاندار و راحتتر کردم و در زیل به آن اشاره میشود :
برای راحتی کار تست و تولید دو تا اپلیکیشن داریم که اپلیکیشن اول خوراک دومی رو تهیه میکنه :
مشخصات پروژه های داخل اپلیکیشن A :
1.لایه مدل
2.لایه ویو (مبتنی بر لایه مدل)
مشخصات پروژه های داخل اپلیکیشن B :
1.لایه BPM
2.لایه ویو (مبتنی بر HumanTaskflow لایه BPM که از taskflow های لایه ویو اپلیکیشن A نیز میتوان در داخل آن استفاده کرد)
نحوه تست و تولید اپلیکیشن A :
در لایه مدل میتوان Entity Object ها و View Object ها را با استفاده از اپلیکیشن Swing ایی که بر روی Application Module قابل اجرا شدن می باشد تست و تولید کرد.
(در خاتمه عملیات تولید لایه مدل فراموش نکنید که کانکشن Application Module از نوع JDBC DataSource باشد و از جنس JDBC URL نباشد)
در لایه ویو میتوان taskflow های مورد نیاز را بصورت standalone و با استفاده از weblogic داخلی jdeveloper تست و تولید کرد.
(قبل از deploy کردن اپلیکیشن خودمون به weblogic داخلی jdeveloper , فراموش نکنید که با استفاده از کنسول معمولی weblogic داخلی jdeveloper از تعریف jdbc/datasource استفاده شده در لایه مدل اطمینان حاصل نمایید)
پس از اطمینان از صحت عملکرد taskflow های اپلیکیشن A , کل اپلیکیشن را در یک کتابخانه از نوع ADF-JAR دیپلوی میکنیم. مزیت این کار اینه که: میتوان از کتابخانه های نوع ADF-JAR در سایر پروژه های ADF ایی استفاده کرد.
نحوه تست و تولید اپلیکیشن B :
لایه BPM را مطابق بیزینسی (خرید , فروش , تولید , حسابداری , انبارداری , تسهیلات , ...) که در حال کار بر روی آن می باشیم ایجاد میکنیم
در لایه مدل , صفحاتJSF را بر اساس BPM Human Taskflow لایه قبلی ایجاد میکنیم و اگه خواستیم میتوانیم صفحات JSF تولید شده را با استفاده از Taskflow ها و بیزینس آبجکت هایی که داخل adf-jar می باشد , سفارشی نماییم.
برای تست و تولید اپلیکیشن B , امکان اجرای آن بصورت standalone وجود ندارد و باید کل پروژه رو که بصورت یک فایل با پسوند ear می باشد به SOA Server , دیپلوی کرد و با لاگین کردن به BPM Workspace امکان مشاهده نتیجه فراهم میشود.
موتور گردش کار OracleBPM شامل ابزارهای زیر می باشد :
یه Engine داره که روی بانک اطلاعاتی Oracle نصب میشه
یه کارتابل داره که روی اپلیکیشن سرور weblogic نصب میشه و مخصوص EndUser هاست.
یه کنسول معمولی weblogic داره که میتوان jdbc/datasource های استفاده شده در برنامه رو تعریف کرد و بر روی نصب کتابخانه ها و اپلیکیشن های مورد نیاز نظارت کرد و میتوان کاربر های جدید رو تعریف کرد.
یه کنسول حرفه ای weblogic داره که میتوان وب سرویس های BPM رو تست کرد.
یه ابزار داریم به اسم jdeveloper که واسه تعریف , اصلاح فرایندهای جدید از اون استفاده میکنیم.
فکر کنم با استفاده از این روش به اهداف پیاده سازی BPM نزدیک بشیم که میگه :
در صورتیکه BPM بطور صحیح پیاده سازی بشه میتوان با کمترین هزینه , نرم افزار رو با بیزینس منطبق کرد.
نکته مهم :
چون لایبراری های استفاده شده در اپ A , پس ازتبدیل آن به adf-jar به داخل آن منتقل نمیشوند باید این لایبراری ها بصورت دستی به اپ B اضافه شوند.
امیر حسین میثمی