به بررسی نکات و مدل داده مجازی و مدل داده‌ سیستم‌های ERP می‌پردازم که به شما کمک می‌کند مدل داده‌ سیستم‌های ERP توسط دکتر روح اله آرزو

به نام خدا

من، دکتر روح‌اله آرزو، با سال‌ها تجربه در زمینه مدیریت کسب‌وکار و فناوری اطلاعات، بر این باورم که داشتن سیستم‌های ERP موفق به عنوان یک ابزار کلیدی در دنیای دیجیتال امروز، می‌تواند به رشد و موفقیت هر کسب‌وکار کمک کند. در این مقاله، به بررسی نکات و مدل داده مجازی و مدل داده‌ سیستم‌های ERP می‌پردازم که به شما کمک می‌کند مدل داده‌ سیستم‌های ERP موفقی راه‌اندازی کنید.

این فصل بر روی مدل داده مجازی (VDM) تمرکز دارد که یک لایه معنایی برای دسترسی به داده های برنامه SAP S/4HANA است. بنابراین، مدل داده‌های رمزی و پیچیده به روشی قابل درک و قابل استفاده مجدد برای توسعه‌دهندگان برنامه‌ها و چارچوب‌های مختلف محصور شده و در معرض دید قرار می‌گیرد. VDM شامل نماهای Core Data Service (CDS) است. داده کسب و کار، که در جداول پایگاه داده انتزاعی ذخیره می شوند، به روشی تجاری-محور در معرض دید قرار می گیرند. این امکان، درک و مصرف آسانتر داده تجاری مورد نیاز را فراهم می کند. کاربران نهایی می توانند با استفاده از نماهای CDS منتشر شده به داده مورد نیاز دسترسی پیدا کنند. آنها می توانند نماهای سفارشی را که بر روی نماهای موجود ارائه شده توسط SAP ساخته شده اند، تعریف کنند. با VDM، یک مدل داده قابل فهم، جامع و قابل اجرا در معرض دید قرار می گیرد و آماده استفاده در برنامه های کاربردی تحلیلی و تراکنشی و رابط های خارجی است.

الزامات کسب و کار

مدل داده‌ سیستم‌های ERP از لحاظ تاریخی رشد کرده است و ده هزار جدول را با شبکه‌های پیچیده روابط و نام‌های حوزه رمزی پوشش می‌دهد. بنابراین، کاوش و مصرف مدل داده توسط توسعه دهندگان، مشتریان و شرکا دشوار است. با توجه به این شرایط اجرای فرآیندهای کسب و کار منجر به تلاش زیاد و دانش بسیار تخصصی می شود. برای حل این چالش، یک لایه معنایی متناظر در بالای مدل داده مورد نیاز است تا پیچیدگی را پنهان کند و امکان دسترسی قابل فهم و کارآمد برای انسان به داده های تجاری را فراهم کند. امروزه حتی کاربران نهایی انتظار دارند که داده های مورد نیاز خود را مانند یک سیستم هوش تجاری خوکار جستجو کنند. با این حال، دستیابی به این امر در سیستم‌های ERP به دلیل موانع مدل داده از نظر یافتن داده‌ها، ارائه زمان‌های پاسخ-پرس و جو کافی و درک ساختارها دشوار است. طراحی یک مدل داده مجازی این مسائل را حل می کند و همچنین به کاربران نهایی امکان دسترسی به داده های مورد نیاز خود را می دهد.

قابلیت راه حل

مدل داده مجازی (VDM) نشان دهنده مدل داده معنایی یک برنامه تجاری در SAP S/4HANA است. هدف ساده کردن پیچیدگی و ارائه داده های تجاری به گونه ای است که درک و مصرف آن را برای توسعه دهندگان و کاربران نهایی آسان نماید. این داده ها را از جداول پایگاه داده زیربنایی انتزاع می کند و آن ها را بر اساس معناشناسی تجاری در معرض دید قرار می دهد. برای اطمینان از این امر، دو شرط باید برقرار شود:

نمای پایگاه داده به پشتیبانی بیشتری از SQL نیاز دارند. مواردی مانند، برای مثال، جستجوی آخرین رکورد، چرخش داده ها، تقسیم داده ها برای پردازش متفاوت، و بررسی کیفیت داده ها را نمی توان در یک پرس و جوی SQL انجام داد. نماها باید داده ها را در ثانیه های فرعی برگردانند. اگر عملکرد خوبی ارائه نشود از سیستم استفاده نمی شود.

