تحية للجميع! اسمي تانيا ، أنا رئيس فريق تطوير Axapta في لامودا. ستناقش هذه المقالة تطوير مشروعنا الأول على منصة Microsoft Dynamics 365 For Finance and Operations.

سأتحدث عن الأساليب التي استخدمناها ، عن الأخطاء التي ارتكبت ، وسوف أشارك معرفتي واكتسبت الخبرة. قد تكون هذه المقالة ذات أهمية لأولئك الذين يبدأون في تطوير مشروع في D365 أو مجرد التفكير فيه.

هذه نسخة مجانية للتقرير من اجتماع Mycrosoft Dynamics 365 & Power Platform Meetup.

هدف المشروع والأساسيات الفنية

يقوم فرعنا الألماني بشراء البضائع وبيعها إلى كيان قانوني روسي. في السابق ، استخدمنا نظام Tsenit ، الذي سمح لنا بالاحتفاظ بالسجلات فقط على مستوى البيانات المالية ، ولكن لم نتمكن من التعامل مع المهام والمهام اللوجستية. لحل هذه المشاكل ، كان لدينا أدوات إضافية. تم تخزين البيانات في عدة قواعد بيانات في وقت واحد. كل هذا أثر سلبًا على سرعة وموثوقية النظام بأكمله.

أردنا أن يساعد نظام المحاسبة الفرع الألماني في تقديم التقارير ودفع الضرائب واجتياز عمليات التدقيق. بالكاد قام ERP السابق بحل هذه المشاكل ، لذلك قررنا تطوير وإطلاق نظام المحاسبة الخاص بنا. كان من المفترض أن يجمع تخطيط موارد المؤسسات لدينا بين التمويل والمحاسبة والخدمات اللوجستية للفرع في دائرة واحدة. كبرنامج رئيسي ، اخترنا Microsoft Dynamics 365 - Dynamics AX السابق ، والمعروف أيضًا باسم Axapta.

تم وصف مكون الأعمال في مقالة "التكنولوجيا والاستعانة بمصادر خارجية والعقلية" . هنا سنتحدث عن التنفيذ الفني. لذا ، كنا بحاجة لأتمتة العديد من عمليات الأعمال:

شراء البضائع من الموردين ؛
البيع إلى كيان قانوني روسي ؛
التكامل بين D365 و Ax2012 ، النظام المحاسبي لكيان قانوني روسي ؛
;
.

في المشروع ، قررنا تطبيق حل السحابة Microsoft Dynamics 365 ، حيث لم يكن لدى المكتب الألماني البنية التحتية لتكنولوجيا المعلومات لنشر التطبيق ، ولا الأشخاص الذين سيكونون مسؤولين عنه. بالنسبة إلى الفروع الصغيرة البعيدة ، يعد مخطط SaaS هو الأمثل ، لأنه يسمح لك بالحصول على جميع البرامج وبيئات التطوير اللازمة لبدء التنفيذ ، فور توقيع العقد مع الموفر.

كانت لدينا مواعيد نهائية ضيقة: كان من الضروري إكمال التطوير بالكامل في 3 أشهر. نظرًا لأنه في النظام القديم ، تم إجراء محاسبة السلع في جداول البيانات ، فإن نقل مجموعة البيانات التاريخية بالكامل سيكون مهمة مستحيلة في منتصف السنة المالية. ولكن في بداية الفترة المشمولة بالتقرير ، يكفي تحويل الأرصدة فقط. وبالتالي ، كان من الضروري إطلاق 1 يناير 2019 ، أو تأجيله لمدة عام آخر.

لم يكن لدى فريقنا خبرة تطوير في D365. على الرغم من كل الظروف ، خططنا لبدء هذا المشروع في أسرع وقت ممكن. بعد ذلك ، سأصف كل مراحل التطوير بشكل منفصل. سوف أسهب في الحديث عن كل تكرار بالتفصيل: ما الخبرة التي حصلنا عليها وما الأخطاء التي ارتكبناها.

التكرار الأول ، تعديلات على إصدار التطبيق 7.3

من أجل الشروع في العمل بسرعة ، قمنا أولاً بتطوير بنية تطبيق بسيطة. وهو يتألف من بيئات التطوير - بيئات المستوى 1 DevBox. تم تثبيت جميع المكونات على خادم / جهاز افتراضي واحد: خادم كائن التطبيق (AOS) وقاعدة البيانات و Dynamics 365 Retail and Management Reporter.

للاختبار ، قررنا استخدام بيئة SAT - بيئة اختبار قياسية من مستويين.

