D365 Maintenance mode

This blog post provides information about maintenance mode in Finance and Operations. When maintenance mode is turned on, it provides a safe way for system administrators to make system changes that might affect system functionality. For example, configuration keys can be enabled or disabled. While maintenance mode is on, only system administrators and users who have the Maintenance mode user role can sign in to the system. By default, maintenance mode is turned off. 

Turn maintenance mode on and off on sandbox and production environments through Lifecycle Services

You can now turn maintenance mode on and off directly through Lifecycle Services (LCS) on your sandbox and production environments. Refer to the following steps to do this:

1. Go to the environment details page and on the Maintain menu, click Enable Maintenance Mode.
2. In the slider, set Turn maintenance mode on for the environment and select Confirm.
3. A servicing operation will begin and your system will go into maintenance mode.
4. On completion, the environment state will be In Maintenance. At this point, only the system administrator will have access to the environment.
5. After you are done making system-wide changes, you can turn off maintenance mode by clicking Disable Maintenance Mode under the Maintain menu.
6. This will start a servicing operation that takes your environment out of maintenance mode. You can see the progress of the operation in the environment details page.
7. After this is complete, your environment goes back to the Deployed state. Now all users can sign in to the environment.
8. You can check the environment history page to see when the maintenance mode was turned on or turned off. To get to the environment history page, select History and Environment changes on the environment details page.

Turning maintenance mode on and off for your sandbox and production environment is very similar to a servicing operation. If turning maintenance mode on or off fails, you will see options such as Resume, Rollback, and Abort. You also have the option to download the logs to troubleshoot why the operation failed.

Processing an Excel file in batch D365 FO

When talking about extending the SysOperationFramework parts, you probably already know that we will have the well-known structure of classes in order to design our batch process: the controller class, responsible for running the operation and modifying the contract, the contract class, responsible for passing parameters and values from the user to the logic that processes operation, the service class, responsible for providing the logic which is being executed (in our example, iterating through the Excel file, getting the purchase orders IDs and posting a product receipt for them), and the User Interface builder (UIBuilder) class, responsible for the actual looks and event handlers of the dialog that is presented to the user.

Let’s have a look at what our code changes will look like in the D365 user interface, before scheduling the actual batch job:

Analyzing this dialog, we will see that it looks like every other batch dialog, with only one parameter: a file.

Below, we will see the code which is taking care of the design and functionality for this batch process.

The controller class

/// <summary> /// Controller class for creating & posting PO packing slips /// </summary> class AXMPostPOReceiptsController extends SysOperationServiceController { /// <summary> /// Creates new instance of <c>AXMPostPOReceiptsController</c> /// </summary> public void new() { super(); this.parmClassName(classStr(AXMPostPOReceiptsService)); this.parmMethodName(methodStr(AXMPostPOReceiptsService, processOperation)); this.parmDialogCaption("Create packing slips"); }

    /// <summary>

/// Sets the caption of the job /// </summary> /// <returns>Caption of the job</returns> public ClassDescription caption() { return "Create packing slips"; }

    /// <summary> /// Method which is run while calling the corresponding menu item /// </summary> /// <param name = "args">Arguments passed from the menu item</param> public static void main(Args args) { AXMPostPOReceiptsController controller; controller = new AXMPostPOReceiptsController(); controller.startOperation(); } }

Tier1 database restore D365 F&O

The process of database import is needed when a new developer starts to work on a project and requires configured data for performing testing scenarios. In our projects we use preconfigured user data to improve our development and testing performance. We store a Tier 1 environment database backup (.bak) and use it when a new developer comes to work with a project.

As Microsoft releases platform updates, we need, somehow, to use old backups from environments of older versions, for data import on Tier 1 developer environments.

This instruction can be used to import and work with databases for different projects.

Import database

To import database a developer needs to have the database backup.

Important! For this operation you need to use Tier 1 database backup (.bak).

Get database backup

You need to have it to the SQLBACKUP(.bak file)  on Tier 1 DEV machine.

Create new database

Create new database in your DEV box and name it as AxDB_New

Restore the backup 

Restore the database backup in newly created databased (AxDB_New).