مشتریان و شرکای SAP می توانند بر روی نماهای VDM منتشر شده توسعه دهند. VDM مدل و منبع داده را برای برنامه های کاربردی تراکنشی و تحلیلی و رابط های خارجی نشان می دهد. مزایای VDM یک مدل داده تجاری محور، قابل درک و غنی از معنایی، قابل استفاده مجدد و پایدار است.

خدمات داده اصلی (CDS)

مدل داده مجازی با استفاده از Core Data Services (CDS) پیاده سازی می شود. CDS به توسعه دهندگان کمک می کند تا مدل های داده معناداری ایجاد کنند. از SQL استفاده می کند و گسترش می دهد و امکان تعریف و مصرف این مدل های داده را در برنامه ها فراهم می کند. بهره وری، مصرف، عملکرد و قابلیت همکاری بهبود می یابد. CDS خانواده‌ای از زبان‌ها و سرویس‌های خاص دامنه برای تعریف و مصرف چنین مدل‌های داده معناداری است:

· زبان تعریف داده (DDL) برای تعریف مدل های داده دامنه معنادار و بازیابی آنها است. این ابزارهای بومی SQL را برای بهره وری بالاتر گسترش می دهند.

· زبان پرس و جو (QL) برای مصرف موجودی های CDS از طریق پلت فرمSQL تعبیه شده است. برای خواندن داده ها استفاده می شود.

· زبان کنترل داده ها (DCL) مجوزهایی را برای نماهای CDS تعریف و دسترسی به داده ها را کنترل می کند. با مفاهیم مجوز کلاسیک ادغام می شود.

· زبان دستکاری داده ها (DML) برای نوشتن داده ها استفاده می شود.

مدل های داده CDS به جای اینکه در سطح برنامه کاربردی باشد، در سطح پایگاه داده تعریف و مصرف می شوند. CDS قابلیت هایی فراتر از ابزارهای مدل سازی سنتی داده ها را ارائه می دهد. آنها از تعریف نماها با SQL پشتیبانی می کنند تا توسعه دهندگان بتوانند از ویژگی های SQL مانند JOIN، UNION، و بند WHERE استفاده کنند. روابط بین دیدگاه ها را می توان به عنوان تداعی مدل کرد. از نام مستعار می توان برای تغییر نام جداول با نام قابل فهم استفاده کرد. نماهای CDS همچنین از استفاده از حاشیه نویسی برای تعریف ابرداده پشتیبانی می کنند. به عنوان مثال، یک حاشیه نویسی می تواند تعریف کند که یک فیلد با نوع DateTime حاوی زمانی است که داده ها ایجاد شده یا آخرین بروز رسانی انجام شده است. سایر قابلیت‌های CDS مورد استفاده در VDM عبارتند از: پارامترها، وسعت دید، نوردهی آسان به عنوان سرویس‌های OData و چهارچوبی برای تعاریف رفتاری. حاشیه نویسی مدل داده مجازی امکان طبقه بندی نهادهای CDS را از نظر گزینه های قابل استفاده مجدد و محتوای ارائه شده آنها فراهم می کند. این طبقه بندی فقط برای ساختار داخلی SAP و تفسیر موجودی های CDS استفاده می شود. پیش بینی می شود که برای مثال با مرورگرهای مشاهده و سایر قابلیت ها که بر اساس مدل داده مجازی است تفسیر شود. اجاره مجدد نهادهای CDS برای مشتریان و شرکا توسط یک طبقه بندی داخلی اختصاصی اضافی از نهادها کنترل می شود.

CDS به طور کامل با ABAP، زبان برنامه نویسی اختصاصی SAP ادغام شده است. این در ABAP SQL تعبیه شده است، که منجر به درک ساده تر دستورات SQL می شود. نماهای CDS نیز با فرهنگ لغت داده ABAP (DDIC) یکپارچه شده است. ABAP DDIC شامل تمام ابرداده‌های مربوط به داده‌های موجود در سیستم SAP از جمله نماهای مختلف است. می توان از مجوزهای موجود ABAP استفاده کرد و از سیستم حمل و نقل ABAP استفاده می شود. شکل 20.1 اتصال سرور برنامه ABAP و پایگاه داده SAP S/4HANA را هنگام استفاده از رویکرد توصیه شده از بالا به پایین نشان می دهد. توسعه دهندگان می توانند در محیط ABAP خود کار کنند و همچنان از قدرت SAP S/4HANA استفاده کنند.

