Discussion :

[b_reda31]

Bonjour,
je vous explique grosso-modo le cahier de charge du projet que je dois réaliser.
Dans une boite qui fait de la distribution (vente) les commerciaux se déplacent au niveau des clients afin de réaliser des commandes.
à partir d'une application, le commercial présente au client le catalogue de produits et par la suite, le client établi un bon de commande depuis cette même application (en cours de réalisation).
Cette commande doit être envoyée directement au siège de la boite (via une connexion 3G) afin de procéder à la livraison du client (facturation, destockage,livraison...etc).

Pour résumer nous avons deux applications :
L'application 1: Installée au niveau du siège de l'entreprise : celle-ci a le rôle d'afficher en permanence les commandes envoyées depuis l'application 2
L'application 2: Celle-ci est installée au niveau de chaque commercial et a pour rôle de présenter le catalogue des produits et d'envoyer les bons de commandes à l'application 1.

Mes principales contraintes sont :
Le client ne peut malheureusement pas obtenir une adresse IP fixe.
Nous ne pouvons pas souscrire à des solutions payantes par internet...



Maintenant, d'un point de vue réalisation, j’hésite entre deux architectures (ou plutôt approches) :

Approche 1 : Applications Client/Serveur :
J'ai crée la base de données HF client/serveur. celle-ci est stockée au niveau du siège. les commerciaux se connectent directement à la base et réalisent leurs commandes à distance depuis une connexion 3G.
Pour contourner le problème d'adresse IP dynamique, j'utilise la formule gratuite de NO-IP en ajoutant une redirection par le port 4900 au niveau du routeur du siège.
J'ai fais quelques essais, et tout fonctionne pour le mieux pour le moment. Cependant, je ne suis pas rassuré d'utiliser NO-IP car mon application dépendra toujours de ce service gratuit aujourd'hui mais qui sait demain?

