confirmation_handler event

Configure this event to handle delivery confirmation information uploaded by MobiLink Listeners. If the status parameter returns 0, then the push request identified by request_id was successfully received by the MobiLink 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 MobiLink Listeners to upload delivery confirmation information. Use the dblsn -ni option if you want delivery confirmation but do not want IP tracking. See MobiLink Listener options for Windows devices.

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 MobiLink 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 MobiLink Listener.
remote_mluser (in)	Varchar	The MobiLink user name of the responding MobiLink 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.

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 mlsrv12 -notifier option. For more information about how to configure a Notifier configuration file, see Server-side settings configured using the Notifier configuration file.

Discuss this page in DocCommentXchange.

confirmation_handler event

Note

Note

See also

Example