رویکرد بالا به پایین از تکنیک Code Pushdown استفاده می کند. کد Pushdown به این معنی است که محاسبات به جای سرور برنامه بر روی سیستم پایگاه داده انجام می شود. این فقط محاسباتی را که برای آنها منطقی است پایین می آورد. برای مثال، برای تعیین مقدار تمام موقعیت‌های فاکتورها، یک تابع تجمیع (در اینجا: SUM()) می‌تواند در پایگاه داده به جای محاسبه مجموع در یک حلقه در سرور برنامه استفاده شود. این منجر به بازیابی سریع داده ها و عملکرد و زمان پاسخ بهتر خود برنامه می شود. SAP ERP کلاسیک از سیستم های پایگاه داده مختلفی پشتیبانی می کرد که برای آنها یک انتزاع دسترسی به داده مربوطه مورد نیاز بود. بنابراین، داده های کسب و کار ابتدا از پایگاه داده به سرور برنامه منتقل شد، برای سوابق مربوطه حلقه زده شد و در نهایت پردازش شد. بنابراین، معمولا داده های بیشتری بین پایگاه داده و سرور برنامه در صورت لزوم رد و بدل می شد. علاوه بر این، عملیات فشرده داده بر روی سرور برنامه به جای پایگاه داده برای دستیابی به عملکرد بهتر اجرا شد. از آنجایی که SAP S/4HANA تنها از SAP HANA به عنوان پایگاه داده پشتیبانی می کند، بهینه سازی چشمگیری می تواند تحقق پیدا کند. برای هر نمای CDS تعریف شده در سطح ABAP یک نمای SQL مربوطه در SAP HANA تولید می شود. تمام عبارات SQL اعمال شده بر روی نماهای CDS به نمای SQL منتقل می شوند و برای عملکرد بهینه در سطح پایگاه داده اجرا می شوند. به عنوان مثال، در حالی که بررسی های مجوز در گذشته بر روی سرور برنامه انجام می شد، با SAP S/4HANA آنها با تقویت خودکار عبارات SQL با یک بند WHERE به سیستم پایگاه داده منتقل می شوند. در این بین چند ده هزار نمایش CDS در SAP S/4HANA در دسترس است زیرا تمام فرآیندهای تجاری از VDM برای دسترسی به داده های برنامه استفاده می کنند.در نتیجه، عملکرد همه آن فرآیندهای تجاری به طور سیستماتیک بهبود یافته است زیرا تمام دسترسی به داده ها به SAP HANA کاهش می یابد. نماهای CDS را می توان با دستورات SQL تعریف کرد اما می توان آنها را با SQLScript نیز کدگذاری کرد. برای این کار از رویه های ذخیره مدیریت شده ABAP (AMDP) استفاده می شود. AMDP ها فقط کلاس های ABAP هستند که به جای ABAP حاوی کد SQLScript هستند. در طول زمان اجرا، کدگذاری SQLScript برای عملکرد بهینه به SAP HANA پایین می‌رود. هر زمان که منطق نمای CDS بیش از حد پیچیده باشد که بتوان آن را با دستورات SQL بیان کرد، رویکرد اسکریپت شده اعمال می شود. از نظر مصرف هیچ تفاوتی بین نماهای CDS مبتنی بر SQL یا SQLScript وجود ندارد.

📷

نماهای CDS مهمترین نوع موجود CDS هستند. نماهای CDS منتشر شده آماده برای استفاده مجدد در VDM وجود دارد. مشتریان همچنین می توانند نماهای CDS سفارشی را تعریف کنند. به عنوان مثال، آنها می توانند به عنوان منبع داده در دستورات انتخاب ABAP استفاده شوند. شکل 20.2 مثالی برای نمای CDS در مورد اسناد فروش ارائه می دهد.

