Documento de conexión con la plataforma. nvía

Transcripción

1 Documento de conexión con la plataforma nvía V4.4

2 Índice 1.- INTRODUCCIÓN PREMIUM Conexiones a la Plataforma i.- Sonic MQ ii.- HTTP (2 peticiones) iii.- HTTP con Content-Reply MMS PREMIUM HTTPMMS (2 peticiones) HTTPMMS con Content-Reply PUSH SMS ENVIO POR URL i.- Introducción ii iii iv v.- Consulta de créditos disponibles...15 Envío de un mismo texto a varios móviles...15 A varios móviles, con textos diferentes...17 Consulta del estado de los envíos ENVIO POR SONICMQ Envío de WapPush ENVIO POR URL ENVIO POR SONICMQ Wap-Billing Introducción

3 6.2.- Modelo de interactuación Suscripciones ALERTAS Introducción Notificación de altas y bajas Envío de alertas por http Envío de alertas por Sonic

4 DOCUMENTO DE CONEXIÓN CON LA PLATAFORMA nvia 1.- INTRODUCCIÓN Este documento proporciona una guía para manejar mensajes sms de cualquier tipo con la plataforma de comunicaciones de Nvia Gestión de Datos (a partir de ahora, Nvia). Los mensajes de tipo Premium son aquellos sms generados por un usuario de móvil a una numeración especial número corto o host-, que empiezan con una o varias palabras identificativas del servicio que se solicita edición-, y que tienen un coste superior al envío normal de sms entre móviles, actualmente entre 0.3 y 1.2 euros. La operadora se los hace llegar a Nvia, quien da la posibilidad a sus clientes de responderlos ellos mismos. En este documento se explicará cómo hacerlo. También se explica aquí como hacer envíos de tipo Push mensajes originados en la plataforma de Nvia que no son respuesta a un sms de un usuario de móvil, como tampoco se habla de ningún otro tipo de mensajes (alertas, mms, etc.). Existen dos vías para enviar sms a través de la plataforma de Nvia. La primera es una petición HTTP a una URL y la segunda es utilizando el gestor de colas SonicMQ, con lo que se puede hacer una conexión directa a un broker a través de una serie de Apis dependiendo de las necesidades del cliente, DLL, ActiveX, C, C++, Java. Ya que lo más utilizado en estos momentos son Java y DLLs para interfaces Visual se han creado unos ejemplos para demostrar el envío de sms a través de estas APIs. Por último, se explicará el envío de alertas a través de la plataforma, siendo las alertas un servicio de suscripción, por el cual se pueden enviar mensajes a los usuarios que hayan solicitado un alta, teniendo cada mensaje un coste para el usuario que lo recibe. Existe una limitación en el número de mensajes enviados a un mismo usuario, tanto por día, como por semana y mes. En este manual se darán las indicaciones para - 4 -

5 el manejo de alertas a través de la plataforma, tanto recibir notificaciones en las altas y bajas, como hacer envíos. No se hará mención a ningún lenguaje de programación, salvo lo estrictamente necesario para la explicación del funcionamiento, y los ejemplos que la acompañen. A quién va dirigido este manual Dado el contenido técnico de este documento, va dirigido a cualquier persona con alguna experiencia en programación. Asimismo, debería tener ciertos conocimientos del funcionamiento básico de la tecnología sms

6 2.- PREMIUM Conexiones a la Plataforma Cuando un cliente decide responder a los mensajes Premium en los que él es el destinatario, Nvia sólo hace de pasarela entre las operadoras y el propio cliente. Existen dos grandes maneras de manejar dichos mensajes Premium. 2.1.i.- Sonic MQ Para garantizar la privacidad de los mensajes de los diferentes clientes, cada uno tendrá una cola en exclusiva para la recepción de sus mensajes cola_recepción_cliente-, y la cola de envío será común para todos: NviaQ. El sms llega a nuestra plataforma, y una vez se detecta que es un mensaje que va a ser tratado por un cliente a través del gestor de colas SonicMQ-, se manda a la cola correspondiente al cliente cola_recepción_cliente- con un identificador único, además del texto completo del sms y otros parámetros. El cliente que quiera manejar el Premium deberá estar conectado al gestor SonicMQ, y una vez procesado el mensaje, enviara la respuesta por la cola NviaQ a nuestra plataforma. Actualmente existen varias soluciones para la conexión a SonicMQ, como un clase Java, cliente C, o una DLL para soluciones basadas en Visual Basic. Nvia facilita el módulo necesario para trabajar al cliente, que lo deberá instalar en su equipo para el desarrollo de la aplicación que desee para la contestación de los mensajes. Para ello existe una API. En cualquier caso el modo de funcionamiento es muy similar: se deben configurar una serie de parámetros que provee Nvia para el correcto funcionamiento del sistema: - Dirección IP del Broker - Nombre de las colas (envío y recepción) - Usuario y contraseña - 6 -

