Implementar Servicio SMS De Lleida.net En Un Programa?


Objetivo: Implementar Servicio SMS De Lleida.net En Un Programa?
Buenas! como siempre, intentando mejorar el servicio a mis clientes, empezé mi proyecto de gambas con idea de que al finalizar una orden de trabajo, se avise automaticamente por SMS a mi cliente, de que puede pasarse a recojer su equipo. Para activar este servicio o no, simplemente un checkbox en el formulario me bastó. Hasta ahora solo guardaba el valor de esta variable en la BD como futura implantación y creo que ha llegado su turno ^^

El formulario es el siguiente:
pantallazonuevocliente

El caso está en que mirando losSDK de lleida.net ( Enlace) no me entero mucho... quizás el que mas claro me pareció fue el ejemplo de JAVA:

/*
* Sample.java
* Created on 2009.03.17
* (c) 2009 LleidaNetworks Serveis Telematics, S.L.
*
*/

package samplenb;


import java.net.SocketException;
import net.lleida.sms.*;

/**
*
* @author David Tàpia <devel@lleida.net>
*/
public class Sample {

/**
* Creates a new instance of Sample
*/
public Sample() {
}

/**
* @param args the command line arguments
*/
public static void main(String[] args) {
net.lleida.sms.ProtocolsMsMass p;
try {
p = new net.lleida.sms.ProtocolsMsMass("user", "pass");
p.setDebugMode(false);
p.setSecureMode(false);
//p.setCustomizedSender("+34777888999");
p.setAllowAnswer(true);
p.connect();

//String test[] = new String[2];
//test[0] = "Texto SMS1";
//test[1] = "Texto SMS2";

String test = "Texto SMS";

//String r[] = new String[2];
//r[0] = new String("997248");
//r[1] = new String("+34666777888");

String r = "+34666777888";


try {
p.getSocket().setSoTimeout(40000);
}
catch(SocketException ex){
ex.printStackTrace();
}

p.checknetwork("+34666777888");
p.sendTextSMS(2, test, r, "");

// Es una conexion por socket y se deben de tener en cuenta las latencias!
// Es un protocolo de comandos CLIENTE/SERVIDOR
try {
// Dormimos 300 milis para esperar las respuestas de los comandos
// Segun el tipo de conexion, este tiempo debe ser mayor
Thread.sleep(300);
} catch (InterruptedException ex) {
ex.printStackTrace();
}

p.disconnect();
} catch (MobileException ex) {
ex.printStackTrace();
}
}
}


Aunque no se mucho de este lenguaje.... así que me encuentro intentando realizar una función a la que le pase un numero de teléfono y un mensaje y lo envie ^^
Este servicio no es gratuito, pero aun así, puede resultar muy interesante para alguno de vosotros. Por lo que si alguno esta dispuesto a echarme una manita, quizás reaprovecheis el código mas de uno ^^

El programa tiene muchas opciones, que si SMS certificado, que si SMS no se que... con un SMS normal y corriente suficiente ^^ como mucho mas, interesante me parece la opción de poder personalizar el remitente del SMS, pudiendo poner el nombre de tu tienda, o cosas así ^^

Gracias de antemano! como siempre!

EDITO: para ampliar informacion:
De momento, creo que la forma mas rapida y factible es hacerlo por E-MAIL: http://soporte.lleida.net/?p=40 como describe el enlace. Enviando un email con una estructura especifica se podría resolver... aun así esperaré vuestras recomendaciones ^^

última edición por CanihoJR el Miercoles, 20 Enero 2010, 11:55; editado 1 vez
Objetivo: Re: Implementar Servicio SMS De Lleida.net En Un Programa?
Para eso lo correcto es que mires las RFCs correspondientes que es lo que hizo el tipo ese que creó ese código en java. La solución para estas cosas es ver las estructuras de información que maneja el estandar, como las envía y como las recibe. Luego lo escribes en gambas o en lo que te plazca.

Para eso están.

Los estándares rfc