البيئة من مستويين هي بيئة متعددة الصناديق ، يتم تثبيت مكوناتها في العديد من الخدمات السحابية وعادة ما تتضمن أكثر من خادم كائن تطبيق (AOS). في الواقع ، إنها قريبة قدر الإمكان من بيئة إنتاجية ، لذلك قررنا اختبارها.

قمنا بنشر بيئات التطوير الأولى على البنية التحتية القائمة داخل الشركة ، ولكن قدرتها لم تكن كافية لمواصلة تطوير المشروع. لذلك ، عندما انضم مطوران آخران إلى المشروع ، قمنا بنشر DevBox لهم بسرعة وسهولة في السحابة.

تمت إدارة بيئات السحابة الخاصة بنا من خلال بوابة خدمات دورة الحياة.

بعد الانتهاء من البيئات ، بدأ الفريق في التطور. قمنا بإعداد بيئة التطوير على Visual Studio وربطناها بالتحكم في إصدار Azure DevOps ، بعد أن أنشأنا سابقًا فرعًا لتنزيل الرمز. بعد ذلك ، قمنا بتطوير نهج لتطوير ونقل التغييرات في بيئة SAT.

لا توجد طبقات في بنية D365 ؛ تم وضع جميع الكود القياسي في النموذج. تم نقل التعديلات إلى بيئة SAT من خلال بوابة LCS مع حزمة تحتوي على نموذج مترجم.

– , – , .

بادئ ذي بدء ، قمنا بتنفيذ التعديل الأبسط والأكثر شيوعًا - إضافة حقل جديد إلى الجدول القياسي ، وتهيئته عند إنشاء السجل ، والإخراج إلى النموذج القياسي.

حتى في مثل هذا المشروع البسيط ، هناك أنواع جديدة من الأشياء. قمنا بعمل ملحق لإضافة حقول جديدة إلى الجدول القياسي. لإحضار الحقل إلى النموذج القياسي ، قمنا بعمل نوع جديد من الكائن - امتداد للنموذج. ولتهيئة الحقل ، أنشأنا فئة توسع أساليب الجدول. سمح بتهيئة الحقل عند إنشاء السجل.

في مثل هذا التعديل البسيط ، رأينا أحد المبادئ الأساسية لـ D365 - ليس تغييرًا ، بل امتدادًا للكائنات القياسية.

التعديل التالي كان إنشاء شكل جديد. الآن ، عند إنشاء نموذج ، كان من الضروري تحديد نمطه.النمط هو نمط يحدد بشكل كامل هيكل التصميم للنموذج. حتى نقوم بإعادة إنتاج البنية الموضحة في النموذج بالكامل ، لن يتم تجميع النموذج الخاص بنا. من المستحيل تغيير قالب النموذج النهائي. لذلك ، قبل البدء في التطوير ، فكرنا مسبقًا في الشكل الذي سيبدو عليه شكلنا.

احتفظنا أيضًا بالقدرة على إدارة تصميم النموذج بأنفسنا. إذا أشرنا إلى نمط - مخصص ، فإننا كنا مسؤولين تمامًا عن تصميم النموذج: ما هي الأشياء الموجودة عليه ومع أي تداخل.

الاستنتاجات بعد التكرار الأول

1. لا تقم بتغيير المعيار ، ولكن قم بتوسيعه فقط.

2. راجع النموذج إذا استخدمنا كائناته في نموذج آخر. هذا هو أحد الاختلافات بين نماذج D365 من الإصدارات السابقة: يوجد كائن في نموذج واحد فقط.

3. هناك قيود في تغيير خصائص الأشياء القياسية. لا يمكن تغيير جميع خصائص الحقول القياسية في ملحقاتها للكائنات القياسية. على سبيل المثال ، ملحق جدول PurchTable هو حقل LineDisc. يمكننا التحكم في رؤية الحقل والتسمية ، ولا يمكن تغيير خصائص مثل إلزامية وقابلة للتحرير.

4. لا توجد وظائف في D365 ، ويتم كل شيء من خلال الفصول الدراسية.

5. لقد تغلبنا على النماذج بدقة كبيرة ، واتضح أن مبدأ "تعديل واحد = نموذج واحد" لا يعمل.

التكرار الثاني والانتقال إلى نموذج واحد

في بداية التكرار الثاني ، كان لدينا نموذجان يشيران إلى بعضهما البعض. ولهذا السبب ، لم يعد بإمكاننا نقل هذه التعديلات بشكل مستقل. لذلك ، قررنا العمل في نموذج جديد واحد ، كان من الضروري نقل جميع التعديلات الحالية.

النموذج في D365 عبارة عن مجموعة من ملفات المصدر الموجودة في دليل منفصل. عند الترجمة ، يتم جمعها في مكتبة منفصلة لها ارتباط بمكتبات أخرى.