7 Funcionamiento Cuando un mensaje para un cliente llega a Nvia, se envía a la cola del cliente una cadena de texto con una serie de parámetros. El separador entre dichos parámetros es el carácter. Dichos parámetros (en orden) son: - IdMensaje: Identificador único del mensaje - pais: Código numérico del país (Ver tabla 2.1) - operadora: Código alfanumérico de la operadora (Ver tabla 2.1) - host: número corto donde se ha recibido el mensaje - movil: número originario del sms - texto: texto del mensaje Tabla 2.1. Códigos de Operadoras de los diferentes países (y código numérico del país) España (34) Movistar Vodafone Amena Euskaltel Yoigo Código MO VO AM EK YO Portugal (351) TMN Vodafone Optimus Código TM VO OP Venezuela (58) Movistar Movilnet Digitel Código BS MN DG Colombia (57) Movistar Comcel OLA Código MO CM OL Ecuador (593) Movistar Porta Allegro Código MO PO AL Perú (51) Movistar TIM Código MO TI - 7 -

8 México (52) Telcel Movistar Iusacel Unefone Código TC MO IU UN Brasil (55) Claro Tim Vivo Brasil Telcom Telemig Oi Código Alemania (49) Código Austria (43) Código Suiza (42) Código Rusia (7) Código En ese momento, en el cliente se lanzará el evento correspondiente a la llegada del mensaje OnMessage. Una vez procesado el contenido, deberá responder al sms mediante su cola de envío, con el método correspondiente (SendMessage) La manera de responder es mediante un texto separado por delimitadores, como se ha visto hasta ahora. Los parámetros (en orden) son: - IdMensaje: identificador único del mensaje - Datos: generalmente, texto del mensaje, - Udh: User Data Header, campo hexadecimal - Dcs: Data Coding Scheme, campo entero En caso de tratarse de un WapPush (en el campo datos pondrá WapPush ), se - 8 -

9 aceptarán los siguientes parámetros: - IdMensaje: identificador único del mensaje - Datos: WAPPUSH - URL: sin - TextoWap: texto que aparecerá antes de la descarga 2.1.ii.- HTTP (2 peticiones) Si el cliente opta por no conectarse al gestor de colas, la pasarela se hace por medio de peticiones http. En este caso el cliente debe habilitar un servidor web, y facilitar a Nvia la URL donde escuchará las peticiones. El cliente decide el nombre de los parámetros (y cuales necesita) salvo el primero -cuyo nombre es fijo obligatoriamente-, y podrán ser los siguientes: - idrespuesta: Identifica unívocamente al mensaje. Debe ser utilizado en la respuesta. Obligatorio; debe recogerse este parámetro (con este nombre) - Movil (opcional) - Host (opcional): número corto por donde se recibe el sms - Operadora (opcional) - texto (opcional) La respuesta a cada petición debe ser OK en texto plano. Para contestar a cada sms, el cliente deberá hacer una petición a nuestro script, accesible en nuestro servidor primario: Y si este falla, en nuestro servidor de backup, en

