ExtraView released version 20.1, which contains 46 new features and 61 fixes:
ExtraView
ExtraView Releases Version 20.0
ExtraView has released version 20, a major release with dozens of powerful new features and fixes. Additionally, starting in version 20.0, ExtraView has changed it’s release numbering scheme such that the release number reflects the year of release plus a sequence number.
ExtraView Releases Version 12.0
With the release of version 12.0 users can enjoy nearly 140 new features and fixes covering reporting, navigation, workflow, notifications, mass updates, mobile, administration, integrations, and user interfaces.
ExtraView Releases Version 11.2
We have officially released version 11.2, with dozens of new features and fixes covering reporting, navigation, workflow, notifications,, mobile, administration, integrations, localization, workspaces, meta data migrations, user interfaces, and more.
Get Fuzzy
One of my favorite scenes from the movie Bull Durham is the “Nobody gets woolly” scene:
Crash: Stop it.
Nuke: What?
Crash: It’s not woolly. Nobody gets woolly. Women get weary. They don’t get woolly. Nobody gets “stress.” They’re wearing a “dress.” I hate people that get the words wrong [referring to the song performed by Otis Redding “Try a Little Tenderness”].
That scene has nothing to do with ExtraView, but the word “fuzzy” does, and for some reason that reminds me of “woolly”.
Anyways, ExtraView Quick Find allows you to perform Fuzzy Searches. (more…)
Lightening the load – Quick Tomcat configuration tip #1
If you have configured Apache as a web server in front of the Tomcat application server for ExtraView, you will have configured a minimum of two JkMount lines.
JkMount /evj/ExtraView tomcat1
JkMount /evj/ExtraView/* tomcat1
When configured in this manner, all requests flow through Apache and to the Tomcat identified as tomcat1 in the worker.properties file. This Tomcat may be a single tomcat, or it may be a loadbalanced set of Tomcat application servers.
If you have multiple Tomcat instances configured, another option you can implement, simply by changing the configuration here, is to route all API requests – including Perforce or SalesForce integration requests – to a particular Tomcat instance.
All other requests – which are generally the interactive end-user requests through their browser – will be routed though another Tomcat instance (or set of loadbalanced Tomcats).
To implement this, we take advantage of the fact that we can identify all API requests based on the parameters that will be appended to the URL. All ExtraView API requests match the pattern “/ExtraView/ev_api.action” so we can configure the JkMount configuration such that all requests that match this pattern, are directed to a particular tomcat:
JkMount /evj/ExtraView/ev_api.action tomcat2
JkMount /evj/ExtraView/0* tomcat1
JkMount /evj/ExtraView/1* tomcat1
JkMount /evj/ExtraView/2* tomcat1
JkMount /evj/ExtraView/3* tomcat1
JkMount /evj/ExtraView/4* tomcat1
JkMount /evj/ExtraView/5* tomcat1
JkMount /evj/ExtraView/6* tomcat1
JkMount /evj/ExtraView/7* tomcat1
JkMount /evj/ExtraView/8* tomcat1
JkMount /evj/ExtraView/9* tomcat1
JkMount /evj/ExtraView/evSignon tomcat1
JkMount /evj/ExtraView tomcat1
JkMount /evj/ExtraView/ tomcat1
With the above configuration, all requests that end in “/evj/ExtraView/ev_api.action” will be routed to tomcat2 – and all other possibilities for URL requests are then itemized, and routed to tomcat1.
Why do this?
In many cases, API requests are generated programmatically, hit the server often and potentially quite hard in a regular pattern. The Perforce and SalesForce daemons are a good example – they “hit” the application every 10 seconds or so, to poll the system and see if there is any work to do. Data warehouse integrations can perform large queries to pull back all the changes to all tickets in the last 12 or 24 hours. Subversion integrations can have a trigger than runs every night to close all tickets that have been open and untouched in more than 30 days.
End users of the human variety, on the other hand, are much more unstructured in their use of the application, and tend to access the tool in a less systematic way . Because they are staring at the screen, waiting for a response to their mouse click, end users are also more sensitive to any delays than a script or daemon.
By splitting out the workload in this way, we can reduce the potential effect of any API calls on the response time for your end users who are interacting with ExtraView through the forms and screens – which makes for happier users!
You can also accomplish the same thing by providing different URLs for daemons and API users – but this method allows you to publish a single URL to access ExtraView, and still retain the option of splitting API traffic – either now, or in the future.
Who got the email?
One of the more popular feature requests we received from customers, was to keep track of which users were sent email notifications on each update. This is useful for providing an audit trail that ensures that the right people have been notified at each step in the ticket workflow – something that can be particularly important in an environment where there are service level agreements in place.
History on email notifications has been being collected in your ExtraView system since version 6.5 – with a few minutes of configuration, you can make it visible.
To enable Notification History, you must first enable permissions on a special field in the data dictionary called NOTIFICATION_HISTORY.
If your system is configured to use Abbreviated History (ABBREVIATED_HISTORY = YES in Behavior Settings), you’re done!
If your system is configured for History using layouts (ABBREVIATED_HISTORY = NO) then you have one additional step –
Once you have configured the permissions on this field, add it to your History layout using the Layout Editor. ( If the below screenshot is unfamiliar, note that it is of the new Design Center layout editor in the 7.0 version of ExtraView.)
Edit a ticket, and click the History button to see:
The information available in the Notification History section includes the timestamp of the update, the subject line used for each email, the “from” email address of the outgoing email, the list of users that particular message was sent to, and the Role of each email message generated.
Standard ExtraView email notification is generated by role. Based on the mailing list of users to be notified, we identify the current role of each recipient, and create an email message for each needed role. In this way, we ensure that each recipient receives an email that matches the security permissions for field visibility, of their current role.
Leveraging Existing Expertise in a Changing Environment
Over the years, I’ve worked with a wide variety of customers, from software development groups, to energy companies, to banks. When we get brought in on a project, many times it is because a decision has been made that the existing business processes and procedures are not working, and it’s time for a change.
Change is not universally embraced, however.
One of the frequent requests that we hear during initial implementation projects, is that management needs a certain set of reports – and this is where they pull out The Spreadsheet.
Many companies have one (or more!) of these – the Excel spreadsheet that has been maintained and updated for years, becoming more and more complex with multiple sheets incorporating data sheets, chart sheets, pivot tables, complex formulas and formatting that makes it look *just* right. (more…)
Document Management Tip – Document Fields
In ExtraView you can create an unlimited number of user defined fields (“UDFs”). UDFs can take various forms, such as lists, radio buttons, check boxes, text areas, dates, etc. UDFs can also be Document fields.
Document fields store document files of any type, such as spreadsheets, PDFs, Word documents, etc. Document fields are similar to attachments in that they allow you to upload and store files in records. Also, like attachments, security can be configured to determine who can upload, view, and/or remove documents. Additionally, you can perform keyword searching on files stored in Document fields. (more…)




