confirmation_handler event

Configure this event to handle delivery confirmation information uploaded by Listeners. If the status parameter returns 0, then 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 parameter to initiate an action in response to the delivery confirmation. If request_option is 0, the confirmation_handler event initiates the default action, where the request_delete event is executed to delete the original push request. If the device sending the delivery confirmation does not match the device identified by the request_id, the default action is to send the original push request through a secondary gateway.

Note

Use the dblsn -x option to allow Listeners to upload delivery confirmation information. Use the dblsn -ni option if you want delivery confirmation but do not want IP tracking. See Listener options for Windows.

Note

This event requires the use of a system procedure. You can not configure this event directly using the Sybase Central method. See MobiLink server settings for server-initiated synchronization.

The following parameters can be captured using the confirmation_handler event:

Script parameter Type Description
request_option (out) Integer

Controls what the Notifier does to the request after the handler returns. The following values can be returned:

  • 0: Perform default Notifier action based on the value of the status parameter. If status indicates that the responding device is the target one, then the Notifier deletes the request; otherwise the Notifier attempts to deliver on a secondary gateway.
  • 1: Do nothing.
  • 2: Execute Notifier.request_delete.
  • 3: Attempt to deliver to a secondary gateway.
status (in) Integer

The situation summary. The status can be used during development to identify problems such as incorrect filters and handler attributes. The following values can be returned:

  • 0: Received and confirmed.
  • -2: Right respondent but the message was rejected.
  • -3: Right respondent and the message was accepted but the action failed.
  • -4: Wrong respondent and the message was accepted.
  • -5: Wrong respondent and the message was rejected.
  • -6: Wrong respondent. The message was accepted and the action succeeded.
  • -7: Wrong respondent. The message was accepted but the action failed.
request_id (in) Integer The request ID. Your request_cursor event must contain a request ID column to use the confirmation_handler event.
remote_code (in) Integer

The summary reported by the remote Listener. The following values can be returned:

  • 1: Message accepted.
  • 2: Message rejected.
  • 3: Message accepted and action succeeded.
  • 4: Message accepted and action failed.
remote_device (in) Varchar The device name of the responding Listener.
remote_mluser (in) Varchar The MobiLink user name of the responding Listener.
remote_action_return (in) Varchar The return code of the remote action.
remote_action (in) Varchar Reserved for the action command.
gateway (in) Varchar The gateway associated with the request.
address (in) Varchar The address associated with the request.
subject (in) Varchar The subject associated with the request.
content (in) Varchar The content associated with the request.
See also
Example

In the following example, you create a table called CustomConfirmation and then log confirmations to it using a stored procedure named CustomConfirmationHandler. 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

To use the ml_add_property system procedure with a SQL Anywhere consolidated database, run the following command:

call ml_add_property( 
    'SIS',
    'Notifier(myNotifier)',
    'confirmation_handler',
    'call CustomConfirmation(?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)');

Alternatively, you can call this event by adding the following line to a Notifier configuration file:

Notifier(myNotifier).confirmation_handler = call CustomConfirmation(?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)

Run the file using the mlsrv11 -notifier option. For more information on how to configure a Notifier configuration file, see Configuring server-side settings using the Notifier configuration file.

Copyright © 2009, iAnywhere Solutions, Inc. - SQL Anywhere 11.0.1