Bar Code/RFID Label Printing

Avoiding the Integration Traps

By Thomas M. Stockwell

�

Bar Code/RFID Label Printing

Avoiding the Integration TrapsBy Thomas M. Stockwell

ExEcutivE Summary

Automated Data Collection (ADC) technologies that use bar code and radio frequency identifica-tion (RFID) labels have revolutionized how our products are packaged and transported through our supply chains. Bar code labels are now so common on products that they are considered to be the status quo for identifying and routing packages in transit. RFID tag technologies are also making tremendous headway in managing inventory at receiving docks and warehouses for many of the largest retail and government supply chains.

These ADC technologies pay for themselves by more-accurately tracking products and by reduc-ing the costs of sharing data with business partners.

However, deriving the maximum value from these technologies is directly related to the level of business process integration that our companies achieve. The best return on investment (ROI) is realized when advanced labeling systems integrate seamlessly with the mission-critical applica-tions of the organization.

IBM has a heritage of building midrange servers that uniquely serve manufacturing and distribu-tion organizations. These servers and the software packages that run on them have been instru-mental in the automation of supply chains and inventory systems from the advent of machine-readable product-labeling systems. The IBM System i and the new IBM Power Servers continue this tradition.

Unfortunately, some companies have implemented overly complex labeling integration schemes with the IBM System i that have turned out to be expen-sive, fragmented, and difficult to maintain. These implementations often fail to fully integrate the fea-tures of bar code and RFID solutions with the power of the IBM DB2 databases and applications.

As a result, these IT shops find themselves trapped by poorly performing ADC implementations that are prone to error. They are also trapped by software that is expensive to maintain. And finally, they are trapped by architectures that cannot be scaled to the evolving demands of the business.

Compliments of

525 West Fifth StreetCovington, KY 4�0��

800.54�.4893tlashford.com

sales@tlashford.com

2

This paper examines three approaches to ADC integration with IBM System i. It identifies the integration traps commonly experienced by business and then examines a better approach using native System i labeling software specifically designed for the IBM System i architecture.

Bar codE and rFid tEchnologiES arE uniquEly ProBlEmatic

As managers, we want to view the requirements of bar code label and RFID tag printing as logi-cal extensions of the information systems that drive our business models. Those IBM System i applications might be our inventory control application, a particular supply chain module, our entire ERP suite, or some other centralized custom application that is unique to our organization.

But, in reality, the technical details of most ADC deployments (both bar code and RFID) have little to do with any of our IBM System i applications.

Instead, most ADC deployments are implemented as separate technological systems that are defined by the unique, discrete engineering requirements associated with the labels or tags them-selves. These requirements dictate the physical properties and qualities of the labels and, in many cases, the actual devices that must be used to create or read the labels.

tEchnology in SEarch oF intEgration

To make matters worse, bar code label and RFID tag printers are built to each manufacturer’s unique control set. The devices use proprietary languages that control how the equipment will function. As a result, printers manufactured by HP, Zebra, Datamax, Intermec, and others do not work interchangeably. Even different models from a single manufacturer may use a different control set.

IT must choose carefully both the equipment that it deploys and the integration strategy it will use so that the company is not locked into a single manufacturer’s product line or model. And, as the company grows and more devices are used, IT will need a strategy that can scale to the requirements of the business model.

Consequently, just as the details of bar code and RFID ADC deployments are defined by the par-ticular hardware technologies of the printers, so too should the strategy for deployment meet the integration needs of the company.

Why is this so important?

In order to be useful to our IBM System i application systems, ADC technologies must be first interfaced to the IBM System i and then integrated with one or more DB2 database software applications.

So the most important question facing our management should be this: What is the best way to integrate ADC printing technology to our company’s IBM System i application software?

3

Of course, what we want is a cost-effective method that will:Reduce the number of errors within the data collection processIncrease the efficiency/speed of data collectionProvide a decent return on investment (ROI) for the life of the integrated system

But at the same time, we want an integration process that will:Integrate tightly with current applications that manage the data-collection processesProvide flexibility for both the current labeling and RFID projects and future projectsUtilize the extraordinary facilities of the IBM System iMinimize the technical expertise required to manage the systemMaximize the functionality of the equipment that is purchasedEstablish a support profile that is sustainable and affordable over time

thrEE intEgration aPProachES

Engineers and systems integrators can use many different means of interfacing and integrating bar code or RFID tag printing with the IBM System i, but generally there have been three approaches, which can be grouped as follows:

