Dynamics 365 Project Operations: Configuring Dual Write alerts

Tested on:
Dual-write application orchestration solution version 2.0.777.353
Dual-write core solution version 1.0.18
Project Operations solution version 4.1.0.35 (UR 1)

Alerts in Dual Write help admins react to planned and unplanned maintenance. During the Dynamics 365 Project Operations public preview, a common scenario is to turn off the F&O Virtual Machine while the Customer Engagement side is still up and running. With alerts, usage on the CE side doesn’t stop despite the F&O VM being stopped. Alerts go beyond sending notifications to admins about something being wrong. They can stop or pause Dual Write maps so that work can continue in the other system.

Before you continue reading this blog post, read this article on docs.microsoft.com to understand the basics of Dual Write alerts. The point of this post is to elaborate on issues that the docs article doesn’t cover. You can use this post as a step-by-step guide for configuring Dual Write alerts. The use cases for this example are:

  • Record creation in CE needs to be possible when the F&O VM is stopped.
  • When the F&O VM is started, all records created in CE need to sync to F&O.

Configuring Dual Write alerts

Before running through all the steps and “gotchas” for configuring alerts, I want to point out that I did run into some behavior that I would categorize as unexpected. As DW alerts are fairly new and there’s not a whole lot of documentation about the feature, it’s hard to say for sure if the behavior I’ve encountered is expected or not. As I learn more about this feature, I’ll update this blog post. Let’s now run through the alert configuration process.

Dual Write is accessed from the data management workspace in F&O. The first thing to do is to verify that all maps are stopped. If an alert is created while maps are running, the alert will not fire off when create, update or delete operations against entities related to the maps are made. When I created an alert with all ProjOps maps on, I wasn’t able to create any records in CE after stopping my VM. Whether a single map or all maps need to be stopped is still a mystery as I’m writing this blog post. I’ve experienced inconsistent behavior during my tests so I’m leaning towards recommending that all maps are stopped before an alert is created. Time and experience will tell whether this approach is overkill or not. During my tests, the Order entity in CE didn’t want to play along even though my DW alert was created after all maps were stopped. As I’m writing this post, I haven’t found a way to create Orders in CE when alerts are on and F&O is down. When I tested record creation on the Order entity, the related map Project contract headers (salesorders) did get paused correctly however saving Orders in CE wasn’t possible.

When it comes to stopping and running maps, it’s good to understand that the stop/run process takes some time. While the stopping part is fairly fast and can be done in bulk, running ProjOps related maps takes about 10 minutes as the maps have to be run in a certain order. If you’re doing a lot of testing with alerts, it’s also good to remember that stopping and starting an F&O VM takes some time. For me, stopping a VM takes approximately 5 minutes, and starting it takes somewhere between 10 to 20 minutes. This makes testing quite time-consuming.

1. Dual Write in data management workspace.
2. Verify that maps are stopped before alerts are created. Otherwise alerts might not fire off.

Alerts are created from the Alert settings ribbon button. If you’re setting alerts for the first time, you’ll most likely find a single default alert in the alert settings menu that opens up. If a default alert exists, delete it. When I left the default alert untouched and created a new one, the new alert didn’t fire off at all before the default alert was deleted.

The alert conditions depend on your use case but for quick testing, I recommend setting the alert as it’s seen in image 3 below. With an error type of Application error, the alert fires off when the F&O VM is stopped. The other error types are seen in image 4. It’s optional to send an email when an alert fires off. There are two sides to this: On the one hand, it’s helpful to get an email when an alert fires off and at least for testing, it’s very helpful. On the other hand, every time a user presses save in CE, an alert fires off and an email is sent. This happens before the related DW map gets paused. This can easily happen anywhere between 2-5 times before a map gets paused and a record save goes through in CE. To control this, it could be a good idea to instruct users to wait for a period of 1 minute before attempting to save again (if you’ve set up alerts according to image 3 below) as it takes a bit of time for DW maps to pause.