لذلك ، فإن الاندماج في نموذج واحد على DevBox جاء لنقل الملفات من دليل إلى آخر وحذف الأدلة القديمة.

لذا ، قمنا ببناء نموذج جديد ، وحصلنا على أحدث إصدار له على كل DevBox ، ثم واصلنا العمل في إطار نموذج واحد على بيئات التطوير.

بطبيعة الحال ، لقد قمنا بالفعل بتحويل نموذجين للاختبار على بيئة SAT. لذلك ، كان من الضروري إزالتها ، وإطلاق واحدة جديدة.

تم إجراء جميع التحديثات على بيئة SAT باستخدام الحزم ، بما في ذلك إزالة النماذج. لقد أنشأنا حزمة تحتوي على نماذج فارغة يجب إزالتها ، وأضفنا نصًا برمجيًا بأسماء هذه النماذج إليها. ثم جمعنا حزمة مع نموذج جديد وقمنا بتدويرها في بيئة SAT. وهكذا ، حصلت SAT على نموذج جديد.

عندما تم دمج النماذج ، لاحظنا أن كل مطور يسمي امتدادات الكائنات بطريقته الخاصة. اتفقنا على قواعد تسمية الكائنات وفقًا للنموذج: PurchTable.LamodaModelFormExtension، PurchTableTypeLamodaModelClass_Extension .

اتفقنا أيضًا في الفريق على أنه بالنسبة إلى كائن قياسي واحد ، فإننا ننشئ ملحقًا واحدًا فقط ونجري تغييرات عليه بالكامل.

لقد اخترت بعض التعديلات المثيرة للاهتمام التي قمنا بها في هذه المرحلة. تظهر مناهج التطوير الممكنة في D365.

المهمة 1

في ترحيل الفاتورة لأمر المبيعات ، كان من الضروري استبدال رقم الفاتورة بالرقم من الأمر. للقيام بذلك ، حددنا فئة قياسية مع إمكانية التمديد ، مما سمح لنا بإجراء هذا التعديل.

قمنا بعمل امتداد لفئة SalesInvoiceJourCreate القياسية. يوجد Next في أسلوب getNumAndVoucher () - هذا هو أسلوبنا الجديد الفائق ، يتحدث عن استدعاء رمز الطريقة القياسي. بعد استدعاء الرمز القياسي ، استبدلنا رقم الفاتورة بالقيمة المطلوبة.

هذا هو أحد أساليب التطوير لدينا: استخدام الإضافات وإضافة الكود الخاص بنا قبل أو بعد (كخيار - قبل وبعد) تنفيذ الكود القياسي.

المهمة 2

كان من الضروري تغيير عرض إجماليات أمر الشراء: قم بتجميع الإجماليات حسب رقم فاتورة المورد من بنود أمر الشراء. في هذه الحالة ، لم نجد مكانًا للتوسع دون تخفيض الأداء إلى النصف ، لذلك قمنا بعمل نسختنا الخاصة من النتائج دون لمس النتائج القياسية.

المهمة 3
تعديل آخر مثير للاهتمام: في أسطر نموذج أمر الشراء ، كان من الضروري إضافة حقول من قائمة العناصر مع إمكانية التصفية. في الإصدارات السابقة ، كان التعديل غير مثير للاهتمام تمامًا وتم حله بمجرد إضافة جدول كمصدر بيانات إلى النموذج وتداخل الطريقتين.

في الإصدار 7.3 ، لم نتمكن من توسيع الأساليب إلى مصدر بيانات نموذج قياسي. لإجراء التصفية وعدم إنشاء نموذج جديد لهذا ، أضفنا طريقة العرض كمصدر بيانات إلى النموذج.

ظهرت القدرة على توسيع الأساليب إلى مصدر البيانات في الإصدار 8.1 من D365.

الاستنتاجات بعد التكرار الثاني

في هذه المرحلة ، قمنا بتطوير التعديلات الأساسية اللازمة لبدء المشروع.

قدمنا قواعد تسمية ملحقات. لم تساعد فقط في جعل الأسماء متسقة ومفهومة ، ولكن تبسيط التحديث بشكل أكبر ، لأن أسماءنا لم تتزامن مع أسماء الكائنات القياسية من حزمة الخدمة.
لقد سررت بسرعة حدوث الإسنادات الترافقية عند بناء مشروع أو نموذج - إنه منظم بشكل مريح للغاية في هذا الإصدار.
يحدث تحديث النماذج في أنواع مختلفة من البيئات بطرق مختلفة. كنا مقتنعين بذلك على مثال لدمج النماذج.
قبل البدء في تطوير تعديل جديد ، تحتاج إلى الحصول على أحدث نسخة من النموذج ، حيث يتم التطوير في إطار نموذج واحد.
تحولت آلية كيان البيانات لتحميل البيانات وتفريغها في Excel عند تحديث البيانات على المنتج إلى أنها مريحة للغاية. يستخدم قسم البيانات والتحليلات لدينا الآن لاسترداد البيانات من D365 المستندة إلى السحابة.

