Bar Code/RFID Label Printing Avoiding the Integration Traps. By Thomas M. Stockwell

Transcription

1 Bar Code/RFID Label Printing Avoiding the Integration Traps By Thomas M. Stockwell

2 Bar Code/RFID Label Printing Avoiding the Integration Traps By Thomas M. Stockwell Executive Summary Automated Data Collection (ADC) technologies that use bar code and radio frequency identification (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 reducing 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 applications of the organization. IBM has a heritage of building midrange servers that uniquely serve manufacturing and distribution organizations. These servers and the software packages that run on them have been instrumental in the automation of supply chains and inventory systems from the advent of machinereadable 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 expensive, fragmented, and difficult to maintain. These implementations often fail to fully integrate the features 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 Street Covington, KY tlashford.com sales@tlashford.com

3 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 logical 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 themselves. 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 particular 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? 2

4 Of course, what we want is a cost-effective method that will: Reduce the number of errors within the data collection process Increase the efficiency/speed of data collection Provide 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 processes Provide flexibility for both the current labeling and RFID projects and future projects Utilize the extraordinary facilities of the IBM System i Minimize the technical expertise required to manage the system Maximize the functionality of the equipment that is purchased Establish 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 tools Embedded Integration using printer commands and programming tools from within an IBM System i application System i Label-Printing Application Software that controls, coordinates, and integrates 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-contained 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 manufacturer 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 programming languages. 3

5 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. DB2 database Communications Protocol Custom RPG/ COBOL Logic Application Program Form / Printer DDS Figure 1: A Single, Modular Integration Using Third-Party Utilities In addition to the actual data transformation, the technician needs to design a label form or template 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 technicians 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 using third-party utilities. Little or no programming experience is required to deliver basic label printing functions. 4

6 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 software 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 implementation. 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 identical. 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 integration fails. Diagnosing and remedying these failures then becomes time-consuming and expensive. But more significantly, when so many vendors are involved, no one vendor will take responsibility for solving a DB2 database Custom RPG/ COBOL Logic DB2 database Custom RPG/ COBOL Logic DB2 database Custom RPG/ COBOL Logic problem. Application Program Application Program Application Program Communications Protocol Form / Printer DDS Communications Protocol Form / Printer DDS Communications Protocol Form / Printer DDS Figure 2: Complexity Increases as System Expands 5

7 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 Function 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 program 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 demand, based upon different conditions that the application program controls. Database-Driven Other elements and/or data can be directly accessed from other IBM i application databases to create highly customized, highly functional DB2 database labels that are truly data-driven. There s no need Database Access Utility for file conversion or file transfer. Centralized Maintenance File Transfer The control of the printer and its formats is centralized Printer Utility at the source of information (within the IBM System i), Label Form Profile Printer Controller while the overall architecture is extremely simple and selfcontained. This makes individual application software Label Design Software Printer Driver maintenance and/or upgrades much easier to handle. Figure 3: Embedded Approaches Rely on Programming Expertise

8 Disadvantages of Embedded Integration There are some limitations, complexities, and increased costs associated with using the embedded integration approach. Required Expertise Embedding the functions of a label printer inside an IBM System 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 program, 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 expensive. 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 IBM i application IBM i application DB2 Database DB2 Database DB2 Database Database Access Utility Database Access Utility Database Access Utility File Transfer File Transfer File Transfer Printer Utility Printer Utility Printer Utility Label Form Profile Printer Controller Label Form Profile Printer Controller Label Form Profile Printer Controller Label Design Software Printer Driver Label Design Software Printer Driver Label Design Software Printer Driver Figure 4: As Embedded Implementations Expand, Programming Costs Rise

9 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 architecture of the IBM System i using natively written System i code. The label-printing software is a native System i application that coordinates the DB2 database functions with the label design and print functionality of a myriad of printers connected directly to the System i. Forms Design Software IBM i Architecture IBM DB2 Database Label Utility Printing Program Label Printing Application Program Interface (API) IBM Data Description Specifications (DDS) Customer RPG/COBOL Application Programs Label Forms Library Code Symbologies Printer Commands IPOS Printer Definitions Advanced Function Printing (AFP) Communications Methodology HP/AFP Printer Definitions The label-printing software can be accessed through an application program Figure 5: Labeling Software as An Architectural Component 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 applications Makes data available to printers in real-time Allows a wide variety of label printers to be used along with laser printers, which offers greater flexibility Maintains the native security of the host system Permits the centralization of all label formats Enables 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 engine, 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 8

10 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 protocol, 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 database 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 possible to the source of the data that needs printing. This simplifies problem diagnostics, 9

11 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 maintained. 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 architecture 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 advanced 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. 10