Scenario 3: Push notifications with quality of service
This chapter provides an example scenario that uses several different systems to send push notifications with different qualities of service (QoS). This scenario demonstrates how a back-end enterprise application can send push notifications to selected mobile applications, and can also send broadcast messages to all mobile applications connected to IBM MessageSight server.
Beyond the delivery of notification messages to Android applications, this scenario does not present the business decision-making logic for sending these notifications.
This chapter covers the following topics:
|
Tip: If you want to implement the scenario presented in this chapter in your own environment, you can download the Project Interchange file for the applications used in this scenario from the IBM Redbooks website. For download instructions, see Appendix D, “Additional material” on page 341.
|
9.1 Business value
Short Messaging Service (SMS) and Multimedia Messaging Service (MMS) messages are delivered by wireless carriers to specific devices using the phone numbers. Developers of server-side applications that implement SMS and MMS messaging must interact extensively with the existing, closed telecommunications infrastructure, including obtaining phone numbers.
The popularity of smartphones, such as iPhone and Android devices, has created a need for a modern mobile messaging infrastructure:
•Is more open and less expensive than SMS or MMS
•Can deliver rich media information directly to the installed application, rather than to phone numbers
A push notification is the ability of mobile devices to receive messages that are pushed from the back-end application and servers. Notifications are received regardless of whether the application is running, and take these forms:
•Alerts (text messages)
•Badges (marks on the application icon)
•Sounds (audio alerts)
•Notification center (iOS) and Notification bar (Android)
The following list includes a few of the benefits of using push notifications:
•Control. Users can choose whether to subscribe to the push service.
•Availability. Push notifications arrive at the user’s device regardless of whether the application is running.
•Efficiency. There is no need to issue constant queries from the applications, which translates to reduced development effort, better application performance, and savings on battery and communication fees.
Common push notification architecture supports a variety of scenarios:
•A single application notifying multiple devices of the same user
•Multiple event sources used by the same application
•Multiple applications using the same event source
•Multiple users logging in to the same application
9.1.1 Using push notifications with MQTT
In many situations, for mobile applications that must react to some data from a remote server, it is more efficient for changes to the data to be pushed to the mobile application, rather than for the mobile to repeatedly poll the server. Polling is generally an unsatisfactory compromise.
Polling infrequently results in a mobile application that can appear slow to respond to changes in the data. For example, polling every 10 minutes can potentially result in an application that takes 9 minutes before it notices the queried data has changed.
Frequently polling can mitigate long waits, but at the cost of increasing the consumption of battery and network resources in the device. It is better for the mobile application to do neither, and simply wait for the server to tell it when the data changes.
In MQTT, after the connection is established, events can be transmitted in both directions, from the client to the server or from the server to the client. Therefore, if the server has data available for the client, the server can push this data to the client rather than the client continuously polling for data on the server until the message is available.
Reliable delivery of messages across fragile networks with different qualities of service, even when the connection breaks, is one of the important features of the MQTT specification. MQTT provides three qualities of service for message delivery:
Qos0 At most once, where messages are delivered according to the best efforts of the operating environment. Message loss or duplication can occur.
QoS1 At least once, where messages are assured to arrive but duplicates can occur.
QoS2 Exactly once, where messages are assured to arrive exactly once.
Using pushing notifications with MQTT provides all of the advantages of MQTT, along with the ability to deliver notifications with various QoS.
9.2 Prerequisites: Technical and infrastructure
To fully understand the scenario, and to successfully implement it in your own infrastructure, both technical and infrastructure prerequisites are required.
9.2.1 Software prerequisites
To run this scenario, you must have the following components installed:
•IBM MessageSight V1.0.0.1 (Appliance)
•WebSphere MQ V7.5.0.2
•IBM Integration Bus V9.0.0.0
•IBM DB2 V10.1.0.2
•Android software development kit (SDK) emulator
Figure 9-1 illustrates the configuration of the environment used to implement this scenario, and represents the systems of the fictitious company, ITSO Transport Corporation.
Figure 9-1 System configuration for ITSO Transport Corporation
For the purpose of this scenario, there are three servers:
•The first server is the IBM MessageSight appliance placed in the DMZ (layers of protection between the server and the device).
•The second server hosts the back-end enterprise service bus (ESB) integration server, and has IBM Integration Bus V9.0 and WebSphere MQ V7.5 installed on it.
•The third server hosts the back-end database, and has IBM DB2 V10.1 installed on it.
9.2.2 Skills prerequisites
To fully implement and understand this scenario, you must be familiar with these tasks:
•Configuring IBM MessageSight infrastructure
•Configuring WebSphere MQ infrastructure
•Configuring IBM Integration Bus infrastructure and developing message flows
•Configuring IBM DB2 infrastructure
9.3 Scenario outline
In this section, you look at an overview of how to configure this scenario. In later sections we go through a detailed description of this configuration.
The fictitious company ITSO Transport Corporation provides transport services to grocery retailers around the country. Trucks from this company are scheduled to pick up groceries from centralized cold storage and deliver groceries to the retail stores using trucks enabled with cold storage containers.
Timely delivery of groceries is a key success attribute for their business, and it helps build customer satisfaction. Every truck scheduled for delivery has two crew members, a truck driver and an assistant.
Timely delivery of groceries is critical to this business, so that fresh produce can be sold on the counters. Any problems during the delivery can cause delivery delays and groceries to get stale. It has been observed that deliveries are obstructed by a variety of problems on the highways. Truck drivers who are not aware of traffic congestion and weather problems on their delivery route might run into unexpected problems and cause delivery delays.
9.3.1 Push notification to selected mobile applications
To help drivers save time and be safe on the highways, ITSO Transport company wants to develop a push notification system that analyzes drivers’ current locations and notifies them with any problems predicted on their delivery route.
Any changes to the geographic location of trucks are published from the mobile applications through MQTT using the MQTT topic string illustrated in Example 9-1. <Truck Number> in the topic string is also the client ID, and is replaced with the actual truck number.
Example 9-1 Geographic location change, publish topic string
/itso/driver/geolocation/<Truck Number>
Example 9-2 illustrates the message payload format for the geographic location changes.
Example 9-2 Geographic location change, message format
TimeStamp,driver username,longitude,latitude
Table 9-1 summarizes the publisher and subscriber for the geographic location topic.
Table 9-1 Publisher and subscriber for the geographic location topic
|
Application
|
Action
|
Protocol
|
QoS
|
Retained
|
|
ITSO mobile application
|
PUBLISH
|
MQTT
|
0
|
N/A
|
|
ITSO back-end enterprise application
|
SUBSCRIBE
|
Java Message Service (JMS)
|
N/A
|
N/A
|
Geographic location changes are published from the ITSO Transport mobile application through MQTT to the IBM MessageSight server. In the background, there is an enterprise application that subscribes to the same topic, as shown in Example 9-1, and receives truck location changes through JMS connection.
This back-end enterprise application is implemented through an IBM Integration Bus message flow that has a JMSInput node. This message flow captures the location changes of trucks and inserts that data into the database.
There is another message flow on IBM Integration Bus:
1. Runs at a scheduled time
2. Checks for all trucks whose geographic location is available in the database
3. Sends them a message as a push notification that sends the drivers critical alert messages
|
Note: The algorithm to select trucks that is provided in this scenario is basic. Better implementations can be performed through integration with rule management systems, such as IBM WebSphere Operational Decision Management. However, to keep it simple for the purposes of this example, push notification is sent to unique trucks whose geographic location is available in the database.
|
The second message flow is based on timer nodes and is run at specific intervals of time. It identifies unique truck numbers that updated their geographic location in the ITSO database. The message flow selects appropriate notification messages for the identified trucks.
This message flow uses a JMS topic, as shown in Example 9-3, to send the notification alerts. <Truck Number> in this topic string is replaced with the actual truck number for which the notification is intended.
Example 9-3 Push notification topic for selected trucks
/itso/driver/notification/<TruckNumber>
The MQTT mobile application subscribes on the same topic in Example 9-3, but the <Truck Number> is replaced with the actual truck number to receive notifications from the back-end system. An alert message sent as a push notification can be in ASCII string format.
Table 9-2 summarizes the publisher and subscriber for push notification topics for selected trucks.
Table 9-2 Publisher and subscriber for push notification topics for selected trucks
|
Application
|
Action
|
Protocol
|
QoS
|
Retained
|
|
ITSO mobile application
|
SUBSCRIBE
|
MQTT
|
2
|
N/A
|
|
ITSO back-end enterprise application
|
PUBLISH
|
JMS
|
N/A
|
N/A
|
Figure 9-2 illustrates the scenario:
1. Geographic location changes are captured from mobile applications in trucks.
2. The back-end system uses that data to send critical alert notifications to selected trucks.
Figure 9-2 Push notification to selected mobile application
9.3.2 Push notification broadcast to all mobile applications
The ITSO Transport Corporation back-end office team might want to notify all of the trucks currently delivering groceries with a few important alerts. Messages to be broadcast are accepted through a WebSphere MQ queue, and later the IBM Integration Bus V9 message flow gets those messages and transforms them in JMS format. The message is marked as retained, and published on a JMS topic, as shown in Example 9-4.
Example 9-4 Push notification topic for all trucks
/itso/driver/notification/AllTrucks
The same topic string is used by the ITSO Transport mobile application to subscribe for broadcast notification messages through MQTT. Alert messages sent as push notifications can be in ASCII string format.
Table 9-3 summarizes the publisher and subscriber for push notification topics for all trucks currently delivering groceries.
Table 9-3 Publisher and subscriber for push notification topics for all trucks
|
Application
|
Action
|
Protocol
|
QoS
|
Retained
|
|
ITSO mobile application
|
SUBSCRIBE
|
MQTT
|
1
|
N/A
|
|
ITSO back-end enterprise application
|
PUBLISH
|
JMS
|
N/A
|
True
|
Figure 9-3 illustrates the scenario described in this section:
1. The back-end office staff can send important notifications for trucks through WebSphere MQ.
2. Later, the message is published to all trucks.
Figure 9-3 Push notification to all mobile applications
|
Note: In the broadcast scenario, the JMS publisher sends retained publications to the MQTT subscribers.
|
9.4 Scenario configuration and implementation
In all of the following steps, we assume that the IBM MessageSight, IBM Worklight, and IBM Integration Bus components are installed, configured, and tested to ensure that they function properly, and that a nominal performance configuration is put in place for each component of the integration to accommodate the anticipated processing load.
For detailed information about installing the applications, see the installation guide and the performance tuning guide (if applicable) for each of these products.
9.4.1 Configuring IBM MessageSight
First, log in to the appliance using the console.
Creating a group for ITSO Transport truck drivers
This is a functional group for truck driver user names. The users of this group are allowed through the connection and messaging policy in a message hub.
You can create the IBM MessageSight groups using the imaserver group command. Example 9-5 shows the syntax of this command.
Example 9-5 The imaserver create group command
imaserver group add "GroupID=GroupID" "GroupMembership=group" "Description=description"
For more information about the parameters for the imaserver group command, see the following website:
The command in Example 9-6 creates a group called drivers on IBM MessageSight ima1.itso.transport.com.
Example 9-6 Creating group drivers on IBM MessageSight
Console> imaserver group add "GroupID=drivers" "Description=ITSO Truck driver group"
The requested configuration change has completed successfully.
Creating users for ITSO Transport
Create four messaging users as example truck drivers in ITSO Transport Corporation. These users are members of the drivers group created previously. Table 9-4 illustrates the messaging users for the ITSO Transport mobile application.
Table 9-4 Messaging users for ITSO Transport mobile application
|
Driver user name
|
Driver password
|
Group membership
|
|
driver01
|
dr!ver@1
|
drivers
|
|
driver02
|
dr!ver@2
|
drivers
|
|
driver03
|
dr!ver@3
|
drivers
|
|
driver04
|
dr!ver@4
|
drivers
|
|
Important: The password mentioned here is for illustration purposes only. You ought to follow the password standards as applicable in your organization.
|
You can create the IBM MessageSight groups by using the imaserver user command. Example 9-7 shows the syntax of this command.
Example 9-7 The imaserver create user command
imaserver user add "UserID=UserID" "Type=Messaging" "Password=password" "GroupMembership=GroupID" "Description=description"
For more information about the parameters for the imaserver user command, see the following website:
The imaserver user add commands in Example 9-8 create messaging users driver01, driver02, driver03, and driver04 on IBM MessageSight ima1.itso.transport.com.
Example 9-8 Creating messaging user drivers on IBM MessageSight
Console> imaserver user add "UserID=driver01" "Type=Messaging" "Password=dr!ver@1" "GroupMembership=drivers" "Description=ITSO Transport Driver 01"
The requested configuration change has completed successfully.
Console> imaserver user add "UserID=driver02" "Type=Messaging" "Password=dr!ver@2" "GroupMembership=drivers" "Description=ITSO Transport Driver 02"
The requested configuration change has completed successfully.
Console> imaserver user add "UserID=driver03" "Type=Messaging" "Password=dr!ver@3" "GroupMembership=drivers" "Description=ITSO Transport Driver 03"
The requested configuration change has completed successfully.
Console> imaserver user add "UserID=driver04" "Type=Messaging" "Password=dr!ver@4" "GroupMembership=drivers" "Description=ITSO Transport Driver 04"
The requested configuration change has completed successfully.
The imaserver user list command in Example 9-9 lists the messaging users created on IBM MessageSight.
Example 9-9 List of messaging users
Console> imaserver user list "Type=Messaging"
UserID: driver01
Description: ITSO Transport Driver 01
Group Membership: drivers
UserID: driver02
Description: ITSO Transport Driver 02
Group Membership: drivers
UserID: driver03
Description: ITSO Transport Driver 03
Group Membership: drivers
UserID: driver04
Description: ITSO Transport Driver 04
Group Membership: drivers
Creating a message hub
Create a message hub for ITSO Transport Corporation with the name ITSO_HUB. Table 9-5 lists the message hub to be created.
Table 9-5 ITSO message hub in MessageSight
|
Message hub
|
Description
|
|
ITSO_HUB
|
Message hub for ITSO Transport application
|
You can create the MessageSight message hubs by using the imaserver create MessageHub command. Example 9-10 shows the syntax of this command.
Example 9-10 The imaserver create hub command
imaserver create MessageHub "Name=hubName" "Description=description"
For more information about all of the parameters for the imaserver create MessageHub command, see the following website:
The command in Example 9-11 creates a message hub called ITSO_HUB on IBM MessageSight ima1.itso.transport.com.
Example 9-11 Creating a message hub on IBM MessageSight
Console> imaserver create MessageHub "Name=ITSO_HUB" "Description=Message Hub for ITSO Transport Application"
The requested configuration change has completed successfully.
Creating connection policies
Two connection policies are created for the ITSO_HUB message hub. Table 9-6 summarizes these connection policies.
Table 9-6 Summary of connection policies
|
Connection policy name
|
Protocol
|
Description
|
|
ITSO_Connections_Driver
|
MQTT
|
Connection policy for the ITSO Transport mobile application on trucks
|
|
ITSO_Connections_ESB
|
JMS
|
Connection policy for the ITSO Transport back-end enterprise application using the JMS protocol
|
You can create the MessageSight connection policies by using the imaserver create ConnectionPolicy command. Example 9-12 shows the syntax for this command.
Example 9-12 The imaserver create connection policy command
imaserver create ConnectionPolicy "Name=connPolicyName" "Description=description" "ClientID=ClientID" "ClientAddress=IP_Address" "UserID=UserID" "GroupID=groupName" "CommonNames=certificateCommonNames" "Protocol=protocols"
For more information about all of the parameters for the imaserver create ConnectionPolicy command, see the following website:
The command in Example 9-13 creates the ITSO_Connections_Drivers connection policy for mobile applications to connect to IBM MessageSight ima1.itso.transport.com.
Example 9-13 Creating the ITSO_Connections_Drivers connection policy
Console> imaserver create ConnectionPolicy "Name=ITSO_Connections_Drivers" "Description=Connection policy for ITSO Transport mobile application on trucks" "ClientID=CASJC*" "GroupID=drivers" "Protocol=MQTT"
The requested configuration change has completed successfully.
The command in Example 9-14 creates the ITSO_Connections_ESB connection policy for back-end connections established from IBM Integration Bus message flows using the JMS protocol. The ClientAddress referred to in the command is the IP address for the IBM Integration Bus server iib1.itso.transport.com.
Example 9-14 Creating the ITSO_Connections_ESB connection policy
Console> imaserver create ConnectionPolicy "Name=ITSO_Connections_ESB" "Description=Connection policy for ITSO Transport back-end enterprise application through JMS protocol" "ClientAddress=9.12.5.184" "Protocol=JMS"
The requested configuration change has completed successfully.
The ClientID referred to in the connection policy for the mobile application in Example 9-13 is the truck number driven by an ITSO Transport Corporation driver. Table 9-7 illustrates the trucks in the ITSO Transport Corporation fleet.
Table 9-7 ITSO Transport trucks
|
Truck Number
|
Description
|
|
CASJC01
|
Truck driven by driver01
|
|
CASJC02
|
Truck driven by driver02
|
|
CASJC03
|
Truck driven by driver03
|
|
CASJC04
|
Truck driven by driver04
|
The command in Example 9-15 shows the list of connection policies just created.
Example 9-15 List connection policies
Console> imaserver list ConnectionPolicy
ITSO_Connections_Drivers
ITSO_Connections_ESB
Creating messaging policies
Four messaging policies are created for this scenario. Table 9-8 summarizes these messaging policies.
Table 9-8 Summary of messaging policies
|
Messaging policy name
|
Protocol
|
Description
|
|
ITSO_Driver_Geolocation_Publish
|
MQTT
|
Messaging policy for publishing the truck longitudes and latitudes
|
|
ITSO_ESB_Geolocation_
Subscribe |
JMS
|
Messaging policy for back-end ESB to subscribe for geographic location changes
|
|
ITSO_Driver_Notification_Subscribe
|
MQTT
|
Messaging policy for trucks to receive notifications and broadcasts
|
|
ITSO_ESB_Notification_
Publish |
JMS
|
Messaging policy for back-end policy to send notifications
|
You can create the MessageSight messaging policies by using the imaserver create MessagingPolicy command. Example 9-16 shows the syntax for this command.
Example 9-16 The imaserver create messaging policy command
imaserver create MessagingPolicy "Name=msgPolicyName" "Description=description" "DestinationType=type" "Destination=destinationName" "MaxMessages=count" "ActionList=actions" "ClientID=ClientID" "UserID=UserID" "GroupID=groupName" "CommonNames=certificateCommonNames" "ClientAddress=IP_Address" "Protocol=protocols"
For more information about all of the parameters for the imaserver create MessagingPolicy command, see the following website:
The command in Example 9-17 creates the ITSO_Driver_Geolocation_Publish messaging policy. This policy is for mobile applications to connect to IBM MessageSight ima1.itso.transport.com through MQTT, and to enable the publish action on topics matching the pattern /itso/driver/geolocation/*.
Example 9-17 Creating the ITSO_Driver_Geolocation_Publish messaging policy
Console> imaserver create MessagingPolicy "Name=ITSO_Driver_Geolocation_Publish" "Description=Messaging policy for publishing the truck longitude and latitudes" "DestinationType=Topic" "Destination=/itso/driver/geolocation/*" "MaxMessages=5000" "ActionList=Publish" "ClientID=CASJC*" "GroupID=drivers" "Protocol=MQTT"
The requested configuration change has completed successfully.
The command in Example 9-18 creates the ITSO_ESB_Geolocation_Subscribe connection messaging policy. This policy is for back-end connections established from IBM Integration Bus message flows using the JMS protocol. This messaging policy enables message flows to subscribe on topics with pattern *. The ClientAddress referred to in the command is the IP address for the IBM Integration Bus server iib1.itso.transport.com.
Example 9-18 Creating the ITSO_ESB_Geolocation_Subscribe messaging policy
Console> imaserver create MessagingPolicy "Name=ITSO_ESB_Geolocation_Subscribe" "Description=Messaging policy for back-end ESB to subscribe for GeoLocation" "DestinationType=Topic" "Destination=*" "MaxMessages=5000" "ActionList=Subscribe" "ClientAddress=9.12.5.184" "Protocol=JMS"
The requested configuration change has completed successfully.
The command in Example 9-19 creates the ITSO_Driver_Notification_Subscribe messaging policy. This policy is for mobile applications to connect to IBM MessageSight ima1.itso.transport.com using the MQTT protocol, and to enable the subscribe action on topics matching the pattern *.
Example 9-19 creating messaging policy ITSO_Driver_Notification_Subscribe
Console> imaserver create MessagingPolicy "Name=ITSO_Driver_Notification_Subscribe" "Description=Messaging policy for trucks to receive notifications and broadcast." "DestinationType=Topic" "Destination=/itso/driver/notification/*" "MaxMessages=5000" "ActionList=Subscribe" "ClientID=CASJC*" "GroupID=drivers" "Protocol=MQTT"
The requested configuration change has completed successfully.
The command in Example 9-20 creates the ITSO_ESB_Notification_Publish, for back-end connection connections established from IBM Integration Bus message flows through JMS protocol. This messaging policy enables message flows to publish on topics with pattern *. The clientAddress referred in the command is the IP address for IBM Integration Bus server iib1.itso.transport.com.
Example 9-20 Creating messaging policy ITSO_ESB_Notification_Publish
Console> imaserver create MessagingPolicy "Name=ITSO_ESB_Notification_Publish" "Description=Messaging policy for back-end policy to send notifications" "DestinationType=Topic" "Destination=*" "MaxMessages=5000" "ActionList=Publish" "ClientAddress=9.12.5.184" "Protocol=JMS"
The requested configuration change has completed successfully.
The command in Example 9-21 on page 241 shows the list of messaging policies just created.
Example 9-21 List messaging policies
Console> imaserver list MessagingPolicy
ITSO_Driver_Geolocation_Publish
ITSO_ESB_Geolocation_Subscribe
ITSO_Driver_Notification_Subscribe
ITSO_ESB_Notification_Publish
Creating an endpoint
One endpoint is created for this scenario, as listed in Table 9-9.
Table 9-9 ITSO endpoint in IBM MessageSight
|
Endpoint
|
Description
|
|
ITSO_EndPoint
|
Connection endpoint for MQTT and JMS connections
|
You can create the IBM MessageSight endpoint by using the imaserver create Endpoint command. Example 9-22 shows the syntax of this command.
Example 9-22 The imaserver create endpoint command
imaserver create Endpoint "Name=endpointName" "Description=description" "Port=portNumber" "Interface=IP_Address" "Protocol=protocols" "ConnectionPolicies=connPolicies" "MessagingPolicies=msgPolicies" "MaxMessageSize=size" "MessageHub=hubName" "SecurityProfile=secProfile" "Enabled=True|False"
For more information about all of the parameters for the imaserver create Endpoint command, see the following website:
The command in Example 9-23 creates an endpoint called ITSO_Endpoint for the ITSO_HUB messaging hub. This endpoint uses all of the connection and messaging policies that were just created.
Example 9-23 Creating endpoint ITSO_Endpoint
Console> imaserver create Endpoint "Name=ITSO_Endpoint" "Description=Connection end-point for MQTT and JMS connection" "Port=16105" "Interface=All" "Protocol=JMS,MQTT" "ConnectionPolicies=ITSO_Connections_Drivers,ITSO_Connections_ESB" "MessagingPolicies=ITSO_Driver_Geolocation_Publish,ITSO_ESB_Geolocation_Subscribe,ITSO_Driver_Notification_Subscribe,ITSO_ESB_Notification_Publish" "MaxMessageSize=1024KB" "MessageHub=ITSO_HUB" "Enabled=True"
The requested configuration change has completed successfully.
After the endpoint is created and enabled, it is ready to be used by JMS and MQTT applications.
9.4.2 Configuring IBM DB2
Database for capturing the geographic locations published from the mobile application in the trucks is created on the db.itso.transport.com server. The database is created with the name ITSODB. Example 9-24 shows the command to create DB2 database ITSODB.
Example 9-24 Creating the ITSODB database
$ db2 CREATE DB ITSODB
DB20000I The CREATE DATABASE command completed successfully.
After the database is successfully created, issue a command to connect to the database. Example 9-25 shows the command to connect to the ITSODB database.
Example 9-25 Connect to the ITSODB database
$ db2 CONNECT TO ITSODB
Database Connection Information
Database server = DB2/LINUXX8664 10.1.2
SQL authorization ID = DB2INST1
Local database alias = ITSODB
Open the DB2 console, and create a table called TRUCKGEOLOCATION, as shown in Example 9-26.
Example 9-26 Creating the TRUCKGEOLOCATION table
db2 => CREATE TABLE TRUCKGEOLOCATION (TIMSTAMP TIMESTAMP, DRIVER_NAME VARCHAR(30), TRUCK_NUMBER VARCHAR(30), LONGITUDE VARCHAR(30), LATITUDE VARCHAR(30))
DB20000I The SQL command completed successfully.
|
Note: Ensure that the database is configured for a DB2 connection service port. For ITSODB, this service is configured to bind port 50001.
|
9.4.3 Configuring WebSphere MQ
In this scenario, use WebSphere MQ queue manager to create an IBM Integration Bus integration node. Also, a queue on this queue manager is used for receiving broadcast messages from the ITSO Transport Corporation back-end office team.
Creating the ITSOQM2 queue manager
You can create the queue managers by using the crtmqm command.
For more information about all of the parameters for the crtmqm command, see the following website:
Example 9-27 shows the command to create a queue manager called ITSOQM2.
Example 9-27 Command to create the ITSOQM2 queue manager
$ crtmqm ITSOQM2
WebSphere MQ queue manager created.
Directory '/var/mqm/qmgrs/ITSOQM2' created.
The queue manager is associated with installation 'Installation1'.
Creating or replacing default objects for queue manager 'ITSOQM2'.
Default objects statistics : 74 created. 0 replaced. 0 failed.
Completing setup.
Setup completed.
Now that all of the queue managers are created, you must start them using the strmqm command.
For more information about all of the parameters for the strmqm command, see the following website:
Example 9-28 shows the command used to start the various queue managers.
Example 9-28 Command to start the ITSOQM2 queue manager
strmqm ITSOQM2
Creating a listener object on the queue manager
In this section, you create listener objects on various queue managers by issuing commands on the WebSphere MQ runmqsc console. Also, the listeners’ control is set to be the queue manager (QMGR), so that listeners start and stop based on the control of the queue manager.
For more information about defining listeners, see the following website:
Example 9-29 illustrates commands to create and start a listener on the ITSOQM2 queue manager.
Example 9-29 Creating and start listener on the ITSOQM2 queue manager
DEFINE LISTENER(ITSOQM2.LISTENER) TRPTYPE(TCP) CONTROL(QMGR) PORT(1414) IPADDR('iib2.itso.transport.com') REPLACE
START LISTENER(ITSOQM2.LISTENER)
Creating a server connection channel
Message Queue Interface (MQI) channels are used by applications in client mode (rather than bindings mode) to connect to queue managers. MQI channels are bidirectional:
•They carry WebSphere MQ API calls, (for example, GET a message from queue XYZ) from the application to the queue manager.
•They also carry responses to those calls from the queue manager back to the application.
For more information about defining channels, see the following website:
Example 9-30 shows the command to be used from the runmqsc console to create the SYSTEM.BKR.CONFIG server connection channel on the ITSOQM2 queue manager.
Example 9-30 Creating a server connection channel
DEFINE CHANNEL('SYSTEM.BKR.CONFIG') CHLTYPE(SVRCONN) REPLACE
Creating a local queue for the application
Example 9-31 shows the command to be ran from the runmqsc console of the ITSOQM2 queue manager.
Example 9-31 Creating a local queue for the ITSO Transport back-end application
DEFINE QLOCAL(ITSO.BROADCAST.IN)
For more information about defining local queues, see the following website:
The ITSO.BROADCAST.IN queue on the ITSOQM2 queue manager is used for receiving broadcast messages from the ITSO Transport Corporation back-end office team. Messages from this queue are broadcast to the mobile application in trucks using IBM Integration Bus and the IBM MessageSight appliance.
|
Exception: To simplify this scenario, the channel authentication is disabled on the ITSOQM2 queue manager by using the following command in the runmqsc console:
ALTER QMGR CHLAUTH(DISABLED)
|
9.4.4 Configuring IBM Integration Bus
In this scenario, you use IBM Integration Bus to capture geographic location change messages from IBM MessageSight. All communication from IBM Integration Bus and IBM MessageSight is performed using the JMS protocol. IBM MessageSight acts as a JMS service provider, and IBM Integration Bus acts as a JMS client. The message flow created in this scenario serves the following purposes:
•Capture geographic location changes and submit them in a database.
•Run a timer-based flow, then identify the trucks that must be notified with notifications based on their geographic location. Notify all of the selected trucks.
•Send a broadcast notification to all of the trucks.
Use the following steps to configure IBM Integration Bus for this scenario:
1. Create an integration node.
2. Create an integration server.
3. Configure a JMS provider for IBM MessageSight.
4. Configure a Java Database Connectivity (JDBC) provider for IBM DB2.
5. Create an IBM Integration Bus application.
6. Deploy an IBM Integration Bus application.
Creating an integration node
You can create an integration node using the mqsicreatebroker command. Example 9-32 shows the syntax of this command.
Example 9-32 The mqsicreatebroker command syntax
mqsicreatebroker brokerName -q queueManagerName [-i generalDefaultUserId -a generalDefaultPassword] [-g configurationChangeTimeout] [-k internalConfigurationTimeout] [-w workPath] [-e sharedWorkPath] [-l userLilPath] [-t] [-m] [-v statisticsMajorInterval] [-P httpListenerPort] [-c icuConverterPath] [-y ldapPrincipal -z ldapCredentials] [-x userExitPath] [-o operationMode] [-s adminSecurity] [-d MQService] [-b cachePolicy] [-r cachePortRange] [-4 integrationRegistryHostname]
To learn more about all of the parameters for the mqsicreatebroker command, see the following website:
ITSOBK2 integration node on iib2.itso.transport.com
Example 9-33 shows the mqsicreatebroker command run on the iib2.itso.transport.com server to create an integration node called ITSOBK2.
Example 9-33 Creating the ITSOBK2 integration node
mqsicreatebroker ITSOBK2 -i <username> -a <password> -q ITSOQM2
Now that an integration node is created, you can start the node using the mqsistart command, as shown in Example 9-34.
Example 9-34 The syntax for the mqsistart command
mqsistart <integration node name>
To learn more about the mqsistart command, go to the following website:
The command used to start the ITSOBK2 integration node is shown in Example 9-35.
Example 9-35 Start the ITSOBK2 integration node
mqsistart ITSOBK2
Creating an integration server
In this section, you create an integration server on the ITSOBK2 integration node by issuing the mqsicreateexecutiogroup command. An execution group is a named grouping of message flows that is assigned to an integration node. The integration node enforces a degree of isolation between message flows in distinct integration servers by ensuring that they run in separate address spaces, or as unique processes.
Example 9-36 shows the syntax of the mqsicreateexecutiongroup command.
Example 9-36 The syntax of the mqsicreateexecutiongroup command
mqsicreateexecutiongroup brokerSpec -e egName [-w timeoutSecs] [-v traceFileName]
To learn more about the mqsicreateexecutiongroup command, see the following website:
Create the ITSOEG integration server on the ITSOBK2 integration node. Example 9-37 shows the mqsicreateexecutiongroup command run on ITSOBK2.
Example 9-37 Creating the ITSOEG integration server on ITSOBK2
mqsicreateexecutiongroup ITSOBK2 -e ITSOEG
Figure 9-4 The ITSOEG integration node on ITSOBK2
Configuring a JMS provider for IBM MessageSight
An IBM Integration Bus node must be configured to use IBM MessageSight JMS client libraries. You can download IBM MessageSight client libraries from the following website:
Download the JMS client library for IBM MessageSight, and extract it into a file system accessible by IBM Integration Bus. In this scenario, the JMS libraries are placed in the /home/wmbadmin/ImaClient directory of the iib2.itso.transport.com server. Example 9-38 shows the JMS client libraries available in this location.
Example 9-38 IBM MessageSight JMS client libraries
$ pwd
/home/wmbadmin/ImaClient/jms/lib
$ ls -lrt
total 368
-rwxrwxrwx 1 wmbadmin mqbrkrs 77116 Jul 10 15:30 providerutil.jar
-rwxrwxrwx 1 wmbadmin mqbrkrs 25998 Jul 10 15:30 jms.jar
-rwxrwxrwx 1 wmbadmin mqbrkrs 22769 Jul 10 15:30 fscontext.jar
-rwxrwxrwx 1 wmbadmin mqbrkrs 209139 Jul 28 05:02 imaclientjms.jar
-rwxrwxrwx 1 wmbadmin mqbrkrs 29120 Jul 28 05:02 jmssamples.jar
After the ITSOBK2 integration node is created, it has a predefined, configurable service for the IBM MessageSight JMS provider named IBM_MessageSight.
Example 9-39 shows the predefined JMS provider that exists for IBM MessageSight in the ITSOBK2 integration node.
Example 9-39 The IBM_MessageSight JMS provider in the ITSOBK2 integration node
$ mqsireportproperties ITSOBK2 -c JMSProviders -o IBM_MessageSight -r
JMSProviders
IBM_MessageSight
clientAckBatchSize='0'
clientAckBatchTime='0'
connectionFactoryName=''
initialContextFactory=''
jarsURL='default_path'
jmsAsyncExceptionHandling='false'
jmsProviderXASupport='true'
jndiBindingsLocation=''
jndiEnvironmentParms='default_none'
nativeLibs='default_Path'
proprietaryAPIAttr1='default_none'
proprietaryAPIAttr2='default_none'
proprietaryAPIAttr3='default_none'
proprietaryAPIAttr4='default_none'
proprietaryAPIAttr5='default_none'
proprietaryAPIHandler='default_none'
The mqsichangeproperties command is used to update the IBM_MessageSight JMS provider with the location of the IBM MessageSight JMS client libraries.
Example 9-40 The syntax of the mqsichangeproperties command
mqsichangeproperties BrokerName ( -b httplistener | -b securitycache | -b servicefederation | -b webadmin | -b cachemanager | -e ExecutionGroupLabel | -c ConfigurableService ) -o ObjectName -n PropertyName ( -v PropertyValue | -d | -p Path/Filename ) [-f]
To learn more about the mqsichangeproperties command, see the following website:
Example 9-41 shows the mqsichangeproperties command to configure the IBM_MessageSight JMS provider with the location of the IBM MessageSight JMS client libraries.
Example 9-41 Configuring JMS provider for IBM MessageSight
mqsichangeproperties ITSOBK2 -c JMSProviders -o IBM_MessageSight -n jarsURL -v /home/wmbadmin/ImaClient/jms/lib
Example 9-42 shows the JMS provider properties after the JMS client location
is set.
is set.
Example 9-42 The IBM MessageSight JMS provider set to use JMS client libraries
$ mqsireportproperties ITSOBK2 -c JMSProviders -o IBM_MessageSight -r
JMSProviders
IBM_MessageSight
clientAckBatchSize='0'
clientAckBatchTime='0'
connectionFactoryName=''
initialContextFactory=''
jarsURL='/home/wmbadmin/ImaClient/jms/lib'
jmsAsyncExceptionHandling='false'
jmsProviderXASupport='true'
jndiBindingsLocation=''
jndiEnvironmentParms='default_none'
nativeLibs='default_Path'
proprietaryAPIAttr1='default_none'
proprietaryAPIAttr2='default_none'
proprietaryAPIAttr3='default_none'
proprietaryAPIAttr4='default_none'
proprietaryAPIAttr5='default_none'
proprietaryAPIHandler='default_none'
Configuring a JDBC provider for IBM DB2
In this section, you create a new configurable service to configure a JDBC provider for IBM DB2. However, before a new configurable service can be created, a security identity must be created to access the database. This can be done by issuing the mqsisetdbparms command.
Example 9-43 shows the syntax of the mqsisetdbparms command.
Example 9-43 The syntax of the mqsisetdbparms command
mqsisetdbparms <brokerName> -n <resource> [-u <userId>] [-p <password>] [-f]
To learn more about the mqsisetdbparms command, see the following website:
Example 9-44 shows the ITSODBId security identity created to access the database from the ITSOBK2 integration node.
Example 9-44 Creating the ITSODBId security identity
$ mqsisetdbparms ITSOBK2 -n jdbc::ITSODBId -u db2inst1 -p ********
BIP8071I: Successful command completion.
To create a new JDBC provider configurable service, use the mqsicreateconfigurableservice command. Example 9-45 shows the syntax of this command.
Example 9-45 The syntax of the mqsicreateconfigurableservice command
mqsicreateconfigurableservice brokerName -c configurableService -o object ( -n name -v value )
To learn more about the mqsicreateconfigurableservice command, see the following website:
Example 9-46 shows the command to create a new IBM DB2 JDBC provider configurable service named ITSODB.
Example 9-46 Creating the ITSODB DB2 JDBC provider
$ mqsicreateconfigurableservice ITSOBK2 -c JDBCProviders -o ITSODB -n connectionUrlFormat,databaseName,databaseVersion,databaseType,jarsURL,portNumber,securityIdentity,serverName,type4DatasourceClassName,type4DriverClassName -v 'jdbc:db2://db.itso.transport.com:50001/ITSODB:user=db2inst1;password=*******;','ITSODB','10.1','DB2 Universal Database','/opt/ibm/db2/V10.1/java','50001','ITSODBId','db.itso.transport.com','com.ibm.db2.jcc.DB2XADataSource','com.ibm.db2.jcc.DB2Driver'
BIP8071I: Successful command completion.
Example 9-47 shows the properties of the ITSODB JDBC provider configurable service.
Example 9-47 The ITSODB JDBC provider properties
$ mqsireportproperties ITSOBK2 -c JDBCProviders -o ITSODB -r
JDBCProviders
ITSODB
connectionUrlFormat='jdbc:db2://db.itso.transport.com:50001/ITSODB:user=db2inst1;password=*******;'
connectionUrlFormatAttr1=''
connectionUrlFormatAttr2=''
connectionUrlFormatAttr3=''
connectionUrlFormatAttr4=''
connectionUrlFormatAttr5=''
databaseName='ITSODB'
databaseSchemaNames='useProvidedSchemaNames'
databaseType='DB2 Universal Database'
databaseVersion='10.1'
description='default_Description'
environmentParms='default_none'
jarsURL='/opt/ibm/db2/V10.1/java'
jdbcProviderXASupport='jdbcProviderXASupport'
maxConnectionPoolSize='0'
portNumber='50001'
securityIdentity='ITSODBId'
serverName='db.itso.transport.com'
type4DatasourceClassName='com.ibm.db2.jcc.DB2XADataSource'
type4DriverClassName='com.ibm.db2.jcc.DB2Driver'
BIP8071I: Successful command completion.
Creating an IBM Integration Bus application
In this section, you create a new application named ITSOGeoNotificationBroadcast for IBM Integration Bus. Before that, you start the IBM Integration Toolkit 9.0.0.0, as described in the following procedure:
1. On the development workstation, select Start → All Programs → IBM Integration Toolkit → IBM Integration Toolkit 9.0.0.0.
2. Click Integration Toolkit 9.0.0.0 to start the Eclipse GUI.
3. In the workspace wizard, enter the workspace location and click OK.
4. After the workspace is launched, close the Welcome tab and go to the Integration Development perspective.
5. Figure 9-5 illustrates the Application Development view in the upper left corner of the Integration Development perspective. Click New Application to open the New Application wizard.
Figure 9-5 Creating a new integration application project
6. Figure 9-6 shows the New Application wizard. Enter ITSOGeoNotificationBroadcast as the Application name, and then click Finish.
Figure 9-6 Creating the ITSOGeoNotificationBroadcast application
7. Figure 9-7 shows the new IBM Integration Toolkit application project, ITSOGeoNotificationBroadcast, created in the Application Development view. Click New → Message Flow.
Figure 9-7 Creating a new message flow
8. Figure 9-8 shows the New Message Flow creation wizard. Enter the Message flow name GeoLocationNotificationMessageFlow, and then click Finish.
Figure 9-8 Creating the GeoLocationNotificationMessageFlow message flow
9. Figure 9-9 shows the message flow editor for the GeoLocationNotificationMessageFlow message flow. Proceed by dragging the nodes listed in Table 9-10 on page 256.
Figure 9-9 Creating GeoLocationNotificationMessageFlow message flow functionality
Table 9-10 lists the node name, node type, and a brief description about that node. Drag these nodes from the palette and rename them to the corresponding node name in the message flow editor area. This message flow has three different parts, each providing a different functionality.
Table 9-10 Nodes in the GeoLocationNotificationMessageFlow message flow
|
Node name
|
Node type
|
Description
|
|
Message flow - part 1: This part of the message flow receives GeoLocation updates on the /itso/driver/geolocation/+ topic, and then inserts details into the database.
|
||
|
RecordGeographic
Location |
JMSInput node
|
This node subscribes to a topic on IBM MessageSight, and receives geographic location change messages.
|
|
GeoLocationToDatabase
|
Java Compute node
|
This Java compute node inserts the changes in geographic location into a database.
|
|
Message flow - part 2: This part of the message flow runs periodically, extracts unique truck numbers from the database, and sends notifications to selected trucks. The business rule illustrated here is simple, and is for scenario purposes only.
|
||
|
Geographic
Alerts |
Timeout notification node
|
This node triggers the part of the flow after every 600 seconds.
|
|
BusinessRuleTruckSelection
|
Java compute node
|
This Java compute node selects unique truck numbers from the database for trucks that are updating changes in the geographic location.
|
|
CreateAlertTopic
|
Java compute node
|
Sends a notification to trucks that were selected by the previous node.
|
|
SendAlert
|
JMS output node
|
This JMS output node publishes notifications to specific trucks.
|
|
Message flow - part 3: A broadcast is sent to all of the trucks that are in the field and have connectivity with IBM MessageSight. The topic on which the notifications are published is /itso/driver/notification/AllTrucks.
|
||
|
BroadcastAlerts
|
WebSphere MQ Input node
|
This WebSphere MQ input node receives messages on WebSphere MQ queue, which need to be broadcast.
|
|
WebSphere MQ to JMS
|
WebSphere MQ JMS transform node
|
WebSphere MQ to JMS transformation.
|
|
setRetain
|
Java compute node
|
Set retain flag on JMS message.
|
|
setBroadcast
|
JMS output node
|
This JMS output node publishes notifications to all trucks.
|
Table 9-11 shows the terminals used to connect the nodes listed in Table 9-10 on page 256.
Table 9-11 Connection between nodes
|
Source node
|
Output terminal
|
Destination node
|
Input terminal
|
|
Message flow - part 1
|
|||
|
RecordGeographic
Location |
Out
|
GeoLocationToDatabase
|
In
|
|
Message flow - part 2
|
|||
|
Geographic
Alerts |
Out
|
BusinessRuleTruckSelection
|
In
|
|
BusinessRuleTruckSelection
|
Out
|
CreateAlertTopic
|
In
|
|
CreateAlertTopic
|
Out
|
SendAlert
|
In
|
|
Message flow - part 3
|
|||
|
BroadcastAlerts
|
Out
|
WebSphere MQ to JMS
|
In
|
|
WebSphere MQ to JMS
|
Out
|
setRetain
|
In
|
|
setRetain
|
Out
|
setBroadcast
|
In
|
10. After the nodes are renamed and connected using the details mentioned in Table 9-10 on page 256 and Table 9-11 on page 257, the connected nodes in the message flow looks similar to those shown in Figure 9-10.
Figure 9-10 Connected nodes in the GeoLocationNotificationMessageFlow message flow
11. Configure the properties of the nodes as shown in Table 9-12.
Table 9-12 Node properties
|
Node name
|
Property tab
|
Property name
|
Property value
|
|
Message flow - part 1
|
|||
|
RecordGeographicLocation
|
Basic
|
Subscription Topic
|
GeoTopic
|
|
RecordGeographicLocation
|
Basic
|
Durable subscription ID
|
itsoesb
|
|
RecordGeographicLocation
|
JMS Connection
|
Location JNDI bindings
|
file:///home
/wmbadmin |
|
RecordGeographicLocation
|
JMS Connection
|
Connection factory name
|
ITSOConnect
Factory |
|
RecordGeographicLocation
|
Input Message parsing
|
Message domain
|
BLOB
|
|
GeoLocationTo
Database |
Basic
|
Java class
|
GeoLocation
Persistence |
|
Message flow - part 2
|
|||
|
Geographic
Alerts |
Basic
|
Unique identifier
|
GeoAlert
|
|
Geographic
Alerts |
Basic
|
Timeout interval in seconds
|
600
|
|
BusinessRule
TruckSelection |
Basic
|
Java class
|
BusinessRule
TruckSelection |
|
CreateAlertTopic
|
Basic
|
Java class
|
CreateTopic
|
|
SendAlert
|
Basic
|
Publication topic
|
Notification
|
|
SendAlert
|
Basic
|
Send to destination list in local environment
|
true
|
|
SendAlert
|
JMS Connection
|
Location JNDI bindings
|
file:///home
/wmbadmin |
|
SendAlert
|
JMS Connection
|
Connection factory name
|
ITSOConnect
Factory |
|
Message flow - part 3
|
|||
|
BroadcastAlerts
|
Basic
|
Queue name
|
ITSO.BROADCAST.IN
|
|
WebSphere MQ to JMS
|
N/A
|
N/A
|
N/A
|
|
setRetain
|
Basic
|
Java class
|
setRetainFlag
|
|
SendBroadcast
|
Basic
|
Publication topic
|
Broadcast
|
|
SendBroadcast
|
JMS Connection
|
Location JNDI bindings
|
file:///home
/wmbadmin |
|
SendBroadcast
|
JMS Connection
|
Connection factory name
|
ITSOConnect
Factory |
12. Create a .bindings file in the /home/wmbadmin directory on the iib2.itso.transport.com server for JMS Topic connection factories and topic details. Example 9-48 shows the contents of the .bindings file.
Example 9-48 The .bindings file for JMS nodes in the message flow
ITSOConnectFactory/ClassName=com.ibm.ima.jms.impl.ImaConnectionFactory
ITSOConnectFactory/FactoryName=com.ibm.ima.jms.impl.ImaConnectionFactory
ITSOConnectFactory/RefAddr/0/Encoding=String
ITSOConnectFactory/RefAddr/0/Type=Port
ITSOConnectFactory/RefAddr/0/Content=16105
ITSOConnectFactory/RefAddr/1/Encoding=String
ITSOConnectFactory/RefAddr/1/Type=Server
ITSOConnectFactory/RefAddr/1/Content=ima1.itso.transport.com
ITSOConnectFactory/RefAddr/2/Encoding=String
ITSOConnectFactory/RefAddr/2/Content=common
ITSOConnectFactory/RefAddr/2/Type=ObjectType
GeoTopic/ClassName=com.ibm.ima.jms.impl.ImaTopic
GeoTopic/FactoryName=com.ibm.ima.jms.impl.ImaTopic
GeoTopic/RefAddr/0/Encoding=String
GeoTopic/RefAddr/0/Type=Name
GeoTopic/RefAddr/0/Content=/itso/driver/geolocation/+
Notification/ClassName=com.ibm.ima.jms.impl.ImaTopic
Notification/FactoryName=com.ibm.ima.jms.impl.ImaTopic
Notification/RefAddr/0/Encoding=String
Notification/RefAddr/0/Type=Name
Notification/RefAddr/0/Content=/itso/driver/notification
Broadcast/ClassName=com.ibm.ima.jms.impl.ImaTopic
Broadcast/FactoryName=com.ibm.ima.jms.impl.ImaTopic
Broadcast/RefAddr/0/Encoding=String
Broadcast/RefAddr/0/Type=Name
Broadcast/RefAddr/0/Content=/itso/driver/notification/AllTrucks
13. Create a Java class for the GeoLocationToDatabase Java compute node. Double-click this Java compute node and create a Java class named GeoLocationPersistence. Also enter ITSOGeoNotificationandBroadcastJava as the source folder name. Example 9-49 shows the Java code for this class.
Example 9-49 Java code for the GeoLocationToDatabase Java compute node
import java.sql.Connection;
import java.sql.ResultSet;
import java.sql.Statement;
import java.util.StringTokenizer;
import com.ibm.broker.javacompute.MbJavaComputeNode;
import com.ibm.broker.plugin.MbElement;
import com.ibm.broker.plugin.MbException;
import com.ibm.broker.plugin.MbMessage;
import com.ibm.broker.plugin.MbMessageAssembly;
import com.ibm.broker.plugin.MbOutputTerminal;
import com.ibm.broker.plugin.MbUserException;
public class GeoLocationPersistence extends MbJavaComputeNode {
public void evaluate(MbMessageAssembly inAssembly) throws MbException {
MbOutputTerminal out = getOutputTerminal("out");
String geoMessageElement[] = new String[4];
MbMessage inMessage = inAssembly.getMessage();
MbMessageAssembly outAssembly = null;
try {
// create new message as a copy of the input
MbMessage outMessage = new MbMessage(inMessage);
outAssembly = new MbMessageAssembly(inAssembly, outMessage);
MbElement inputRoot = inMessage.getRootElement();
byte[] MessageBodyByteArray = (byte[]) (inputRoot.getFirstElementByPath("/BLOB/BLOB").getValue());
String MessageBodyString = new String(MessageBodyByteArray);
String JMSTopic = inputRoot.getFirstElementByPath("/JMSTransport/Transport_Folders/Header_Values/JMSDestination").getLastChild().getValueAsString();
String truckNumber[] = JMSTopic.split("/");
StringTokenizer st = new StringTokenizer(MessageBodyString,",");
int index=0;
while (st.hasMoreTokens()) {
geoMessageElement[index++]=st.nextToken();
}
Connection conn = getJDBCType4Connection("ITSODB",JDBC_TransactionType.MB_TRANSACTION_AUTO);
Statement stmt = conn.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_READ_ONLY);
stmt.execute("INSERT INTO DB2INST1.TRUCKGEOLOCATION (TIMSTAMP, DRIVER_NAME, TRUCK_NUMBER , LONGITUDE, LATITUDE) VALUES('"+
geoMessageElement[0]+"','"+
geoMessageElement[1]+"','"+
truckNumber[4] +"','"+
geoMessageElement[2]+"','"+
geoMessageElement[3]+"')");
} catch (MbException e) {
throw e;
} catch (RuntimeException e) {
throw e;
} catch (Exception e) {
throw new MbUserException(this, "evaluate()", "", "", e.toString(),null);
}
out.propagate(outAssembly);
}
}
14. Create a Java class for the BusinessRuleTruckSelection Java compute node. Double-click this Java compute node and create a Java class named BusinessRuleTruckSelection. Also enter ITSOGeoNotificationandBroadcastJava as the source folder name. Example 9-50 shows the Java code for this class.
Example 9-50 Java code for the BusinessRuleTruckSelection Java compute node
import java.sql.Connection;
import java.sql.ResultSet;
import java.sql.Statement;
import java.util.ResourceBundle;
import com.ibm.broker.javacompute.MbJavaComputeNode;
import com.ibm.broker.plugin.MbElement;
import com.ibm.broker.plugin.MbException;
import com.ibm.broker.plugin.MbMessage;
import com.ibm.broker.plugin.MbMessageAssembly;
import com.ibm.broker.plugin.MbOutputTerminal;
import com.ibm.broker.plugin.MbUserException;
public class BusinessRuleTruckSelection extends MbJavaComputeNode {
public void evaluate(MbMessageAssembly inAssembly) throws MbException {
MbOutputTerminal out = getOutputTerminal("out");
MbMessage inMessage = inAssembly.getMessage();
MbMessageAssembly outAssembly = null;
try {
// create new message as a copy of the input
MbMessage outMessage = new MbMessage(inMessage);
outAssembly = new MbMessageAssembly(inAssembly, outMessage);
String alertMessage = AlertSelection();
Connection conn = getJDBCType4Connection("ITSODB",JDBC_TransactionType.MB_TRANSACTION_AUTO);
Statement stmt = conn.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_READ_ONLY);
ResultSet rs = stmt.executeQuery("SELECT UNIQUE TRUCK_NUMBER FROM TRUCKGEOLOCATION");
while(rs.next())
{
MbElement localEnv = outAssembly.getLocalEnvironment().getRootElement();
MbElement TruckNumber = localEnv.getFirstElementByPath("TruckNumber");
MbElement AlertMessage = localEnv.getFirstElementByPath("AlertMessage");
if(TruckNumber!=null)
{
TruckNumber.detach();
}
if(AlertMessage!=null)
{
AlertMessage.detach();
}
localEnv.createElementAsLastChild(MbElement.TYPE_NAME_VALUE,"TruckNumber",rs.getString("TRUCK_NUMBER"));
localEnv.createElementAsLastChild(MbElement.TYPE_NAME_VALUE,"AlertMessage",alertMessage);
out.propagate(outAssembly,true);
}
} catch (MbException e) {
e.printStackTrace();
throw e;
} catch (RuntimeException e) {
e.printStackTrace();
throw e;
} catch (Exception e) {
e.printStackTrace();
throw new MbUserException(this, "evaluate()", "", "", e.toString(),null);
}
}
private String AlertSelection()
{
String message = new String();
int randomNumber = (int)(Math.random() * (10 - 1) + 1);
ResourceBundle rb = ResourceBundle.getBundle("Messages");
message = rb.getString(Integer.toString(randomNumber));
return message;
}
}
|
Note: For a Java compute node to build random messages, a Messages file is created and is referred to from the Java ResourceBundle API. The following list shows the contents of the Messages_en.properties file:
1 = Inclement weather in your area, drive safely and inform main office if you expect delivery to be delayed.
2 = Highway construction on I-75, use alternative route if possible.
3 = Tornado Warnings issued in your area, take cover immediately.
4 = Truck malfunction in your area, inform front office if you are available to pick up load for delivery.
5 = Traffic Jam reported on Highway 5, use alternative route.
6 = Accident on Interstate 10, take alternative route.
7 = Heavy snow - use precaution and engage inclement weather driving gear.
8 = Bay bridge is closed, plan alternative route.
9 = Highway 92 closed, take alternative route.
10 = Return to station, additional cargo is ready for delivery.
Random messages are returned from the AlertSelection() method.
|
15. Create a Java class for the CreateAlertTopic Java compute node. Double-click this Java compute node and create a Java class named CreateTopic. Also enter ITSOGeoNotificationandBroadcastJava as the source folder name. Example 9-51 shows the Java code for this class.
Example 9-51 Java code for Java compute node CreateAlertTopic
import com.ibm.broker.plugin.MbBLOB;
import com.ibm.broker.plugin.MbElement;
import com.ibm.broker.plugin.MbException;
import com.ibm.broker.plugin.MbMessage;
import com.ibm.broker.plugin.MbMessageAssembly;
import com.ibm.broker.plugin.MbOutputTerminal;
import com.ibm.broker.plugin.MbUserException;
public class CreateTopic extends MbJavaComputeNode {
public void evaluate(MbMessageAssembly inAssembly) throws MbException {
MbOutputTerminal out = getOutputTerminal("out");
MbMessage inMessage = inAssembly.getMessage();
MbMessageAssembly outAssembly = null;
try {
MbMessage outMessage = new MbMessage(inMessage);
outAssembly = new MbMessageAssembly(inAssembly, outMessage);
MbElement localEnv = outAssembly.getLocalEnvironment().getRootElement();
MbElement dest = localEnv.createElementAsFirstChild(MbElement.TYPE_NAME, "Destination", null);
MbElement jmsDestList = dest.createElementAsFirstChild(MbElement.TYPE_NAME, "JMSDestinationList", null);
MbElement destData = jmsDestList.createElementAsFirstChild(MbElement.TYPE_NAME, "DestinationData", null);
destData.createElementAsFirstChild(MbElement.TYPE_NAME_VALUE, "DestinationName",
"/itso/driver/notification/"+localEnv.getFirstElementByPath("TruckNumber").getValueAsString());
destData.createElementAsFirstChild(MbElement.TYPE_NAME_VALUE, "DestinationType", "Topic");
MbElement root = outMessage.getRootElement();
MbElement msgElement = root.getLastChild();
msgElement.detach();
MbElement BLOB = root.createElementAsLastChild(MbBLOB.PARSER_NAME);
BLOB.createElementAsLastChild(MbElement.TYPE_NAME_VALUE, "BLOB", localEnv.getFirstElementByPath("AlertMessage").
getValueAsString().getBytes());
outMessage.finalizeMessage(MbMessage.FINALIZE_VALIDATE);
} catch (MbException e) {
throw e;
} catch (RuntimeException e) {
throw e;
} catch (Exception e) {
throw new MbUserException(this, "evaluate()", "", "", e.toString(),null);
}
out.propagate(outAssembly);
}
}
16. Create a Java class for the setRetain Java compute node. Double-click this Java compute node and create a Java class named setRetainFlag. Also enter ITSOGeoNotificationandBroadcastJava as the source folder name.
|
Note: The purpose of this class is to set the JMS Retain flag on JMS publications sent through the JMS output node on the Broadcast topic. IBM MessageSight considers the JMS Retain flag while distributing messages using the MQTT protocol.
|
Example 9-52 shows the Java code for the setRetainFlag class.
Example 9-52 Java code for Java compute node setRetain
import com.ibm.broker.javacompute.MbJavaComputeNode;
import com.ibm.broker.javacompute.MbJavaComputeNode;
import com.ibm.broker.plugin.MbElement;
import com.ibm.broker.plugin.MbException;
import com.ibm.broker.plugin.MbMessage;
import com.ibm.broker.plugin.MbMessageAssembly;
import com.ibm.broker.plugin.MbOutputTerminal;
import com.ibm.broker.plugin.MbUserException;
import com.ibm.broker.plugin.MbXML;
public class setRetainFlag extends MbJavaComputeNode {
public void evaluate(MbMessageAssembly inAssembly) throws MbException {
MbOutputTerminal out = getOutputTerminal("out");
MbMessage inMessage = inAssembly.getMessage();
MbMessageAssembly outAssembly = null;
try {
MbMessage outMessage = new MbMessage(inMessage);
outAssembly = new MbMessageAssembly(inAssembly, outMessage);
MbElement outputRoot = outMessage.getRootElement();
MbElement applicationFolder = outputRoot.getFirstElementByPath("/JMSTransport/Transport_Folders/Application_Properties");
MbElement JMS_IBM_Retain = applicationFolder.createElementAsLastChild(MbXML.ELEMENT,"JMS_IBM_Retain",1);
JMS_IBM_Retain.createElementAsFirstChild(MbXML.ATTRIBUTE, "dt", "i4");
} catch (MbException e) {
throw e;
} catch (RuntimeException e) {
throw e;
} catch (Exception e) {
throw new MbUserException(this, "evaluate()", "", "", e.toString(),null);
}
out.propagate(outAssembly);
}
}
Deploying an IBM Integration Bus application
Before deployment, a broker archive (BAR) file must be created to compile the message flow. Use the following procedure:
1. Create a new BAR file, as shown in Figure 9-11.
Figure 9-11 Creating a new BAR file
2. The New BAR file wizard opens. Enter GeoNotificationandBroadcast as the BAR file name and click Finish. Figure 9-12 shows the New BAR file wizard.
Figure 9-12 The New BAR file wizard
3. After the BAR file is created, the wizard opens in the BAR file editor, as shown in Figure 9-13. Click the Prepare tab in this editor and select the ITSOGeoNotificationBroadcast application to be compiled in this BAR file.
Figure 9-13 Select an application in the BAR file editor
4. Click the Manage tab and then click Rebuild, as shown in Figure 9-14. If there are no compilation errors, the BAR file is built. Save the BAR file before deployment.
Figure 9-14 Building the BAR file
5. After the BAR file is created, deploy it on the ITSOEG integration server on the ITSOBK2 integration node. To deploy it from the Integration toolkit, drag the BAR file on ITSOEG. Figure 9-15 shows the ITSOGeoNotificationBroadcast application deployed on ITSOEG.
Figure 9-15 An application deployed on the ITSOEG integration server
9.5 Testing the scenarios
To test this scenario, you take three trucks and three truck drivers. Table 9-13 shows the current status of their assignments.
Table 9-13 Current delivery assignments for different trucks
|
Truck number
|
Driver user name
|
Current assignment
|
|
CASJC01
|
driver01
|
Delivering groceries from San Jose, California (CA) to Santa Cruz, CA. The geographic location of this truck is always changing.
|
|
CASJC02
|
driver02
|
This truck has not yet started for the assignment, but the driver has logged in to the application and will start for delivery soon. The geographic location for this truck is not changing for now.
|
|
CASJC03
|
driver03
|
This truck is scheduled for delivery in the next few hours, and the driver has yet to check in.
|
Use the MQTT hybrid Android application developed using IBM Worklight to test this scenario.
|
Important: This scenario uses the following assumptions:
•All of the trucks are fitted with an Android mobile device.
•The mobile application is installed on all of the trucks in the fleet.
|
Figure 9-16 illustrates that driver01 is logged in to the mobile application on the CASJC01 truck. This Truck is currently on its way to delivery from San Jose, CA to Santa Cruz, CA.
Figure 9-16 Driver01 logged in to the mobile application on CASJC01
Figure 9-17 illustrates that driver02 is logged in to the mobile application on the CASJC02 truck. This truck has still not left the ITSO Transport facility, and no geographic location changes are emitted from the mobile application.
Figure 9-17 Driver02 logged in to the mobile application on CASJC02
9.5.1 Capturing and publishing geographic location changes
Detailed explanations about the MQTT hybrid mobile application are provided in Chapter 5, “MQTT with mobile platforms” on page 99. What we demonstrate here is that constant geographic location changes for the trucks are published by mobile application on a topic to IBM MessageSight.
IBM Integration Bus message flow has already subscribed to receive these publications. After a new publication is received, IBM Integration Bus submits the longitude and latitude location of the truck, along with the truck number and a time stamp into the TRUCKGEOLOCATION table in the ITSODB database.
Figure 9-18 on page 273 shows the part of the message flow on the IBM Integration Bus application that captures the geographic location change publications and insert details into the database.
More details about this scenario are included in section 9.3.1, “Push notification to selected mobile applications” on page 229.
Figure 9-18 Geographic location changes captured in IBM Integration Bus
Because the application is running on an Android emulator for testing purposes, you use Android commands to simulate geographic location changes. The current emulator from where the CASJC01 truck is simulated has opened telnet port 5554. Figure 9-19 illustrates the telnet session for the Android emulator on localhost port 5554.
Figure 9-19 Android emulator telnet session
Example 9-53 shows the geographic location changes simulated on the Android emulator, where the driver has logged in with the user name driver01 and the truck number CASJC01.
Example 9-53 Geographic location changes for the CASJC01 truck
geo fix 123.34 -34.23
OK
geo fix 123.34 -34.53
OK
geo fix 123.34 -34.75
OK
Example 9-54 shows that the location changes simulated in Example 9-53 are now inserted into the TRUCKGEOLOCATION table on ITSODB.
Example 9-54 Geographic location changes inserted into database
db2 => select * from TRUCKGEOLOCATION
TIMSTAMP DRIVER_NAME TRUCK_NUMBER LONGITUDE LATITUDE
-------------------------- ----------- ------------ ---------------------------
2013-09-17-09.29.21.912000 driver01 CASJC01 123.33999999999999 -34.22
2013-09-17-09.29.53.892000 driver01 CASJC01 123.33999999999999 -34.53
2013-09-17-09.30.00.389000 driver01 CASJC01 123.33999999999999 -34.75
This shows that any geographic location changes for a truck are captured by the mobile application and recorded in the back-end database.
9.5.2 Push notification for selected trucks
As seen in 9.5.1, “Capturing and publishing geographic location changes” on page 272, only the CASJC01 truck is sending geographic location changes. Figure 9-20 shows the part of the message flow in the IBM Integration Bus application that runs every 600 seconds. It scans for unique truck numbers in the TRUCKGEOLOCATION table, and then sends random alert messages to the mobile application in the trucks.
|
Note: The business logic to select trucks for alert notification is simple, and for illustration purpose only. Currently, all trucks that have recorded their geographic location will be sent a notification.
|
The mobile applications in the trucks have subscribed to receive this notification with quality of service QoS2. More details about this scenario are included in 9.3.1, “Push notification to selected mobile applications” on page 229.
Figure 9-20 A push notification created and published to selected trucks
Figure 9-21 shows the mobile application on the CASJC01 truck, and the notifications that it received from the back-end system with QoS2.
Figure 9-21 Push notification messages for the CASJC01 truck with QoS2
9.5.3 Push notification broadcast to all trucks
ITSO Transport Corporation has a requirement that their back-end office team must be able to send important notifications to truck staff who are currently connected through the mobile application, or the staff who get connected when their delivery is scheduled. More details about this scenario are included in 9.3.2, “Push notification broadcast to all mobile applications” on page 232.
If the back-end office team sends a message to be broadcast now, because
the CASJC01 and CASJC02 trucks are connected through the mobile application, they will receive these notifications. When driver03 connects the mobile application on the CASJC03 truck to IBM MessageSight, the mobile application will receive the previously broadcast notification, because the original messages were published with a retained property from the IBM Integration Bus message flow.
the CASJC01 and CASJC02 trucks are connected through the mobile application, they will receive these notifications. When driver03 connects the mobile application on the CASJC03 truck to IBM MessageSight, the mobile application will receive the previously broadcast notification, because the original messages were published with a retained property from the IBM Integration Bus message flow.
Figure 9-22 shows the part of the message flow in the IBM Integration Bus application that accepts important messages to be broadcast to all of the trucks in the ITSO Transport Corporation fleet.
Figure 9-22 Push notification accepted from the back-end office team and sent to all of the trucks
To run this scenario, simulate the back-end office team by directly putting the message in the ITSO.BROADCAST.IN queue on the ITSOQM2 queue manager. Example 9-55 shows a message to be broadcast from the ITSO Transport back-end team to all of the trucks. The message is for illustration purposes, and is put in the queue using the amqsput sample WebSphere MQ utility.
Example 9-55 Push notification to be broadcast to all trucks
$ ./amqsput ITSO.BROADCAST.IN ITSOQM2
Sample AMQSPUT0 start
target queue is ITSO.BROADCAST.IN
Please drive safely and abide state laws
Sample AMQSPUT0 end
|
Note: This message is picked up from the queue by the message flow, and a JMS retain flag is set to make this notification a retained publication.
|
After the notification is sent, the CASJC01 and CASJC02 trucks receive this broadcast message. Figure 9-23 shows the notification received on the CASJC01 truck.
Figure 9-23 Broadcast notification received on the CASJC01 truck with QoS1
Figure 9-24 shows the notification received on the CASJC02 truck.
Figure 9-24 Broadcast notification received on the CASJC02 truck with QoS2
Figure 9-24 and Figure 9-23 on page 277 show that the broadcast notification with QoS1 was received at the same time, because the truck drivers on the CASJC01 and CASJC02 trucks were connected at that time.
After some time, the driver03 truck driver connects the mobile application on the CASJC03 truck to IBM MessageSight by logging in to the application. CASJC03 received this broadcast because this message was published with a retain flag. As soon as the mobile application from CASJC03 got connected, it received the broadcast message that was published earlier. Figure 9-25 shows the notification received on CASJC03, but the receive time stamp is different from the receive time stamp of CASJC01 and CASJC02.
Figure 9-25 Broadcast notification received on CASJC03 with QoS1
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.