Modular Integration using a printer manufacturer’s utility software and services along with third-party integration toolsEmbedded Integration using printer commands and programming tools from within an IBM System i applicationSystem i Label-Printing Application Software that controls, coordinates, and inte-grates the functions of bar code and RFID label printing with the System i architecture and applications

Each of these three approaches has advantages and disadvantages, so choosing which approach best fits your organization can make a big difference in the ROI that can be expected from an ADC implementation.

Modular IntegratIon

Most bar code and RFID label printer applications are designed to be modular: they’re self-con-tained and are designed to print a label or encode an RFID tag from a printer connected to a PC. Some can be modularly interfaced to wired or wireless communications networks, while others must use printer controllers or PCs to communicate with a hosted database.

To support the modular nature of bar code and RFID tag printers and printer drivers, a manu-facturer often also sells utility label design and print software that permits simple data files (flat files) to drive the basic functions of the printer. Some utility software packages also permit a printer to be integrated with Windows- or Linux-based databases through high-level program-ming languages.

•••

••••••

•

•

•

4

How Modular Integration Works with System i

This modular approach may subsequently lead IT to undertake a multi-step data integration configuration that can result in a complex future integration trap.

Let’s first look at the tasks a systems integrator is facing.

The main task a systems integrator faces is figuring out a way to extract data from the DB2 database application, transfer that data to the PC and, ultimately, send it to the printer. Unfortunately, too often the technical person assigned to perform this data integration isn’t familiar with the IBM System i or the DB2 database. As a result, the integrator may look for other modular components—like the third-party utilities—to complete the data integration process. These may include PC-based software tools such as file transfer utility programs, EBCDIC-to-ASCII character-conversion tools, ODBC drivers, and/or print emulation utilities. This approach will lead him to use these third-party data extraction tools, but that’s not where the path ends.

In addition to the actual data transformation, the technician needs to design a label form or tem-plate for the desired label. This design tool will reside on the system integrator’s PC.

As we can see, this model of modular integration is composed of many parts—some of which reside on the System i, some of which reside on an intermediary PC, some of which reside on a separate designer’s PC. This interface and integration approach is very popular with PC techni-cians today for a number of reasons:

The elements of the integration are modular and easy to individually implement.No real understanding of the IBM System i architecture is required.Data extraction can be configured with limited knowledge of the DB2 database by us-ing third-party utilities.Little or no programming experience is required to deliver basic label printing functions.

•••

•

Form / PrinterDDS

DB2 database

CommunicationsProtocol

Custom RPG/COBOL Logic

Application Program

Label Printer

Figure 1: A Single, Modular Integration Using Third-Party Utilities

5

Disadvantages of Modular Integration

Where the customer ends up isn’t strictly modular at all. It’s a kind of custom, mixed-modular integration that has many technical dependencies that will make it difficult to sustain over the lifetime of the configuration. It traps the organization into a future of configuration complexity. As the printer infrastructure within the organization expands, a number of problems arise:

Control of Software Versions—It will become increasingly difficult to keep all soft-ware versions of drivers, utilities, label templates, and base operating system software at compatible levels. Operational Complexity—When something goes wrong, it will be hard to diagnose the source of the problem because there are no integrated diagnostic tools. The system just goes into a failing state.Limitations—Because of the limited functions of printer-supplied utility programs and third-party tools, it will be difficult to enhance the functionality of the overall ADC system. For instance, redesigning and enhancing a label using two or more data sources may exceed the capabilities of the original implementation, forcing IT to use advanced, expensive programming techniques.Fragmentation—Label formats and data are scattered about the ADC implementa-tion. For instance, if labeling is taking place at two locations within the company, the label formats at either location may be different, when, in fact, they should be identi-cal. This may incur costs due to chargebacks from business partners. Data that resides on the System i may change within the time it takes to transfer the data to the PCs handling the label printing.Security—Individual users utilizing the PC will have access to label formats and data, which can corrupt the implementation. Management of the Support Profile—There are many elements to the configuration that may or may not be supported by the printer manufacturer or the software vendor over time. As one element changes within the infrastructure, the implications to the support profiles of individual devices are often masked until some portion of the integra-tion fails. Diagnosing and remedying these failures then becomes time-consuming and

expensive. But more signifi-cantly, when so many vendors are involved, no one vendor will take responsibil-ity for solving a problem.

•

•

•

•

•

•

Form / PrinterDDS

DB2 database

CommunicationsProtocol

Custom RPG/COBOL Logic