قمنا بالتطوير الرئيسي في الوقت المحدد. خرج Go Live ، النموذج في همز. وواجهنا مشكلة تحرير التعديلات المختبرة فقط داخل النموذج. أردنا أيضًا تسهيل عملية تصحيح الأخطاء أثناء اختبار التعديلات وتسريع تحديث بيئة الاختبار.

كيف يعمل الآن

في التكرار الأخير ، أضفنا بيئتين: البناء والاختبار. بعد تهيئة جميع البيئات والتحقق منها ، قمنا بتبسيط الاختبار وتعلمنا تحرير التعديلات المختبرة فقط داخل النموذج.

للاختبار ، قمنا بنشر بيئة ذات مستوى واحد وربطها بفرع التطوير في نظام التحكم في الإصدار. يتألف التحديث الآن من الحصول على أحدث إصدار من النموذج نفسه وتجميعه. في هذه البيئة ، ظهرنا لأول مرة ، كما هو الحال في DevBox المعتاد.

يتم الآن إنشاء حزم الإصدار للإصدار في بيئة بناء جديدة. تم نقل التعديلات المختبرة إلى فرع جديد في نظام التحكم في الإصدار عن طريق مجموعات التغييرات (حزم التغيير التي تم تحميلها على نظام التحكم في الإصدار) ، على أساس مبدأ من الأقدم إلى الأخير.

ثم نشرنا الحزمة في بيئة SAT حيث تم اختبار المستخدم ، وبعد ذلك قمنا بجدولة الحزمة على بوابة LCS لإصدارها في المنتج. لذلك قمنا بإعداد عملية الإصدار باستخدام بيئة البناء.

وقررنا عدم مراجعة المشاريع ، ولكن تم تعديل مجموعة التغييرات للتعديل إلى التحكم في الإصدار.

تحديث الإصدار السحابي الأول

لقد عملنا على إصدار السحابة ، لذلك كنا بحاجة إلى التحديث بانتظام. كان التحديث الأول انتقالًا من الإصدار 7.3 إلى الإصدار 8.0. استغرق حوالي أسبوعين.

بالطبع ، خلقنا المشاكل الرئيسية لأنفسنا ، لكننا فزنا أيضًا:

لم نتفق على الفور على قواعد تسمية الكائنات القياسية. في التحديث الأول ، تزامنت أسماء الكائنات مع أسماء الكائنات في حزمة الخدمة.
عند تحديث البيئات السحابية ، قمنا بالضرورة بتسجيل الخروج من أجهزة AOS ، وإلا تعذر إكمال عملية التحديث مع مستخدم قام بتسجيل الدخول.
يجب الجمع بين حزمة التحديث لبيئات الإنتاج و SAT مع حزمة النموذج.

اليوم ، يستغرق تحديث جميع بيئاتنا حوالي 3-4 أيام ويتم بدون مشاركة المطورين. يمكننا أيضًا إصدار إصدار في نفس وقت التحديث ، والشيء الرئيسي هو أن الإصدار و SAT و prod لديهم نفس الإصدار.

تتكون عملية التحديث من تنزيل حزمة التحديث على بوابة lcs. يتم تحديث DevBox والاختبار أولاً ، ثم يتم تحديث البنية ، والأخير هو SAT و prod.

نتائج المشروع الأول بأكمله

لقد اكتسبنا خبرة في بناء بنية تطبيق D365.
طورت طريقة جديدة لمراجعة الكود.
لقد وضعنا قواعد نقل قواعد البيانات إلى DevBox (في D365 من المهم إجراء اختبار أولي على DevBox ، ونحن الآن نختبر المطورين على DevBox).
كتب إرشادات التطوير في D365.
تعلمت أن تتطور في السحابة.

ساعدتنا كل هذه التجربة على تطوير المشروع بشكل أكثر عمقًا. الآن نحن نعرف قدرات النظام ، يمكننا بناء البنية بشكل صحيح ، أو بالأحرى تعيين المهام. تجعل العمليات المدمجة حول المشروع من السهل بما يكفي ربط المطورين الذين يكتبون للمرة الأولى تحت D365.

تطوير أول مشروع على منصة Microsoft Dynamics 365 For Finance and Operations