Click here to view and discuss this page in DocCommentXchange. In the future, you will be sent there automatically.

SQL Anywhere 10.0.1 » MobiLink - Server-Initiated Synchronization » MobiLink Notification Properties » Notifier properties » Notifier events

begin_connection property Next Page

confirmation_handler property

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 parameterDescription
request_option (out)

Integer. Controls what the Notifier does to the request after the handler returns. Can be one of:

  • 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 will delete the request; otherwise the Notifier will attempt 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. 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:

  • 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. Identifies the request.
remote_code (in)

Integer. Summary reported by the remote Listener. Can be one of:

  • 1: Message accepted.
  • 2: Message rejected.
  • 3: Message accepted and action succeeded.
  • 4: Message accepted and action failed.
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.
See also

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) )
     INSERT INTO CustomConfirmation( 
  content )

     VALUES (
  @content );
     SET @request_option = 0;