CHAUSSEA a réalisé son ERP avec WINDEV
CHAUSSEA représente plus de 30 millions de paires de chaussures vendues par an. Pour développer son ERP métier dans un objectif de croissance et d'agilité, la DSI a choisi WINDEV et WINDEV Mobile.
CHAUSSEA : 30 millions de paires vendues par an
La société est née en 1984 avec la volonté de chausser tout le monde en France et également en Europe ( près de 400 magasins). En se concentrant exclusivement sur les chaussures et les accessoires, CHAUSSEA revendique une véritable ambition « fashion » tout en pratiquant des prix remarquables. Cela représente plus de 30 millions de paires vendues par an. « Le caractère innovant de CHAUSSEA provient également de sa capacité à développer des outils de vente dans les magasins pour donner la faculté à chacun des vendeurs d’offrir la paire attendue par le client » , déclare Aziz Messaoudi, DSI de CHAUSSEA.
ERP métier pour CHAUSSEA : WINDEV est omniprésent
Et de préciser : « Et comme nous sommes météo dépendants, il est nécessaire d’agir rapidement au niveau logistique. Ainsi, nous avons mis en place un ERP métier capable de répondre avec précision à ces besoins variables. Le back office siège et magasin, le front office, l’intranet et toutes les solutions mobiles s’appuient sur les environnements de PC SOFT : WINDEV et WINDEV Mobile » .
HFSQL & Oracle : totale synchronisation
Cet ERP propre au retail s’appuie au siège sur la base Oracle et gère aussi bien l’assortiment des produits, le pilotage des magasins en France et à l’international, que le suivi des clients multi canaux. Pour le front et back office en magasin, la DSI a opté pour la base de données HFSQL. L’application de point de vente, développée en WINDEV est déployée sur plus de 1 000 caisses ( norme NF 525) et est synchronisée quotidiennement avec Oracle. Le DSI de Chaussea précise : « Le choix de HFSQL s’explique notamment par le déploiement libre de la base. De plus, en termes d’administration et de sécurité, HFSQL possède des atouts considérables » .
WINDEV Mobile : temps réel via 2 millions de Webservices par jour
En magasin, l’application mobile permet quant à elle de connaitre le stock en magasin ou dans un magasin voisin ou encore dans le dépôt central. Elle gère également les inventaires, la réception ou le transfert de marchandises.
« Pour capitaliser sur notre savoir- faire en Wlangage, nous avons évidemment choisi WINDEV Mobile pour ces applications » . A titre d’exemple, la solution implémentée génère un Webservice pour chaque boite de chaussure scannée. Cela représente ainsi plus de 2 millions de Webservices consommés par jour !
WINDEV au sein de CHAUSSEA : une approche pragmatique et Agile
Le DSI de CHAUSSEA tient à témoigner de son expérience relative au développement de L’ERP avec WINDEV :
« Quel que soit le background des développeurs, l’équipe peut se focaliser sur les besoins métier, le fonctionnel. Ils apprécient tous l’approche pragmatique de WINDEV » . Et de conclure : « Grâce à ses IDE, notre fonctionnement en mode Agile nous permet d’être très réactif. C’est une condition sine qua non de notre activité. Il est évident que WINDEV contribue à la flexibilité et à la croissance de CHAUSSEA » .
systématiquement les ressources via la commande # qui suit, même lorsqu'il s'agit d'une ressource « buit- in » , c'est- à- dire chargée par défaut,
# au moins pour la lisibilité. Import- Dscresource - Name Service Node localhost
{
# Le nom de ce bloc de ressource est à votre libre- choix.
Service "Spooler: Running"
{ Name = "Spooler" State = "Running" } } }
Les configurations peuvent contenir plusieurs instances du même type de ressource, mais chaque instance doit avoir un nom unique. Dans l’exemple suivant, un second bloc de ressources Service est ajouté pour configurer le service DHCP.
Configuration Testconfig { Import- Dscresource - Name Service Node localhost
{ Service "Spooler: Running" { Name = "Spooler" State = "Running" }
# Pour configurer un deuxième bloc de ressources de service, ajoutez un autre bloc de
# ressource Service et utilisez un nom unique.
Service "DHCP: Running"
{ Name = "DHCP" State = "Running" } } }
Configuration du LCM
Le Gestionnaire de configuration local ( LCM pour Local Configurztion Manager) est le moteur de la fonctionnalité DSC. Le LCM s’exécute sur chaque noeud cible afin d’analyser et d’appliquer les configurations transmises au noeud. Il a également en charge plusieurs autres opérations liées à DSC dont notamment la détermination du mode d’actualisation ( push ou pull), la spécification de la fréquence à laquelle un noeud extrait et applique les configurations, l’association du noeud à un service d’extraction et la spécification des configurations partielles. Un type spécial de configuration vous permet de configurer le LCM pour définir chacun de ces comportements.
Création et application d’une configuration du LCM
Pour configurer le LCM, vous devez créer et exécuter un type spécial de configuration appliquant ses paramètres. La spécification d’une configuration du LCM se fait via l’attribut Dsclocalconfigurationmanager. L’exemple ci- dessous montre une configuration simple définissant le LCM en mode par envoi. [ Dsclocalconfigurationmanager()] configuration Lcmconfig
{ Node localhost { Settings { Refreshmode = ' Push' } } }
Le processus d’application des paramètres au Gestionnaire de configuration local est similaire à l’application d’une configuration DSC. Vous devez créer une configuration du LCM, la compiler dans un fichier MOF, puis l’appliquer au noeud. À la différence des configurations DSC, vous n’appliquez pas de configuration du gestionnaire de configuration local en appelant l’applet de commande StartDscconfiguration. Au lieu de cela, vous appelez Dsclocalconfigurationmanager en spécifiant le chemin du fichier MOF de configuration du LCM comme paramètre. Après avoir appliqué la configuration du LCM, vous pouvez afficher ses propriétés en appelant l’applet de commande Get- Dsclocalconfigurationmanager. Une configuration du LCM peut contenir des blocs correspondants seulement à un ensemble limité de ressources.
Paramètres de base du LCM
À la différence de la spécification de points de terminaison ( de chemins) et de configurations partielles du service d’extraction, toutes les propriétés du Gestionnaire de configuration local sont configurées dans un bloc de paramètres ( Settings). Le Gestionnaire de configuration local démarre le cycle Configurationmodefrequencymins d’après les critères suivants :
• une nouvelle métaconfiguration est appliquée à l’aide de
Set- Dsclocalconfigurationmanager • l’ordinateur est redémarré Pour toute condition où le processus du minuteur plante, le problème est détecté dans les 30 secondes et le cycle est redémarré. Une opération simultanée peut retarder le démarrage du cycle. Si la durée de cette opération dépasse la fréquence du cycle configurée, le minuteur suivant ne démarrera pas. ✖