Je vais démarrer un développement inédit pour moi et j'aurais besoin de
vos avis éclairés.
Le décor :
- le siège de la société où tourne une application de gestion sous SQL
Server
- des commerciaux avec des portables sur lesquels se trouvera une
application de prise de commandes (que je vais développer en HF).
- lorsque les commerciaux se connecteronnt (par internet) au siège, une
autre application (développée par mes soins aussi) devra identifier
celui qui se connecte, lire ses commandes et les intégrer dans la base
SQL Server puis renvoyer sur le portable les mises à jour de tarifs et
les nouveaux articles créés au siège.
Après avoir envisagé la réplication de la base SQL Server (impossible
dans ce cas), j'ai envisagé la connexion RPC. Un RPC inversé en quelque
sorte, puisque j'aurai autant de serveurs qu'il y a de commerciaux et un
seul client : le siège.
Je précise que je n'ai jamais touché à RPC auparavant.
En gros ma question est la suivante : RPC est-il un bon choix dans ce
cas de figure ou dois-je m'orienter vers autre chose ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Gégé
> Le décor : - le siège de la société où tourne une application de gestion sous SQL Server - des commerciaux avec des portables sur lesquels se trouvera une application de prise de commandes (que je vais développer en HF). - lorsque les commerciaux se connecteronnt (par internet) au siège, une autre application (développée par mes soins aussi) devra identifier celui qui se connecte, lire ses commandes et les intégrer dans la base SQL Server puis renvoyer sur le portable les mises à jour de tarifs et les nouveaux articles créés au siège.
[coupé]
En gros ma question est la suivante : RPC est-il un bon choix dans ce cas de figure ou dois-je m'orienter vers autre chose ?
Comme toujours, le client/léger est une bonne solution et procure nombre d'avantages. Je te propose d'utiliser la technologie WDScript. Cette dernière pouvant se coupler avec d'autres comme PHP ou ASP. Tu peux tester cela facilement avec Easy-Wdscript disponible sur : http://wdscript.sf.net
> Le décor :
- le siège de la société où tourne une application de gestion sous SQL
Server
- des commerciaux avec des portables sur lesquels se trouvera une
application de prise de commandes (que je vais développer en HF).
- lorsque les commerciaux se connecteronnt (par internet) au siège, une
autre application (développée par mes soins aussi) devra identifier
celui qui se connecte, lire ses commandes et les intégrer dans la base
SQL Server puis renvoyer sur le portable les mises à jour de tarifs et
les nouveaux articles créés au siège.
[coupé]
En gros ma question est la suivante : RPC est-il un bon choix dans ce
cas de figure ou dois-je m'orienter vers autre chose ?
Comme toujours, le client/léger est une bonne solution et procure nombre
d'avantages. Je te propose d'utiliser la technologie WDScript. Cette
dernière pouvant se coupler avec d'autres comme PHP ou ASP.
Tu peux tester cela facilement avec Easy-Wdscript disponible sur :
http://wdscript.sf.net
> Le décor : - le siège de la société où tourne une application de gestion sous SQL Server - des commerciaux avec des portables sur lesquels se trouvera une application de prise de commandes (que je vais développer en HF). - lorsque les commerciaux se connecteronnt (par internet) au siège, une autre application (développée par mes soins aussi) devra identifier celui qui se connecte, lire ses commandes et les intégrer dans la base SQL Server puis renvoyer sur le portable les mises à jour de tarifs et les nouveaux articles créés au siège.
[coupé]
En gros ma question est la suivante : RPC est-il un bon choix dans ce cas de figure ou dois-je m'orienter vers autre chose ?
Comme toujours, le client/léger est une bonne solution et procure nombre d'avantages. Je te propose d'utiliser la technologie WDScript. Cette dernière pouvant se coupler avec d'autres comme PHP ou ASP. Tu peux tester cela facilement avec Easy-Wdscript disponible sur : http://wdscript.sf.net
MarcK
Bonjour,
Nous utilisons une appli identique à la tienne pour la souscription de contrat d'assurance depuis 5 ans en utilisant le RPC et le FTP windev (plus d'un millier de softs installés). Pas de problème majeur rencontré.
Si nous devions le refaire aujourd'hui, je pense que nous utiliserions Soap qui est un standard utilisant HTTP (pas de problème de configuration de firewall par exemple. Le RPC doit lui utiliser un port différent). De plus, ces fonctions seraient compatibles avec un éventuel site web.
Marc -- Ce message a été posté via la plateforme Web club-Internet.fr This message has been posted by the Web platform club-Internet.fr
http://forums.club-internet.fr/
Bonjour,
Nous utilisons une appli identique à la tienne pour la souscription de contrat
d'assurance depuis 5 ans en utilisant le RPC et le FTP windev (plus d'un millier
de softs installés). Pas de problème majeur rencontré.
Si nous devions le refaire aujourd'hui, je pense que nous utiliserions Soap qui
est un standard utilisant HTTP (pas de problème de configuration de firewall par
exemple. Le RPC doit lui utiliser un port différent). De plus, ces fonctions
seraient compatibles avec un éventuel site web.
Marc
--
Ce message a été posté via la plateforme Web club-Internet.fr
This message has been posted by the Web platform club-Internet.fr
Nous utilisons une appli identique à la tienne pour la souscription de contrat d'assurance depuis 5 ans en utilisant le RPC et le FTP windev (plus d'un millier de softs installés). Pas de problème majeur rencontré.
Si nous devions le refaire aujourd'hui, je pense que nous utiliserions Soap qui est un standard utilisant HTTP (pas de problème de configuration de firewall par exemple. Le RPC doit lui utiliser un port différent). De plus, ces fonctions seraient compatibles avec un éventuel site web.
Marc -- Ce message a été posté via la plateforme Web club-Internet.fr This message has been posted by the Web platform club-Internet.fr
http://forums.club-internet.fr/
Eric
Le 19 mai 2004 à 09:17, Gégé nous disait :
Comme toujours, le client/léger est une bonne solution et procure nombre d'avantages. Je te propose d'utiliser la technologie WDScript. Cette dernière pouvant se coupler avec d'autres comme PHP ou ASP.
Merci de t'intéresser à mon problème en cette période plutôt « calme »... :-)
J'ai regardé le principe de WDScript (très intéressant) mais pas trop adapté à mon cas cependant. Les commerciaux doivent saisir les commandes chez le client (donc sans accès internet) et, une ou deux fois par semaine, transférer ces commandes en bloc au siège. Or, si j'ai bien compris, WDScript serait utile si les commerciaux saisissaient directement les commandes sur le web.
-- Cordialement
Le 19 mai 2004 à 09:17, Gégé nous disait :
Comme toujours, le client/léger est une bonne solution et procure nombre
d'avantages. Je te propose d'utiliser la technologie WDScript. Cette
dernière pouvant se coupler avec d'autres comme PHP ou ASP.
Merci de t'intéresser à mon problème en cette période plutôt
« calme »... :-)
J'ai regardé le principe de WDScript (très intéressant) mais pas trop
adapté à mon cas cependant. Les commerciaux doivent saisir les commandes
chez le client (donc sans accès internet) et, une ou deux fois par
semaine, transférer ces commandes en bloc au siège. Or, si j'ai bien
compris, WDScript serait utile si les commerciaux saisissaient
directement les commandes sur le web.
Comme toujours, le client/léger est une bonne solution et procure nombre d'avantages. Je te propose d'utiliser la technologie WDScript. Cette dernière pouvant se coupler avec d'autres comme PHP ou ASP.
Merci de t'intéresser à mon problème en cette période plutôt « calme »... :-)
J'ai regardé le principe de WDScript (très intéressant) mais pas trop adapté à mon cas cependant. Les commerciaux doivent saisir les commandes chez le client (donc sans accès internet) et, une ou deux fois par semaine, transférer ces commandes en bloc au siège. Or, si j'ai bien compris, WDScript serait utile si les commerciaux saisissaient directement les commandes sur le web.
-- Cordialement
Eric
Le 19 mai 2004 à 11:16, MarcK nous disait :
Nous utilisons une appli identique à la tienne pour la souscription de contrat d'assurance depuis 5 ans en utilisant le RPC et le FTP windev (plus d'un millier de softs installés). Pas de problème majeur rencontré.
Le RPC n'est-il pas lent ? Un certain nombre de commerciaux n'ont pas l'ADSL et se serviront de bons vieux modems 56 k.
Si nous devions le refaire aujourd'hui, je pense que nous utiliserions Soap qui est un standard utilisant HTTP (pas de problème de configuration de firewall par exemple. Le RPC doit lui utiliser un port différent). De plus, ces fonctions seraient compatibles avec un éventuel site web.
C'est une idée.
Merci !
-- Cordialement
Le 19 mai 2004 à 11:16, MarcK nous disait :
Nous utilisons une appli identique à la tienne pour la souscription de contrat
d'assurance depuis 5 ans en utilisant le RPC et le FTP windev (plus d'un millier
de softs installés). Pas de problème majeur rencontré.
Le RPC n'est-il pas lent ? Un certain nombre de commerciaux n'ont pas
l'ADSL et se serviront de bons vieux modems 56 k.
Si nous devions le refaire aujourd'hui, je pense que nous utiliserions Soap qui
est un standard utilisant HTTP (pas de problème de configuration de firewall par
exemple. Le RPC doit lui utiliser un port différent). De plus, ces fonctions
seraient compatibles avec un éventuel site web.
Nous utilisons une appli identique à la tienne pour la souscription de contrat d'assurance depuis 5 ans en utilisant le RPC et le FTP windev (plus d'un millier de softs installés). Pas de problème majeur rencontré.
Le RPC n'est-il pas lent ? Un certain nombre de commerciaux n'ont pas l'ADSL et se serviront de bons vieux modems 56 k.
Si nous devions le refaire aujourd'hui, je pense que nous utiliserions Soap qui est un standard utilisant HTTP (pas de problème de configuration de firewall par exemple. Le RPC doit lui utiliser un port différent). De plus, ces fonctions seraient compatibles avec un éventuel site web.
C'est une idée.
Merci !
-- Cordialement
Gégé
Les commerciaux doivent saisir les commandes
chez le client (donc sans accès internet) et, une ou deux fois par semaine, transférer ces commandes en bloc au siège. Or, si j'ai bien compris, WDScript serait utile si les commerciaux saisissaient directement les commandes sur le web.
Ouh là, cela veut dire qu'il y a saisie hors ligne de commande. Comment peux-tu gérer les stocks comme cela ? De toute façon avec Easy-WDScript, tu peux très bien faire de la saisie hors connexion et le transfert des données quand tu veux ?
Les commerciaux doivent saisir les commandes
chez le client (donc sans accès internet) et, une ou deux fois par
semaine, transférer ces commandes en bloc au siège. Or, si j'ai bien
compris, WDScript serait utile si les commerciaux saisissaient
directement les commandes sur le web.
Ouh là, cela veut dire qu'il y a saisie hors ligne de commande. Comment
peux-tu gérer les stocks comme cela ?
De toute façon avec Easy-WDScript, tu peux très bien faire de la saisie
hors connexion et le transfert des données quand tu veux ?
chez le client (donc sans accès internet) et, une ou deux fois par semaine, transférer ces commandes en bloc au siège. Or, si j'ai bien compris, WDScript serait utile si les commerciaux saisissaient directement les commandes sur le web.
Ouh là, cela veut dire qu'il y a saisie hors ligne de commande. Comment peux-tu gérer les stocks comme cela ? De toute façon avec Easy-WDScript, tu peux très bien faire de la saisie hors connexion et le transfert des données quand tu veux ?
Eric
Le 21 mai 2004 à 11:15, Gégé nous disait :
Les commerciaux doivent saisir les commandes
chez le client (donc sans accès internet) et, une ou deux fois par semaine, transférer ces commandes en bloc au siège. Or, si j'ai bien compris, WDScript serait utile si les commerciaux saisissaient directement les commandes sur le web.
Ouh là, cela veut dire qu'il y a saisie hors ligne de commande. Comment peux-tu gérer les stocks comme cela ?
Pas comme je le voudrais... mais il n'est pas question de changer de fonctionnement : le client a tranché !
De toute façon avec Easy-WDScript, tu peux très bien faire de la saisie hors connexion et le transfert des données quand tu veux ?
Je vais regarder ça de plus près.
-- Cordialement
Le 21 mai 2004 à 11:15, Gégé nous disait :
Les commerciaux doivent saisir les commandes
chez le client (donc sans accès internet) et, une ou deux fois par
semaine, transférer ces commandes en bloc au siège. Or, si j'ai bien
compris, WDScript serait utile si les commerciaux saisissaient
directement les commandes sur le web.
Ouh là, cela veut dire qu'il y a saisie hors ligne de commande. Comment
peux-tu gérer les stocks comme cela ?
Pas comme je le voudrais... mais il n'est pas question de changer de
fonctionnement : le client a tranché !
De toute façon avec Easy-WDScript, tu peux très bien faire de la saisie
hors connexion et le transfert des données quand tu veux ?
chez le client (donc sans accès internet) et, une ou deux fois par semaine, transférer ces commandes en bloc au siège. Or, si j'ai bien compris, WDScript serait utile si les commerciaux saisissaient directement les commandes sur le web.
Ouh là, cela veut dire qu'il y a saisie hors ligne de commande. Comment peux-tu gérer les stocks comme cela ?
Pas comme je le voudrais... mais il n'est pas question de changer de fonctionnement : le client a tranché !
De toute façon avec Easy-WDScript, tu peux très bien faire de la saisie hors connexion et le transfert des données quand tu veux ?