Application Program

Form / PrinterDDS

DB2 database

CommunicationsProtocol

Custom RPG/COBOL Logic

Application Program

Form / PrinterDDS

DB2 database

CommunicationsProtocol

Custom RPG/COBOL Logic

Application Program

Label Printer Label Printer Label Printer

Figure 2: Complexity Increases as System Expands

�

eMbedded IntegratIon wIth the SySteM i

When a company needs extremely tight integration between an application program and a label printer, the IT department may choose to directly integrate the printing application using the IBM System i programming functions of Data Description Specifications (DDS) and Advanced Func-tion Printing (AFP). This is sometimes called the “embedded integration” approach because it embeds the functional commands of the label printer inside an IBM System i application pro-gram itself. There are several advantages to this integration approach:

Logic Control—There is complete integration between the software application’s function and the creation of the bar code label and/or RFID tag. The printer can be made to print whatever data the program can access. Vendor Support—This integration approach is fully supported by IBM’s architecture without a need for third-party tools.

On Demand Printing— Program logic can be used to print different labels on de-mand, based upon different conditions that the applica-tion program controls. Database-Driven—Other elements and/or data can be directly accessed from other databases to create highly customized, highly func-tional labels that are truly data-driven. There’s no need for file conversion or file transfer.Centralized Maintenance—The control of the printer and its formats is centralized at the source of information (within the IBM System i), while the overall architecture is extremely simple and self-contained. This makes indi-vidual application software maintenance and/or upgrades much easier to handle.

•

•

•

•

•

DB2 database

IBM i application

Database AccessUtility

File Transfer

Printer Utility

Label FormPro�le

Printer DriverLabel Design Software

Printer Controller

Label Printer

Figure 3: Embedded Approaches Rely on Programming Expertise

�

Disadvantages of Embedded Integration

There are some limitations, complexities, and increased costs associated with using the embed-ded integration approach.

Required Expertise—Embedding the functions of a label printer inside an IBM Sys-tem i application program requires a high level of programming skill.Label Design Complexity—Designing a label using IBM System i program logic and DDS can be exceedingly complex, and the template design tools provided by IBM are difficult to master. This can result in the need to hire expensive consultants.Resilience—Once a printer’s functions have been embedded in an application pro-gram, changing the printer model or changing the logic of the program may require that a programmer revisit the entire embedded logic of the application. This can create a dependency on external consultants that raises the cost over time and reduces the ROI. Maintenance Complexity—As the number of applications that use the embedded approach increases, the complexity and cost of maintaining the array of custom software applications increases. Each programmed solution is unique and requires custom attention.Increased Cost—Programming labels by using the embedded approach can be expen-sive. This is especially true when compared to third-party software applications suites that provide most or all of the advantages of embedded integration at a fraction of the cost.

•

•

•

•

•

IBM i application

DB2 Database

DatabaseAccess Utility

File Transfer

Printer Utility

Label FormPro�le

Printer Driver

Label Design Software

Printer Controller

Label Printer

IBM i application

DB2 Database

DatabaseAccess Utility

File Transfer

Printer Utility

Label FormPro�le

Printer Driver

Label Design Software

Printer Controller

Label Printer

IBM i application

DB2 Database

DatabaseAccess Utility

File Transfer

Printer Utility

Label FormPro�le

Printer Driver

Label Design Software

Printer Controller

Label Printer

Figure 4: As Embedded Implementations Expand, Programming Costs Rise

8

SySteM i label PrIntIng aPPlIcatIon Software

A third approach to printer integration uses System i label-printing application software.

This approach integrates the modular characteristics of modern label printers with the integrated archi-tecture of the IBM System i using natively written System i code.

The label-printing software is a native System i ap-plication that coordinates the DB2 database func-tions with the label design and print functionality of a myriad of printers connect-ed directly to the System i.

The label-printing software can be accessed through an application program interface (API), creating a completely integrated and automated bar code labeling and RFID tag environment.

How does the use of an API benefit the labeling application? Permits programmers to closely integrate label printing with mission-critical applicationsMakes data available to printers in real-timeAllows a wide variety of label printers to be used along with laser printers, which offers greater flexibilityMaintains the native security of the host systemPermits the centralization of all label formatsEnables centralized support and continuity for standard label interfaces to RPG and COBOL programs

A forms-design application and utility tool can also access the elements of the application en-gine, centralizing and standardizing how label printers are interfaced and integrated with the System i. All of these functions are sustained within the secure architecture of IBM System i. As a result, each label solution attached through this architecture becomes a natively integrated