10 Los parámetros que admite el script para respuestas de texto, son: - idrespuesta: el mismo que se recibió originalmente. - texto: texto a responder Los parámetros para envío de datos binarios son: - idrespuesta: el mismo que se recibió originalmente. - texto: datos en hexadecimal - udh: User Data Header, campo hexadecimal - dcs: Data Coding Scheme, campo entero. Para hacer respuestas de tipo WapPush, se usan los parámetros: - idrespuesta: el mismo que se recibió originalmente - texto: wappush (tal cual: &texto=wappush& ) - url. se enviará sin al principio de la dirección - textowap: texto que aparecerá antes de la descarga del contenido. El cliente deberá indicar a Nvia la o las direcciones IP desde las que realizará las peticiones para asegurar su autenticidad. Nvia a su vez hará sus peticiones desde las siguientes direcciones IP: iii.- HTTP con Content-Reply En este caso la respuesta al sms será la respuesta a la propia petición http, por lo que el cliente también debe habilitar un servidor web, y facilitar a Nvia la URL donde escuchará las peticiones. Nvia, a su vez, indicará al cliente los parámetros que

11 debe admitir obligatoriamente el script que escuhe las peticiones. Los parámetros, todos opcionales, son los siguientes: - Movil (opcional) - Host (opcional): número corto por donde se recibe el sms - Operadora (opcional) - texto (opcional) Asimismo, se manda un parámetro id_mensaje, que identifica unívocamente a cada mensaje, por si se quisiera llevar el control de que no se reciben duplicados. Id_mensaje es alfanumerico, y contiene las iniciales de la operadora seguido de un número. La respuesta deberá tener el siguiente formato: - OK (espacio) texto del mensaje - OKWAP (espacio) URL sin (espacio) texto wap - OKBIN (espacio) Datos (espacio) Udh (espacio) Dcs Las direcciones IP desde las que se realizarán las peticiones son las mismas que en el caso anterior. En caso de no responder correctamente, Nvia reintetará la petición pasado un minuto, luego 2, 4, 8 y 16, almacenando la petición en un log de errores si en este último intento no se obtuvo respuesta. En este caso se enviará un mail a la persona que aparezca como contacto técnico en nuestra plataforma, indicando que no se ha podido realizar la petición

12 3.- MMS PREMIUM HTTPMMS (2 peticiones) En el caso de que el mensaje recibido por Nvia sea un MMS, el envío de dichp MMS hacia el cliente se hará mediante una petición HTTP, con un método post que incluirá el contenido, según se explica posteriormente. En este caso, por tanto, el cliente debe habilitar un servidor web, y facilitar a Nvia la URL donde escuchará los envíos. Los datos enviados por Nvia al cliente estarán formados por un mensaje multipart, en el que el primer fichero será un xml con los datos de identificación del mensaje y el segundo fichero serán los datos enviados por el usuario desde el móvil. Las principales etiquetas del xml serán: - IDRespuesta: Identifica unívocamente al mensaje. Debe ser utilizado en la respuesta. Obligatorio; debe recogerse este parámetro para responder - Movil: número de teléfono del móvil que ha enviado el MMS. - Host: número corto al que se ha enviado el MMS - Operadora Operadora del móvil que ha enviado el MMS (según tabla 2.2) - Asunto indica el parámetro asunto incluido en el MMS. Si no existe este campo se incluirá en el asunto la primera palabra del primer fichero de texto incluido en los datos del MMS. Los datos enviados como segundo parámetro del multipart podrán estar formados por un solo fichero (jpg, mid, txt ) o por otro multipart formado por varios ficheros, entre los que puede estar incluido un fichero SMIL (fichero utilizado para dar formato a un MMS). La respuesta a cada petición debe ser OK en texto plano. La contestación al MMS deber ser un SMS. La respuesta se realiza de la misma

13 manera que los SMS (punto 2.1.ii); es decir, haciendo una petición http a nuestro servidor principal: Y si este falla, en nuestro servidor de backup, en Los parámetros que admite el script para respuestas de texto, son: - idrespuesta: el mismo que se recibió originalmente. - texto: texto a responder Los parámetros para envío de datos binarios son: - idrespuesta: el mismo que se recibió originalmente. - texto: datos en hexadecimal - udh: User Data Header, campo hexadecimal - dcs: Data Coding Scheme, campo entero. Para hacer respuestas de tipo WapPush, se usan los parámetros: - idrespuesta: el mismo que se recibió originalmente - texto: wapppush - url. se enviará sin al principio de la dirección - textowap: texto que aparecerá antes de la descarga del contenido. El cliente deberá indicar a Nvia la o las direcciones IP desde las que realizará las peticiones para asegurar su autenticidad. Nvia a su vez hará sus peticiones desde las siguientes direcciones IP:

