Those of us who have struggled with various versions of Dynamics have always missed in D365FO the access to the AOT in the Production environment, access to its database, and being able to tinker there.
This desire or this melancholy is accentuated when in D365FO we will not be able to create Jobs in Production without first having to upload a package and stop the environment.
The end of these days has come. In release 10.0.25, we will see a series of new functionalities, and the possibility to "upload jobs" in Production without having to stop the environment.
So we only need our environment to be in version 10.0.25 (still in Preview) and perform the following steps:
Overview
1. Enable the flight that allows us to enable the feature
To do this, on the machine where we have version 10.0.25, we execute the following sentence using the d365fotools
Enable-D365Flight -FlightName AppConsistencyCustomScriptFlight
2. From this moment we will see a new menu point in D365FO
System Administration / Periodic Tasks / Database / Custom Scripts
3. Once inside the form that appears, it looks like this:
As we can see, it is a very simple form where it allows us to load new Jobs (Load button) and see the history of the execution of the Jobs and their information.
Upload
To be able to execute a Job in an environment enabled for it, we must follow the following steps:
1. Create in any development environment an independent package with a model with only ONE Runnable Class (the Job).
This requirement is essential for the correct validation of the characteristic.
In this case we will create a Job that only shows us a message on the screen.
2. Once the Job is created, we create a deployable package from Visual Studio selecting that package
3. In the D365FO Custom Scripts form, click Load and it will ask us for the package generated in the previous step
4. We introduce an informative purpose and select the package. Obviously it warns us of the dangers of executing this type of process in environments, especially Productive ones.
5. We will see our loaded package in Loaded state
Execution
Once the package is loaded in the environment, a series of steps must be executed to validate that what we are going to do is correct and that we are aware of the dangers of carrying out these actions.
1. A user other than the one who uploaded the package must approve that job. This approval is a totally administrative step. It is clear that we can also reject or abandon that Work because it is no longer necessary.
2. Once approved, we see that there is a record of who and at what time this approval was made.
3. Even so, it only leaves us "Run test". It is about executing the job but without it having a real effect but only for information of what would happen if we executed it. That is why it is interesting to add messages and validations to be able to see them in the tests.
4. In the result we can see how it has executed the test and has returned the message that we had given it.
5. Even so this is not enough but we have to validate this test using the following button:
6. And now we can execute it. It warns us that the changes will be irreversible. We use the "Run" button and it will launch the job.
7. Once launched, it allows us to mark that job depending on the result we have obtained.
8. With this process done, we can no longer launch the job again unless we load the package into the system again. In this way, there is a record of which jobs have been launched and who did each of the steps.
Interesting functionality as well as dangerous. Even so, it is not as simple as launching a RunnableClass, but there are several validations in between that should make it safer to execute this type of process.
Be ready for March 2022!!!