En tu caso concreto he visto dos: RFC5724 y RFC4355. Entiendo que la que mas te puede interesar es esta última pero habría que leerlo para ver lo que cuenta cada una.

Esa es la forma de hacer las cosas bien.

Perfil MP  
Objetivo: Re: Implementar Servicio SMS De Lleida.net En Un Programa?
Tal vez ésto te pueda servir de algo.


saludos

Perfil MP  
Objetivo: Re: Implementar Servicio SMS De Lleida.net En Un Programa?
Buscando buscando, he encontrado esta página. Mira a ver si te puede ser útil, parece interesante:

http://www.altiria.com/web/sms_mms/home.html

Espero te ayude, salu2 crack

Perfil MP  
Objetivo: Re: Implementar Servicio SMS De Lleida.net En Un Programa?
Aquí está un extracto de la RFC 5724

Definición de campos
Citar:
2.2. Formal Definition

The URI scheme's keywords specified in the following syntax
description are case-insensitive. The syntax of an "sms" URI is
formally described as follows, where the URI base syntax is taken
from [RFC3986]:

sms-uri = scheme ":" sms-hier-part [ "?" sms-fields ]
scheme = "sms"
sms-hier-part = sms-recipient *( "," sms-recipient )
sms-recipient = telephone-subscriber ; defined in RFC 3966
sms-fields = sms-field *( "&" sms-field )
sms-field = sms-field-name "=" escaped-value
sms-field-name = "body" / sms-field-ext ; "body" MUST only appear once
sms-field-ext = 1*( unreserved )
escaped-value = *( unreserved / pct-encoded ) ; defined in RFC 3986

Wilde & Vaha-Sipila Standards Track [Page 7]

RFC 5724 sms" URI Scheme January 2010


Some illustrative examples using this syntax are given in
Section 2.5.

The syntax definition for <telephone-subscriber> is taken from
Section 5.1 of [RFC3966]. Please consider Erratum 203 [Err203] in
that specification. For the reader's convenience, Appendix A
contains a fixed syntax of the telephone number URI scheme, including
Erratum 203, but RFC 3966 (plus all applicable errata) is the
normative reference. The description of phone numbers in RFC 3966
(Section 5.1) states: "The 'telephone-subscriber' part of the URI
indicates the number. The phone number can be represented in either
global (E.164) or local notation. All phone numbers MUST use the
global form unless they cannot be represented as such. Numbers from
private numbering plans, emergency ("911", "112"), and some
directory-assistance numbers (e.g., "411") and other "service codes"
(numbers of the form N11 in the United States) cannot be represented
in global (E.164) form and need to be represented as a local number
with a context. Local numbers MUST be tagged with a 'phone-
context'."

This specification defines a single <sms-field>: "body". Extensions
to this specification MAY define additional fields. Extensions MUST
NOT change the semantics of the specifications they are extending.
Unknown fields encountered in "sms" URIs MUST be ignored by
implementations.

The "body" <sms-field> is used to define the body of the SMS message
to be composed. It MUST not appear more than once in an "sms" URI.
It consists of percent-encoded UTF-8 characters. Implementations
MUST make sure that the "body" <sms-field> characters are converted
to a suitable character encoding before sending, the most popular
being the 7-bit SMS character encoding, another variant (though not
as universally supported as 7-bit SMS) is the UCS-2 character
encoding (both specified in [SMS-CHAR]). Implementations MAY choose
to discard (or convert) characters in the <sms-body> that are not
supported by the SMS character set they are using to send the SMS
message. If they do discard or convert characters, they MUST notify
the user.

The syntax definition for <escaped-value> refers to the text of an
SMS where all <reserved> (as per [RFC3986]) characters in the SMS
text are percent-encoded, please refer to [RFC3986] for the
definitions of <unreserved> and <pct-encoded> and for details about
percent-encoding.

User agents SHOULD support multiple recipients and SHOULD make it
clear to users what the entire list of recipients is before
committing the user to sending all the messages.


Procesar el sms
Citar:
Processing an "sms" URI