Approche 2 : Passer à partir des mails
Pour l'application 2 (commercial): au lieu d'acceder à la base et d'y ajouter des enregistrements, l'application envoie un mail pour chaque commande réalisée ; dont le contenu (message) est structuré (sous forme d'un fichier xml par exemple), que défini une commande et contientra toutes les informations nécessaires pour interpréter la commande (IdClient,IdProduit,Qt,...etc)
Au niveau de l'application 1 (siège) : celle-ci devra "scruter" la boite de réception mail et récupérer tous les mails non lus et les traiter par la suite (interprétation et insersoin dans la base).


L'avantage de cette approche est que la base est inaccessible ce qui rend l'application plus sécurisée, de plus il n'est pas nécessaire que l'application 1 soit en ligne au moment de la réalisations des commandes. Cependant je me demande si c'est une solution fiable ? est-ce qu'un mail peut pour une raison ou un autre ne pas être envoyés sans que l'utilisateur en soit informer ?

Voilà, je m'excuse de la longueur de ce message et si vous êtes arrivé jusqu'ici en sa lecture je vous en remercie. Je suis preneur de tout conseil que vous pourriez m'apporter.

Merci

Réda

[serendib]

Bonsoir b_reda31 ,

Une idée en partant sur l'approche 2 :

Je suppose que la structure des fichiers de l'appli siège est identique à l'appli commerciaux.
Donc analyse commune.
Alors un fichier commandes_REP (en-tête), un fichier lignes_cdes_REP, un fichier Clients.REP.
Le commercial prend la cde sur son portable.
Tu lui fais une petite procédure de zip des 3 fichiers cités ci-dessus.
Comme nom : Commercial+Date+Heure
Et tu génères un envoi sur un FTP.
Lorsque l'envoi est correctement terminé un flag dans les en-têtes de cde_REP.
(afin de ne pas les envoyer deux fois)

Le commercial envoi cde par cde ou tout en fin de tournée.

Au siège :
- On scrute les réceptions des zips.
- On traite la commande.
- On efface sur le FTP.

C'est long à dire mais c'est simple comme bonjour à réaliser.

A toi de paufiner pour que ce soit simple pour les utilisateurs.

En attendant de meilleures idées.

[b_reda31]

Merci bien serendib.
Vous me proposez une approche très intéressante que je n'avaias pas envisagée.L'utilisation du protocole FTP semble très utile dans mon cas pour l'envoi des cdes.
Seul hic ! Je retombe au problème de ma première approche car je dois forcement fournir l'adresse du serveur FTP (siège) et celle-ci est dynamique ! Je me retrouverai obligé de passer par NO-IP ou une solution de ce genre.
à moins que je vous ai mal compris?

[serendib]

Merci bien serendib.
Vous me proposez une approche très intéressante que je n'avaias pas envisagée.L'utilisation du protocole FTP semble très utile dans mon cas pour l'envoi des cdes.
Seul hic ! Je retombe au problème de ma première approche car je dois forcement fournir l'adresse du serveur FTP (siège) et celle-ci est dynamique ! Je me retrouverai obligé de passer par NO-IP ou une solution de ce genre.
à moins que je vous ai mal compris?

Dans mon idée il s'agit d'un serveur FTP autre.
Si votre FAI est orange, par exemple, on passe par les pages persos.
Mes Clients m'envoient régulièrement leur bases par ce biais.
J'imagine que chez tous les FAI on a un minimum de capacité pour ce faire.
Chaque zip ne pèsera pas bien lourd et si l'on épure automatiquement ...

[b_reda31]

Malheureusement notre seul et unique FAI ne fournit pas ce genre de service !
Je vais faire quelques recherches et voir s'il existe des serveurs FTP gratuit qui fournissent plusieurs comptes FTP . . .

[serendib]

Malheureusement notre seul et unique FAI ne fournit pas ce genre de service !
Je vais faire quelques recherches et voir s'il existe des serveurs FTP gratuit qui fournissent plusieurs comptes FTP . . .

C'est qui ce FAI ?

Et pourquoi plusieurs comptes ?

[b_reda31]

C'est qui ce FAI ?

Il s'agit d'algerie telecom. je ne veux pas faire de mauvaises pubs mais leurs serveurs sont à éviter.

Et pourquoi plusieurs comptes ?

Pensez vous que je puisse utiliser qu'un seul compte FTP alors que plusieurs commerciaux peuvent envoyer les fichiers au même moment?

[serendib]

Relis bien ce que je t'ai dis plus haut :

Tu lui fais une petite procédure de zip des 3 fichiers cités ci-dessus.
Comme nom : Commercial+Date+Heure
Et tu génères un envoi sur un FTP.

Pas de doublons possibles.

[b_reda31]

Relis bien ce que je t'ai dis plus haut :

Tu lui fais une petite procédure de zip des 3 fichiers cités ci-dessus.
Comme nom : Commercial+Date+Heure
Et tu génères un envoi sur un FTP.

Pas de doublons possibles.

Oui j'avais bien compris. Cependant, mon soucis est au niveau des comptes du serveur FTP : les commerciaux vont devoir se connecter au serveur ftp via un compte ftp (nom d'utilisateur + un mot de passe).
Je me demande juste s'il est possible d'envoyer simultanément plusieurs fichiers au serveur depuis plusieurs IP via le même compte FTP ...je vais me renseigner sur ce coté là.

Je reviens maintenant à l'idée que vous me suggérez et que je vais tenter de mettre en oeuvre :

Je suppose que la structure des fichiers de l'appli siège est identique à l'appli commerciaux.
Donc analyse commune.
Alors un fichier commandes_REP (en-tête), un fichier lignes_cdes_REP, un fichier Clients.REP.
Le commercial prend la cde sur son portable.
Tu lui fais une petite procédure de zip des 3 fichiers cités ci-dessus.
Comme nom : Commercial+Date+Heure
Et tu génères un envoi sur un FTP.
Lorsque l'envoi est correctement terminé un flag dans les en-têtes de cde_REP.
(afin de ne pas les envoyer deux fois)

Le commercial envoi cde par cde ou tout en fin de tournée.

