IATM : ISDN Automatic Test Manager

Back to Products

5. IATM external interfaces

IATM employs a number of structured interfaces to the BT infrastructure and legacy systems, for example :

IBM MQ messaging 

 Programmatic CSS transactions and receipt of Vegas alarms

DEC print protocols

 Receipt of EFI exchange alarms

Email and SMS

 "Keep customer informed", via BT email and SMS gateways

GWI

 WorkManager task-building and task-monitoring interface

DCOM and XML

 Task-browser interface

Currently IATM has not required CORBA or SNMP interfaces, but these could be added without difficulty (other City Computing servers are equipped with these interfaces).

IATM is equipped with a sophisticated screen-scraping ("phantom user") interface. Note that whenever possible City Computing prefer to use a programmatic interface instead of screen-scraping – however for legacy systems or systems that are unwieldy or time-consuming or expensive to equip with a programmatic interface, screen-scraping can be an effective technique.
Historically, “screen-scraping” solutions are written by the application intercepting the byte-stream from the host and decoding it by using the same rules as a terminal before deciding how to respond. This means that the application needs to know what byte-codes cause the terminal to do things like “move cursor up”, “clear screen”, “scroll text”, “backspace” and so on. This makes the application a mixture of high-level “screen-scraping” control logic and low-level terminal-model. 

The IATM method of “screen-scraping” is more effective than traditional "screen-scraping" technologies. IATM uses a standard City Computing terminal emulator to provide the terminal model and then drives the emulator by scripts written in the interpreted language “PERL”.  This has many advantages : the high level application need not worry about how the byte-stream is converted to a screen image - it just asks the emulator and is provided with the appropriate screen ; when the screen-scraper is driving the host connection, the terminal emulator can be used to view the interaction - it is simple to watch the keys being “typed” and the screens being updated ; coding the application in a flexible interpreted language (PERL) means that changes can be implemented very rapidly (even on the live system) and be effective immediately - new screens or unexpected data from the host can be accommodated in the screen-scraper without any significant delay.

This technique of PERL-plus-emulator is a powerful tool to interact with any system that supports a terminal interface. It is primarily this design that has allowed IATM to become so effective so quickly - a PERL test-script could be written up to a point, then the emulator could be used to type keys to determine the rest of the sequence, then the PERL script completed. Scripts could be enhanced as and when required - allowing a flexible approach to the ISDN diagnostic process : changing on a daily basis as the capabilities of the IATM system expanded.

6. IATM user interface – "City Centre and "Task Browser"

IATM uses the generic “City Centre” and “Task Browser” applications.

“City Centre” is web-based. It validates the user onto the system and presents a framework for launching the “Task Browser”. A series of labelled “City Centre” buttons allow the user to select how the browser should be automatically configured when it appears.

The “Task browser” is a “thick client” executable. It draws its configuration information from the “City Centre” button and the IATM application server.

The “Task Browser” is used by a number of City Computing systems and is capable of taking instructions from the application server to present a range of functions and appearances. We have used the "Task Browser" technology to uniformly and coherently present the following types of data within a telecommunications environment.

  • Customer fault reports
  • Switchboard alarms
  • Exchange alarms
  • Automatic diagnostic results
  • Orders and related provision activities
  • Field engineer activities
  • Job control records and reminders
  • Robot account information
  • Active robot status and robot control
  • System and robot auditing information
  • Automatic process control tables and revision history
  • Incoming fault report rates
  • Proactive and aftercare monitoring activities
  • User information including active users.
  • Internal messaging facilities

Both "City Centre" and "Task Browser" applications run on the user PC’s and are downloadable over the intranet from the IATM Domain Controllers.

