Discussion :

[tux59]

Bonjour,

Je viens d'acheter windev 15 , mais j'ai quelques interrogations concernant la faisabilité de mon projet, je suis en pleine lecture du bouquin d'auto-formation d'ailleurs.
Je voudrais réaliser une application de gestion commerciale composée d'un back office et d'un front office qui serait pour l'encaissement (on va l'appeler caisse )

Je voudrais que les back office se répliquent entre eux via un site maître mais je voudrais également que chaque back office puisse accueillir plusieurs caisses, c'est à dire que les caisses seront des clients et le back office le serveur de cette architecture client / serveur.

Pensez-vous qu'il soit possible de cumuler les 2 fonctionnalités ? Par contre si j'ai bien compris, je dois faire un second projet caisse avec une base en client / serveur ?

Merci pour votre aide

@++

[tatayo]

Bonjour,

Je viens d'acheter windev 15 , mais j'ai quelques interrogations concernant la faisabilité de mon projet, je suis en pleine lecture du bouquin d'auto-formation d'ailleurs.
Je voudrais réaliser une application de gestion commerciale composée d'un back office et d'un front office qui serait pour l'encaissement (on va l'appeler caisse )

Pensez-vous qu'il soit possible de cumuler les 2 fonctionnalités ? Par contre si j'ai bien compris, je dois faire un second projet caisse avec une base en client / serveur ?

Bonjour,
A mon avis tu as 3 projets:
1. Le site maitre
2. Le Back-Office
3. La caisse

Pour ce qui est de la faisabilité, je pense qu'il n'y a pas de soucis, Windev propose tout ce dont tu as besoin pour le faire.

Je pense par contre qu'il te faut prévoir le cas où le Back-Office et la caisse sont physiquement sur la même machine.

Je voudrais que les back office se répliquent entre eux via un site maître mais je voudrais également que chaque back office puisse accueillir plusieurs caisses, c'est à dire que les caisses seront des clients et le back office le serveur de cette architecture client / serveur.

Pour le côté réplication Windev le propose en standard, mais rien ne t'empêche de faire ton propre moteur, pour être totalement maitre de ce qui transite.
Je pense également que la caisse doit avoir sa propre base de données et ne pas dépendre du Back-Office, pour que l'encaissement puisse se faire même si ce dernier n'est pas joignable (panne matériel, réseau HS...)

Tatayo.

[tux59]

Salut,

Merci pour ta réponse, mais en y réfléchissant, je me demande si je ne devrais pas faire ainsi.

Dans chaque magasin je place un serveur HFSQL, les caisses et les back office se comportent comme des clients de ce serveur. Je n'avais pas envisagé le cas, que plusieurs employés pouvaient avoir besoin d'un back office.
Chaque magasin se réplique ensuite par rapport au site maître.

Donc dans ce cas, j'ai un projet pour le serveur maître, pour le serveur, le back office et la caisse.

Par contre quand tu dis, de faire son propre moteur de réplication, pourquoi pas, mais j'avoue ne pas trop savoir comment gérer les conflits de clés primaires qui peuvent arriver.

[Raptor92]

Bonjour Tux,

Nous avons résolu le problème des clés primaires par cette solution:

- Les tickets de ventes possèdent une souche devant le numéro du ticket.
- Cette souche identifie le magasin (90 dans notre cas)

-Chaque magasin possède sont serveur (dans notre cas un sql server 2008)
- Chaque serveur se réplique vers le serveur principal du siège.

De cette façon, il peut entrer sur le serveur plusieurs tickets de magasins différents en même temps que cela ne risque rien dû que le numéro de souche est différent selon le magasin.

Souche + numéro de ticket = ID

Pour le coté réplication, je suis en parfait accord avec ce que dit Tatayo

Cette une manière parmi d'autres bien sur

Très bonne journée

[tux59]

Salut,

Sympa la solution, merci

Donc si je comprend bien chaque ticket a une clé composée comme clé primaire ID magasin + ID ticket.
Utiliser une seule clé, ne me paraît pas simple, car comment savoir si c'est le magasin 90 ou 9 pour suivre ton exemple.

Par contre, j'ai encore une petite question, je sais j'abuse , mais si j'ai bien vu HFSQL peut être installé sur du linux. C'est principalement une question de coût, car pour un client, débourser pour une licence 2008 server n'est pas toujours simple.

[tatayo]

Tu as plusieurs solutions:
Formater ton champ, par exemple 3 charactères pour le magasin, 3 pour la caisse et 10 pour le ticket. Ainsi 0010050000032658 correspond au ticket 32658 de la caisse 5 Du magasin 001
Utiliser une Clé composée (IdMag,IdCaisse,NumTicket). Ainsi il n'y a aucune ambiguité possible, et de plus tu peux gérer l'intégrité référentielle, faire des cumuls par magasin/caisse de façon plus aisée...

Tatayo.

[vmolines]

...
Par contre, j'ai encore une petite question, je sais j'abuse , mais si j'ai bien vu HFSQL peut être installé sur du linux. C'est principalement une question de coût, car pour un client, débourser pour une licence 2008 server n'est pas toujours simple.

Bonjour,

SQL Server propose une version Express qui est un moteur de base de données gratuit, complet et performant.