Si je comprends bien, j'envoi au serveur FTP les fichiers relatifs à la commande :
il y a certains points que je ne comprends pas :

- Que signifie le préfixe REP (ou l'extension?) dans les noms des fichiers? est-ce simplement des fichiers HF qui faudra lire et ajouter leurs contenus à la base?
- Quel est le rôle du fichier Clients.REP. S'il s'agit du client de la commande, n'est-il pas préférable de l’intégrer dans l’entête (fichier Commande_REP) ?
- et si par exemple au lieu d'envoyer 3 fichiers j'envoie qu'un seul fichier XML (NomCommerciale+Date+Heure.xml) qui contiendrait toutes les infos de la commandes ? est-ce avantageux?

Je tente juste de bien comprendre l'approche que vous me proposez et non pas de la mettre en question

[serendib]

En préambule, toute proposition, par définition est faite pour être remise en question.
Je n'ai pas la science infuse et le principe d'un forum est de débattre.

Ceci dit :

REP n'est pas un suffixe.
commandes_REP.FIC (en-tête), un fichier lignes_cdes_REP.FIC, un fichier Clients_REP.FIC
sont des fichiers HF ayant la même structure que les fichiers correspondants de l'analyse
afin de les distinguer pour les traiter au siège.

Intégrer les données Clients dans l'entête des cdes ne me semble pas une bonne idée.
D'une part il peut y avoir beaucoup d'infos (adresse, tél., blablas, mode de paiement, etc...)
Et si un Client repasse une cde 4 jours après on ressaisie tout ?
Pas très pratique pour le commercial.

- Pourquoi pas un XML global mais ça complique pour pas grand chose.
(voir le problème des infos Clients évoqué ci-dessus)

Enfin, tout celà n'est qu'une approche parmis tant d'autres.
Donc à remettre en question, bien entendu.
Quand à moi, c'est ainsi que le procéderais.
Le point le plus délicat sera de distinguer les nouveaux Clients sans créer de doublons.
Mais en général le contrôle sur Sté+Code Postal+Téléphone peut suffire.

[serendib]

Cependant, mon soucis est au niveau des comptes du serveur FTP : les commerciaux vont devoir se connecter au serveur ftp via un compte ftp (nom d'utilisateur + un mot de passe).
Je me demande juste s'il est possible d'envoyer simultanément plusieurs fichiers au serveur depuis plusieurs IP via le même compte FTP ...je vais me renseigner sur ce coté là.

D'une part ils n'auront rien à saisir puisque que l'identifiant et le MDP seront renseignés quand ils appuieront sur le bouton "envoi".
C'est à toi de coder celà.
Quand au nombre d'envois simultanés, il suffit d'indiquer dans ton traitement d'envoi si ça s'est bien passé ou non
et ils recommencent si non.
Mais pour que l'envoi (qui va durer 1 ou 2 minutes maxi) soit pollué par un autre il faudrait qu'il y ait un sacré débit de ventes des commerciaux
et qu'ils soient nombreux.
Bien sûr si ta Sté est une multinationale côtée en bourse, c'est une autre histoire, mais dans ce cas tu as largement les moyens
de louer un serveur adoc.

[b_reda31]

Je vous remercie encore serendib pour votre précieuse aide !

Je commence maintenant à mieux comprendre l'approche que vous me proposez. Seulement, je voyais les choses un peu différemment :
Chaque commerciale a à sa disposition une liste de clients au niveau de sa tablette. Lors de la création d'une commande deux cas de figure se présentent :
1. Le client existe dans la base : Dans ce cas, la commerciale n'a qu'à choisir ce client parmi la liste des clients puis commencer à ajouter les articles à la commande et enfin valider la commande. (envoi au serveur)
2. S'il s'agit d'un nouveau client, la commercial devra le préciser et renseigner toutes ses informations (fiche client) puis commencer la commande et la valider par la suite.(envoi au serveur)

Intégrer les données Clients dans l'entête des cdes ne me semble pas une bonne idée.
D'une part il peut y avoir beaucoup d'infos (adresse, tél., blablas, mode de paiement, etc...)
Et si un Client repasse une cde 4 jours après on ressaisie tout ?
Pas très pratique pour le commercial.

Je pense que dans ce cas, le problème ne se pose pas car la commerciale n'a pas à saisir toutes les infos du clients à chaque commande (seulement lors de sa création)


Mainetenant concernant la procédure d'envoi de la commande. Je mets tout ça dans des fichiers HF et je compresse le tout dans un zip comme vous me le suggérez.
Dans un de ces fichiers, j’intègre d'une part toutes les informations du client(Raison sociale,Tel adresse, blabla....) (je ne me limite pas uniquement à l'identifiant). D'autre part, je précise à l'aide d'un FLAG* s'il s'agit d'un nouveau client ou d'un client déjà existant

Pourquoi envoyer toutes les information du client : parce que la commerciale doit avoir la possibilité de changer ces informations (changement d'adresse du client, de tel,observation,coordonnées GPS...etc).
Au niveau du siège, je scrute le serveur FTP, je récupère le zip, je vérifie s'il s'agit d'un nouveau client ou non (FLAG*):
Si nouveau client ==> HAjoute au fichier client.fic du siège
Sinon ==> HModifie (mettre à jours les informations du client même si elles n'ont pas changé)
Ensuite je traite la commande puis je supprime le zip du serveur FTP comme vous me l'avez conseillé.

Voilà comment je vais tenter de mettre en oeuvre votre approche serendib. Est-ce bon selon vous ? ou peut être que certains cas m'ont échappé

[b_reda31]

Me revoilà !
Grâce à vous serendib, j'ai pu mettre en place cette conception que je vais tenter d'expliquer :



(1) Les Commerciaux établissent les bons de commande puis les envoient au serveur FTP (Dossiers /Commandes)
(2) Un commercial peut ajouter un nouveau client à la base, le fichier client est envoyé directement au dossier /Clients du serveur FTP

Au niveau du siège :

(3) et (4), on "scrute" les dossiers /Commandes et /Clients :
On récupère les nouvelles commandes, on les ajoute à la base puis on supprime les fichiers en question du serveur. Même chose pour les nouveaux clients...

(5) Au niveau du siège, l'administrateur peut mettre à jours la liste des produits, des catégories, des clients,...etc. Dans ce cas, on envoie au serveur FTP les mises à jours (Clients, Produits,...etc) dans le dossier /MAJ

Ensuite au niveau des commerciaux, on teste si une mise à jours est nécessaire. Si tel est le cas, on la récupère (6) et (7)


Mon problème actuel, se situe au niveau des points (3) et (4) : La scrutation, il s'agit d'un traitement périodique.
Je l'ai codé sous forme d'une procédure globale utilisant essentiellement les fonctions : FTPConnecte, FTPRécupère, et FTPSupprimeFichier

Je m’interroge sur l'endroit ou intégrer cette procédure? Dois-je l’intégrer dans l'application du siège en tant que "procédure automatique", ainsi elle sera exécutée toute les X minutes par exemple.
Cependant, son traitement est bloquant. L'administrateur ne pourra donc pas se servir de l'application au moment de l'exécution de la procédure.
Ou peut être qu'il serait préférable d’intégrer la procédure dans une autre application ou d'un service déclenché par l'application principale?

Qu'en pensez-vous?

[Lo²]

Bonjour,

Un service sera le meilleur choix à mon avis, car cela permet à l'application de tourner malgré qu'aucune session utilisateur ne soit ouverte.
Autrement, si pas de service, tu lances la procédure qui scrute le FTP dans un thread secondaire, ce qui évite qu'elle soit bloquante.

[b_reda31]

Merci Lo² !
Entre Service et Thread Secondaire, je pense plutôt opter pour un thread secondaire ; je préfère que cette scrutation se fasse uniquement lorsque l'application principale est ouverte et non pas à tout moment après chaque démarrage de la machine.
ça sera l'occasion pour moi de travailler avec les threads sous windev ! pour la première fois