When planning an application for an AWP (Axeda Wireless Protocol) agent, you need to know how often you need to contact the asset. You also need to know if you need to know when an asset that polls the Axeda Platform has missed a specified number of polls and is "missing". In the Axeda Platform, "missing" simply means that the asset cannot be contacted. For wireless assets you can choose whether to have the asset poll the Platform on a regular basis, or, to minimize costs, you can set up the asset so that it does not poll (or polls very infrequently), but responds to Shoulder Tap messages from the Platform.
To take advantage of shoulder tap messaging for AWP assets, the following tasks must be completed:
o A developer needs to create the AWP application. For the Java-based AWP Toolkit, no special programming tasks are required. For the C-based AWP Toolkit, to important steps are required:
§ When configuring the device using M2M_Context_setDevice, the developer needs to set the poll rate for the device to NULL.
§ The developer needs to use the M2M_Context_setPollMode method to set the alwaysPoll flag to 0 (do NOT poll). Use the M2M_Context_forcePoll method to force a polling message from the asset to the Axeda Platform as appropriate.
o Using
the Axeda Web Services and API, a developer needs to create the model
profile for the assets and in the profile, configure the model to use
the “shoulder tap” delivery method. The developer needs to make sure that
the model profile is associated with the appropriate model. For information
on creating model profiles and associating them with models using the
Axeda API classes (ModelProfile, ModelProfileSearchCriteria, and DeliveryMethodDescriptor)
and the Axeda Web Services (ModelProfileService), refer to the
Axeda® Platform API Developer’s Reference and the
Axeda® Platform Web Services Developer’s Reference. Appendix A
of the Web Services reference provides instructions for configuring model
profiles.
If your assets cannot handle the Email Transport for Shoulder Tap messaging,
you can write a Groovy script that functions as the Transport for the
Shoulder Tap delivery method. You must configure the Groovy script as
a custom object of Type "Shoulder Tap" using the Axeda Configuration
application. Appendix A of the Axeda®
Platform Web Services Developer’s Reference explains how to set
up this CustomObjectTransport in the Model Profile. For an example of
this type of custom object, refer to Custom
Object Example: A Transport for the Shoulder Tap Delivery Method.
o A new property needs to be created for the model, either programmatically by a developer using the Axeda Platform SDK or manually by a Platform administrator (or a nonadministrative user who is authorized to view and update models) in the Axeda Configuration application. The property must be called “Email” and the value must be set for each asset of the model to the be the Email id of the asset. See also Model Wizard - Model Properties step.
o An Axeda Platform administrator needs to set the maximum number of rows in the Shoulder Tap messaging table that the ShoulderTapRetry task should retrieve at a time when retrying shoulder tap messages. The Shoulder Tap table contains one row per shoulder-tap-able asset and keeps track of the number of outgoing messages (for example, setDataItem) waiting for each asset as well as the number of times the Platform has attempted to deliver a shoulder tap message to the asset. The ShoulderTapRetry task retries a shoulder tap message if the retry count is less than the maximum retry count configured in the Model Profile.
o The Axeda Platform administrator also needs to set the interval for the ShoulderTapRetry scheduled task.
Notes: If an AWP asset is
enabled for Shoulder Tap messaging and is also configured NOT to poll
the Axeda Platform (poll rate set to NULL), then the Ping Rate for the
asset is shown as "0" in the Asset dashboard.
A ping rate of 0 typically means that the asset can never be "Missing."
However, for shoulder-tap assets, the task that checks for missing assets
checks the table of shoulder tap messages to determine if an asset is
Missing. If the number of retries for a shoulder tap message for an asset
has been exhausted and the asset has not responded to the shoulder tap,
the task sets the status of the asset to Missing. If you never want
these assets to show a status of Missing, go to the Missing
Assets page of the Model wizard and select the option, "Don't
consider assets of this model as missing." See also Missing
Assets.