Les seules limitations sont :

- Base limitée à 4go
- 1 seul processeur physique utilisé par le processus. Un processeur multi core est pleinement utilisé
- 1go de mémoire utilisé pour les traitements du moteur

Ce qui est largement suffisant pour bon nombre d'applications. Je ne connais pas la volumétrie pour chacun de vos magasins mais c'est une solution à étudier. Les bases des magasins peuvent être en SQL Server Express tandis que la base centrale peut se payer une version plus évoluée.

[tatayo]

Dans chaque magasin je place un serveur HFSQL, les caisses et les back office se comportent comme des clients de ce serveur. Je n'avais pas envisagé le cas, que plusieurs employés pouvaient avoir besoin d'un back office.
Chaque magasin se réplique ensuite par rapport au site maître.

Attention, si ton serveur HF n'est plus disponible (une panne, ça arrive, surtout dans un environnement pas totalement maitrisé comme un magasin, crois en mon expérience), l'encaissement devient impossible. Je pense sincèrement que la caisse doit pouvoir être autonome, au moins en ce qui concerne l'encaissement.

Par contre quand tu dis, de faire son propre moteur de réplication, pourquoi pas, mais j'avoue ne pas trop savoir comment gérer les conflits de clés primaires qui peuvent arriver.

Que ce soit une réplication automatique en Windev, ou "faite maison", le problème est le même.
Je pense qu'il te faut une souche, un préfixe... pour chaque BASE dans laquelle les documents, fiches... seront créés. Ainsi le problème des conflits ne se pose pas.

Tatayo.

[tux59]

Salut,

Grâce à votre aide et le guide d'auto formation tout commence à s'éclairer pour mon projet.

Par contre pour l'interface graphique, je voudrais la réaliser avec des onglets verticaux sur la gauche et que la partie droite change en fonction de l'onglet, un peu le principe des différentes fenêtres de windev. Ceci est pour coller un peu avec nos interfaces graphiques de gestions des sites internet, le client est moins perdu.

Cela est-il réalisable assez facilement, il me semble qu'il est nécessaire d'utiliser des plans ?

Merci

[tatayo]

En fait la réponse est dans la question, tu peux utiliser un champ onglet, et disposer les onglets à gauche, tout simplement.

Tatayo.

[tux59]

merci bien, tout est vraiment simple avec windev

[Emmanuel Lecoester]

Bonjour,

Je viens d'acheter windev 15 , mais j'ai quelques interrogations concernant la faisabilité de mon projet, je suis en pleine lecture du bouquin d'auto-formation d'ailleurs.
Je voudrais réaliser une application de gestion commerciale composée d'un back office et d'un front office qui serait pour l'encaissement (on va l'appeler caisse )

Je voudrais que les back office se répliquent entre eux via un site maître mais je voudrais également que chaque back office puisse accueillir plusieurs caisses, c'est à dire que les caisses seront des clients et le back office le serveur de cette architecture client / serveur.

Pensez-vous qu'il soit possible de cumuler les 2 fonctionnalités ? Par contre si j'ai bien compris, je dois faire un second projet caisse avec une base en client / serveur ?

Merci pour votre aide

@++

Une très grande marque basée dans le nord utilise WinDev pour gérer le front et le back de ses caisses donc je n'y vois aucun inconvénient

[hpascal]

Bonjour

Une très grande marque basée dans le nord utilise WinDev pour gérer le front et le back de ses caisses donc je n'y vois aucun inconvénient

Emmanuel Lecoester : en HyperFile ???

tux59 : je te conseille fortement de partir sur une base de données "solide", qu'on trouve d'ailleurs en version gratuite par exemple mysql ou postgreSQL.
Windev fournit un accès natif gratuit pour ces bases et c'est très performant.

http://www.pcsoft.fr/accesnatifs/clientserveur.htm

[tux59]

Salut,

@hpascal
En quoi HyperFileSQL ne sera pas adapté à mon projet ?

@Emmanuel
est-il possible de connaître la marque ?

merci

[hpascal]

Bonjour

En quoi HyperFileSQL ne sera pas adapté à mon projet ?

En terme de performances HF c'est correct sur des petits volumes, sinon c'est catastrophique.
Ensuite, en terme de stabilité. Attention ! ce n'est pas une généralité, mais il y a souvent eu des cas de corruption d'indexs inexpliqués sur les fichiers HyperFile.
J'ai travaillé plusieurs années sur HyperFile (classic) et je ne veux plus en entendre parler pour des projets réseau.
Je dis bien HyperFile Classic, car depuis la version Client/Serveur la donne a un peu changé.

Coté performances dès qu'on essaye de faire des requêtes moyennement complexes HyperFile est largué. Parcours les messages du forum dédié à HyperFile pour avoir des avis.

Maintenant il y a aussi des expériences réussies avec HF Client/Serveur, tu peux demander des avis dans ce sens sur ce forum

Quelle sera la volumétrie de ta base ?

[Emmanuel Lecoester]

Le prospect (et oui je n'ai pas eu la mission) était en HyperFile avec réplication des caisses vers deux serveurs maitres pour maitriser la disponibilité (avec aussi la possibilité d'avoir une caisse faisant office de serveur).

Désolé je ne peux pas vous fournir son nom