Systems,
Releases and Items
BETA I
User`s
Guide
April 2005
Change Record
|
Date |
Who |
What |
|
|
|
|
|
06-Apr-2005 |
JJM/MGTech |
Added Moving an Item |
|
28-Aug-2004 |
JJM/MGTech |
Initial draft for BETA I. |
Instructions
If, after reviewing this document, SRI looks
interesting to you, then contact us regarding obtaining a BETA copy for
your detailed comments. We will provide
a temporary link to the SRI Client Installer BETA for your free
evaluation. The SRI Client Installer is
12M in size and includes everything needed to configure a complete SRI
production environment.
Overview
SRI is a single rooted hierarchy that extends three levels deep. This is a simple yet surprisingly powerful structure. There can only be one starting point for any SRI hierarchy. Each hierarchy branch terminates after a maximum of two levels. The follow figure illustrates the SRI hierarchy:
Systems
Releases
.
.
Release
Items
Items
A single System starts the hierarchy. It is composed of an arbitrary number of Releases each of which is composed of an arbitrary number of Items. Typically, this architecture is used to represent current time at the start of each hierarchy (a System) that is made of preceding Releases and Items. This does not always need to be the case however and the structure can be thought of as not having any particular time direction at all.
A SRI database is composed of one or more stored SRI hierarchies. SRI is intended to model processes that contain dependent elements that ultimately make up a completed unit. SRI then allows the state of any number of processes to be tracked and stored for trending analysis and reporting. Some possible SRI scenarios include:
· Assembly and manufacturing activities where complete units are made up of custom components each needing different tracking requirements.
· Aging applications that report on pending operations such as Account Receivables or Billing Systems. SRI could be used to create a pending Item and then arrange for that item to transit through different thresholds with time.
· Software development organizations that build applications made of chronological releases. SRI can measure and store each point in a given codesets’ life cycle from development, testing and production support.
· A Field Service Operations Center dispatching Field Engineers to remote sites. SRI will keep a history of past problem resolutions as well as quantify the current overall maintenance effort.
· Etc…
Features
In order to facilitate hierarchical process modeling in a production environment, SRI BETA I implements the following attributes:
· A multi-user, portable database schema supported by any Microsoft ADO® provider.
· Database objects bound to a client view. As the SRI hierarchy is modified in a client or the database, each is synchronized to reflect the current state of the hierarchy.
· The ability to access different SRI databases from the same client.
· Item aging through three ascending threshold magnitudes. Each element in the hierarchy can be assigned an individual threshold model. Each threshold can have different ranges assigned before breaching adjacent thresholds.
· Hierarchy security varying by Owner and Admin roles.
· A user configurable, built-in reporting engine.
· The ability to export the data to external formats such as Microsoft Excel®.
· Run time instrumentation and monitoring. An Administrator can use SRI to set up automatic monitoring of the SRI database and its connected clients. Programmable monitor filters can trap unattended alarms and events and initiate automatic actions.
· Online System Administration providing the ability to configure global parameters as well as maintain individual SRI clients on a running system (much more planned for Release 2).
· SRI hierarchy distribution through a dynamic Request Map that allows for real time scalability across different database hosts and databases (planned for Release 2).
· Highly generalized source code modules that lend themselves towards rapid site customizations. Contact Morning Glory Technologies for more details on leasing SRI sources.
Getting Started
Please read Systems, Releases and Items Release Notes and Systems, Releases and Items Installation Guide for important new information before using SRI. This document assumes that the SRI server environment and database have been established and specified for your SRI client and that a successful SRI client installation on your workstation has occurred.
Accepting the defaults during the SRI client setup will install all the components needed to operate the client. The default client environment provided by the SRI client installer is a standalone, self-contained SRI database and client.
The SRI client installer creates a new, empty SRI database and establishes a default Administrator account for it. The default Administrator username for newly created SRI databases is Admin. The password is Admin.
Depending on your particular SRI installation, you may have
a local client installed on your workstation or a link to a one on a
server. The SRI client looks for a
file named SRI.ini in its execution directory. This is the folder that the SRI
client was started from. The client refers to this file at startup in order set
various run time behavior and to find a default SRI database to log into. See your SRI Administrator for more
details.
Document Conventions
·
Items given simultaneously in BOLD and Italic
in this document are references to Menu, Command
and other items within the SRI client user interface.
Logging In
Upon startup, SRI looks for an initialization file called SRI.ini in its execution directory. This file contains settings that control run time behavior and specifies where to find the users’ default SRI database. After looking up the default database, a connection is attempted. If the connection attempt succeeds, SRI presents the database login dialog:
The label shown at the bottom displays the default SRI database and other status while logging in. Passwords are case sensitive. If this is a newly created SRI database, there is one account created with Admin privileges. The default username is Admin. The default password is Admin.
Systems
After logging in the SRI client, all the Systems in the default SRI database are displayed:
This view can be recalled at anytime by clicking the Systems menu at the top of the client. Click on a System in this view to show it’s current Production release. Each System in a SRI database is annotated with the Release within the hierarchy that represents the current system. Production Releases within a System can be designated using the Release Tree or Releases view of a selected System. Double click a System to display its Release Tree and related Items. The System view also permits System Owners and Administrators to add a new System to the database or edit an existing one. The bottom bar shows the current client Role as well as other status.
Adding a System
Click the Add System command button at the bottom of Systems view or right click on the Systems view and select the Add System item from the Popup menu
Pick an Owner from the pull down menu if you’d like to change it from the currently logged in user. Click the Save command button to save the new System or click the Quit command button to abandon the Add operation without saving anything.
A default Release and Item record are created on the database and that release is designated as the current System:
Editing a System
System Owners and Admin users can Edit System info from the Systems view:
Releases
The Releases that comprise a System are accessible from the Systems view. There are two views of a Systems’ Releases: Release Tree and Release Information
Release Tree
Entire SRI hierarchies are accessible via the Release Tree view. Double click on a System in the System view or click the Release Tree command button at the bottom of the System view to access that system’s Releases and Items.
Double click on a System to expand its Releases. Double click on a Release node to expand it and expose the Items under it.
Release Maintenance
A Release can be designated as the current system by right clicking on a Release in the Release Tree and selecting Make Production Release from the popup menu that appears.
Right Click a System node in the Release Tree and select Add Release to create a new release under that System. System Owners and Administrators can move individual Items between Releases using the Release Tree. Drag Items and drop them into a Release node to move that Item to that Release.
Right click on a Release Node and select Delete Release to delete that Release and all the Items under it:
There must be at least one Production Release per System.
Release Information
System owners and Administrators may edit release information in this view. Right Click on a system in the System view and select Releases from the popup menu or click the Releases command button at the bottom of the System view to access that system’s Releases:
Release info such as Version, Title, Description and Release Date can be edited from this view.
Items
Editing Item Details
Double clicking on an Item in the Release Tree opens that Item in edit view.
Clients that aren’t the System owner or an Admin can only edit Unit Test info such as Item Description, Item Resolution and Unit Test Completed date.
Moving an Item
It is possible for system owners and administrators to move Items between Releases. Items can even be moved between Releases in different Systems. Drag an item from a Release Tree to it’s new Release within the same SRI hierarchy or a completely different one.
GYR Thresholds
Green-Yellow-Red Thresholds are a measurement of an
Item’s age. An Items age is determined
from its Date Assigned if the Items Status is Open or from its System
Test Completed date if the Item is Closed. Operate the sliders underneath a Threshold’s color
to modify the GYR Threshold ranges for the Item. There is a range of 365 days that can be distributed among the
Threshold colors. Modifying either the
Assignee, Date Assigned, Status or GYR Thresholds
fields has the potential to change the Days Open value. GYR Thresholds are used in GYR
Reports.
An Assignee indicates that an Item is ready for System Test by designating a Unit Test Completed date and associated Item Resolution. A System Owner Closes an Item after successful system test by assigning a System Test Completed date, Item Resolution and finally by setting the Item’s Status to Closed. You must click Save to commit changes.
Reports
GYR Reports
GYR Reports are a collection of Items that result from queries generated by the GYR Reporting Engine. The GYR Reporting Engine interface is invoked by clicking on the GYR Reports item under the Reports menu in the SRI client:
The GYR Report Engine interface is organized into two distinct groups: The Systems, Releases and Persons group depicted by the three lists on the upper left and the GYR Thresholds, Priority and Status group shown in the bottom eight check boxes. The Sort Order frame shown in the upper right is used to sort the report output. The SQL box in the bottom right shows the generated SQL from the report engine.
If rows from only one group are selected, UNION queries are generated that includes all the rows from each element in that group. If rows from both groups are selected, UNION queries are generated for rows selected in the Systems, Releases and Persons groups but the resulting dataset is appended with a WHERE clause formed from the GYR Thresholds, Priority and Status group.
The following shows the generated SQL for three Systems with Items in the Yellow GYR Threshold range.
SELECT * FROM
(SELECT S1.System_Title,
R1.Release_Version,
R1.Release_Title, Bug_id,
Items.Release_ID, Person_ID,
Green,Yellow, Assigned_DT, Status,
ST_complete_DT, Bug_Description,
Bug_Resolution, UT_Complete_DT,
Priority, SubSystem, Update_By,
Update_DT
FROM [
(SELECT
B.* FROM BUGS B, RELEASES R
WHERE B.RELEASE_ID = R.RELEASE_ID
AND (
R.SYSTEM_ID = 13 OR
R.SYSTEM_ID = 10 OR
R.SYSTEM_ID = 1))
]. AS
Items, Releases R1, Systems S1
WHERE Items.Release_ID = R1.Release_ID
AND R1.System_ID = S1.System_ID)
WHERE ((INT(NOW()
- Assigned_DT) > Green)
AND (INT(NOW() -
Assigned_DT) <= Yellow)
AND Status = 'O')
The code highlighted in Blue is a standard wrapper that surrounds the generated SQL. This wrapper includes the Systems and Releases portion of the SRI hierarchy in the resulting list of Items. This is done to keep the series of generated SQL blocks trivial and to allow for easier maintenance.
The code shows the generated SQL from each element in the two groups. Since elements from both groups were selected, a WHERE clause made from the GYR Thresholds, Priority and Status group (Yellow) is appended.
Note that the only appropriate logical operator to use while combining elements in a GYR UNION query or WHERE clause is OR. AND is never appropriate for any GYR query.
The Sort Order frame in the upper right of the GYR Reports Engine UI is used to sort the resulting Items list. Drag sort columns from the list of the Available Columns into the Selected Columns list. Drag columns in the Selected Columns list into the desired order for the sorted list of Items in the GYR Display.
Click the ASC or DESC buttons to control if increasing or decreasing values are shown in the sorted list of Items
Click Run to execute the generated query and create a GYR Display of the resulting Items.
GYR Displays
GYR Displays show the Items list from GYR Reports Engine queries. Items in the list are available for further SRI operations or for export into a csv (comma separated values) flat file suitable for input into external application such as Microsoft Excel®.
Double click on an Item in the list or click the Edit Item button to edit the item. Click the Show SQL Button to display the generated GYR query used to create the list. The Status Bar on the bottom shows the System and Release an Item belongs to. Click on the Status Bar to invoke the Release Tree the Item falls under.
Items in the list are evaluated for their current Color displayed in the Days Open label. The Item’s age is ascertained by inspecting the Status for each item. If the Item is Open (Status = O), then the Item’s Assigned Date is subtracted from the current date. The result is compared to the GYR Threshold ranges in effect for that item and the appropriate color is set. If the Item’s Status is Closed (Status = C), then the item’s System Test Date is substituted for Assigned Date in the calculation and the Days Open label is annotated.
Exporting Data
Items displayed in the GYR Display or in an Item Edit form can be exported to a csv (comma separated values) flat file that contains the System, Release and all the Item information in the list. This file can be opened directly by Microsoft Excel® and others. To create a csv file from the list of Items, click the Export item under the File menu:
Select a filename to store the csv file in using the File Open common Dialog:
After selecting a file to store the csv file in, the SRI client opens the file:
The Excel objects aren’t available if Microsoft Excel® isn’t installed on your computer.
The SRI client creates a log file in the directory the export was saved in for each Item list exported. The log file contains the time of the export and the actual generated SQL used to create the export:
This information is also kept in the global application log maintained by each SRI client on the SRI server. See the Application Environment section in the Administration chapter for more details.
SRI Client
The SRI client looks for SRI.ini in its execution folder (the directory SRI was called from) in order to resolve the default database to use and set other run time settings. It is possible to edit these settings using the client and then re-cache the new settings afterwards while the client is still running. Select Edit Defaults from the File menu at the top of the SRI client to accomplish this:
This invokes a Windows Notepad® editing session on SRI.ini. The client waits until Notepad has exited and then re-reads SRI.ini using any new settings without having to re-start the client.
The Open item under the File menu lets you browse for another SRI database to log into. You can also Drag and Drop SRI databases from Windows Explorer on to the SRI client workspace to open them. The current database is closed if opening the new one succeeds.
Admin users gain additional item under this menu called New that allows them to create a new SRI database initialized with default settings.
SRI.ini
SRI.ini is divided into two sections: Database and Debug. The first section specifies where the client may find all the pieces that make up a SRI application. Ask your SRI administrator which Server and Paths to use in this section for your installation.
In the Debug section, setting SQLTrace to True will cause your client to log the actual SQL strings used while interacting with the SRI database into the global application log.
Setting LocalLog to True causes your client to ignore the global application log sending messages to a log on its local execution directory instead. This segregates your client’s messages into its own log.
Administration
Application Environment
The SRI application is composed of a SRI database and one or more connected clients.
The data access method is Microsoft ADO 2.5. The SQL used to access a SRI database is ANSI compatible and not specific to a particular database vendor. An entire SRI schema could be exported to any database host that supports ADO. The default SRI database shipped with the client installer is Microsoft’s distributable Jet 4.0 OLE DB Provider. This format is compatible with Microsoft Access.
The location of the SRI database is specified in each client’s SRI.ini file. The SRI.ini Database section allows you to specify where a client finds the startup SRI database and where to write client messages. The SRI.ini setting ArchiveServer specifies the network node name that contains the default SRI database. Setting ArchiveDir specifies its folder on the ArchiveServer
Each client writes to a log file named after the currently connected database name. The client appends the database name with a .log file extension. The client attempts to open this file on either the server and path specified in the SRI.ini ArchiveServer and AppDir settings or in the client’s execution direction if SRI.ini setting LocalLog is set to false. This allows a client to write their messages into a separate log or to arrange for all clients to write into a single, common log.
The directory specified in AppDir is also used to tell the client where to find the help and mod folders. These folders store the resources needed for the online Help pages and the Message of the Day files. These folders contain web pages that a SRI client can display in their embedded web browsers.
The client displays the root document \\ArchiveServer\AppDir\help\Help.html if a user clicks Contents under the Help menu item.
The client embedded browser navigates to \\ArchiveServer\AppDir\mod\mod.html at startup if the Database Parameter SHOWMOD is set to True.
Database Parameters affect all clients at log in and are described in the Admin Menu section of this document.
Admin Menu
SRI clients designated as Admin users gain extended privileges. They are regarded by the client as a System Owner for all Systems in the database. They can edit all aspects of a System and its Releases and Items.
Admin users can create new SRI databases by clicking the New item under the File menu. The SRI client creates a new SRI database with a single SRI hierarchy. A single Admin user is created. The default username is Admin. The default password is Admin.
Admin users display an additional menu item in the SRI client called Admin. This menu provides access to the SRI run
time Tools and Monitor:
The Tools menu allows you to edit the list of authorized users and their roles.
Click on an Authorized User and press the Delete key to erase that user. Enter data on the row proceeded by a * to begin entering information for a new user. Press Enter to save the new user. Edits made to the grid are automatically transferred to the database.
The Current Users grid shows currently connected SRI clients. Inspecting the list of Authorized Users generates this list. Whenever a SRI client logs into a SRI database, the clients’ row is looked up in the list of Authorized Users and the Last Login field for that user is updated with the current data and time. When the client logs out, the Last Logout field is updated with the current date and time. If a clients’ Last Logout field is greater than the current Last Login field, that client is assumed to be still logged in.
It may be possible for a client to exit before it has had time to update the Authorized Users list requiring a re-login to clear the list or manual edits of the Last Logout and Last Login fields in the list of Authorized Users by the Administrator
The Admin Tool Settings allows you to configure global settings that affect all the authorized users of a SRI database Currently, the global parameter SHOWMOD is supported. Setting this Key’s Value to True causes each SRI client’s embedded browser to navigate to the Message of the Day page at \\ArchiveServer\AppDir\mod\mod.html after logging in.
The bottom Local Client Flags frame shows various run time flags and variables currently in effect on the running SRI client.
The SRI Monitor watches the SRI applications log and reports any changes as they occur in real time. The Monitor looks for a file named after the current database name and the extension .log. This is the same naming convention used by SRI clients to conduct their message and event logging. The Monitor looks for the log file in the SRI application directory specified by SRI.ini setting AppDir. Each SRI Client saves the application log and starts a new one after the application log exceeds 100K bytes in size.
Typically, several SRI clients are connected to a single database with each logging events and messages into a common log. Changing the SRI.ini LocalLog setting to true can modify this behavior and cause an individual SRI client to log events into a local log instead.
Each client is heavily instrumented. All major activity and events are logged in the application log. Additionally, modifying SRI.ini setting SQLTrace to true provides a record in the application log of each SQL command issued to the SRI database.
Using the Monitor, it is possible to view detailed client interactions with the SRI database in real time. Client messages all conform to a common format
Each message is prefix with a standard header that includes the Operating System user name and host name and the SRI user name and role. The dates and times are those on the SRI client machine.
Real Time Filters:
The SRI Monitor supports
custom filter lists. Use Filters to store and apply filter strings that invoke specified client
operating system commands if the filter string should appear in the SRI
Application Log. This could be used to
configure a set of alarms or even build a remote scheduler or command
dispatcher by appending filter strings into a remote control file that is being
monitored in real time.
The SRI Client could run in
several environments each monitoring a single, common application log. Filter strings could then be used to invoke
simultaneous or cascading actions on each SRI client by appending them to the
common SRI application log.
To use filters, Right Click
on the Monitor and select Filter List from the popup menu that
appears. You can add or delete Filter
Strings and their corresponding Command String here. The filter string can be any free form
text. The command string can be any
executable, script name or link that is within the execution space that the SRI
client is running on.
After adding or editing filters they MUST be applied to the real time monitor. Press the Apply button on the Filters form to apply the filter list to the real time monitor. To view how many occurrences of a given filter have been written to the log since filtering started, select the log file and open it's filter list. Select each filter in the list on the form. The Monitor shows the number of times the selected filter occurred and the date/time it last occurred in the Filter Lists status bar
Release Notes
This is a Beta SRI version. It is intended to exercise proposed core SRI components outside the development environment using clients with no fore knowledge of any design bias or limitations.
- The list of currently connected clients is lacking any client specific information. It is just a simple lookup against the list of authorized client names. This makes it possible for a client to log in to a SRI database from two network locations. The second login strands the first on the list of connected clients then. I’ll add a formal Sessions list and a client communications mechanism if SRI actually progresses in Beta.
- There are many more Params global settings that I can think of.
- The Colors in the GYR Displays should be shown in a vertical column in the Item list.
- Opening or creating a New SRI database causes the client to substitute whatever is stored in SRI.ini AppDir setting with the directory name that the new SRI database is in. Any ideas about what should be done instead??
- The ability to re-cache SRI.ini Database settings could lead to a SRI client crash if they specify non-existent SRI database locations or name. Use the File Open common dialog to open SRI databases.
- There hasn’t been a lot done with many features that seem obvious to me because I want to wait until I hear from you before cutting much more.