Smarter Planet solutions with sensor monitoring, Part 2: Sensor solutions for a smarter supply chain

Smarter Planet™ initiatives are playing a major role in how we recognize where technology is shaping our interactions with the world around us. As described in Part 1, observation and processing of sensor data to extract insights from the physical world are common to many of these initiatives. Part 2 in this series shows how IBM® WebSphere® Sensor Events can be used to develop smarter planet solutions that leverage sensor event processing. This article presents a pharmaceutical supply chain example that follows an individual product from manufacturer to customer. You will see how disparate data from RFID sensors distributed throughout the supply chain feed an interconnected supplier system, resulting in the entire supply chain becoming intelligent, and significant value being added through reduced losses from counterfeiting, theft, product expiration, and recall liability. This content is part of the IBM WebSphere Developer Technical Journal.


Tim Hanis (, WebSphere Sensor Events Chief Architect, IBM

Tim Hanis is the lead architect in WebSphere Sensor Events development at IBM in Research Triangle Park, NC. He has led a number of development projects within IBM and has extensive experience helping customers solve business problems with WebSphere products.

developerWorks Contributing author

Allen Smith ( ), Senior Software Engineer, IBM

Allen Smith is a Senior Certified IT Specialist in IBM's Application and Integration Middleware Software group in Research Triangle Park, North Carolina. He works with business partners to design and implement sensor based solutions using WebSphere Sensor Events. You can contact Allen at

developerWorks Contributing author

John Senegal (, WebSphere Sensor Events Lead Developer, IBM  

John Senegal is the lead developer for WebSphere Sensor Events Server at IBM in Research Triangle Park, NC. He has broad experience working with IBM customers and partners building solutions using IBM tooling and middleware.

Ken Greenlee (, Advisory Software Engineer, IBM  

Ken Greenlee is an Advisory Software Engineer with the WebSphere Sensor Events team at IBM in Research Triangle Park, NC. He has extensive Java/WebSphere experience and is responsible for many components within the WebSphere Sensor Events server product. He has worked with customers to create solutions based upon the WebSphere Sensor Events software stack. He has reached the third patent plateau, most on RFID technologies.

Bruce Hyre (, Senior Software Engineer, IBM  

Bruce Hyre is a Senior Software Engineer with the IBM Sensor Solutions in Research Triangle Park, North Carolina. He specializes in the design and integration of WebSphere Sensor Events with business partners and device manufacturers.

09 December 2009

Also available in Chinese


The term supply chain is very broad and can be applied across multiple industries. To demonstrate how IBM WebSphere Sensor Events and other IBM solution components can be used to create a smarter supply chain, this article looks at the management of a pharmaceutical supply chain, with which a pharmaceutical company needs to protect its distribution network and customers from prescription drug counterfeiting, support drug recalls, and more.

On the surface, the pharmaceutical supply chain is similar to other supply chains with manufacturers, wholesalers, and retailers. However, because of the particularly serious nature of the products that flow through this supply chain, typical supply chain problems are exacerbated and potential liabilities can be quite high. After examining the supply chain for a theoretical pharmaceutical company and some of its representative problems and challenges, you will:

  • See how IBM solution components can address these problems.
  • Learn about the architecture of a possible solution.
  • Review code samples for a specific use case.
  • Examine how the supply chain has become smarter.

The supply chain today

The purpose of this particular supply chain is to provide a channel to move pharmaceutical grade medications from the manufacturer to consumers. Most manufacturers, regardless of the products they produce, don't have (or want to manage) a distribution network that reaches all of the outlets that want their products (in this case, pharmacies and hospitals). Therefore, they enlist wholesalers and distributors whose sole focus is to optimize the distribution of many products to many endpoints, via complex distribution networks:

  • The chain here is triggered when a doctor writes a prescription.
  • The patient submits the prescription to the local pharmacy.
  • The pharmacy orders a drug product from a specific distributor, per the manufacturer.
  • A distributor purchases the product from the manufacturer (or from wholesalers or other distributors).
  • The distributor sells and distributes the product to pharmacies.
  • The pharmacy provides the drug product to the patient.

The process might seem clean and simple – and pretty typical of most products. In the pharmaceutical supply chain, however, add in the complexities of environmental sensitivity (like temperature, humidity, and light), time sensitivity (like product expiration), regulatory compliance, safety, and the high levels of liability that go along with pharmaceuticals, and it becomes far more complicated than the average distribution process (and more than this article will address).

Major challenges

Any supply chain will have its challenges. In the case of pharmaceuticals, these are some of the most serious:

  • Counterfeits

    Across the globe, reports claim that about 10% of all prescription drugs could be counterfeit. Other reports claim that the percentage of counterfeits in the US is around 2%, but in some less industrialized countries that percentage can reach nearly 50%. The implications for both patient safety and company financials are enormous. In the US, many states in fact have begun legislation requiring drug manufacturers to deal with this counterfeiting problem.

    How do counterfeit products of any type get into the supply chain? In many cases, it occurs during the distribution stage of the supply chain flow, which can be quite complex for pharmaceuticals. It is possible for a drug product to travel through a network of four to eight (or more) distributors before it gets to a pharmacy. Counterfeiters who exploit this might pose as a small wholesaler willing to pass a "special manufacturer discount" to a larger wholesaler. If the wholesaler buys, those counterfeit products are now in the supply chain. The last distributor in the chain might not know where the product originated, and unless the manufacturer has a way to get feedback on how many units of a given product went onto the pharmacy shelf, the counterfeit drug could be dispensed to the public.

  • Recalls

    In the US, when a drug is deemed to be harmful the FDA issues a Class I or Class II recall. The drug manufacturer must take responsibility for the recall, and can be held liable if anyone is harmed by the drug. Naturally, the manufacturer will want to narrow the scope of the recall as much as possible by identifying which lots or batches are affected. This requires a way to quickly and easily locate all of the harmful product in the field, otherwise the manufacturer is not able to know how much of the drug has been sold or reclaimed, and thus is unable to determine the potential liability exposure. Consumers are expected to be diligent in observing, acknowledging, and reacting to media blasts that are typically issued by manufacturers for recalls, but for others who continue to use the drug, the consequences could be serious and the liability to the manufacturer could be substantial. Given the complexity of the supply chain, some manufacturers have difficulty finding where their products have gone. Few would argue that the reliability and efficiency of the current system and process of recalls need improvement.

The goal, then, is to update and improve the supply chain to protect the safety of consumers and the integrity of the manufacturer.

A smarter supply chain

These supply chain problems can be summarized as a lack of visibility. If a pharmacy can verify that the products they receive actually originated from the manufacturer, then counterfeiters would be out of the picture. If a manufacturer can verify which pharmacies received which lots and batches of products, then a more effective, lower cost recall system and that could save lives and liability could be developed.

The solution is for the supply chain itself to become smarter.

  • Instrumented

    As described in Part 1, the first step to becoming smarter is instrumentation. It is instrumentation that will provide the foundation for supply chain visibility. In the pharmaceutical supply chain, instrumentation is about using identification technologies that enable manufacturers, distributors, and pharmacies to identify each individual drug container as it flows through the supply chain. The focus of this effort is primarily the responsibility of the manufacturer: as they produce the product and fill containers with the product, they must assign a unique identity to each bottle or package that contains the product. It's like giving each drug container its own serial number that will be associated with that container for the life of the product.

    Identity technologies have been around for some time. However, the most commonly used form of identification has been the barcode, which identifies the type of product but does not distinguish between individual containers (that is, all containers of the same drug get the exact same barcode). Now, technologies and standards such as GS1-128, 2D, Datamatrix barcodes, and Electronic Product Code (EPC), enable manufacturers to identify products much more precisely than by type alone. Through what is known as serialization, the product identity on the container can indicate what type of product is in the container, the type of container (bottle, case, tote, pallet, and so on), and provide a unique ID for each container.

    Indentifying the product is only the first part of instrumentation. The second and probably most important benefit is enabling other systems to observe the product as it moves through the supply chain. This requires hardware that, when placed at strategic locations in the supply chain, can provide valuable information about what products were seen, when they were seen, and, most importantly, where they were seen. This hardware could be a handheld barcode or Radio Frequency Identification (RFID) reader used manually, or automated readers fixed in place at each of the manufacturers' packing and shipping stations. For ideal visibility, RFID readers would also be placed at the receiving, packing, and shipping stations of each distributor. Finally, the pharmacy would need a reader for receiving.

  • Interconnected

    Having identity read points at each station in the supply chain is great. A manufacturer could potentially gain greater efficiency in seeing how a product flows through their manufacturing process. However, the true value of the instrumentation is lost if each read point, each supplier, and each distributor are not fully interconnected. Interconnectivity is about having a system that will receive information from each read point in the supply chain, and sharing that information with other internal and external systems. A supply chain is inherently about flowing product through many distributed, disparate locations; without interconnectivity, you cannot begin to fix problems in the chain itself.

    Interconnectivity enables the exchange of information. When the manufacturer sees what product was shipped to a distributor, that information can be used to drive other business processes, such as ASN (Advanced Shipping Notice) creation, short claims processing, expiration management, inventory management, loss prevention, fraud detection, cold chain management, and so on.

    Now the instruments and partners are interconnected, but what to do with all of this new data?

  • Intelligent

    Once this instrumented information becomes visible to all partners in the supply chain and key components are connected, the whole chain can become intelligent: you can put in place intelligent systems, processes, and procedures that utilize the interconnected identity information. You can validate the pedigree of the product at each read station by checking its identity and making inquiries on the manufacturer's system to verify its lineage.

    Manufacturers could make inquiries on pharmacy systems to ensure that the shipped product made it through the supply chain to its intended destination. Manufacturers could also change the status of products in pharmacy systems so a pharmacist would know if a product was recalled, and whether they should instruct their customers to destroy or return the recalled product.

    From a financial standpoint, manufacturers and distributors could take advantage of increased visibility into the system to further optimize just-in-time practices -- reducing inventories, improving turnaround, decreasing transit time, and increasing salable shelf life. Inventories would be more accurate, reliable, and up to date at every point in the distribution chain, reducing lost product and the need for audits. And certainly, any losses due to diversion, counterfeiting, and recalls would be reduced.

Bringing it all together

Through the process of instrumentation, interconnection, and intelligence, a supply chain system with major challenges is transformed into a system that is smarter: more accurate, more reliable, more efficient, and more open, which ultimately makes it much more valuable.

Let's look at a solution using the IBM smarter supply chain reference architecture (Figure 1).

Figure 1. Smarter supply chain reference architecture
Figure 1. Smarter supply chain reference architecture

Elements of this solution architecture include:

  • Data capture

    When implementing a smart supply chain, the Data Capture and Delivery component would be the "first stop" in the chain of processing between the sensor device and the WebSphere Sensor Events server. The data capture component of WebSphere Sensor Events consists of a software stack that resides on or near the sensor device. It provides a framework that enables you to build device adapters for device communications. In a smart supply chain, sensors will typically be identity readers of some kind. As products flow through the supply chain, these sensors detect their presence and report the identity of the item and time it was seen. The raw data from sensors is useless to enterprise resource planning systems and warehouse management systems and has limited value in driving smarter business processes. The raw data, then, must be preprocessed in some way to be of any value. The data capture stack provides a framework to perform a variety of data processing activities, such as several flavors of filtering, aggregation, and smoothing. The data capture framework can also be used to develop intelligent rules for processing and forwarding the raw sensor data.

  • WebSphere Sensor Events

    Since the Data Capture and Delivery component typically runs in a distributed platform and has limited resources for processing and storing data, the data must be forwarded to a server platform. Data from sensor devices can be sent to the WebSphere Sensor Events server via several different protocols using the sensor event gateway component. The supported channels are HTTP, JMS, and Web services. Sensor data is sent to the server from a sensor or distributed platform in the form of an event. The event is in a normalized form that enables the WebSphere Sensor Events server to perform several common services on the event, such as persistence and filtering.

    The WebSphere Sensor Events server also provides a framework for building applications for processing these sensor-generated events. The framework enables you build event processing components called Reusable Components. Reusable Components will be discussed more later, but for now it is sufficient to know that Reusable Components are event processing components modeled after Service Component Architecture (SCA) components. The server provides a set of predefined services in the form of these Reusable Components, and these services enable application builders to feed filtered and augmented sensor data to backend systems.

  • WebSphere Business Events

    Part of the processing of these sensor events is the ability to find patterns or discrepancies in the sensor data as it flows through the system. In this reference architecture, that role is filled by WebSphere Business Events, which provides a platform that enables solution builders and users to write detection rules on patterns of data. Once the pattern is detected, the revelent parties can be notified or some action can be performed. If necessary, a WebSphere Business Events rule could drive an action all the way down to the sensor device itself, perhaps to shut the device off or change the power level.


    This component represents a user's current back end systems. They could consist of warehouse management systems (WMS), Electronic Data Interchange (EDI), or an enterprise resource planning system. It would be impractical to expect users to completely rewrite their back end systems to support this new data, so interconnectivity is necessary to feed this data into (integrate this data with) these back end systems.

  • IBM InfoSphere Traceability Server

    Connecting data to local systems and monitoring these systems can create a lot of value for internal operations and inventory levels. However, the cornerstone of a smarter supply chain is the ability to share information and data with other partners in your supply chain ecosystem. IBM InfoSphere™ Traceability Server fulfills that role in this reference architecture. It implements the EPCglobal defined EPC Information Services (EPCIS) interface, which provides a standard way of feeding events into an EPCIS repository. Once in the repository, the data from those events is available to authorized partners. The data a partner might want to know could include when the product was shipped, if the entire order shipped, and so on. Likewaise, the manufacturer could verify that orders shipped had actually arrived. EPCIS will be discussed more later.

  • IBM Cognos Business Intelligence

    The architecture provides a way to capture the data, provides facilities to filter, augment, and add business context to data as it is processed and stored, and provides a secure way to share that data with partners. All of these steps are necessary to facilitate the smarter transformation of a supply chain. However, making anything smarter is ultimately about making data-driven decisions.

    IBM Cognos® Business Intelligence provides the linkage between the data that was captured and how that data informs smarter business decisions and smarter processes. In addition, Cognos Business Intelligence enables smarter solutions to:

    • Monitor performance and drill down to transaction details.
    • Identify key metrics and receive alerts when performance deviates.
    • Provide regular reporting and analysis, and identify trends and anomalous conditions to enable optimizations and operational corrective actions to be performed.

Next, let's look at a simple example to illustrate how WebSphere Sensor Events can be used to implement a smarter pharmaceutical supply chain solution.

Sample scenario

There are three partners in this sample supply chain: Biggie Pharmaceuticals, Inc. develops and manufactures pharmaceutical products. They ship their products directly to large retail pharmacies but use a distributor, Speedy Distributors Co., to ship to smaller retail pharmacy chains and independent pharmacies. The last link in the chain is Mom & Pop's Pharmacy, a small individually owned and operated pharmacy.

Suppose Mom & Pop's places an order for one case of a migraine product called MigHelp, produced by Biggie Pharmaceuticals. MigHelp is available only in pill form and is packaged in 100 pill containers. This example will track a single container of MigHelp as it is manufactured and shipped from Biggie Pharmaceuticals to Speedy Distributors and finally to Mom & Pop's. Once it arrives at Mom & Pop's, you will verify that the container they received is the one actually shipped from Biggie Pharmaceuticals.

The container of MigHelp ordered by Mom & Pop's travels through these steps in the supply chain:

  1. Biggie Pharmaceuticals:
    1. Product identification: In this step (referred to in EPCIS terminology as commissioning), EPC values are generated to uniquely identify each MigHelp container. An RFID printer writes each EPC value to the memory of an RFID chip embedded in a paper label. This chip, together with its paper label, makes up the RFID tag. The printer also prints information on the label indentifying the drug, its production date, batch lot, and its manufacturer. Each printed RFID tag is affixed to a MigHelp container. Once this process is complete, each MigHelp container is uniquely identified and can be tracked through the supply chain.
    2. Packing: Containers of MigHelp are packaged into cases which are then loaded onto pallets.
    3. Shipping: The pallets of MigHelp and other products ordered by Speedy Distributors are loaded onto a truck and transported to Speedy Distributors' central warehouse.
  2. Speedy Distributors:
    1. Receiving: The shipment from Biggie Pharmaceuticals arrives at Speedy Distributors' central warehouse. The pallets of MigHelp and the other drugs are unloaded from the truck.
    2. Storing: The pallets of MigHelp are broken down, separating the individual cases which are stored in Speedy's warehouse.
    3. Packing: The one case of MigHelp, along with cases of other drugs ordered by Mom & Pop's, is packed onto a new pallet.
    4. Shipping: The pallet ordered by Mom & Pop's is loaded onto a truck.
  3. Mom & Pop's:
    1. Receiving: The shipment from Speedy Distributors arrives at Mom & Pop's Pharmacy.
    2. Stocking: The case of MigHelp is removed from the pallet, and the individual bottles are placed on the pharmacy shelf.

In this scenario, the container of MigHelp must go through these nine steps in the supply chain before it can be sold at Mom & Pop's Pharmacy. RFID reads are performed at each of these steps in the supply chain. These reads enable you to track the case of MigHelp through the supply chain to determine its authenticity or, in the case of tampering or counterfeiting, to isolate the source of disruption in the distribution process.

The components of the solution include the physical hardware to print and read the RFID tags, WebSphere Sensor Events, and an EPCIS repository product, such as IBM InfoSphere Traceability Server.

The EPCIS specification

Let's take a brief look at the EPCIS specification to better understand how an EPCIS repository plays in the solution.

EPCIS (Electronic Product Code Information Services) is a software interface specification from the EPCglobal standards group for the sharing of EPC related information. It is designed to help trading partners leverage EPC data through EPC related data sharing. The data sharing might occur within a single enterprise or, in the case of trading partners, across multiple enterprises.

Raw RFID read events include the EPC value of a tagged item, the time the EPC was read, and the ID of the reader that read the EPC. They do not, however, provide information about the business context in which the event occurred. The EPCIS specification permits the data from raw read events to be augmented with contextual information about the observation of tagged items in the supply chain. This descriptive information is combined with the raw read data to create an EPCIS event. An EPCIS event provides important business information, such as the time, location, disposition, and the business step in which a tagged item was observed. For example, an event might indicate that an item was shipped on a certain date at a certain time.

The EPCIS specification defines two interfaces:

  • The capture interface specifies how EPC data should be combined with business context data and made available to applications that wish to consume it.
  • The query interface specifies how applications query EPCIS data after it has been captured, typically by interacting with an EPCIS repository.

WebSphere Sensor Events combines business context data with tag read data to create EPCIS events and sends them to back end EPCIS query systems via JMS. WebSphere Sensor Events also provides APIs that can be used by WebSphere Sensor Events-based applications to query EPCIS repositories.

In the smarter pharmaceutical supply chain scenario, WebSphere Sensor Events will be used to create an EPCIS event each time the RFID tag on the MigHelp container is read. EPCIS events will be created, for example, when the RFID tag is read during the shipping process at Biggie Pharmaceuticals and during the receiving process at Speedy Distributors. EPCIS events created by WebSphere Sensor Events will be stored in an EPCIS repository provided by InfoSphere Traceability Server. This scenario will also use the APIs for querying back end EPCIS systems to track the MigHelp container's movement through the supply chain.

Reusable Components

Applications create EPCIS events and interface with back end EPCIS query systems using WebSphere Sensor Events Reusable Components, which are components of the WebSphere Sensor Events programming model that provide APIs for accessing business level functions. Reusable Components can be viewed as building blocks available to WebSphere Sensor Events-based applications for orchestrating business level tasks. For smarter supply chain solutions, these tasks include the management of EPC values, printing RFID tags, and the creation of EPCIS events that indicate a tagged item was observed at a particular location or that determine where a tagged item was last seen.

Most Reusable Components are designed to interface with an external back end system. For smarter supply chain solutions, the back end system would typically be an EPCIS system, such as InfoSphere Traceability Server. The Reusable Component framework, however, decouples the Reusable Component interface from the back end system implementation. This decoupling enables you to choose the back end system to use through configuration. Most of the EPCIS interfacing Reusable Components can be configured to use the WebSphere Sensor Events database instead of an external EPCIS system. This enables smarter supply chain solutions to be prototyped and developed using only WebSphere Sensor Events, reducing initial cost and complexity.

Reusable Components are implemented as message-driven EJBs and expose their functions through stateless session bean methods, Web services, and JMS messages. Listed below are brief functional descriptions for each EPCIS interfacing Reusable Component. (See the WebSphere Sensor Events Information Center for more details.)

  • EPCIS Connector converts a sensor event into an EPCIS event. This component is called by the other Reusable Components to create EPCIS events.
  • Aggregation records an association between one or more child EPC values and a parent EPC value in the back end system.
  • Disaggregation removes the association between one or more child EPC values and a parent EPC value in the back end system.
  • Commissioning activates an EPC value in the back end system.
  • Decommissioning deactivates an EPC value in the back end system.
  • Observation creates an EPCIS event identifying where and when an EPC tagged item was observed, and the business context in which it was observed.
  • EPC generates and decodes EPC values.
  • Info queries the back end system for detailed information about an EPC value.
  • Locating queries the back end system to determine the most recent location an EPC value was observed.
  • Reporting queries the back end system for the locations where a given EPC value was observed, or for the EPC values observed at a given location during a certain time period.
  • Validation queries the back end system to determine whether or not a set of EPC values are currently commissioned.

In this sample scenario contained within the article, you will:

  • Use the Validation, Commissioning, Observation, and Reporting Reusable Components to initialize the EPC value assigned to the MigHelp container you are tracking.
  • Create ECPIS events identifying where and when your container was seen (that is, observed).
  • Generate a report of your container's movement through the supply chain.

Next, it's time to implement the sample scenario.

Implementing the sample

In a real implementation, RFID readers, printers, and the Data Capture and Delivery component of WebSphere Sensor Events would be included as the "first stop" in the processing chain between the reader and the WebSphere Sensor Events server. To simplify the sample (and the installation and sample code), you will use a predefined EPC value that represents the RFID tag affixed to your MigHelp container, and a lightweight Web application, called SmarterPharma, to substitute for these components and simulate the required RFID tag reads at the previously defined points in the supply chain process.

To run the sample, you need to install the SmarterPharma application (which you can download from this article) into the same application server instance on which WebSphere Sensor Events is installed. When the application has been installed, you can get to the SmarterPharma Web page by navigating to: http://<sensor_events_host_name>:9080/devworks/SmarterPharma.

The SmarterPharma page (Figure 2) enables you to commission the EPC value used in the sample scenario and generate the RFID tag reads for each of the defined supply chain locations, as if they had been emitted from an actual reader. At this point in an actual implementation, the data capture component would have processed the data from the reader (that is, normalize, filter, aggregate, and disambiguate the data), converted it into XML, and sent it via JMS to the server gateway to be published on the IBM WebSphere Application Server messaging engine. Instead, the Smarter Pharma Web page will inject the equivalent event straight into WebSphere Application Server messaging.

When you have generated all the reads required to move the MigHelp container from Biggie Pharmaceuticals to Mom & Pop's Pharmacy, you can generate a report that tracks the container's movement through the supply chain.

Figure 2. Smarter Pharma sample Web page
Figure 2. Smarter Pharma sample Web page

WebSphere Sensor Events application flow

To communicate with the WebSphere Sensor Events server, an application generates ISensorEvent XML and sends the XML to WebSphere Sensor Event's gateway for processing. The gateway converts the XML to an ISensorEvent object and publishes the object onto the WebSphere Application Server messaging engine that is configured for WebSphere Sensor Events. Once the event object is published, the publish and subscribe messaging engine (pub/sub) delivers the event to all subscribed Java™ 2 message-driven beans (MDBs). The MDB contains the application logic and is called a task agent in WebSphere Sensor Events.

Deciding which action to perform

In this example, the Smarter Pharma application sends event XML to the gateway with unique source ID values (Table 1), which correspond to the event location selected in the user interface (meaning the event location generating the event). For example, when commissioning the EPC, the source ID is Biggie_commissioning. When selecting to read the RFID tag at the Biggie Pharmaceuticals packing location, the source ID is Biggie_packing.

Table 1. Sample application location and source ID values
LocationSource ID
Biggie Pharmaceuticals PackingBiggie_packing
Biggie Pharmaceuticals ShippingBiggie_shipping
Speedy Distributors ReceivingSpeedy_receiving
Speedy Distributors StoringxSpeedy_storingxx
Speedy Distributors PackingSpeedy_packing
Speedy Distributors ShippingSpeedy_shipping
Mom & Pop's ReceivingMomPops_receiving
Mom & Pop's StockingMomPops_stocking

Sample application logic

In this application, the important action is commissioning. The application logic (Figure 3) detects if the event source ID indicates the event is a commissioning event. If it is a commissioning event, the application checks to see if the EPC is already commissioned. Only then does the application commission the EPC. Finally, in all cases, the application observes the event.

Figure 3. Sample application logic flow
Figure 3. Sample application logic flow

Implementing the sample application logic

Follow the instructions in the WebSphere Sensor Events toolkit to create an EJB project. The EJB project contains the task agent MDB. The relevant source code from the sample application task agent is shown in Listing 1.

Listing 1
private static CommissioningHome commissioningHome;
private static ObservationHome observationHome;
private static ValidationHome validationHome;

protected void onIBMSensorEvent(ISensorEvent ise) {
   try {
      // extract the original event ID
      String originalEventId = ise.getHeader().getEventId();
      // extract the sourceId
      String sourceId = ise.getHeader().getSourceId();
      sourceId = sourceId != null ? sourceId.toLowerCase() : "";

      // is this a commissioning event?
      if (sourceId.endsWith("commissioning")) {
         // has the EPC already been commissioned?
         Validation validationRuc = validationHome.create();
         boolean isCommissioned = validationRuc.validateEvent(ise);  
         if (!isCommissioned) {
            // guarantee event ID uniqueness
            // commission the EPC
            Commissioning commissioningRuc = commissioningHome.create();
      // restore the original event ID
      // record the event
      Observation observationRuc = observationHome.create();
   } catch (Exception e) {
public void ejbCreate() {
   try {
      InitialContext ic = new InitialContext();

      Object commissioningObj = ic.lookup("ejb/com/ibm/premises/reusable/
      commissioningHome = (CommissioningHome) PortableRemoteObject.narrow
		(commissioningObj, CommissioningHome.class);
      Object observationObj = ic.lookup("ejb/com/ibm/premises/reusable/
      observationHome = (ObservationHome) PortableRemoteObject.narrow
		(observationObj, ObservationHome.class);
      Object validationObj = ic.lookup("ejb/com/ibm/premises/reusable/
      validationHome = (ValidationHome) PortableRemoteObject.narrow
		(validationObj, ValidationHome.class);
   } catch (Exception e) {

public void onMessage(javax.jms.Message msg) {

In this code:

  • The ejbCreate method caches the EJB home interface of all required Reusable Components.
  • The onMessage method passes control to the super class' onMessage method, which then calls the onIBMSensorEvent to handle the event.
  • The onIBMSensorEvent is the heart of the task agent and contains the implementation of the logic from the flow chart. By extracting the source ID value from the event header, the code is able to determine if this is a commissioning action. If it is a commissioning action, the code checks whether the EPC has already been commissioned by calling the Validation Reusable Component. If the EPC value is not commissioned, the Commissioning Reusable Component defines the EPC value in the EPCIS data store. Finally, the code calls the Observation Reusable Component to record the EPC RFID tag read in the EPCIS data store.

Running the application

To deploy and run the sample SmarterPharma application:

  1. Before deploying the sample application, create a JMS activation specification in WebSphere Application Server with these attributes:
    • Scope: server1
    • Provider: default messaging provider
    • Name: SmarterPharmaAS
    • JNDI name: eis/SmarterPharmaAS
    • Destination type: Topic
    • Destination JNDI name: jms/ibmse
    • Message selector: ibmse LIKE '%/report/TagReport' OR ibmse LIKE '%/report/TagAggregationReport'
    • Bus name: ibmsensorevent
  2. Restart WebSphere Application Server to activate the new JMS activation specification.
  3. Deploy the sample application EAR to WebSphere Application Server.
  4. To run the sample application, open a Web browser and navigate to: http://<sensor_events_host_name>::9080/devworks/SmarterPharma.
  5. As mentioned earlier, this Web application will simulate sensor events that would have originated from various stages in the supply chain. The first step in that process is the unique identification of the product container at the manufacturer. In this step, a unique EPC code is assigned to an RFID tag and that tag is affixed to a product container. You then need to record the association of that EPC code with that specific product. This is commissioning. In the application, commission the EPC code by clicking the Commission button. The remaining steps in the supply chain process will also be similarly simulated using the application.
  6. Next, to generate reads for Biggie Pharmaceuticals packing and shipping, and for Speedy Distributors receiving and storing locations, select those locations from the Locations drop-down and click the Read button. At this point, the case of MigHelp you are tracking has moved from manufacturer to distributor. Since your trading partners are interconnected by means of a shared EPCIS repository, Speedy Distributors can check the authenticity of the MigHelp container by querying the EPCIS repository to get the list of EPCIS events for the container.
  7. Click on the Report button to display the EPCIS events generated for the MigHelp container. The report should contain five events similar to the report shown in Figure 4.
    Figure 4. Sample report
    Figure 4. Sample report
  8. The EPCIS events displayed in the report indicate the MigHelp container was observed at the expected locations in the supply chain, thus ensuring its authenticity. You are now ready to ship the MigHelp container from Speedy Distributors to Mom & Pop's Pharmacy. To move the container through the remaining locations in the supply chain, select Speedy Distributors packing and shipping locations and Mom & Pop's receiving and stocking locations from the Locations drop-down and click the Read button.
  9. When the container has been received by Mom & Pop's Pharmacy, Mom & Pop's can check the container's pedigree by querying the shared EPCIS repository for the container's EPCIS events. The final report should contain a total of nine events, as shown in Figure 5.
    Figure 5. Final report
    Figure 5. Final report

You can see in this simple report view that you now have access to critical supply chain data that was previously unavailable. In deployment scenarios, this type of supply chain data can be used for near real-time operational process monitoring, for short and long term analytics and process optimizations, and to represent key metrics in dashboards and monitors that could signal potential bottlenecks so that proactive steps can be taken; this is in addition to the product authenticity verification and tamper detection that have also been implemented.

Using InfoSphere Traceability Server

The use of InfoSphere Traceability Server is not required to run the sample application as it has constructed it here. However, its role is extremely important in actual supply chain deployments to achieve the visibility (interconnectivity) of product movement throughout the complete supply chain process.

To use InfoSphere Traceability Server as the EPCIS data store, and to configure the Validation, Commissioning, Observation, and Reporting Reusable Components to use the EPCIS back end follow the instructions in these WebSphere Sensor Events documents:


So far, the articles in this series have explored how the key aspects of Smarter Planet -- instrumentation, interconnection, and intelligence -- are realized through sensor solutions and the use of WebSphere Sensor Events. This article focused on the supply chain, an area that spans multiple industries and solutions. It described goods shipping, receiving, and distribution in a sample pharmaceutical track and trace scenario, and showed how sensor technology, along with WebSphere Sensor Events processing, can capture new information about critical parts of the business. The new intelligence provides the basis on which a smarter supply chain can be built.

Within WebSphere Sensor Event processing, you saw how existing services that integrate sensor data into InfoSphere Traceability Server are leveraged to provide that capability for product tracking across multiple vendor participants in the supply chain process. Sample code was provided as a reference and starting point for development and delivery of smarter supply chain solutions.

The next article in this series will look at the area of healthcare and show how sensor solutions are helping provide critical patient monitoring in connected health solutions. Where we spent some time talking about the role of InfoSphere Traceability Server in the context of data sharing across the entire ecosystem in the supply chain scenario, we will describe in detail how you can derive business level events from raw sensor event data in the connected health scenario by leveraging the integrated business event processing product, IBM WebSphere Business Events. Sensor device integration beyond RFID as the base sensor technology will also be discussed to show how WebSphere Sensor Events provides device integration for a range of sensor platforms.


Code sampleSmarterPharma.zip703KB



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into WebSphere on developerWorks

ArticleTitle=Smarter Planet solutions with sensor monitoring, Part 2: Sensor solutions for a smarter supply chain