مجوز برای مشاهده CDS

نماهای CDS که حریم خصوصی داده‌های حساس را آشکار و از داده‌های مربوطه محافظت می‌کنند باید ایمن شوند. دسترسی به نماهای CDS را می توان محدود کرد و با نقش ها بیان می شود. یک مخزن به نام DCL Source نقش های CDS را تعریف می کند. نقش CDS برای یک یا چند نمای CDS اعمال می شود. شرایط دسترسی با کلمه کلیدی WHERE تعریف می شود و به عنوان یک فیلتر برای نمای CDS مربوطه عمل می کند. محدودیت های دسترسی به طور خودکار برای مستقیم انتخاب های ABAP SQL در نماهای CDS محافظت شده اعمال می شود. اگر یک نمای CDS دارای چندین قانون باشد، محدودیت‌های دسترسی به‌طور پیش‌فرض با یک OR منطقی ترکیب می‌شوند. همچنین می توان آن را به صراحت به عنوان جایگزینی DLC یا استفاده از حالت ترکیبی AND تعریف کرد. این بدان معناست که نتایج جستجوی یک نمای CDS را می توان با استفاده از DCL محدود کرد تا فقط کاربران دارای نقش متناظر بتوانند داده های برگشتی را بخوانند. توجه به این نکته مهم است که کنترل دسترسی CDS تنها در صورتی کار می کند که برنامه مستقیماً به نمای CDS محافظت شده دسترسی داشته باشد.

قراردادهای ثابت برای مشاهده CDS

نماهای CDS مبنایی برای تعریف یک VDM معنادار و افشای تمام داده های تجاری پایگاه داده SAP S/4HANA به روشی قابل درک است. آنها برای اهداف مختلف استفاده می شوند، به عنوان مثال، ایجاد یک رابط بین برنامه ها و افزونه ها در یک مجموعه و برای سیستم ها و برنامه های کاربردی راه دور. مشتریان می توانند از نماهای CDS منتشر شده توسط SAP برای ایجاد نماهای سفارشی خود استفاده کنند. برای انجام این توابع به طور قابل اعتماد، نماهای CDS باید بین دو ویژگی تعادل پیدا کنند:

انعطاف پذیری: نماهای CDS باید درجه خاصی از انعطاف پذیری را برای توسعه بیشتر ارائه دهند.

پایداری: ویژگی های معنایی و فنی باید به اندازه کافی ثابت نگه داشته شوند تا نماهای CDS پس از هر ارتقاء نیازی به تنظیم نداشته باشند.

نماهای CDS منتشر شده برای مدل نمای SAP S/4HANA یک مبنای پایدار برای سناریوهای توسعه مشتری فراهم می کند، به عنوان مثال، ایجاد نماهای سفارشی یا پرس و جوهای تحلیلی. آنها باید معیارهای پایداری خاصی را پشتیبانی کنند تا اطمینان حاصل شود که هنگام ارتقاء سیستم SAP S/4HANA، اشیاء ساخته شده سفارشی تحت تأثیر قرار نخواهند گرفت. SAP برای اطمینان از اینکه نماهای CDS منتشر شده وظایف خود را به طور قابل اعتماد انجام می دهند، سه قرارداد پایداری معرفی کرده است. هر قرارداد در مورد سناریوهای مصرف متفاوت دیدگاه های CDS اعمال می شود.

قرارداد گسترش فیلد کاربر کلیدی (C0)

قرارداد گسترش فیلد کاربر کلیدی تضمین می‌کند که تغییرات در نمای CDS، چهارچوب پسوندهای فیلد را نمی‌شکنند. کاربران کلیدی می توانند با استفاده از برنامه Custom Fields and Logic یک فیلد سفارشی اضافه کنند. مصرف کننده می تواند از فیلدهای افزونه مانند فیلدهای معمولی استفاده کند.

فقط نماهای CDS که SAP آن‌ها را به‌عنوان قابل توسعه تعریف کرده است، برای گسترش فیلد در برنامه موجود هستند.چهارچوب برنامه افزودنی عناصری هستند که برای گسترش فیلد کاربر کلیدی ثابت نگه داشته می‌شوند. C0 از طریق وضعیت API یک نمای CDS بیان نمی شود. در عوض، با انتشار یک نمای CDS در رجیستری گسترش تعریف می شود.

