Technical issues can be perplexing! In this section we attempt to explain technical matters that have special interest in the WISL community.

Web/Backroom Interface

     Several years ago when a computer equipment distributor was first beginning to utilize the Web to offer access to its product catalog, one of the company's sales reps admitted that the order requests submitted through its web based system were printed and re-keyed by clerks into their backroom order processing system. It was explained that this process offered an opportunity to check the customer's work. This may be true but it requires significant redundant clerical effort and introduces the possibility of transcription error.

    It is obvious that the customer's work could have been checked without re-entering the entire transaction and that the real reason for re-entering orders was due to the lack of an automated interface between the web based order entry facility and the backroom order processing system. This points out an all too common occurrence in dealing with computer system interfaces. We have found it particularly perplexing when dealing with desktop based software products that tend to have a built in assumption that direct user interaction is always involved. Another glaring example is the failure of EDI to be widely accepted except when forced by big bully customers such as Walmart, Sears or General Motors. There seems to be an intrinsic reluctance by developers to accommodate an automated interface with another system even where they have developmental control over both.

    There are two major options when dealing with an automated web/background interface. The first is to generate transaction records from the interactive web based process accumulate them in a file and transmit them to the backroom system at pre-defined intervals. Typically there would be an automated process at the backroom end that would then accept and process the transactions. Often there are files of data required to edit the web based transactions that are periodically updated on the backroom system and sent in the reverse direction using similar facilities to update the web based data collection facility. This approach does not require a constant direct connection between the two platforms and a software layer to co-ordinate the two systems in real time but it suffers in those cases where it is desirable to have the current state of the data base and certain processes to be available to both systems at all times. An example where this approach is acceptable is with WISL's "Support Request" facility described elsewhere in this newsletter. In fact this approach is suitable for the majority of data collection facilities that we encounter on the internet.

    An example of an application that requires a real-time interface is WISL WebRate which provides web based users with the ability to determine the current cost of shipping something which requires immediate access to the backroom data base and complex processes that would be extremely expensive to develop on the web based application. WISL utilizes IBM's Redback middleware to provide the connection between the web user and the backroom based FAIS rating engine and data base. An overview document and PowerPoint demo are available at: http://www.wisl.com/wislwebapps/logistics/webrate.htm