•

••

•••

IBM i Architecture

IBM DB2 Database

Forms Design Software Label UtilityPrinting Program

Customer RPG/COBOLApplication Programs

Label Printing Application Program Interface (API)

IBM Data Description Speci�cations (DDS)

Label Forms Library Code Symbologies Printer Commands

IPOS Printer De�nitions HP/AFP Printer De�nitions

Communications Methodology

Advanced Function Printing (AFP)

Label Printer Label Printer Label PrinterLabel Printer

Figure 5: Labeling Software as An Architectural Component

9

application of the System i itself. This reduces the required training to use and maintain the overall labeling printer infrastructure. It also protects the system from changes—intentional or inadvertent—by unauthorized individuals.

Modular Approach vs. Label-Printing Software Approach

We saw that the most difficult problem associated with the modular integration approach was that each label printer installation is configured like a string of pearls, with each pearl consisting of an individual modular element: printer hardware, connectivity method, communications pro-tocol, printer driver, file access method, database utility, label template, application code, etc. This modularity can be effective with one label-printer setup, but as you add a second or third printer to the infrastructure, the chances of software version incompatibilities increase while the number of potential maintenance problems spirals exponentially.

Compared to this modular integration approach, a comprehensive label-printing software application is much more powerful. It fits into the integrated architecture of the System i and enhances the system’s value. And instead of piecing together PC protocols, print drivers, emulators, and/or third-party utility programs for integration to the IBM System i databases, the label-printing application becomes fully integrated with the DB2 database and System i functions. This architectural approach is much more scalable than the modular approach, and it permits IT to focus on developing new solutions instead of getting bogged down in PC or printer software maintenance tasks.

Embedded Approach vs. Label-Printing Software Approach

We saw that the greatest problems associated with embedding label code directly in System i applications were the level of expertise required to program the system and the cost of maintaining the custom code over time.

Compared to an embedded integration approach, a comprehensive label-printing application can greatly simplify what IT must do to create and print a label. There’s no need for a highly trained RPG or COBOL programmer to use low-level DDS or other embedded programming techniques. The label application software provides a comprehensive, native IBM System i software solution that is designed for rapid deployment, ease of use, and cost-effective data-base integration without any programming at all. Software to design the form templates is also integrated with the solution, simplifying the overall configuration.

BESt PracticES For laBEl-Printing intEgration

All three approaches to integrating bar code labels and RFID tags to the System i are valuable. Some are more resilient than others. So what are the best practices for integrating ADC label printers to the IBM System i?

Whenever possible, centralize the functions of label-printing software as closely as pos-sible to the source of the data that needs printing. This simplifies problem diagnostics,

•

�0

ensures the most accurate and timely data, and supports advanced integration functions of both the printer and the hosting servers.Keep the complexity of the integration solution to a minimum so that as the printer infrastructure expands, standardization of the elements of the systems can be main-tained. This will reduce ongoing maintenance costs and increase the ROI.Use the strengths of the System i’s integrated architecture to enhance the capabilities of the ADC system. This will reap benefits to the organization over the long run of the installation, simplify operations, ensure security, and make future expansion easier. Avoid integration solutions that create nested dependencies or that distribute key elements of the solution to servers or client PCs outside the organization’s control. This includes proprietary form-template design software, third-party proprietary database configurations, or licensed software solutions that do not provide a defined ongoing support capability. If something goes wrong, the elements of the ADC support profile will become the most important asset that protects your company’s investment in the label-printing solution.

Building thE BEttEr adc Print intEgration Solution

How a company approaches the technology of bar code and RFID label printing will make a significant difference in the success and expansibility of its ADC implementation. Bar code and RFID labeling equipment must meet rigorous standards for technical proficiency and durability to withstand the day-to-day demands on shop floors and in warehouse environments.

Likewise, the method by which IT chooses to integrate these expensive printers to the IBM System i should also provide stability and durability to the overall information system.

Building a better ADC solution for the IBM System i should start with the premise that the archi-tecture of the System i is perfectly capable of interfacing with modular bar code and RFID label printers. It is how IT chooses to approach the process of integrating label printing to System i that will ultimately determine the company’s success with ADC and IT’s return on investment. The best approach recognizes the strengths of the IBM System i and then utilizes the ad-vanced capabilities of its architecture to deliver a system that is manageable, scalable, and secure and offers the best tools to maximize the efficiency and the accuracy of the company’s information system.

•

•

•