قرارداد داخلی سیستم (C1)

نماهای CDS را می توان برای استفاده داخلی سیستم یا برای استفاده از راه دور API منتشر کرد. اکثر نماهای CDS منتشر شده از قرارداد ثابت C1 برای استفاده داخلی پیروی می کنند. هدف قرارداد اطمینان از ثبات کافی است به طوری که نماهای CDS سفارشی پس از ارتقا به نسخه نرم افزار بعدی، به عنوان مثال، از SAP S/4HANA 1809 به SAP S/4HANA 1909، همچنان کار می کنند. فقط نماهای SAP منتشر شده برای قرارداد C1 در دسترس هستند. ابزارهای کلیدی کاربر برای برنامه های افزودنی مشتری چنین نماهای CDS دارای ویژگی های زیر هستند:

نماهایCDS منتشر شده برای استفاده داخلی سیستم با پیشوند I_ (نماهای رابط) یا C_ (نماهای مصرف) شروع می شوند. همه این نماهای رابط و مصرف از قرارداد C1 پیروی نمی کنند.

افزایش طول میدان مجاز است و باید توسط مصرف کنندگان تحمل شود.

آنها در چندین ابزار کلیدی کاربر، به عنوان مثال، مشاهده CDS سفارشی، فیلدهای سفارشی، و منطق و اشیاء تجاری سفارشی در دسترس هستند.

معیارهای اصلی ثبات برای نماهای CDS منتشر شده با C1 عبارتند از:

عدم حذف فیلدها

عدم تغییر نام فیلدها

تغییرات محدود در تایپ داده فیلدها

ثبات معنایی پردازش نما و فیلدها

پایداری حاشیه نویسی نمای انتخاب شده مربوط به پردازش داده ها

قرارداد API از راه دور (C2)

برخی از نماهای CDS باید توسط API های راه دور قابل دسترسی باشند. خدمات خارجی مانند OData این دسترسی از راه دور را امکان پذیر می کند. SAP چنین دیدگاه های CDS را برای قرارداد C2 منتشر می کند. نماها در ابزارهای کلیدی کاربر موجود نیستند. افزایش طول میدان امکان پذیر نیست. این باعث می شود عناصر بیشتری نسبت به قرارداد C1 برای استفاده داخلی ثابت بماند. مورد اصلی استفاده از نماهای API راه دور این است که آنها عملکردهای پایه پایگاه داده (به روز رسانی، بازیابی، حذف) را در سناریوهایی انجام می دهند که در آن برنامه ها با یک کلاینت خارجی تعامل دارند. پس از انتشار چنین دیدگاهی، تغییرات ناسازگار ممنوع است. در صورت لزوم باید نسخه‌های View جدید ایجاد و منتشر شود.

قراردادهای نامگذاری VDM

VDM بر اساس مجموعه ای از قوانین نامگذاری رایج است. قوانین زیر نام‌های ثابت و قابل توضیح را تضمین می‌کنند:

• نام ها باید دقیق باشند و یک موضوع را مشخص کنند. به عنوان مثال، یک سند سفارش فروش باید SalesOrder نامیده شود و نه ID یا Order.

• نام ها معنای تجاری یک موضوع را نشان می دهند.

• موضوعات مختلف باید نام های متفاوتی داشته باشند. اگر دو فیلد از یک نام استفاده کنند، به این معنی است که لیست‌های ارزش اصلی آنها مطابقت دارند.

• نام ها از اصطلاحات انگلیسی دو کلمه مرکب بدون فاصله با حرف اول بزرگ ایجاد می شوند. زیرخط فقط در موارد از پیش تعریف شده استفاده می شود. در صورت امکان باید از اختصارات خودداری شود. می توان از آنها برای ماندن در محدوده کاراکتر معین استفاده کرد. به عنوان مثال، Query را می توان به اختصار Qry نامید. این قوانین نام‌گذاری برای همه موجودیت‌های CDS و بخش‌های آنها، به عنوان مثال، نام‌های فیلد، پیوندها، پارامترها یا نماهای CDS اعمال می‌شود. الگوی اصلی برای View Names vdm است.

📷

ساختار مدل داده مجازی

