Reusable Components are WebSphere® Sensor Events task agents that can react to handle a sensor event or to provide information back to the caller or onto an SIBus. They are provided as a suite of business-level services, and they also define the programming model for building custom agents on WebSphere Sensor Events that can handle events and expose services to applications.
Each Reusable Component is a task agent and has configuration properties that can be modified in the WebSphere Sensor Events Administrative Console. For details on how to use the WebSphere Sensor Events Administrative Console to modify an agent, see Working with agents in the WebSphere Sensor Events information center.
The common configuration properties for all Reusable Components are:
This property defines the target interface or enterprise application that contains the Reusable Component implementation logic, such as ruc.epcis, ruc.wse, ruc.its, ruc.db, or ruc.custom. For example:
Setting value to ruc.custom means that you will use a custom back-end implementation. When using ruc.custom as the value, you must also specify an additional ruc.targetBackendJNDI property to point to the new back-end EJB, using its JNDI name. See Creating a Reusable Component and a back-end implementation for details about creating a customer back-end implementation.
When updating the targetBackend property, make sure the Reusable Component is targeted toward a back-end implementation that uses all of the specific back-end interfaces that the Reusable Component needs to call. The following table shows the mapping of the Reusable Components to the back-end interfaces that they need.
Reusable Component | Possible Back-End Interfaces | Name of the Back-End Interface to Use with ruc.custom |
---|---|---|
Aggregation | ruc.db, ruc.epcis, ruc.custom | Aggregation |
Asset Management | ruc.db, ruc.custom | Asset Management, Asset Type Management |
BAE | not applicable | not applicable |
Commissioning | ruc.db, ruc.epcis, ruc.its, ruc.custom | Commissioning |
Decommissioning | ruc.db, ruc.epcis, ruc.its, ruc.custom | Commissioning |
Disaggregation | ruc.db, ruc.epcis, ruc.custom | Aggregation |
EPC | ruc.its, ruc.wse, ruc.custom | EPC Management |
EPCIS Connector | not applicable | not applicable |
Inference | ruc.db, ruc.its, ruc.custom | Aggregation Inference |
Info | ruc.its, ruc.custom | Aggregation Inference, EPC Detailed Query, Master Data |
Locating | ruc.db, ruc.epcis, ruc.custom | Observation |
Observation | ruc.db, ruc.epcis, ruc.custom | Observation |
ruc.wse, ruc.custom | EPC Print | |
Reporting | ruc.db, ruc.epcis, ruc.custom | Observation |
Validation | ruc.db, ruc.epcis, ruc.its, ruc.custom | Commissioning |
WBE | not applicable | not applicable |
Each Reusable Component can have multiple actions, so you may need multiple versions of the action-name.output.success and action-name.output.failure properties. Also, certain Reusable Components have additional properties that are further explained in the individual topics for each Reusable Component.
You also use the WebSphere Sensor Events Administrative Console to set the endpoints for the Reusable Components. The endpoints are necessary when you are using Web services to call InfoSphere Traceability Server. You can set the endpoints as properties in either the WebSphere Sensor Events SystemAgent or in each individual Reusable Component task agent. Setting the endpoints in the SystemAgent means that any Reusable Component can use them, while setting the endpoints in individual Reusable Component task agents means you that particular agent will use those endpoints. You can also leave the endpoint property value empty in a task agent if you are not using ruc.epcis or ruc.its as the back-end implementation in that specific Reusable Component.
Use the following properties to set the complete endpoint, or a specific part of the endpoint:
The following values are supported for the remote_system name epcis, which is used by the ruc.epcis back-end implementation for all queries and the ruc.its back-end implementation for many queries:
There are three methods for invoking Reusable Components: stateless session beans, Web services, and MDBs.
Stateless session beans and Web services are synchronous calls, meaning that if those methods returns a value, then they will return that value directly. The MDBs are asynchronous, meaning that when a message is sent to the Reusable Component, the Reusable Component sends a response to the SIBus, instead of directly returning the response value. To retrieve the response value, you must subscribe to the response message topic. The topic names are configurable for each action in each Reusable Component.
For more information, refer to the exact API for each Reusable Component that is explained in each Reusable Component detail topic. The API is also in the Javadoc information.
For more information, refer to the API that is a subset of the session bean methods, as indicated in each Reusable Component detail topic.