You can implement this property to programmatically handle delivery confirmation information uploaded by remote listeners. If the status parameter is 0, the push request identified by request_id was successfully received by the Listener identified by the remote_device parameters.
You can use the request_option out parameter to take an appropriate action in response to the delivery confirmation. If request_option is 0, the confirmation_handler takes the default Notifier action: the request_delete event is executed to delete the original push request. However, if the Listener device sending the delivery confirmation does not match the Listener device identified by the request_id, the default action is to send the original push request on a secondary gateway.
Note: to enable remote Listeners to upload delivery confirmation information use the dblsn -x option. If you want delivery confirmation but do not want IP tracking, use the dblsn -ni option.
See -x and -ni in Listener syntax.
Following are the confirmation_handler parameters. You can use all of the parameters or a subset. This property requires the use of a stored procedure.
Script parameter | Description |
---|---|
request_option (out) |
Integer. Controls what the Notifier does to the request after the handler returns. Can be one of:
|
status (in) |
Integer. Summary of the situation. The status can be used during development to catch problems such as incorrect filters and handler attributes. The status can be one of:
|
request_id (in) | Integer. Identifies the request. |
remote_code (in) |
Integer. Summary reported by the remote Listener. Can be one of:
|
remote_device (in) | Varchar. Device name of the responding Listener. |
remote_mluser (in) | Varchar. MobiLink user name of the responding Listener. |
remote_action_return (in) | Varchar. Return code of the remote action. |
remote_action (in) | Varchar. Reserved for the action command. |
gateway (in) | Varchar. Gateway associated with the request. |
address (in) | Varchar. Address associated with the request. |
subject (in) | Varchar. Subject associated with the request. |
content (in) | Varchar. Content associated with the request. |
In the following example, you create a table called CustomConfirmation and then you log confirmations to it using a stored procedure called CustomConfirmationHandler. In this example, the output parameter request_option is always set to 0, which means that default Notifier handling is used.
CREATE TABLE CustomConfirmation( error_code integer, request_id integer, remote_code integer, remote_device varchar(128), remote_mluser varchar(128), remote_action_return varchar(128), remote_action varchar(128), gateway varchar(255), address varchar(255), subject varchar(255), content varchar(255), occurAt timestamp not null default timestamp ) CREATE PROCEDURE CustomConfirmationHandler( out @request_option integer, in @error_code integer, in @request_id integer, in @remote_code integer, in @remote_device varchar(128), in @remote_mluser varchar(128), in @remote_action_return varchar(128), in @remote_action varchar(128), in @gateway varchar(255), in @address varchar(255), in @subject varchar(255), in @content varchar(255) ) begin INSERT INTO CustomConfirmation( error_code, request_id, remote_code, remote_device, remote_mluser, remote_action_return, remote_action, gateway, address, subject, content ) VALUES ( @error_code, @request_id, @remote_code, @remote_device, @remote_mluser, @remote_action_return, @remote_action, @gateway, @address, @subject, @content ); SET @request_option = 0; end |
Send feedback about this page via email or DocCommentXchange | Copyright © 2008, iAnywhere Solutions, Inc. - SQL Anywhere 11.0.0 |