نماهای DM از یک رویکرد لایه ای پیروی می کنند و در یک ساختار سلسله مراتبی سازماندهی می شوند. لایه‌های بالایی از بین لایه‌های یکسان یا پایین‌تر، ارتباط را انتخاب کرده و تعریف می‌کنند. لایه‌های پایین‌تر نمی‌توانند از بین لایه‌های بالایی تداعی را انتخاب یا تعریف کنند. نماهای VDM با استفاده از حاشیه نویسی ویژه CDS @VDM.viewType به لایه ها اختصاص داده می شوند. شکل 20.3 مجموعه نماهای VDM را نشان می دهد. دو لایه وجود دارد، لایه نمای رابط شامل نماهای ترکیبی و پایه و لایه نمای مصرف شامل نماهای مصرفی و نماهای API خارجی. لایه نمای رابط، نماهایی را برای استفاده مجدد فراهم می کند. نماهای مصرف و API خارجی بر اساس لایه های پایین تر و برای یک هدف مشخص ساخته شده اند. پاراگراف های زیر نماهای مختلف VDM را توضیح می دهند.

نماهای پایه

نماهای پایه پایین ترین سطح از مجموعه نمای VDM هستند و در بالای جداول پایگاه داده قرار می گیرند. آنها تنها نماهایی هستند که مستقیماً به جداول پایگاه داده دسترسی دارند که آنها را به مهمترین مؤلفه VDM تبدیل می کند. دیدگاه های اساسی اهداف اصلی زیر را دارند:

📷

همه دیدگاه های دیگر بر اساس آنها است. نماهای پایه به عنوان بلوک های ساختمانی قابل استفاده مجدد برای سایر نماهای غیر پایه VDM عمل می کنند. این بدان معنی است که سایر نماها نیازی به انتخاب مستقیم از جداول پایگاه داده ندارند.

نام‌های غیرشفاف و درک نشدن فیلدهای جدول در لایه پایگاه داده از نظر معنایی تجاری تغییر نام داده می‌شوند. در نتیجه، نام فیلدها شفاف تر و قابل فهم تر است.

نماهای اساسی انتزاعی جداول پایگاه داده لایه های بالاتر معنایی را تسهیل می کنند.

نماهای ترکیبی

نماهای ترکیبی عملکرد بیشتری را در بالای نماهای اصلی ارائه می دهند. در درجه اول آنها به عنوان بلوک های ساختمانی قابل استفاده مجدد برای نماهای دیگر عمل می کنند. آنها همچنین می توانند برای پشتیبانی از یک دامنه مصرف خاص تعریف شوند. به عنوان مثال، نماهای مکعب تحلیلی را می توان تعریف کرد، که منابع داده را برای استفاده در پرس و جوهای تحلیلی چندگانه یکپارچه می کند.

دیدگاه های معاملاتی

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

نماهای مصرف

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

نماهای استفاده مجدد محدود

نماهای اولیه و ترکیبی توصیف شده به طور پیش فرض بخشی از لایه رابط با I_prefix هستند، به این معنی که می توانند توسط هر برنامه SAP استفاده شوند. آنها همچنین می توانند توسط مشتریان و شرکای SAP پس از انتشار استفاده شوند. گاهی اوقات تیم های توسعه نماهای پایه و ترکیبی را تعریف می کنند که قرار است فقط در برنامه های خود استفاده شوند. در چنین مواردی یک نمای استفاده مجدد محدود با پیشوند R_ تعریف می شود. چنین نماهایی نمی توانند توسط تیم های توسعه دیگر از برنامه های کاربردی دیگر استفاده شوند. به عنوان مثال، نماهای دارای پردازش تراکنش فعال هستند که عملکردها و عملیات داخلی یک شی کسب و کار را نشان می دهند.

نماهای API از راه دور

نماهای API از راه دور می توانند به صورت خارجی مصرف شوند و عملکرد یک مدل شی تجاری واحد را نشان دهند. مدل VDM داخلی سیستم، که می تواند در طول زمان تکامل یابد، از مصرف کنندگان خارجی خود جدا می شود. یک رابط پایدار ایجاد شده است. برای اجازه استفاده از نماهای API راه دور، خدمات OData تعریف شده است. سرویس‌های OData منتشر می‌شوند و آماده استفاده از برنامه‌های راه دور هستند.

