Image enablers let you add imaging functions to your existing applications without major modifications to your existing code. Image enablers make your life easy. They let your corporate information strategy drive your imaging requirements instead of the other way around. This makes you more productive.
There are more image enabling products to choose from than ever before. They come in three major product categories: turnkey systems, toolkits and enablers.
Turnkey systems are the imaging market's "out-of-the-box" solution. Everything you need is included with the system. This is your best choice if you want to get up and running as soon as possible.
The downside? A turnkey system may not do everything you want it to. Most turnkey products are standalone systems. This sometimes makes it difficult to connect them with the line-of-business system that your enterprise revolves around.
You have to manage two parallel systems. Your users are required to navigate a separate interface for each system.
This is changing. Some turnkey imaging systems are now bundled into integrated product suites. This makes imaging part of an overall information management strategy. It's easier to integrate line-of-business resources. Since most of these new systems are high-priced, enterprise-level solutions, you may not need (or want) all of that power.
Toolkits are at the opposite end of the product spectrum. They give you the building blocks you need to create the exact system that you want. You can integrate anything into the system, including your legacy database. This saves time.
Toolkits are relatively inexpensive. But you need programmers who know how to use them. Unfortunately these people don't come cheap. The more complicated your system, the more you'll pay for system development costs. You can reduce the development requirements with a high-level visual toolkit, but your system will be less customizable. It will also be more difficult to tightly integrate with your existing line-of-business information system.
Image enablers fill the gap between turnkey apps and toolkits. They are more flexible than the turnkey apps and require less development effort than toolkits. Enablers let you add imaging functions to existing applications, without major modifications to your existing code.
With some of the newer products you simply tab through a few setup screens and you're ready to go.
The tradeoff? They're not as customizable as toolkits. And you can't scale the system as easily as a modular turnkey product or a toolkit.
This isn't a problem if you don't want to customize or scale up your system. You may just want to link your images to an existing line-of- business database for one or two well-defined applications like purchasing or accounts payable. In this case, evaluate image enablers first.
Which enabler is right for you? It depends on your applications. Here are the most popular types of enablers.
Screen Scraping
Screen scraping was the first popular technique for image enabling. It's still used for DOS and host applications that use terminal emulation software.
A screen scraping enabler reads ("scrapes") data from a predefined portion of a host application screen. (It actually reads it from the corresponding part of the video memory buffer.) The data is then copied into the search command of the imaging system, where it is used as an index.
Example: The enabler scrapes the purchase order number from the upper left corner of the purchasing application screen (as defined by screen coordinates) and copies it to the imaging system which retrieves the corresponding document. The image typically is displayed in a separate window next to the data.
Advantages? It's easy to set up and doesn't require you to modify line-of-business application code. All you need to do is create a script that specifies the data from your app that you want to associate with your images.
Some image enablers that support screen scraping let you extend your image applications beyond retrieval and display.
With ApplicationExtender from OTG Software (Bethesda, MD 301-897-1400) the screen scraping software runs in the background (as a TSR). To grab an image, you hit a hotkey. Once the image is displayed, you can zoom in and out and add a variety of annotations. It works with any ODBC-compliant database that meets OTG's certification requirements.
A common setting for ApplicationExtender enabling solutions is the customer service department in banks and credit unions. The product is used to link an imaging system to the line-of-business system running on a host system like an AS/400.
If a customer wants a duplicate statement, the customer service representative pulls up their account information from the host database and hits a hotkey to pull up the scanned statement from the imaging system.
This can be faxed directly from the workstation. In the past the customer service representative had to print out the statement and then fax it out. Costly and time consuming.
ApplicationExtender is often used with OTG's DiskExtender. DiskExtender provides storage management on a variety of media including WORM, magneto-optical and tape.
Other screen scraping enablers include QuickImage from Pixel Science (Great Neck, NY 516-773-7377). Designed for AS/400 applications, QuickImage includes built-in image processing functions like sharpen, deskew, zoom, etc.
You can display images without splitting the screen. This saves time. Specify the size and location. QuickImage uses this information to merge your images with the AS/400 screen. Several images can be displayed at once.
Images can be correlated with your host data for printing with Pixel Science's QuickPro. This includes QuickImage and QuickSpool, the company's report management (COLD) application. Specify the location and size. The program prints the images on any PC printer.
Example: Put product photos next to specifications summaries when printing an inventory report.
Screen scraping is also provided with HostLink from EZPower (Philadelphia, PA 215-496-1700). HostLink can scrape data from scrolling screens as well as from fixed screen coordinates.
While screen scraping is simple and effective, it isn't an ideal enabling solution. The main drawback is the screen positioning used to determine image reference information such as screen number and field location.
Why? The position may vary from one part of an application to another. This complicates the process of configuring the enabling application. Let's say the data location is uniform throughout the entire line-of-business application. If you want to add a new field to the application, your programmers may need to modify the screen layout to do it. The previously defined mappings of the old screen scraping locations also need to be updated.
Screen scraping can be set askew by different terminal emulation products. Many organizations use a variety of terminal emulation equipment. One emulator may send text to the screen differently than another. That can confuse the screen scraper and confound your enabling strategy.
Screen scraping is less secure than other forms of image enabling. The software runs on each client workstation instead of on the host. This makes screen scraping harder to manage than many other approaches, particularly in large imaging installations with many users.
Dynamic Data Exchange
Microsoft's Dynamic Data Exchange (DDE) technology lets Windows-based terminal emulators communicate directly with Windows-based imaging systems. You don't have to specify the exact location of data on the screen. There's also more error recovery than less sophisticated approaches like screen scraping.
The downside? DDE's scripting language. This is limited and hard to program. To solve this problem some vendors have developed products that work around this. With ImageExtender from Cambridge Imaging Technologies (McLean, VA 703-356-4600) you image enable your existing line-of-business database (or other Windows applications) with IELink. The utility lets you create a DDE enabling script using simple point-and-click commands.
RasterView from TMS/Sequoia (Stillwater, OK 405-377- 0880) includes a sample enabling application written in DDE code. You can use it as it comes or customize it to fit your needs. RasterView's key features include color and multi-image viewing, zooming and scale-to-gray.
DDE has some advantages over simple screen scraping but it's still not an optimal enabling technology.
The two disadvantages:
1. DDE can be unreliable and unpredictable in some circumstances. The asynchronous communication link DDE provides doesn't provide immediate confirmation when one application sends a message to another. application If the app that supposedly received the message doesn't respond, there are no helpful error messages to help you figure out the reason why. Dynamic Data Exchange messages sometimes go to the wrong application. This can create confusing results that are difficult to correct.
2. DDE has taken a back seat since Microsoft's big push on OLE automation and ActiveX controls. These tools have taken the center stage and Dynamic Data Exchange has been largely abandoned by developers. They like the new cutting edge tools that fit into he emerging applications marketplace.
OLE Automation
The successor to DDE in the realm of Microsoft technology is object linking and embedding (OLE). The mechanism that allows OLE to be used in enabling applications is OLE automation.
With OLE automation, you no longer send simple data streams between two apps over an asynchronous (you talk, then I talk) connection as with DDE. Instead, you can make Windows applications share functions with one another as needed.
If you want to view an image within a Word document, drag the view icon onto your Word toolbar and click on it. You don't need to write complex code. You use a simple scripting language that binds selected sets of functions or entire apps to Windows buttons. Or use ActiveX controls with preprogrammed functions that you customize using a dialog box.
A leader in using OLE automation for image enabling is Watermark Software (Burlington, MA 617-229-2600). Watermark eliminates the need for special programming tricks to link an image with a database record in your line-of-business system. Just put an image in your viewer and open the database record you want to associate with it. Click on a button to send a copy of the data to your image database.
To view the image, simply click on another button to query the image server for all the images stored with that index. Access documents from within the Watermark Client application or from within your line-of-business program. If you want to send the image to another person, simply drop the image into a compatible groupware or mail application and off it goes.
The Watermark Client product (previously called Enterprise Edition) was recently released in a 32-bit version consisting of two applications. The Explorer application connects you to a Watermark document management server.
Use Explorer to manage folders, documents and document types, and to search for, preview and route all types of documents including images. Any document that you can access in Microsoft Explorer can be dragged and dropped into a Watermark folder for storage.
The second component of Watermark Client is Workspace. This is where you display, annotate and print documents stored on the Watermark server. Workspace lets you view a file saved on local and network drives. You can then store it as a Watermark document.
Application-Level Enabling
An API is a program that runs on a host computer system such as a mainframe. It sits on top of most types of existing host applications like accounts payable. This can be called by the host application whenever you request an image.
The host app doesn't have to be altered to incorporate the API. You just add a simple set of programming code to it. The code supplies imaging functionality to the existing app without affecting the host system's performance.
In most cases the images are stored on a local area network server that's separate from the mainframe host system. You access the images with terminal emulation software that lets your PC communicate with the host.
Run your mainframe application in a display window. When you want to view an image, put your cursor on the appropriate data record and press a function key. The image is instantly retrieved from the network's image server and displayed in an adjacent window.
The API's role in this process is simple. When you press a function key to request an image, the mainframe application grabs the appropriate data record and tells the API that you want the corresponding image. The API uses the host system's data stream to transfer the request to your PC.
Using software installed to support the API, your PC captures the request and sends it over your network to the image server. The server fetches the image off a storage device and sends it in compressed form back to your machine. Here it's decompressed and displayed.
All the API really does is accept the data record (index) for a specific image and send it back to you. It "enables" the mainframe to act as an index database of sorts for the images stored on your image server. Even though this seems simple, API enabling offers several important advantages.
It provides an open, two-way communication channel. The host application and the imaging application talk directly to each other. You don't need to specify screen coordinates that identify the data you want to use for retrieving images. You gain this advantage without making any changes to your existing application. MIS likes this.
The code required to link the API and the host is relatively simple. Developers can image enable their host database with very little effort. They don't even have to learn a new programming language. The API can be created with the same language used to develop the existing application.
With some of today's API-based image enabling products you don't need programmers. LAVA Enabler from LAVA Systems (Mississauga, ONT 905-625-5924) guides you through a very simple, step-by-step process that creates a custom link between the API and the host's line-of-business database.
Programming in the traditional sense is not required.
Configuring LAVA Enabler is a three-step process.
1. Put the host application and the enabler in adjacent display windows. Link the two by clicking on a button in the enabler window. The enabler generates an application identifier and sends it directly to the image database.
This lets data from the host application window, such as an invoice number, reference a variety of different index fields contained within your imaging system. Unlike in screen scraping, the data does not have to be selected from within certain specified screen coordinates.
2. Select the action(s) you want the link to perform. Lava's LAVA Enabler includes several built-in actions including search, update and view. You can select from several versions of a function.
With the view function, you can tell the enabler to show the parts of an image that correspond to fields in the application window as you tab from field to field. If an action you want isn't provided, click on the "Custom Action" selection and add it using Visual Basic.
3. Select an event to launch the action(s) you've selected. Create a toolbar button labeled "Search." Or designate a function key for the search action.
You can integrate your actions into the workflow system included with LAVA 5.0. When a purchase order comes into your company's order processing department, someone in the department clicks on the image, and an insert action is launched that puts the appropriate part of the line-of-business application in the host display window. The index data for the purchase order can then be inserted.
LAVA's enabling technology works with popular application environments like SAP R/3 and JD Edwards' One World. It can enable all host based systems that use 3270 or 5250 Windows terminal emulation packages to communicate with the host system.
