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 |