ARS 7.6 - What's new? (Part One)
The official BMC release notes for ARS 7.6.3 describe all of the new features and known issues of BMC Remedy AR System (ARS) 7.6.3. (This document can be downloaded from BMC's site with a valid support account.) This article will technically review the new features and look beneath the hood to identify the benefits, pitfalls and opportunities which 7.6.3 brings us.
ARS 1.1 was released in Q4 1992, 18 years later the application development toolkit underpins the industry leading BMC Remedy ITSM Suite. Remedy Corporation saw ARS as both a rapid development toolkit and an ideal technology for the IT Service Management market. Bespoke applications developed using ARS were as, if not more, common than the applications developed by Remedy Corp. Over time, the focus of Remedy Corp, then BMC, was for ARS to take second place to the comprehensive ITSM Suite applications developed using the ARS toolkit. The number of bespoke Remedy applications has been declining as the ITSM suite has grown more popular and ubiquitous. BMC have now positioned the ITSM Suite as a high-end platform for IT Service Management within the context of BMC BSM; consequently fewer companies are leveraging ARS as a bespoke application development platform.
The recent releases of ARS 7.5 and ARS 7.6 have elevated both the development platform and architecture of ARS to become truly modern and very feature-rich. Ironically, bespoke application development using Remedy is now finally capable of creating sophisticated and feature rich applications with excellent user experiences; just as the capabilities of the toolkit are least well promoted.
Typically releases for ARS follow a pattern where a release has been primarily focused on the back-end, development and infrastructure OR the user experience.
ARS 7.5 contained a large number of user interface enhancements, and because ARS 8.0 will be the first release which does not include the Remedy User Tool, we would expect ARS 8.0 to be a UI-focused release. Once BMC are able to focus purely on the web interface without being constrained by the development overhead of a dual platform user interface, we can expect substantial steps forward with ARS 8.0.
We would therefore expect ARS 7.6 to be an architecturally focused release, building on and refining the functionality brought in with ARS 7.5. We are not disappointed in this expectation; ARS 7.6 is primarily focused on improving performance of the infrastructure and applications. This release also has some thoughtful improvements to the web architecture which lay the foundation for ARS 8.0. Finally, ARS 7.6 sees some very welcome refinements of the new objects introduced in ARS 7.5 as well as some great new features.
Performance Improvements
In our opinion this is a key driver for this architectural release. The footprint of ARS has grown increasingly larger as the target market has moved into the enterprise space. The vast array of new features in ARS 7.5 has introduced some performance issues for customers, however for consultants the system requirements of the new ARS 7.5 and 7.6 environments are challenging.
Previously it was possible to run a full ARS and ITSM server installation within a VM on a laptop and even to run multiple VMs in parallel. Our recent build of a Windows VM running Oracle, ARS 7.6, and the full ITSM 7 suite requires far more memory and system resources than ever before. A minimum of 1 GB RAM is required to enable the VM to run at all, around 2GB is needed to be able to develop workflow, around 3-4GB is required for a performance good enough for customer demonstrations. We hope to see more innovation from BMC to allow the performance of the platform and applications to support Laptop virtualisation.
Improved Mid Tier Caching
There are several significant improvements to the way Mid Tier handles its cache.
As always, changes to the workflow of a Remedy application need to be carefully planned due to the recaching of both ARS and Mid Tier server caches. Recaching has been an issue for a while and BMC are targeting this persistent issue by improving the way Mid Tier recaches.
In ARS 7.6.3, the Mid Tier cache now updates only those workflow objects which have been changed - rather than rebuilding the entire cache when a single Active Link is changed. This 'smart' recaching only works for ARS Servers which are in production mode i.e. Development cache is turned off.
BMC are leveraging the open-source Java caching solution Ehcache to handle the Mid Tier's cache of ARS workflow objects. This tool has enabled caching to be persistent, much like Remedy Workflow is cached for the Remedy User Tool, Ehcache allows the Mid Tier cache to be written to the file system and reused after a Mid Tier server restarts. This functionality has to be explicitly enabled for the Mid Tier. Cache persistence promises to reduce the start up time for Mid Tier servers, particularly relevant in enterprise environments. Ehcache provides many configuration options including the ability to change the weight given to different types of objects. Finding the right combination of settings to optimise performance will be challenging and time-consuming for most Remedy support teams.
The long-hoped-for simplification of the pre-fetch functionality in ARS Mid Tier is finally here! It was possible to create an XML document listing all Forms which should be loaded into the cache when a Mid Tier Server starts up was both. Creating this XML document was difficult and exceptionally timeconsuming, as the process was entirely manual. BMC have implemented some excellent improvements in this area.
- Forms with active links and menus are preloaded into the system’s memory. Mid Tier makes the assumption that if a Form has Active Links or Menus on its fields, it is probably a user interface and will be accessed by users. As we often see menus on Join Forms and backend Forms, it remains to be seen how effective that assumption is.
- For legacy purposes, if a prefetchConfig.xml file exists then all of the forms and views specified in that file are preloaded.
- Views are preloaded according to usage statistics gathered by the mid tier server. Its not clear whether these usage statistics also capture the group permissions of the users accessing Forms, as this affects the workflow which needs to be cached.
This is a great step and we hope to see more automated, self-improving performance enhancements in ARS 8.0 which will be entirely web-based.
Mid Tier Performance Monitoring
It is now possible to monitor real-time Mid-Tier performance using a JMX console such as JConsole (http://java.sun.com/developer/technicalArticles/J2SE/jconsole.html). We'll be looking at this functionality in more detail to see how this new feature can best be leveraged. This enhancement reinforces BMC's use of Java and standard web technologies to support its offering.
Mid Tier Network Performance
Once of the main gripes network administrators have with Remedy is its "chattiness". There are a great many interactions between client and server for any user operation. BMC have focused on this area and have reduced the number of roundtrips between the browser client and server. In addition work has been done to make page loading more efficient. In line with the phasing out of the Remedy User Tool, no development effort has been spent specifically optimising the network interactions of the Remedy User Tool.
Client-side data
In support of the efforts to reduce the network chattiness of the Mid Tier Client a new set of features which support management of Table data has been added in this version. To summarise this enhancement, this change allows the client to manage table data sets locally, without needing to apply changes to the database. this represents a significant performance improvement over previous versions, where all changes to data being displayed in tables needed to be committed to the database, and the table data refreshed before the changed data could be displayed to users. This change currently only affects tables, and allows table rows to be modified, created or deleted on the local client and then all changes to be committed as a batch.
This will certainly improve performance in locations where users are working with large data sets in tables, and, its possible to leverage this functionality in other areas by simply hiding a table implementing this functionality.
This change is a significant enhancement to the workflow which signals that BMC are thinking carefully about client-server interactions in workflow. However to leverage the benefits of this change requires workflow redevelopment, and careful thought from developers;
1) New entries and modified entries are not sent to the server immediately but sent in a batched update. Consideration needs to be given to how a failure to update data as part of a batch update, which is a single transaction, is handled. As usual with Remedy a failure in a transaction will cause the whole transaction to rollback. A developer needs to consider how this failure will be presented to users.
2) Modified data is no longer sent to the server each time, any Filters which are responsible for data integrity may need to be duplicated in Active Links. If there are a lot of checks against data held in other Forms when modifying or creating table entries then moving these to the client may lose the network performance benefits of batch updates.
Window Opening Simplified
At some point in the history of the Window Open, Window Loaded and Display Active Link firing conditions, someone got very confused. Here's the explanation from BMC about how this ended up working in ARS 7.5;
When you opened a new window in Modify mode, seven sets of active links executed: Window Open (first of two), Window Loaded, Set Default, Search, Window Closed, Window Open (second of two), and Display.
This not only made developing workflow complex but also caused performance issues on the client when duplicate workflow fired unnecessarily. ARS 7.6 has a new Window Open mode called "Modify Directly" which will only trigger Window Open and Display. This will not change legacy behaviour of applications as this new mode has to be explicitly invoked. It seems curious that Window Open was chosen in preference to Window Loaded, but the rationalisation here is welcome.
API Get Set
After changing the values of an entry using this new API command, the data from the entry is automatically retrieved. This should have a minor network performance benefit in reducing the number of API calls.
That's all for this round up of ARS 7.6.3. We'll be taking look at the new UI enhancements in the next blog post.
Alderstone
Reader Comments