The following list describes the steps for processing an "sms" URI:

1. The phone number of the first <sms-recipient> is extracted. It
is the phone number of the final recipient and it MUST be written
in international form with country code, unless the number only
works from inside a certain geographical area or a network. Note
that some numbers may work from several networks but not from the
whole world -- these SHOULD be written in international form.
According to [RFC3966], all international numbers MUST begin with
a "+" character. Hyphens, dots, and parentheses (referred to as
"visual separators" in RFC 3966) are used only to improve
readability and MUST NOT convey any other meaning.

2. The "body" <sms-field> is extracted, if present.

3. The user agent SHOULD provide some means for message composition,
either by implementing this itself or by accessing a service that
provides it. Message composition SHOULD start with the body
extracted from the "body" <sms-field>, if present.

4. After message composition, a user agent SHOULD try to send the
message first using the default delivery method employed by that
user agent. If that fails, the user agent MAY try another
delivery method.

5. If the URI contains a comma-separated list of recipients (i.e.,
it contains multiple <sms-recipient> parts), all of them are
processed in this manner. Exactly the same message SHOULD be
sent to all of the listed recipients, which means that the
message resulting from the message composition step for the first
recipient is used unaltered for all other recipients as well.



Comparación de SMS
Citar:
Two "sms" URIs are equivalent according to the following rules.
Since the definition of the <telephone-subscriber> is taken from
[RFC3966], equivalence of individual values of <telephone-subscriber>
is based on the rules defined in Section 4 of [RFC3966], repeated
here for convenience:

o Both must be either a <local-number> or a <global-number<, i.e.,
start with a "+".

o The <global-number-digits> and the <local-number-digits> must be
equal, after removing all visual separators.

Wilde & Vaha-Sipila Standards Track [Page 9]

RFC 5724 sms" URI Scheme January 2010

o For mandatory additional parameters and the <phone-context> and
<extension> parameters defined in [RFC3966], the <phone-context>
parameter value is compared either as a host name if it is a
<domainname> or digit-by-digit if it is <global-number-digits>.
The latter is compared after removing all <visual-separator>
characters.

o Parameters are compared according to <pname>, regardless of the
order they appeared in the URI. If one URI has a parameter name
not found in the other, the two URIs are not equal.

o URI comparisons are case-insensitive.

Since "sms" URIs can contain multiple <telephone-subscriber>s as well
as <sms-fields>, in addition to adopting the rules defined for
comparing <telephone-subscriber>s as defined by [RFC3966], two "sms"
URIs are only equivalent if their <sms-fields> are identical, and if
all <telephone-subscriber>s, compared pairwise as a set (i.e.,
without taking sequence into consideration), are equivalent.


Como verás si lees la rfc encontrarás que a menudo se refiere a otra RFC. Por ejemplo hay una RFC para definir como es un número de teléfono y por tanto para describir el número de teléfono de un sms se remite a un número válido según esa RFC. Por eso son estándares.

Ahí tienes toda la información de campos, protocolos, condiciones de validación, etc para que debe cumplir tu software. Como tu solo quieres enviar un sms de vez en cuando no te compete toda la RFC. Busca las condiciones válidas para un envío de SMS, haz un form con esos datos, y el botón de enviar que compruebe lo que la RFC define como condiciones de sms válido. Con eso cuando envies el paquete la compañía telefónica no te lo devolverá por inválido y ya es problema suyo que llegue a quien tenga que llegar.

Perfil MP  

Página 1 de 1


  
No puede crear mensajes
No puede responder temas
No puede editar sus mensajes
No puede borrar sus mensajes
No puede votar en encuestas
No puede adjuntar archivos
Puede descargar archivos
No puede publicar eventos en el calendario

   

Está utilizando la versión (Lo-Fi). Para ver la versión completa del foro, haga clic aquí.

Powered by Icy Phoenix based on phpBB
Design by DiDiDaDo

Página generada en:: 0.1572s (PHP: -14% SQL: 114%)
Consultas SQL: 30 - Debug off - GZIP Activado