.svg)
Created by: Kristinn Magnusson
We are excited to release exMon 4.0! This release continues our focus on ease of use but we also introduce preview support to Salesforce and Harvest cloud data providers.
Before diving into the changes, we would like to highlight our most recent posts on using exMon. They can be a valuable resource in mastering exMon.
- Using the exMon Continuous Monitoring Portal (Tutorial)
- Create a Query (Tutorial)
- Create a Compare Query (Tutorial)
Here are our most important changes in exMon 4.0:
Actionable and informational exceptions
Tests in exMon create two main types of exceptions: actionable and informational.
Actionable exceptions can be fixed and the goal should be to fix all actionable exceptions.
Examples of actionable exceptions are Discrepancies between prices in the master database and the point of sale system, billing addresses not set for customers and discount rates too high for some products.
Informational exceptions are generated from tests monitoring past events.
The specific exceptions can not be fixed, but analyzing and monitoring the exceptions can aid in changing behaviour. An example of informational exceptions could be sales with low margins.
In this release we have more distinction between those two types of exceptions, making working with those exceptions easier.
By default, tests create actionable exceptions but you can configure it to generate informational exceptions with the Severity setting.
On the exMon Portal, you can then choose between working with All exceptions, actionable exceptions or informational exceptions.
Action property
In exMon, the developer of a test and the person working with the exceptions are rarely the same people. Therefore, it is important that each test is well documented and describes both what is being monitored and how to fix the exceptions generated.
In this release, we have added an Action property for tests. Developers can then add details on what needs to be done to fix exceptions in that test. These details will be visible on the portal and in all emails generated by the test.
Exception email triggers
In previous versions, emails could only be configured to be sent when there were new exceptions.
In most cases that is the preferred behaviour but in some cases, you would need to be notified on each execution if there are any open exceptions, or you would need to be notified when exceptions are closed.
In this release, we have redesigned how to configure when exception emails are sent, so now you can choose to receive email on new exceptions, whenever there are open exceptions or when exceptions are fixed.
Furthermore, you can also choose to include a list of open exceptions and fixed exceptions in the email.
For further information, visit Exception emails
Compare Query Value Comparison
When comparing two data sources with Compare Queries, we most often want the values we are comparing to be the same, or at least, that the difference is less than a predefined threshold.
Imagine a scenario where we are comparing planned costs versus actual costs. It would be an error if actual costs are higher than planned costs, however, it would be fine if the actual costs are lower than the planned costs.
In exMon 4.0 we add Value Comparison for Compare Queries. With the value comparison dialog you can choose between error conditions, configuring the test to fail if both data providers are not the same or if a data provider is higher or lower than the other one.
You can also define a threshold of how high the difference can be before it’s counted as an error.
Data provider parameters
With exMon 3.9 we added Data provider groups, allowing you to create a single query against multiple data providers.
The Data Provider groups work great for data providers that are structured exactly the same, however, if there is a slight difference between data providers, it could result in data provider groups not being usable.
An example of this can be Navision instances that contain tables that are structured exactly the same, but the table names are prefixed differently. Then we cannot create a single query that works against all Navision providers.
To fix this issue, we have added support for data provider parameters. When used, exMon replaces all parameters used in the query before executing it on each provider.
This can, for example, be used for table names, schema names, data provider-specific filters, or other data provider-specific constants.
You configure parameters in exMon Data Governance under General > Data Provider > Provider > Parameters.
Automatic refresh of properties in exMon Data Governance
If you have developed in exMon, you have surely added a Data Provider or a user for a test you are developing, and be forced to close and reopen the test before it comes available for use.
We finally added automatic refresh of properties in exMon Data Governance so now it “just works”.
This should work for all fields in exMon Data Governance; users, Data Providers, systems, email templates and more, and should provide a much better user experience.
Salesforce and Harvest data providers – preview
In this release, we add preview support for both Salesforce and Harvest as data providers in Tests.
With those data providers, you are able to monitor data quality in your cloud data or to compare it against other data providers you store locally.
If you want to test against your Salesforce or Harvest data, please contact us and we can send you some further information about the new providers.
Other Improvements
exMon Data Governance
- Object and Process Groups allow users to select multiple tasks simultaneously.
- Execution dialog now remembers previously executed settings while the task is open.
- Execution dialog now warns if you try to execute without saving.
- Browsing for Active Directory users now works in environments with multiple domains.
- Production is now the default UAT for schedule groups.
exMon Portal
- Bug: Adding or renaming systems no longer force you to restart IIS.
Framework
- Variance is now also calculated for key errors.
- Bug: The schedule “between” issue has been fixed before the schedule would not start in the lower limit of between.