14 3.2.- HTTPMMS con Content-Reply En este caso la respuesta al MMS será la respuesta al propio POST, por lo que el cliente también debe habilitar un servidor web, y facilitar a Nvia la URL donde escuchará los envíos. Los datos se enviarán utilizando el mismo procedimiento que en el HTTPMMS (2 peticiones) explicado en el apartado anterior. La respuesta deberá tener el siguiente formato: - OK (espacio) texto del mensaje - OKWAP (espacio) URL sin (espacio) texto wap - OKBIN (espacio) Datos (espacio) Udh (espacio) Dcs Las direcciones IP desde las que se realizarán las peticiones son las mismas que en el caso anterior. En caso de no responder correctamente, Nvia reintetará la petición pasado un minuto, luego 2, 4, 8 y 16, almacenando la petición en un log de errores si en este último intento no se obtuvo respuesta. En este caso se enviará un mail a la persona que aparezca como contacto técnico en nuestra plataforma, indicando que no se ha podido realizar la petición. 4.- PUSH SMS ENVIO POR URL 4.1.i.- Introducción El envío de los mensajes se hace mediante peticiones http a un script php- en los servidores de Nvia. Todos los parámetros se admiten por POST y por GET. El php únicamente reenvía la petición al servidor de envíos, donde posteriormente se valida usuario, contraseña y si hay créditos, por lo que el php siempre devuelve OK (texto plano, aunque puede llevar saltos de línea, por lo que se recomienda hacer uso de

15 alguna función que compruebe si la respuesta contiene el texto OK, o que quite saltos de línea y espacios). Únicamente si hay un fallo de conexión con el servidor de envíos el resultado del php será ERROR; en este caso, el envío no se habrá realizado y hay que reintentarlo (recomendable hacerlo a través del servidor de backup). Previo al envío de mensajes es necesario tener créditos -1 crédito=1 push-, que el cliente debe solicitar a Nvia. 4.1.ii.- Consulta de créditos disponibles Para conocer el estado de la cuenta, un cliente puede conocer en cada momento el número de créditos disponibles para envíos, mediante una petición http al siguiente script: La respuesta a esta llamada es únicamente el número de créditos, en texto plano, para poder procesarlo si se desea desde procesos automatizados. 4.1.iii.- Envío de un mismo texto a varios móviles Hay dos scripts preparados para el envío de pushes. En primer lugar Para realizar el envío de un único texto, a diferentes móviles, se usará la siguiente URL con los parámetros que se describen posteriormente -los marcados con (*) son obligatorios-: y en caso de no funcionar, en el servidor de backup: las variables necesarias son las siguientes (importante escribirlas exactamente igual, importa mayúsculas y minúsculas). (*)user... este es el usuario de la cuenta creada por Nvia

