Portal    Foro    Buscar    FAQ    Registrarse    Conectarse


Publicar nuevo tema  Responder al tema 
Página 1 de 1
 
 
Implementar Servicio SMS De Lleida.net En Un Programa?
Autor Mensaje
Responder citando   Descargar mensaje  
Mensaje 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 
CanihoJR - Ver perfil del usuarioEnviar mensaje privadoVisitar sitio web del usuario 
Volver arribaPágina inferior
Responder citando   Descargar mensaje  
Mensaje 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.
 
 



 
soplo - Ver perfil del usuarioEnviar mensaje privado 
Volver arribaPágina inferior
Responder citando   Descargar mensaje  
Mensaje Re: Implementar Servicio SMS De Lleida.net En Un Programa? 
 
Tal vez ésto te pueda servir de algo.


saludos
 



 
nrcefe - Ver perfil del usuarioEnviar mensaje privado 
Volver arribaPágina inferior
Responder citando   Descargar mensaje  
Mensaje 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
 



 
Ender - Ver perfil del usuarioEnviar mensaje privado 
Volver arribaPágina inferior
Responder citando   Descargar mensaje  
Mensaje 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.
 



 
soplo - Ver perfil del usuarioEnviar mensaje privado 
Volver arribaPágina inferior
Mostrar mensajes anteriores:    
 
OcultarTemas parecidos
Tema Autor Foro Respuestas último mensaje
No hay nuevos mensajes Donde Escribir Los Codigos Para Implementa... kexxya General 1 Domingo, 12 Junio 2011, 14:17 Ver último mensaje
soplo
No hay nuevos mensajes Wsdl - Alguien Se Peleo Con Algun Tipo De ... arubioc Aplicaciones/Fragmentos de Código 2 Miercoles, 26 Septiembre 2012, 08:11 Ver último mensaje
arubioc
No hay nuevos mensajes Servicio MySQL netking86 Bases de Datos 3 Viernes, 05 Octobre 2012, 10:22 Ver último mensaje
netking86
No hay nuevos mensajes Comsumir Un Servicio Web SoyDesarrollador General 1 Viernes, 23 Agosto 2013, 16:31 Ver último mensaje
jguardon
 

Publicar nuevo tema  Responder al tema  Página 1 de 1
 

Usuarios navegando en este tema: 0 registrados, 0 ocultos y 1 invitado
Usuarios registrados conectados: Ninguno


 
Lista de permisos
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



  

 

cron