SugarCRM détails techniques

logo_sugarcrm

Le présent article a pour objectif de décrire l’aspect technique de SUGARCRM.

Présentation

SugarCRM est un logiciel libre de gestion de la relation client édité par la société américaine SugarCRM, programmé en PHP et utilise une  base MySQL, Microsoft SQL Server ou Oracle comme stockage de données. Du point de vue commercial, SugarCRM  permet aux entreprises de créer des relations clients extraordinaires avec une solution de CRM la plus innovante, flexible et abordable sur le marché. La société met l'individu au centre de ses activités sur les solutions aidant à transformer l'expérience client et permet des interactions hautement personnalisées qui animent l'excellence et la fidélité client tout au long du cycle de vie du client dans son ensemble.

 

Environnement Technique

Cette couche de l’environnement est la partie sur laquelle l’application va être installée. Elle doit être configurée avec les prés-requis minimaux pour héberger une application SugarCRM6 (http://support.sugarcrm.com/05_Resources/03_Supported_Platforms/Sugar_6.5.x_Supported_Platforms)

  • SugarCRM

SugarCRM est à la fois une société et une application proposant des fonctionnalités de SFA. La société propose une édition gratuite et open source dont la dernière version est la 6.5.20. L’application a été structurée de sorte à ce qu’une partie importante des fonctionnalités puissent être surchargées afin de pouvoir modifier les fonctionnalités existantes ainsi que d’en ajouter des nouvelles.

Comme la plupart des applications reposant sur un environnement LAMP, une application SugarCRM est divisée en deux parties distinctes :

  • Une partie applicative en PHP
  • Une partie stockage des données sur laquelle MySQL est utilisé (les autres éditions permettent d’utiliser une base MS SQL SERVER ou ORACLE)

2.2.1.      Structure de l’application PHP

structure

Figure 1 : Structure du système de fichier

L’organisation standard d’une application SugarCRM. Ci-après les explications sur les divers dossiers et les fichiers les plus importants :

2.2.1.  Dossiers et fichiers

Dossiers
  • cache : Stockage des caches de l’application
  • custom : Emplacement des fichiers de personnalisation
  • data : Emplacement des fichiers de base fournissant les fonctionnalités de base de l’application (Relations, Beans, …).
  • include : Fonctions et librairies utilitaires
  • metadata : Emplacement des fichiers de métadonnées décrivant les relations.
  • ModuleInstall : Fonctionnalités d’installation des modules SUGAR
  • modules : Emplacement des modules installés au niveau de l’application. Les modules sont les entités de bases manipulées au niveau d’une application SugarCRM. Ils représentent les entités métiers fournissant les fonctionnalités (Compte, Contacts, Leads, …). Toute entité est un module dans SugarCRM (ou presque) et les fonctionnalités disponibles pour un utilisateur font partie généralement d’un module (Même les fonctionnalités d’administration. Le module offre l’entrée du menu ainsi que les actions permettant d’effectuer les tâches d’administration).
  • service : Emplacement des codes de web services par défaut
  • themes : Emplacement des thèmes de base de l’application
  • upload : Emplacement des fichiers uploadés dans l’application (Les pièces jointes des notes et les documents sont dans ce dossier). L’emplacement est paramétrable depuis les configurations.
  • Zend : Classes PHP utilisées par le framework

 

Fichiers
  • php : Fichier de démarrage lors de la consultation par navigateur
  • php : Fichier principal pour l’exécution des tâches planifiées SUGAR (Notifications, nettoyage de cache, Purge de BDD, …)
  • service/v4_1/rest.php : Point d’entrée pour les appels REST
  • service/v4_1/soap.php : Point d’entrée pour les appels SOAP
  • php : Configuration de base de l’application après installation dont les lignes les plus importantes sont :
    • db_config/db_host_name : Hôte du serveur de base de données
    • db_config/db_user_name : Nom d’utilisateur pour la connexion à la base (Utilisateur disposant de droits d’altération des schémas)
    • db_config/db_password : Mot de passe de l’utilisateur
    • db_config/db_name : Nom de la base de données
    • db_config/db_type : Type de base de données (Devrait être mysql)
    • db_config/db_manager : Manager de base utilisé par PDO (MysqlManager, MySQLiManager,…)
    • site_url : URL d’accès à l’application

 

 

2.2.2.      Structuration de la base de données

Une base de données SUGARCRM est composée d’un nombre assez important de tables suivant les fonctionnalités mises en place il existe généralement une table par module (ou deux s’il y a une table d’extension pour les champs personnalisés). Les noms des tables correspondent généralement au nom du module (c’est pas toujours le cas mais globalement tous les modules par défaut ont cette correspondance entre nom du module et nom de table).

2.2.2.1.  Modules de principaux

Ce sont les modules contribuant principalement dans les fonctions SFA :

  • Leads (leads): Offre les fonctionnalités de prospection et de transformation (Conversion)
  • Comptes (accounts): Offre la gestion des clients
  • Contacts (contacts): Offre la gestion des contacts des clients
  • Opportunités (opportunities): Soutient les fonctionnalités de relation avec les clients (Affaires)

Le schéma ci après représente les relations entre ces entités de base :

base

Figure 2 : Diagramme des modules de bases et relations

2.2.2.2.  Modules complémentaires

Ce sont les modules offrant des fonctionnalités de supports aux modules existants pour le stockage des informations annexes. Ci après une liste de ces modules :

  • Documents (documents) : Stockage des documents et pièces jointes
  • Offres (aos_quotes) : Stockage des offres
  • Tâches (tasks) : Stockage des tâches relatives à une entité ( compte, contact, lead et opportunité,…)
  • Notes (notes) : Stockage des notes relatives à une entité
  • Réunions (meetings) : Stockage des planifications de réunions
  • Produits (aos_products) : Stockage de la liste des produits (offres)
  • Catégories de produits (aos_product_categories) : Stockage des catégories de produits (offres)
  • Emails (emails) : Stockage des emails (échanges emails avec les comptes, contacts, leads et opportunités,…)

2.2.2.3.  Relations

C’est une notion propre à SugarCRM pour stocker les métadonnées relatives à l’association entre les modules. Le principe est le même que sur un modèle Entité Relationnel (C’est transformé et géré automatiquement par SugarCRM à partir des métadonnées, il ne faut pas modifier les tables directement). Les relations sont stockées dans des fichiers de métadonnées (du dossier metadata) et visibles depuis l’interface d’administration de SugarCRM (studio : Interface de paramétrage de SugarCRM pour créer des champs, des relations ainsi que des listes personnalisées).

Les relations sont nommées suivant les noms définis dans les fichiers de métadonnées mais généralement, il est assez facile de les retrouver dans la base sans connaissance préalable de ces fichiers.

Par exemple, les tables en base :

  • accounts_contacts : représente les relations entre compte et contacts
  • documents_contacts : contient les relations entre les contacts et les documents (documents liés à un contact)
  • meetings_leads : contient les relations entre les leads et les réunions (Réunions effectuées avec les leads)

2.2.2.4.  Les personnalisations

SugarCRM permet de faire des modifications sur les modules existants. Ces modifications peuvent consister à l’ajout de champs ou de relations personnalisées avec d’autres modules.

Les champs personnalisés sont stockés dans des tables séparées, dont les noms sont post fixés par « cstm »  (ex : accounts_cstm, contacts_cstm, …). La relation avec la table principale est assurée par un champ « id_c » existant dans ces tables (clés primaires). Une partie des métadonnées sont stockées dans la table « fields_metadata »

Les relations personnalisées sont souvent stockées dans des tables de relation, même les relations one to many et one to one (à part les champs de type RELATE : Relation one to many spéciale dont les enfants n’ont pas pour vocation à être affichés depuis les parents). Les noms des relations sont définis à la création (souvent depuis studio) et dont les tables créées ont généralement des noms se terminant par « _c ».

2.2.2.5.  Les droits

La gestion de droit au niveau de l’application se fait à travers l’utilisation de modules spécialisés. Les modules intervenant dans la gestion des droits sont, à part les fonctionnalités de vérification des accès et des habilitations, des modules comme tout autre module.

  • Utilisateurs (module : Users, table : users) : Ce sont les entités sur lesquelles s’appliquent les contrôles d’accès et d’habilitation, ce sont les utilisateurs de l’application.
  • Rôles (module : ACLRoles, table: acl_roles) : Ce sont les entités permettant de regrouper les habilitation sur les différentes actions (ex : un rôle commercial ne pourra par exemple modifier que ses opportunités).
  • Actions (module : ACLActions, table : act_actions): Définit la liste des actions pouvant être attribués à des Rôles. Chaque action est associée à une habilitation correspondante pour le rôle (ex : action éditer, afficher, importer, …)
  • Groupes (module : SecurityGroups, table security_groups) : Permet de regrouper des utilisateurs dans des équipes sur lesquelles les rôles sont affectés. Les rôles sont affectés aux équipes au lieu de les affecter aux utilisateurs directement

2.3  Installation de l'application

L’installation de l’application se fait en utilisant les sources déjà existantes de l’application et l’installation des modules contenant les personnalisations (champs, entités, …).

2.3.1     Installation de la base

L’installation de la base consiste à importer un DUMP de la base existante avec seulement les données de référence (configuration, métadonnées des champs, …) sur une base de donnée vide mysql.

2.3.2      Configuration

La configuration consiste à changer les paramètres se trouvant dans le fichier config.php pour pointer vers la base de données à utiliser (voir les Fichiers utiles). Éventuellement, il est aussi possible de modifier certains paramètres depuis l’interface d’administration.

2.3.3     Installation des modules supplémentaires

Certaines personnalisations de l’application comme les champs personnalisés sont séparées dans des modules distincts. Certaines mises à jour de l’application nécessitent l’installation de ces modules. Généralement, la création d’une application en utilisant un schéma existant ne nécessite pas l’installation des modules.

  • Sauvegarde

Pour assurer le bon fonctionnement de l’application ainsi que la reprise en cas de problème, il est préférable d’exécuter des sauvegardes fréquentes à la fois des sources et surtout de la base de données.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.