سناریوهای مصرف

پرکاربردترین سناریوهای مصرفی که توسط نهادهای CDS پشتیبانی می شوند عبارتند از تجزیه و تحلیل، برنامه های کاربردی SAP Fiori UI، جستجوی سازمانی و API های راه دور. شکل‌های زیر دو مجموعه نمای VDM معمولی را برای برنامه‌های دارای پردازش تحلیلی و تراکنشی نشان می‌دهند. نماهای خاص مورد استفاده در بالای نماهای اساسی و ترکیبی قابل استفاده مجدد تعریف می شوند. مدل داده و عملکرد با نیازهای برنامه فردی سازگار می شود.

برنامه های کاربردی تحلیلی

برنامه های کاربردی تحلیلی بر اساس نماهای مکعبی و شبکه ای از نماهای مرتبط هستند. آنها برای نظارت و تجزیه و تحلیل داده ها استفاده می شوند. در بالای مجموعه VDM در شکل 20.4 یک یا چند نمای پرس و جوی تحلیلی وجود دارد که عملکرد پیش بینی شده را از نمای مکعبی زیرین خود نشان می دهد. نمای مکعب به نمای بعد در لایه رابط مرتبط است. این نماهای بعدی با نماهای بعدی و متنی دیگر در لایه خود مرتبط هستند. نماهای اصلی داده ها را از جداول پایگاه داده انتخاب می کنند. نماهای پرس و جوی تحلیلی در پایگاه داده اجرا نمی شوند، بلکه بر روی انتخاب هایی از مکعب اجرا می شوند.

برنامه های کاربردی تراکنش

برنامه های کاربردی دارای پردازش تراکنش، سناریوی مصرف دوم را نشان می دهند. مدل در شکل 20.5 بر اساس نماهای تراکنشی است. دیدگاه‌های معاملاتی از طریق انجمن‌های ترکیبی مرتبط هستند و یک شی تجاری کامل را ایجاد می‌کنند. نمای مصرف عملکرد مربوطه را به تصویر می‌کشد و مدل داده را با حاشیه‌نویسی گسترش می‌دهد تا برنامه UI ساخته شده بر روی نما را ارائه دهد. لایه های پایینی مجموعه VDM داده ها را از جداول پایگاه داده انتخاب کرده و در اختیار لایه های بالاتر قرار می دهند. توصیه می شود با استفاده از مدل برنامه نویسی برنامه RESTful ABAP برنامه های کاربردی تراکنشی توسعه دهید.

نتیجه

معرفی VDM به کاربران نهایی اجازه می دهد تا داده های مورد نیاز در سیستم های ERP را خودشان جستجو کنند. این ویژگی سناریوی هوش تجاری خودکار است. VDM داده ها را از جداول پایگاه داده به روشی تجاری محور برای سهولت درک و مصرف آن در معرض دید قرار می دهد. از نماهای CDS تشکیل شده است. نماهای CDS بر اساس Open SQL هستند. مدل داده های معنادار درک مدل را آسان تر می کند. با توجه به قراردادهای نامگذاری، ماهیت اعلامی دارد و به طرز چشمگیری به تفکر مفهومی نزدیک است. یکی دیگر از مزایای اصلی VDM قابلیت استفاده مجدد است. پس از ساخت و انتشار، VDM ها می توانند توسط بسیاری از برنامه های کاربردی مختلف مصرف شوند. از آنجایی که نماهای CDS در لایه برنامه وجود دارد، امنیت ABAP موجود می تواند برای محافظت از نماهای CDS استفاده شود. همانطور که کدگذاری به سرور پایگاه داده پایین می‌رود، محاسبات را می‌توان نزدیک به داده‌ها انجام داد. بنابراین، زمان پاسخگویی و عملکرد برنامه ها بهبود می یابد. VDM یک مدل داده برای برنامه‌ها ارائه می‌کند، که تجاری محور، قابل درک، قابل استفاده مجدد، پایدار و اجرا شده در پایگاه داده است. از اصطلاحات تجاری شناخته شده استفاده می کند، روابط بین نهادها را مستند می کند، و موجودیت ها را با معنای تجاری اضافی برای درک بهتر غنی می کند.