16 (*)password... la contraseña de la cuenta creada por Nvia (*)contenido... Texto del sms o datos de un mensaje binario -si es texto, máximo de 160 caracteres. (*)moviles... Móviles destinatarios del sms, separados por comas. udh... User Data Header necesario fundamentalmente para envío de logos y melodías. dcs... Se usa para especificar si es un sms de 7 u 8 bits y si lo enviamos a la SIM o a pantalla remitente... Para que en lugar de un numero corto aparezca el texto que queremos (máx. 11 caracteres) notify... Para recibir acuse de recibo del sms enviado Almacenado, Enviado, expirado (la combinación de las letras AEX que queramos en función del dato que nos interese) delivery... Especificamos el día y la hora de entrega con el siguiente formato DDMMAAhhmm Para facilitar las consulta del estado de los envíos, además de por fechas, hay 2 parámetros que pueden ayudar a hacer dichas consultas. idenvio Para consultar el estado de un envío que englobe a varios móviles, se puede asignar un identificador único al mismo. Es recomendable usar formatos tipo fecha-hora, para asegurar la unicidad (por ejemplo, ddmmaahhmmss). Sólo se enviará un push por móvil e identificador, por lo que para mandar 2 pushes al mismo móvil hay que poner otro idenvio. idpropio También para facilitar las consultas del estado de los envíos, este parámetro sirve para que el cliente pueda poner un valor que considere oportuno, por ser de uso interno. Por ejemplo, para una cadena de franquicias con un software de envío, se puede poner aquí el identificador de la franquicia, de manera que luego se puede buscar el estado de un envío por fecha y franquicia (esta búsqueda podría incluir

17 más de un envío más de un idenvio, por tanto-). Ejemplo: notify=aex&contenido=prueba+de+envio&moviles=6nnnnnnnn&remitente=wwwww 4.1.iv.- A varios móviles, con textos diferentes En segundo lugar, para el envío de diferentes contenidos a diferentes móviles, se usará el siguiente script y parámetros: y si no funciona, en el servidor de backup: ( ) las variables necesarias son las siguientes (importante escribirlas exactamente igual, importa mayúsculas y minúsculas); las marcadas con (*) son obligatorias: (*)user... este es el usuario de la cuenta creada por Nvia (*)password... la contraseña de la cuenta creada por Nvia (*)contenido... Tuplas separadas por comas con el siguiente formato: movil contenidoreal udh dcs - movil... Móviles destinatarios del sms, - contenidoreal texto o datos a ser enviado. Contenido propiamente dicho. Si es un texto, no es necesario incluir caracteres de escape para las comas, pero no puede contener el carácter. - udh... User Data Header necesario fundamentalmente para envío de logos y melodías. - dcs... Se usa para especificar si es un sms de 7 u 8 bits y si lo enviamos a la SIM o a pantalla

18 remitente... Para que en lugar de un numero corto aparezca el texto que queremos (máx. 11 caracteres). notify... Para recibir acuse de recibo del sms enviado Almacenado, Enviado, expirado (la combinación de las letras AEX que queramos en función del dato que nos interese). delivery... Especificamos el día y la hora de entrega con el siguiente formato DDMMAAhhmm idenvio Para consultar el estado de un envío que englobe a varios móviles, se puede asignar un identificador único al mismo. Es recomendable usar formatos tipo fecha-hora, para asegurar la unicidad (por ejemplo, ddmmaahhmmss). Sólo se enviará un push por móvil e identificador, por lo que para mandar 2 pushes al mismo móvil hay que poner otro idenvio. idpropio También para facilitar las consultas del estado de los envíos, este parámetro sirve para que el cliente pueda poner un valor que considere oportuno, por ser de uso interno. Por ejemplo, para una cadena de franquicias con un software de envío, se puede poner aquí el identificador de la franquicia, de manera que luego se puede buscar el estado de un envío por fecha y franquicia (esta búsqueda podría incluir más de un envío más de un idenvio, por tanto-) Ejemplo: ZZZZZ&notify=AEX&contenido=6nnnnnnnn prueba+de+envio&remitente=wwwww 4.1.v.- Consulta del estado de los envíos Una vez se ha realizado un envío, se puede consultar el estado del mensaje en cada móvil que pertenece a dicho envío; para ello, tal y como ya se ha comentado previamente; para ello existen los scripts que se comentan a continuación. Todos ellos devuelven un xml con la siguiente estructura: <?xml version="1.0" encoding="iso " standalone="yes"?> - <envios>

19 <encontrados>21</encontrados> - <datos> - <detalle> <id_envio /> <movil></movil> <fecha_entrada></fecha_entrada> <hora_entrada></hora_entrada> <texto_envio> </texto_envio> <fecha_entregaoperadora></fecha_entregaoperadora> <hora_entregaoperadora></hora_entregaoperadora> <fecha_notificacion /> <hora_notificacion /> <estado></estado> </detalle> </datos> </envios> Teniendo cada campo el siguiente significado: Id_envio: El identificador de envío dado por el cliente Movil: Número de móvil destinatario del push Fecha_entrada/hora_entrada: Fecha y hora en la que el enviador recibe el mensaje de la cola y pasa a procesarlo. Texto_envio: Texto enviado Fecha_entregaoperadora/hora_entregaoperadora: Fecha y hora en que una vez procesado, el mensaje se envía efectivamente a la operadora. En envíos masivos, o coincidiendo con otros envíos, puede tardar unos minutos entre que se recibe (hora_entrada), y se entrega Fecha_notificacion/Hora_notificacion: Fecha y hora en los que la operadora ha dado la última información acerca del estado actual del mensaje. Estado: Estado actual del mensaje; uno de los siguientes valores: - N. Enviado: notificación de enviado. El mensaje ha sido entregado en el móvil de destino con éxito. - N. Almacenado: El mensaje se ha intentado entregar, pero sin éxito, por lo que la operadora ha almacenado el mensaje para reintentar su entrega