The task-browser gives considerable advantages over a menu-based system.

  • Microsoft-windows based user interface, with integrated help facilities.
  • Easy to learn, flexible, consistent context-sensitive multiple window view. The user decides what type of windows he needs and how many of each
  • “Action control lists” allow a very fine control over user privileges. Every action in the browser can be allowed or denied to any user if necessary.
  • Browser has powerful list viewer and searching facilities. Most data is rendered in a row-column format with automatic updates without user intervention.
  • User can define own columns for display, sorts for ordering the lists and filters to operate on the list. Sorts, columns and filters can also be defined for a group of users and for the global system. This allows users to quickly analyse data
  • Users are assigned to groups. This allows functional or geographical division of filters, sorting rules and column selections.
  • Powerful search capabilities directly from browser.
  • Automatically refreshing screens, with efficient, scalable data delivery (use of data caching software as middle tier).
  • All views and forms are defined in the server database. New functionality can be incorporated without need for software delivery.

When faults have been automatically tested by IATM and it has been determined that the staff of technical centre need to manually progress the fault, the fault is put into the IATM database in a location where the men can view the details by using the IATM Task Browser.

Although the functionality of  the user interface is quite sophisticated, users have been able to operate it successfully with the minimum of instruction. Fault reports are allocated by right-clicking on icons within the task browser window. Changes are reflected immediately on every task browser. By “double-clicking” on a fault-icon the user can inspect all details including fault-notes with the latest additions from the Customer Support System.  The view of faults can be filtered to specific customers, directory numbers, geographical regions and so on. CSS fault information can be associated with EFI fault information. Faults are prioritised in order of customer-importance, time and severity in a flexible manner according to user and group sorting criteria.

The "Task Browser" can be used by managers to allocate faults to specific technical-centre staff and supports proactive and aftercare views to allow technical centre staff to view EFI alarms on faults that have been closed and raise new faults against EFI reports.

IATM has a built-in jeopardy monitor which interfaces to the CSS system to track faults from IATM first-sight right up until conclusion. CSS has information as to who is currently dealing with the fault and what its status is. The jeopardy monitor determines this information and updates the IATM database. The jeopardy information is viewed through the task-browsers giving an immediate view of the location and progression of any fault report.

IATM information is regularly automatically exported to an Oracle database package (built alongside the IATM system). This allows reports to be generated, long-term statistics to be calculated and trends analysed. The automatic testing effectiveness can be judged from this information, plus the performance of the technical centres and the other BT agents involved in the ISDN repair process.

7. Example IATM screens

7.1. IATM City Centre

The diagram shows a typical IATM Control Centre view. Only one button has been defined by the system administrator for this class of user and this launches the task-browser with pre-configured views and filters appropriate to the user's "duty".

The user can change log-on group by pulling down a new group from the list of groups for which he is a member. The group settings determine his "City Centre" toolsets and also the "Task Browser" sorting, filtering and column selection lists to which he has access.

The user can change his cache setting if required – this is the route by which database updates are received by the task-browser. Normally this would only need to be changed if the default cache was inaccessible.

The "Contents" area allows tool-buttons to be grouped in sets according to a flexible directory hierarchy.

The "Admin", "Refresh",  "Support", "Feedback" and "Edit" buttons have the following purpose

Admin - allows password changes. For privileged users this also allows definition of new button sets and gives access to Task Browsers configured for user administration.
Refresh - reloads the web-page – useful after new button sets have been defined.
Support - gives a page of contact information
Feedback - produces a form to email a fault description
Edit - puts the "Tools" area into edit mode – allowing new tool buttons be constructed (dependent on user privileges)

7.2. IATM Task browser

The view below shows a complex example of the browser displaying ISDN2 faults, ISDN30 faults, exchanges affected by "Major Service Outage" and a pop-up form allowing an IATM internal message to be sent to another IATM user.

7.3. IATM ISDN active fault reports

The illustration below shows a sample ISDN2 view with a sorted, filtered list of ISDN2 fault reports. Sorting and filtering rules can be defined by the user or be provided by stored definitions constructed for the user's group by a group administrator. Columns can be selected from any available columns in the database. The view is refreshed dynamically with no need for user intervention and the updates are displayed almost immediately after any database change.

Double-clicking on a fault-report will open up a "Property view" giving all pertinent details, arranged as tabs. (The illustrated tab shows the IATM robotic conclusions)

previous page | click to continue