Welcome to Nastel's monthly support newsletter! In this month’s newsletter, we are going to focus on the Nastel support system.
In addition to the support newsletter, be sure to follow Nastel on your favorite social media channel, LinkedIn, Twitter, or Facebook. We provide product-related updates, pertinent articles, webinars and videos there. This newsletter is targeted at existing customers and provides general product related updates. There is still a lot more to know about Nastel!
Table of Contents
Many of you reading this have probably registered to use the support center, but if you haven’t yet, the process is easy, just click here:
We ask you to register yourself since we find that it is easier to remember your user name. You must remember this name as it is your access to the support system. You can use your email address as your user name. If you want to know associated issue numbers, the support team can make them available.
The overall flow of a ticket is shown in this diagram:
While there are a variety of stages, there are 3 that you are involved in.
- New - This status is defined when an issue is initially open. At this point, it has not yet been assigned for review. There are several key pieces of data that we need a ticket is opened:
- Category: The product or component associated with the problem
- Reproducibility: How often the product occurs
- Severity: What is the severity of the impact on you
- Priority: How urgent is the issue (see notes below)
- Profile: The version of the associated product or component
- Summary: A meaningful summary of the issue. Avoid being too general, such as “getting an error” or “please help”.
- Description: Detailed notes about the issue being reported
- Upload files: Any pertinent logs, documents, files, images
- Feedback – Additional information is needed to continue. This could be responses to questions about the environment. Other examples include traces or logs to analyze the cause of a problem either as files or streamed to the support portal.
- Once the information has been provided, the customer can respond with a note and/or change the status to assigned
- Verification – A solution, response, or permanent fix to a problem has been provided. The support representative is waiting for the customer to verify this addresses the problem.
- If the verification confirms the issue is addressed, the customer responds with a note and/or changes the status to resolved
- If the verification fails, the customer responds with a note and/or changes the status to assigned
Priority determines the urgency of a ticket and response times to address it. Priority can be Immediate (P1), Urgent or High (P2), Normal (P3), or Low (P4). As indicated, a P1 Immediate ticket needs to be serviced right away. It will be escalated as needed within the support organization. It is important that for a P1 issue that your company resources are available to work on the ticket as required. P2 Urgent and High tickets are just a step lower than P1, but have a less critical impact. Using an analogy, P1: my fire alarm is going off; P2: my fire alarm is broken; P3: my fire alarm battery needs to be replaced; P4: my fire alarm documentation has a typo. Severity is related to priority but is not a measure of urgency, but how the issue is affecting you.
Note that the development teams work off a different set of issues. These “internal” tickets are the ones we assign to releases and work on. They exist because there could be multiple internal tickets created from one customer request or multiple customers might have the same issue related to a single internal ticket. When the issue is addressed and is marked to be resolved, the fixing release will be indicated. It is not always possible to directly identify the specifically related fixes in the release notes since the internal ticket(s) may have different summary information.
One of the areas we get frequent questions around is enhancement requests. These are cases where the product does not work the way you would like it to, or you want something new that you believe would be beneficial to your company. In this case, the issue severity is assigned to the feature. Like all developers of software solutions, we get a lot of feature requests and we review and discuss them all, and try to satisfy as many as possible. The general criteria as to when that happens are based on value to you and other customers. Some enhancements may take longer than others to get to and some are determined to not make sense to be added to the product (for a number of reasons). When an enhancement request moves from an acknowledged status to confirmed, this means that it has been targeted for a release.
There is still no guarantee a "confirmed" enhancement request will make the next release as, with any agile development effort, it may not end up in scope. One thing to consider when opening an enhancement request is to describe what you are trying to do, not how. That is, using my analogy above, consider an enhancement request to make the smoke detector reset button bigger. But the real issue is that the smoke detector is going off too frequently and you want the button bigger to make it easier to reset. What we want to know is the real requirement, to improve the smoke detector alarming frequency.
If there is something you want quickly, one option to consider is having the Nastel professional services team implement it for you. Since Nastel products are designed to be extensible, in many cases, there are ways to do things without waiting for the feature to be implemented in code. For example, if there is data that is needed, we can use one of the many data collectors to augment the core data that is needed. An example of this was recent changes for RDQM, which were added new commands and data via the CD releases. When this was still being developed for Navigator 10.1, we worked with several customers to provide the key data they required.
In the Nastel Resource Center, you will find several related articles and how-to videos on using the support system.
2. Popular FAQs
Q: Where can I find previous Newsletters?
A: Previous newsletters are located HERE.
Q: Getting an error 404 after deploying Nastel Navigator to Apache Tomcat; why?
A: After deploying Nastel Navigator to Apache Tomcat, a 404 error sometimes appears in the browser console when trying to access the Nastel Navigator URL using ip:port/navigator. See the solution HERE.
Q: In Navigator, when I save messages to file, I get a message saying it saved but no file is created; why is that?
A: This is an indicator that the temporary file used to store the results could not be created. You need to check the location of the temp file folder. See more details about this error HERE.
3. XRay COVID-19 Data Lake
Nastel has pulled together multiple COVID-19 datasets from CDC, Johns Hopkins University and several others into a single interactive data lake on which you can:
- Run your own queries & computations
- Create analytics & web dashboards
- Share your charts & graphs in web apps
The data lake is updated daily with the latest COVID-19 stats from around the world. View the dashboard live, no registration required)!
4. Webinars & TechTalks
Hopefully you had a chance to attend the first of the Nastel Customer Webinars for 2021. If you did then you know some of the information in this month's newsletter already, if not then watch our webinar replay or view our slide deck for Nastel Technologies Overview of Product Updates 2021!
- What’s new in Nastel AutoPilot, Nastel Navigator and Nastel XRay
- Introducing Navigator X
- Other New Developments (including a new DevOps benchmarking tool to try for free)
Click HERE to see our library of other on-demand sessions.
5. Keeping up with Nastel
Nastel has exciting new things going on all the time and we want to ensure you and your colleagues can easily find our recent press releases and other news.
Click HERE to read Nastel news.
6. Nastels' blog
Click HERE to read Nastel's blog.