20 posteriormente. - N. Expirado: El mensaje se ha intentado entregar por un período de 5 días, sin éxito, por lo que la operadora lo marca como expirado y no se vuelve a reintentar. - N. Sin Servicio: El móvil al que se intenta el envío se ha dado de baja y por tanto no es un móvil válido - Enviados: El mensaje se envío sin acuse de recibo, por lo que la única información que se tiene es que el mensaje se ha enviado a la operadora para que ésta lo entregue. - Bandeja de Salida: El mensaje esta en nuestra cola pendiente de ser entregado a la operadora (sin acuse de recibo). - Enviados NR: El mensaje está en la cola, pendiente de ser entregado a la operadora (con acuse de recibo) - Retenidos: Los mensajes que se intentan enviar cuando no hay créditos quedan en este estado. Cuando vuelve a haber créditos, los mensajes en este estado no se vuelven a enviar automáticamente. El cliente debe ponerse en contacto con Nvía si desea que se intente de nuevo su envío. - Error: Error en la entrega a la operadora; puede ser porque el número de destino fuera erróneo (por contener algún carácter, por ejemplo), porque la fecha de entrega sea anterior a la actual, cuando el remitente personalizado exceda los 10 caracteres En los scripts, todos los parámetros son obligatorios, salvo móviles que sirve para restringir la búsqueda a los móviles que se incluyan en este parámetro, separados por comas. Por fecha

21 assword=&fechaini=18/09/2006&fechafin=19/09/2006&moviles= Por idenvio word=&idenvio=3&moviles= Por fecha e idpropio ser=&password=&fechaini=18/09/2006&fechafin=24/09/2006&idpropio=&moviles= El parámetro pais se puede dejar en blanco en caso de tratarse de búsquedas de envíos realizados en España ENVIO POR SONICMQ Como se puede ver en los ejemplos que acompañan en este documento la forma de envío por el SonicMQ se basa en una conexión al broker y una cola de envío llamada Push con un usuario y contraseña, a continuación se envía por orden los datos tomando como separador, a continuación explicamos la cadena que se tendría que enviar con todos sus campos aunque sólo son obligatorios los 2 primeros. Cadena = Movil Texto Notify Delivery Udh Dcs Remitente IDSms A diferencia del envío por URL podemos añadir en el último campo un IDSms. Ese campo se utiliza si se solicita una cola de recepción de acuses de recibo. En la cola de acuses de recibo recibiríamos la siguiente información: IDSms Tipo de Notificacion Notificacion o Descripcion Tipo de Notificacion : NTF (notificacion de acuse) o ERROR Notificacion o Descripcion: NA (Almacenado), NE (Enviado), NX (Expirado) si el Tipo de Notificacion es NTF y sino viene la descripción del error producido

22 - 22 -

23 5.- ENVÍO DE WAPPUSH ENVIO POR URL Hay dos scripts preparados para el envío de pushes. En primer lugar, para realizar el envío de un único texto, a diferentes móviles, se usará la siguiente URL con los parámetros que se describen posteriormente: y en caso de no funcionar, en el servidor de backup: las variables necesarias son las siguientes (importante escribirlas exactamente igual, importa mayúsculas y minúsculas). (*)user... este es el usuario de la cuenta creada por Nvia (*)password... la contraseña de la cuenta creada por Nvia (*)contenido... Una sola tupla que se enviará a todos los móviles, con dos opciones: contenido udh dcs (contenido binario y udh y dcs) ó url textowap (url sin ; textowap es el texto de la página previa a la descarga, por ejemplo, Descargar ) (*)moviles... Móviles destinatarios del wappush, separados por comas. notify... Para recibir acuse de recibo del sms enviado Almacenado, Enviado, expirado (la combinación de las letras AEX que queramos en función del dato que nos interese) idenvio Para consultar el estado del envío es necesario asignar un identificador único al mismo. Es recomendable usar formatos tipo fecha-hora, para asegurar la unicidad (por ejemplo, ddmmaahhmmss). Sólo se enviará un push por móvil e identificador, por lo que para mandar 2 pushes al mismo móvil hay que poner otro