The Action on dual-write options are where things get interesting. As I’m writing this blog post I don’t have an immediate use case in mind for completely stopping DW maps. If you can come up with some, be sure to leave a comment. There is a very important difference between these two options from a record sync point of view.

Stopping Dual-Write

When this option is selected and an alert fires off, the related DW map is stopped. DW’s async mode doesn’t kick in and when the related DW map is eventually run again, records don’t sync from CE to F&O. In my tests, stopping DW also resulted in a plugin error and a description of that was seen on the related DW map in F&O. The related map was also still running so the alert never stopped the map. For the use cases covered in this example, this option is unusable.

Pausing Dual-Write

When this option is selected and an alert fires off, the related DW map is paused. DW goes to async mode and new requests are queued. When the related maps are run, the records are synced from the queue to F&O. The queue worked fairly well however on few occasions records were not automatically synced to F&O when a related map was run. These records synced immediately when they were updated in CE.

3. Creating a new alert.
4. Different error types.

Testing configured alerts

After an alert has been configured, DW maps need to be run. In the Dynamics 365 Project Operations public preview, the ProjOps related maps need to be run in a specific order. This takes approximately 10 minutes and the exact instructions can be found in Microsoft’s public preview guide Project Operations: Installation Guide. Image 5 below illustrates ProjOps’ maps, excluding maps for expenses.

5. ProjOps DW maps excluding maps for expenses.

When the maps are running, the VM running F&O can be stopped from LCS. When the VM is stopped, it’s time to head to CE to test record creation. In my tests, I tried creating Project, Account, and Order records with Order records failing as mentioned earlier. For this example, let’s focus on the Project entity. The first time a record is saved, an error is displayed. See image 6 below for the error. As the DW alert was configured to fire off when one application error happens in one minute, it’s easy to deduce that bashing save multiple times will produce the error over and over. This will also flood your inbox with alert notifications emails if you’ve opted in to receive them. If this was a real-life business use case, users should be made aware that patience is key when this specific error comes up. It takes a minute for the maps to be stopped and the record can then be saved.

6. Error when saving a record in CE while an F&O VM is down.
7. DW alert email.

Running maps in F&O

After creating a record in CE, it’s time to start the F&O VM and navigate to DW. As a Project record was created, the map related to the Project entity will be stopped as seen in image 8 below. When the map is then run, its status will display as Catching Up until all records in the async queue are processed.

8. Stopped DW map.
9. Catching Up message.

When the map’s status is Running, the created record(s) can be seen in the Project management and accounting module in F&O.

10. Projects synced to F&O from the async queue.

Summary of key takeaways

What we learned in this step-by-step example was that DW alerts have some extremely important nuances that are currently not documented on docs.microsoft.com. They are:

  • DW alerts only kick in when you first stop DW maps, create the desired alerts, and then run DW maps.
  • The default alert that comes with at least the ProjOps configuration can cause problems. Delete that alert and create a new one from scratch.
  • Pausing an entity will put DW in async mode and new requests are queued.
  • Running paused maps will sync records from the async queue.
  • Stopping DW maps will show a plugin error when an alert fires off and you return to the Dual Write configuration in F&O. The related map(s) will display as running. To be confirmed whether this is a bug or not.
  • If maps are stopped and records are created, those records will NOT sync between systems. Sync only happens when a map is paused and then run.

Disclaimer:
All my blog posts reflect my personal opinions and findings unless otherwise stated.

2 thoughts on “Dynamics 365 Project Operations: Configuring Dual Write alerts”

  1. Hi Antti,

    From where did you get the Project Operations solution with ready made mappings for the Project entities for dual write? We cannot find them on the App Source like the Dual-Write Orchestration Solution.

    Thanks.

    1. Hi Robert. The DW solutions are applied in F&O under Data Management -> Dual Write. You have to have both the DW orchestrations and core solutions installed in CDS and then after you’ve linked your CDS environemnt to your F&O, you can apply the solutions in F&O. If you are able to find the public preview deployemnt guide, this is all described in it.

Comments are closed.