Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Save more on your purchases now! discount-offer-chevron-icon
Savings automatically calculated. No voucher code required.
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Conferences
Free Learning
Arrow right icon
Arrow up icon
GO TO TOP
Extending Microsoft Dynamics 365 for Operations Cookbook

You're reading from   Extending Microsoft Dynamics 365 for Operations Cookbook Create and extend real-world solutions using Dynamics 365 Operations

Arrow left icon
Product type Paperback
Published in May 2017
Publisher Packt
ISBN-13 9781786467133
Length 442 pages
Edition 1st Edition
Languages
Arrow right icon
Author (1):
Arrow left icon
Simon Buxton Simon Buxton
Author Profile Icon Simon Buxton
Simon Buxton
Arrow right icon
View More author details
Toc

Table of Contents (16) Chapters Close

Preface 1. Starting a New Project 2. Data Structures FREE CHAPTER 3. Creating the User Interface 4. Application Extensibility, Form Code-Behind, and Frameworks 5. Business Intelligence 6. Security 7. Leveraging Extensibility 8. Data Management, OData, and Office 9. Consuming and Exposing Services 10. Extensibility Through Metadata and Data Date-Effectiveness 11. Unit Testing 12. Automated Build Management 13. Servicing Your Environment 14. Workflow Development 15. State Machines

Introduction

Microsoft Dynamics AX 2012 underwent a name change in what would have been version 7. The official name is now Microsoft Dynamics 365 for Operations. It isn't just that the version number has been dropped, but it appears to have been adopted into the Microsoft Dynamics 365 product suite. The product is not a component of Microsoft Dynamics 365, which is just a way to group Microsoft's various business solutions. We can't, therefore, shorten the name to Dynamics 365, we will refer the product by either its full name or the abbreviation Operations.

New features will be introduced to Operations as both a continual and cumulative process. There are two main types of update, Platform and Application. Platform updates are similar to the binary updates in prior releases, but also contain AOT elements that are now locked and can no longer be changed. Platform updates can contain changes to the language, and new features have been brought in with each bi-yearly release. When running in the Cloud, Microsoft will periodically release updates to the Platform for you. This is needed, since the it uses Azure SQL Server and they may need to service the platform in order to maintain compatibility to the database server.

Application updates are changes to the other packages that make up the source code of Operations, and can be considered similar to the meta data updates in previous releases of Operations.

This book was started on the May 2016, or Update 1 release and has been updated with each release. The version on publication is Update 5, released in March 2017.

All development work is carried out in conjunction with Visual Studio Team Services or VSTS. It used to be optional, but the implementation process that is managed through Lifecycle Services (LCS) requires that we have a VSTS project linked to it to function to its fullest. This is not just for source control and work management, but it is also used when performing code upgrades.

Please see the following links for further reading on Microsoft Dynamics 365 for Operations:

All development work in Operations is either performed on a development virtual machine hosted in Azure, or a local virtual machine. Each developer will use their own virtual machine. Azure hosted virtual machines are deployed through LCS under your own Azure subscription, and can be used to development, learning, and demonstration. Once, as a customer, a cloud hosted subscription has been bought, you are provided 3 environments as part of that subscription under Microsoft's subscription. These are Build, Sandbox, and Production. The build sever is a OneBox server (all in one virtual machine) that is also labelled Development, but it should always be used as a build server and not for development. The sandbox server is a full environment, with multiple servers using a separate Azure SQL Server. The production environment is the environment that you (as a customer) will go live with. All code must first be deployed to the sandbox before it is applied to live, which this is enforced by LCS - no more 'quick fixes' directly into live, and no access to SQL server for the production environment.

The on premise version of Operations may allow us to bypass some of these rules, but we shouldn't try - these practices of forcing code through a full testing cycle are very important. Waiting a couple of days for a needed feature may be inconvenient, but regression is perceived very negatively by users. During the implementation we ask a lot of the users, they are already busy with their jobs and are being asked to also help with testing new software, so user buy-in to the project is a critical factor, and regression is the most efficient way of eroding the initial excitement of delivering new software.

For local development virtual machines that are often the cheapest option, we will download the virtual machine from Microsoft Connect. This is a website used for many programs at Microsoft, and access is provided to partners and customers.

lock icon The rest of the chapter is locked
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at €18.99/month. Cancel anytime