24 idenvio. delivery... Especificamos el día y la hora de entrega con el siguiente formato DDMMAAhhmm En segundo lugar, para el envío de diferentes contenidos a diferentes móviles, se usará el siguiente script y parámetros: y si no funciona, en el servidor de backup: ( ) las variables necesarias son las siguientes (importante escribirlas exactamente igual, importa mayúsculas y minúsculas). (*)user... este es el usuario de la cuenta creada por Nvia (*)password... la contraseña de la cuenta creada por Nvia (*)contenido... Tuplas separadas por comas con uno de los siguientes formatos: movil contenidoreal udh dcs - movil... Móvil destinatarios del wappush, - contenidoreal texto o datos a ser enviado. Contenido propiamente dicho. Si es un texto, no es necesario incluir caracteres de escape para las comas, pero no puede contener el carácter. - udh... User Data Header necesario fundamentalmente para envío de logos y melodías. - dcs... Se usa para especificar si es un sms de 7 u 8 bits y si lo enviamos a la SIM o a pantalla Segunda opción: movil url textowap

25 - movil... Móvil destinatario del wappush, - url sin - textowap texto que aparecerá en la página previa a la descarga. Por ejemplo pulse para descargar. notify... Para recibir acuse de recibo del sms enviado Almacenado, Enviado, expirado (la combinación de las letras AEX que queramos en función del dato que nos interese). idenvio Para consultar el estado del envío es necesario asignar un identificador único al mismo. Es recomendable usar formatos tipo fecha-hora, para asegurar la unicidad (por ejemplo, ddmmaahhmmss). delivery... Especificamos el día y la hora de entrega con el siguiente formato DDMMAAhhmm Al igual que para el sms, los parámetros se admiten por POST y por GET. El php únicamente reenvía la petición al servidor de envíos, donde posteriormente se valida usuario, contraseña y si hay créditos, por lo que el php siempre devuelve OK (texto plano, aunque puede llevar saltos de línea, por lo que se recomienda hacer uso de alguna función que compruebe si la respuesta contiene el texto OK, o que quite saltos de línea y espacios). Únicamente si hay un fallo de conexión con el servidor de envíos el resultado del php será ERROR; en este caso, el envío no se habrá realizado y hay que reintentarlo (recomendable hacerlo a través del servidor de backup) ENVIO POR SONICMQ Se hace igual que los pushes, pero con el contenido ya codificado. Cadena = Movil Contenido Notify Delivery Udh Dcs Remitente IDSms Al igual que con el push de sms, podemos añadir en el último campo un IDSms

26 Ese campo se utiliza si se solicita una cola de recepción de acuses de recibo. En la cola de acuses de recibo recibiríamos la siguiente información: IDSms Tipo de Notificacion Notificacion o Descripcion Tipo de Notificacion : NTF (notificacion de acuse) o ERROR Notificacion o Descripcion: NA (Almacenado), NE (Enviado), NX (Expirado) si el Tipo de Notificacion es NTF y sino viene la descripción del error producido

27 6.- WAP-BILLING Introducción El Wap Billing permite a un cliente de Nvia realizar portales Wap independientes de la operadora, en los que cobrar por los contenidos el precio que él desee (hasta un máximo, variable según operadra). Nvia ofrece una pasarela de pago transparente, para gestionar el cobro Modelo de interactuación A continuación se detalla gráficamente el proceso de navegación, compra, validación y retorno al portal. Posteriormente se explica el procedimiento paso a paso. 1.- Navega por el portal Portal wap Pasarela de pagos Operadora usuario 2.- Descargar contenido 3.- Consulta identificador identificador 4.- Redirigir a pasarela transparente 5.- Vuelta al portal 6.- Consulta resultado resultado