What Is ARS Object History?
ARSOH is a filter plugin which enables Remedy administrators and developers to maintain a running history of changes to ARSystem workflow objects in a centralized repository. The daemon is capable of listening to events from multiple ARServer instances. Target operating systems for the first release include all platforms that support java.
ARSOH is capable of supporting all ARSystem workflow objects for which a Remedy server event is generated. This includes forms, fields, form views, active links, filters, escalations, containers (active link guides, filter guides, applications, and packing lists), and menus. This does not include flashboards, flashboards data sources, flashboard variables, flashboard alarms, DSO mappings, or DSO pools.
The main object audit daemon has the following characteristics:
Module 1: Object History Filter Plugin
The Object Audit Daemon captures changes to ARSystem workflow objects and stores the definition in a central repository. A strain ID will be created for each object to uniquely identify each object. The strain ID persists from the time of object creation to the time of object deletion. ARSOH will compensate for name changes to workflow objects using the ARSystem server events feature. Server events are communicated to ARSOH through a configurable polling interval.
The user interface for repository access is accomplished using standard Remedy forms. Information collected in the repository includes:
Unique identifier
Strain identifier
Server name
Name of the object
Type of operation (create, set, delete)
The object type
User making change
Timestamp of object change
Definition of object at the time of change
Revision counter
Previous version unique identifier
The end user interface for this module allows viewing of the repository via the Remedy User tool with methods to view:
Objects changed per user
Objects changed for a date range
All revisions for a given object
Why Such a Program?
There are several reasons behind the development of this program:
All too often, Remedy applications flex to the needs of the business in a way that is not conducive to the maintenance and administration of an application.
When things go wrong and applications stop working, fixes are implemented on the fly, and no record of what or how is retained.
During the application upgrade of purchased applications, reimplementation of customizations is cumbersome due to one or more of the following:
No record of customizations were generated or retained, either technical or functional
Vendor provided objects were modified and no method of identification was used to differentiate which objects were changed and which ones were not
When working with a series of workflow objects, and things just aren't going right and you need a way to go back in time with all the objects you modified
The available alternatives are clunky and cost prohibitive in terms of productivity:
This program is to the alternative what CVS is to RCS or a complete lack of control
No more checking in and checking out ARSystem workflow objects
No more object locking
Outside resources perform customizations and cry foul play after the engagement when things stop working (yes, this works both ways).
Outside resources are brought in to provide a solution and the level of technical documentation required for future maintenance is inadequate.
A better way of administering AR System Servers is long overdue.
Future Plans
The future direction of this program is speculative at this point as new and better ideas come along, but the targeted extensions are listed below. The object history daemon will serve as the underlying framework for the following modules:
Module 2: Requirement Management and Developer Check-in
This module will track, per functional requirement, various information pertaining an enhancement, module, or workflow change. In addition to tracking requirements, this module will enable each developer to check-in to a requirement under active development. By checking in to a requirement, all changes made by that developer can be tracked and correlated with a requirement. This will in turn automatically generate and maintain a packing list that includes all the objects created and modified to meet each requirement. This type of information is important for tracking bugs and during application upgrades. The information to be collected, per requirement, includes:
Requirement Specification (The what, who, when, and how)
System Generated Technical Documentation (The objects created, modified, and deleted)
Administrative Documentation (How to keep healthy, administer, integrate, and extend the module)
End User Documentation (Step by step instructions on using the feature)
Testing Documentation (Step by step instructions and requirement validation points)
Module 3: Release Management, part 1
This module will serve to track releases of the tracked enhancements (see module 2). The planned level of granularity for revision control will be four levels (i.e., version 1.0.3.1):
Level 1: Application version compatibility release level (HD 5.0 vs. HD 5.5 vs. HD 5.6)
Level 2: Module specific release level (major overhauls, rewrites)
Level 3: Functional release level (changes or additions to functionality)
Level 4: Reactive bug fixes (corrections to improper code)
This module will also seek to meet these requirements:
Ability to extract the definition files of a requirement for any revision level.
Conflict tracking and resolution. Identifies objects modified by two or more developers under the guise of two or more requirements between release cycles.
Module 4: Release Management, part 2
This module will seek to extend the capabilities added by module 3 by adding the following capabilities:
Ability to move specific enhancements between environments.
Ability to perform backwards environment refreshes of both the ARS application and the repository.
Module 5: Repository Integrations
This module will seek to take advantage of revision systems available, both commercially and through the OSI. The purpose of this effort is to offload the revision storage from the ARSystem Server to a system designed to act as a code repository. The specific version control systems under consideration include:
Subversion
CVS
PVCS
Visual SourceSafe
Module 6: Application Integrations
This module will seek to use external applications as the gateway for bug tracking and requirement management. The specific products under consideration include:
Remedy Change Management
Remedy Help Desk
Bugzilla
