We’re excited to announce our lastest patch release for 5.0, and it is a HUGE one. The patch provides the usual collection of bug fixes (for details, see xMatters 5.0 patch 004 Release Notes) and adds the longest list of cool new features I think we have ever delivered in a patch. Here are the top features in the release:
We talk to our database a lot. That hurts our transactional throughput because we write to the database a lot. That hurts our reporting because we read from the database a lot. That makes our DR processes harder because our databases are big. None of these things are good.
In our quest to give our database a break we are changing how we record our event information to the database. That will not only help all of the previously mentioned problems, it will also give us a chance to review our existing reports and make sure they are solving actual Client problems. We have been working on this problem for several months and in this patch we are providing the first set of new reports to our software Clients (our on demand Clients received these reports in their Summer release). And over the next few patches we will continue to layer in enhancments to these reports as well as introduce some new reports.
Let's first look at the old reports. Here are the main offenders:
- Notification Summary - A trimmed down view of our Exhaustive Report, which basically makes for an Event Summary with pretty colors. It does show a summary of the notifications, but it doesn't auto-update and isn't as intelligible as we would like for it to be.
- Event Summary - A two part report with event information at the top and notification summary information down low. Oh, and a hidden Easter egg somewhere in the middle that shows more details. The event information and details are handy, but the notification summary information is redundant.
- Exhaustive - Shows everything. Seriously, EVERYTHING! And has a chronological view and a hierarchical view. It can take a very long time to run this report and can consume a lot of web server and database resources.
So let's talk about the new world order. We are changing the way we fundamentally work with the database and in doing so we have to make some changes to reporting. We are going to now report off of what is called Audit Data. There is less of it because it is only created as needed. As a result of this change, we need to point all of our reports at the Audit Data instead of the "exhausting data". So while we are in there, we thought we should optimize the reports to answer the key questions:
- What the heck is going on with my event?
- Why did X get notified?
- Why the @#$% didn't X get notified?
Here is how we get there in this patch:
New Report #1: Replace the Event Summary and Notification Summary with what was formerly the REB Tracking Report. Now it is just the Tracking teport. The biggest benefit of the Tracking report is that it provides real-time updating of notification status. Here is what it looks like:
If you click on any of the statuses you are taken to a drill-through which shows the detail records that match the criteria for the box you clicked on:
We aren't done with this report yet. In the next patch you will get some additional great new features including the ability to export the data in the drill-through screens to an Excel export. But for now we believe it provides immense value by displaying the real-time notification statuses and the interactive drill-through.
New Report #2: The Exhausting Report will be replaced with a Log (who doesn't love logs?). It loses the hierarchical view (don't worry) but it also loses the 1990's pagination and the terrible performance. Plus it gains a killer new search capability to search for recipients using our typeahead recipient selector. And because we got rid of that nasty pagination it will find you log entries from anywhere in the report (which is why you shouldn't have worried about the hierarchical view going away). Here is a sample search:
New Report #3: We all love a good Easter egg, but not in our enterprise software, so we decided to replace the super double top secret "See All" link in the Event Summary report with a Properties report, complete with Event
Here is the Replay Event link's page which allows you to re-send the same event - perfect for testing your message and process:
The new reports are accessed from our Events Activity, Events for User and Events for Group reports which have been updated with a new dropdown widget which shows the new reports in the top and the older reports at the bottom. There also is an Conference indicator which shows you the Scenarios/Advanced Messaging events which have a conference bridge associated with them. We will eventually remove the older reports, but we wanted to provide a transition for Clients to get used to the new reports. Here is how the transition stage looks where we show both the old and new reports:
We aren't done yet! In the next patch you will get the following great new reporting features and more:
- Export for the drill-through views
- A revised pagination widget for the Log and the drill-through views.
- A jump-to-parent navigation tip in the Log view to navigate to the parent of the current log record.
- A new report called the Report Card which allows you to set a "% delivered" threshold and compare your notification processes to that metric.
- Improvements and replacements for the Administrator-level reports such as Submitted Notifications and Live Notifications.
Fill Counts are one of the most powerful tools in our communication plans (Scenarios), but their power can come with a cost: usability. So we put our UI/UX experts to work to come up with a better solution for showing Fill Counts. We call it Scenario Type. When you build out your recipient definition you will find a Scenario Type selector that triggers various Fill Count behaviors. The default type is Broadcast, which represents the most common behavior our clients use today.
Here's a handy list of the Scenario Types, with descriptions, to help you get the flavor of what they're all about:
- Broadcast - The Scenario will end when the configured Duration for the Scenario has elapsed.
- Quorum - The Scenario will end when the General Fill Count is met or the configured Duration has elapsed. (Useful when a specific number of responses are needed, but there are no special skills required)
- Assembly - The Scenario will end when all Fill Count are met or the configured Duration has elapsed. (Useful when you need a mix of special skills and unspecialized responders)
- Group Assembly - The Scenario will end when all Group Fill Counts are met or the configured Duration has elapsed. (Useful when you need special skill sets)
No changes are required for existing clients; your Scenarios will automagically default to the correct Scenario Type. And, any new Scenario will be much easier to design.
Information security is an important consideration for all organizations in this day and age. To support these security requirements we are providing a new feature which allows an xMatters administrator to define a list of valid email domains which xMatters users must stay within when they add a new email device. The initial release of this feature will block a user from adding any new email devices through the UI that don't match the list of valid domains. Any existing email devices which fall outside of compliance will still be active in the system, but the user of the device will not be allowed to make any changes to the device without bringing the address into compliance.
Parlez-vous français? I don't, but the xMatters SMS compliance UI screens and the messages sent to users are now available for translation in all of the langauges that we support.
SMS compliance is becoming a trickier situation every day. Carriers don't want to deliver messages they aren't going to be paid for, and users don't want to pay for messages they didn't ask for (aka SPAM). As such, SMS aggregators and carriers can impose penalties on xMatters clients if they consistently renotify a user/device which a carrier is saying doesn't want the message. Our latest SMS feature helps everybody by allowing the xMatters administrator to enter a list of SMPP codes that we can catch to automatically deactivate the device. When we deactivate the device we can notify the user (but not on the deactivated device - obviously), their supervisor and the supervisor of every group they are a member of.
The latest translations are in for our supported languages.
Clients who license our multi-tenant service provider product have unique security and support needs: on the one hand they need to keep their tenant's data segregated, but they also need to provide communication processes which span the tenant's users and the users who are tasked with supporting the tenants. With this release we have revised the mechanism for granting access to users to perform support roles. The new mechanism is more restrictive in that it requires a support user have an explicit mapping to a user in the tenant company. Additionally the user in the tenant company is allowed to have one, and only one, mapping. And the tenant company user is not allowed to have any devices because the user is not to be notified.
Why all the changes and restrictions?
- The mapping restrictions make the Information Security folks happy because shared user ID's are a no-no.
- The device restrictions on mapped users are there because mapped users are not intended to be notified - our service provider features allow you to target the actual support user which means the support user only has to maintain their contact information in one company. Ditto for targeting support groups, which can be centrally maintained in the support organization and referenced from tenant notification processes.
Here is a sample view of the mapping screen showing a search across tenant companies which is pulling back users from a company named "Suzie" and another named "Acme":
t is a smaller "bit twiddling" feature, but we added optional support for quality of protection ("qop") for SIP messages. There is no user interface as the exchange is done down in the protocol level and automatically changes our registration procedures based on the presence of qop. The new support of this feature doesn't change the official list of SIP environments that we support, but it does allow us to evaluate expanding to other platforms - in this case Nortel CS2k servers.
These are the main new features in this release, but please check out the full release notes for all of the details on these features as well as a few others. We hope you enjoy the new release!
Until the next update,
The xMatters Team