Bir etkinlikle daha karşınızdayım bu seferki etkinliğimiz Dynamics 365 User Group. Bu etkinlikte Common Data Service ile nasıl veri modelleri oluşturup bunları Power Platform ve Dynamics 365 içinde kullanılacağından bahsedeceğim.
Common Data Service, iş uygulamaları tarafından kullanılan verileri güvenli bir şekilde depolamanızı ve yönetmenizi sağlar. Common Data Service içindeki veriler bir dizi varlık içinde saklanır. Bir varlık, bir tablonun veriyi veritabanında nasıl depoladığına benzer şekilde, verileri depolamak için kullanılan bir kayıt kümesidir. Common Data Service, tipik senaryoları kapsayan bir dizi temel varlık içerir, ancak kuruluşunuza özgü özel varlıklar oluşturabilir ve bunları Power Query kullanarak verilerle doldurabilirsiniz. Sizler bu verileri kullanarak zengin uygulamalar oluşturmak için Power Apps’i kullanabilir.
Dynamics 365 User Group etkinliğinde aslında işin en önemli kısmı olan veri modeli üzerinde oluşturabildiğiniz mantık ve doğrulama işlemleri konusuna değineceğim. CDS içindeki varlıklar, veri kalitesini sağlamak ve varlık içinde veri oluşturan ve kullanan her uygulamada tekrarlanan kodu azaltmak için zengin sunucu tarafı mantığı ve doğrulamasından yararlanabilir.
İş kuralları, verileri oluşturmak için kullanılan uygulamadan bağımsız olarak, birden çok alan ve varlıktaki verileri doğrular ve uyarı ve hata mesajları sağlar.
İş Süreci Akışları, kullanıcılara verileri tutarlı bir şekilde girmelerini ve her seferinde aynı adımları izlemelerini sağlama konusunda rehberlik eder. İş süreci akışları şu anda yalnızca Model tabanlı uygulamalar için desteklenmektedir.
İş akışları, kullanıcı etkileşimi olmadan iş süreçlerini otomatikleştirmenizi sağlar. Daha fazla bilgi için İş Akışlarına genel bakış konusuna bakın. Kodlu iş mantığı, uygulamayı doğrudan kod yoluyla genişletmek için gelişmiş geliştirici senaryolarını destekler.
In enterprise scenarios, it is a common requirement to be able to deliver common or separate CRM modules to separate business units according to an enterprise-level or separate roll-out timeline.
The typical challenges of this scenario result from parallel development tracks and frequent changes to enterprise projects, which require the greatest degree of flexibility in every aspect:
Sharing common code/customization base
Managing solution layering and dependencies
Managing changes in layering (moving items to common or back, customizing common elements locally)
Versioning common and local solutions
Parallel development on multiple solutions, multiple solution-layer setups, and multiple versions of a solution
Central repository of every/any solution
Test and deploy all possible or required combination of solution layers
Managing solution branch and merge
Regression testing changes and impacts across solutions and branches
Common, single versioning of all solution elements
Development and Version Control
You need streamlined and common techniques of development and repository management for complex enterprise deliveries. The standard features of Microsoft Team Foundation Server serve as the basis of larger application delivery management scenarios:
Debugging and diagnostics
Architecture and modeling
Integrated development environment
Build management and automation
Test case management
Work item tracking
Reports and dashboards
When working with multiple development teams developing multiple solutions and versions in parallel on an enterprise delivery, the following base process is minimally recommended:
Developers should have isolated VMs to work on either hosted locally or centrally to share infrastructure between team members. Every developer work-item needs to be committed to the TFS environment (integration environment).
The development lead is in charge of making sure that the developments (customizations, configurations, and custom source files) can integrate in the integration environment without any side effects.
The TFS source control should be considered as the central repository for all solution items:
All CRM customizations (Entities, forms, views, workflows, templates, web resources, etc.)
Source codes and projects for custom components
Plug-ins, custom activities
Custom web applications
Custom .Net components
Custom services and other external components
Web resource files
External components and references (SDK, Enterprise Library, etc.)
Unit test source codes for above components
Automated test sources for the entire application
Setup package for the entire application
Deployment scripts for the packages
Build definition for the entire application
The customer requirements and the work-item break-down should be stored in TFS work-item management. This way the development check-ins can be connected to the work-items, and the built-in development tracking and reporting functions of TFS can be leveraged. You will also be able to use the change-impact analysis functions of TFS for risk analysis and selecting the regression test scenarios for a specific change-set.
In multi-feature and multi-team scenarios you usually need multiple development and test environments, probably using different versions of the application. The TFS build automation and lab management functions provide the necessary toolset for managing daily build and deployment steps. You find more details about the topic in the Build and Test sections.
Version Control Process
The CRM customizations are out-of-the-box bound to a single CRM solution zip file, which requires special techniques to manage as part of a source control system.
The SolutionPackager tool (see Use the SolutionPackager Tool to Compress and Extract a Solution File) is designed to unpack (split) a solution .zip file into a broad set of files within folders by entity name. The breakout into files enables that modifications to different components will not cause changes to occur in the same files. For example, modifying an entity Form and a View would result in changes in different files (hence no conflicts to resolve). Pack will take the files from disk and glue them back together to construct a managed or unmanaged .zip file.
The development process for Solution Packages with the SolutionPackager tool is illustrated in the following graphic.
The developer works on his/her daily environment to work on the CRM development task allocated. Before starting a work item the developer (or the build master) gets the latest version of customization tree from TFS and uses the SolutionPackager tool to create the solution zip file. The developer (or the build master) deploys the latest solution package on the development environment. The same solution can also be deployed to the test CRM environment.
At the end of a day or after finishing a work item, the developer exports the solution zip file from the development environment. Executing the SolutionPackager tool on the zip file will generate the separate customization elements of the entire solution. The customization files need to be checked out and checked-in individually only when changed.
The Visual Studio project may be created manually. The SolutionPackager tool will automatically create the folder structure below that (the unpack script need to be executed in the solution project folder).
The current version of SolutionPackager tool provides the basic functionality to convert the packaged customization zip file to a version controllable folder structure. The following manual steps are still needed by the developers or test leads to be able to maintain the source tree:
1. Check-in check-out of specific customization elements, which will be affected by a work-item change.
2. Execute the pack/unpack operation manually and selecting the changed customization elements (Note: this can be integrated into the clean and deploy process of the Developer Toolkit).
3. Taking care of the managed and unmanaged version of components at check-in time.
4. Managing the assembly versioning (FQ strong names) of plug-ins used by a CRM solution.
5. Managing RibbonDiffXML (merging changes).
The following techniques may be used to further support the version control process:
Removing assembly strong names from customization files to be able to track only the real changes.
Some schema parts are reordered randomly during solution import-export; these elements may be ordered alphabetically to more convenient source control tracking.
Enterprise CRM projects usually face the requirement of supporting multiple locales. Although CRM has OOB support for localization, it is always a challenge to provide full solution localization because different components required different localization strategies, and the explosion of components may be required.
Localization of some specific CRM components is currently not supported or not applicable. For example:
CRM Developer Toolkit
Roles & FLS profiles
The CRM Developer Toolkit may be used for daily developer work for creating streamlined plug-ins, generating codes, solutions, and accessing CRM customization pages. The source code should be checked in directly under TFS. The applied customizations can be exported, unpacked from the CRM organization, and the specific changed elements can be checked in manually.
Note: The Developer Toolkit can support the process of packing and unpacking by turning on the ability to export a CRM Solution as part of the local deployment process.
Sitemap, Ribbon Editor
The CRM customization system only supports editing the sitemap and ribbon definition manually as xml files, after a manual export and followed by an import operation. The SiteMap and Ribbon Editor tools provide a graphical UI for executing these types of customizations.
These tools can be also combined with the unpacked structure:
§ Sitemap.xml is unpacked into a separate xml file and can be directly edited by SiteMap Editor.
§ The Ribbon Editor supports editing directly on a CRM environment, so developers need to edit on the server and then unpack the solution zip file and check-in the changes.
Daily Developer Work
The developers should use unmanaged solutions and shared configuration environments during development time. One developer usually works on one solution (either CRM or other Visual Studio solution), but multiple developers can work on the same solution in parallel.
The developer environments should be typically updated on a per-day basis using the last successful build. You should consider the best environment allocation and setup strategy for your team, depending on the actual project and team setup (see Deployment and Test).
The developers typically use standard CRM customization UI for executing their daily work. They create CRM customization elements (entities, screens, ribbons, views, dialogs, plug-in registrations, etc.). They may use Visual Studio for creating custom developed plug-ins, web applications, or other components, and may also use other external tools such as resource editors, designers, sitemap, ribbon, and metadata editor for CRM.
The editing of external components and resources can be typically executed offline on the developer machine after executing the TFS check-out operation (VS built-in editors usually manages check-out automatically).
Just before the check-in, they need to export the solution from the CRM environment and execute a special batch file per solution, which will unpack the customization file.
Developers need to take care of the actual check-in. They need to be aware of the executed changes and which schema members it affected. Only the changed elements need to be checked-in, and there are also special cases when the check-in elements need also to be merged back or compared to the previous version (for example, ribbonDiffXml).
Before the actual check-in operation, the developer must get the latest sources and create a local build, including a solution package, to deploy and test in the development environment; this is the recommended practice for quality check-ins. This process may be also supported by the Gated Check-in or Continuous Integration feature of TFS.
The daily development process is illustrated in the following figure.
The build process can be automated using the standard TFS build agent. The build agent is a Windows service that executes the processor-intensive and disk-intensive work associated with tasks such as getting files from and checking files into the version control system, provisioning the workspace for the builds, compiling the source code, and running tests.
A typical build process consists of the following steps:
Getting the build definition (You may have multiple parallel projects/builds.)
Update build number (solution versioning)
Prepare build context
Create a drop location
Get build agent
Get build directory and initialize workspace
Get source files
Compile sources and create setup packages
Run unit tests
Process test results
Drop build and notify
The build process may be extended further by automated deployment and testing (for more details see the Build,Test and Deployment sections):
Rollback test environments
Deploying setup packages to test environments
Executing automated test steps/schedule manual test scenarios
Offline Build Process
The offline build process is designed as an independent build flow enabled to execute the building of a whole CRM solution package without a running instance of Dynamics CRM. The offline build process leverages the static schema of the solution elements and customization files (see Development and Version Control).
The build process can be easily extended to use the SolutionPackager tool. The CRM Solution Builder project template and target file samples can be used to integrate the pack operation into the daily build process (see CRM SolutionBuilder).
During the build process, the Visual Studio standard projects will be compiled, built, and dropped as defined in the build and project definitions.
Building the CRM customization project will trigger the pack operation will the up-to-date customization source tree (see solution tree structure above). All customizations will be merged together as a single customization.xml and solution.xml file. The previously built solution resources and assemblies can be included directly in the solution package.
Note: ILMerge operation may be required to make DB-registered assemblies work with referenced assemblies.
The deployment automation of packed CRM solution can be executed identically to standard CRM solution deployment.
On enterprise projects the following scenarios can cover the typical deployment requirements:
Automated deployment of development environments, test environments, and integration environments
Offline setup packages and scripts to enable deployment to acceptance and production environment as a sandbox
Rollback environments to a baseline (both CRM components and the CRM database)
May already contains existing solutions and possible CRM Update Rollups
Deploying CRM solutions
Deploying CRM base data and custom security roles
Additional configuration of the organization, BU, and user settings using the CRM API
Note: For further details on CRM automated deployment process see the Test and Deployment sections.
The version control differences between managed and unmanaged solutions are already described in ManagingVersion Requirements section. The SolutionPackager tool will process and unpack both types of solutions. The unpack process will create differencing elements with “managed” postfix for easier version control management.
The general recommendations for using managed or unmanaged solutions:
Use unmanaged solutions for development.
Use managed solutions for all downstream environments.
Use as few solutions as possible for easier management.
Customize existing managed solutions as little as possible.
Execute integration tests using managed solutions frequently to test and address possible collisions.
Test managed solution combinations for every possible or supported scenario.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.