Documentation pour la version boîte de Bitrix24. Fin de l'assistant d'installation

Cadre Bitrix - noyau technologique (plateforme) de création et de gestion de projets (sites internet et portails d'entreprise). La plateforme vous permet de créer un nombre illimité de projets en utilisant une copie (licence) du produit, en plaçant le noyau et la base de données du système en une seule copie sur le serveur.

Sur ce moment toutes les fonctionnalités de l'ancien noyau ne sont pas dupliquées dans D7. Mais le nouveau noyau D7 Cadre Bitrix remplaçant progressivement l'ancien. Si l'utilisation d'un ancien noyau a entraîné un avertissement de l'EDI : Method/class is deprecated , alors vous devez utiliser des méthodes.

Pour plusieurs raisons, la documentation de l'API peut ne pas couvrir toutes les méthodes. Pour comprendre comment cela fonctionne, il est parfois préférable de regarder le code réel du programme. Pour cela, vous pouvez utiliser module gratuit du marché : .

Note: en ajoutant #examples à l'adresse de n'importe quelle page, vous pouvez accéder rapidement à un exemple, s'il en possède un. (Cela ne fonctionne pas dans les fichiers de documentation au format CHM.)


Versions d'entité

Cadre Bitrix est en constante évolution. De nouvelles fonctions apparaissent, certaines deviennent obsolètes et de nouveaux paramètres apparaissent dans les fonctions. Cependant, un assez grand nombre de projets ne sont pas mis à jour. Pour faciliter le travail de programmation, la documentation indique avec quelle version du produit la classe, la méthode, le paramètre, l'événement existait (existe).

Les versions sont répertoriées à deux endroits : dans le titre et dans les tableaux. Si la méthode est valide, le titre contiendra uniquement le numéro de version avec lequel il apparaît dans le produit. Si la méthode est obsolète, la gamme de versions où elle était valable sera également indiquée.

Les tableaux indiquent la version avec laquelle l'entité est apparue dans le produit uniquement si son apparition ne coïncide pas avec le moment de l'apparition de la classe, de la méthode elle-même, etc. Dans l'illustration ci-dessous : le paramètre COURSE_ID est apparu avec la méthode (c'est-à-dire à partir de la version 5.1.0), et le paramètre CHAPTER_ID uniquement à partir de la version 9.5.4.

Si un paramètre (il s'agit généralement de paramètres) a changé avec le développement du produit, il y aura une note correspondante dans sa description. (Par exemple : avant la version x.x.x le paramètre s'appelait *****).

Exemple

Remarques:

  • Marque Dépassé pour une méthode, un paramètre ou une clé signifie qu'il n'est pas recommandé de l'utiliser car il n'y aura ni extensions ni correctifs.
  • L'installation des versions n'est pas complètement terminée, des travaux dans ce sens sont actuellement en cours.

"Bitrix", 2001-2019, "1C-Bitrix", 2019

L'intégration d'une boutique en ligne sur 1C-Bitrix avec le système peut être effectuée à l'aide du module système dans Bitrix.Marketplace.

Lors de l'installation, le module vous aidera à télécharger les commandes existantes dans le système.

Après l'installation, le module :

  • télécharger les nouvelles commandes de 1C-Bitrix vers le système ;
  • mettre à jour les données sur les commandes existantes en tenant compte des modifications apportées à 1C-Bitrix ;
  • télécharger les nouvelles commandes et clients du système vers 1C-Bitrix ;
  • mettre à jour les données sur les commandes existantes en tenant compte des modifications apportées au système (par exemple, le statut de la commande a été modifié dans le système, le nombre de marchandises dans la commande, etc., ces modifications seront également reflétées dans 1C-Bitrix) ;
  • envoyer des informations sur le paiement en ligne d'une commande par l'utilisateur au système.

Il est également possible de personnaliser les classes du plugin sans perdre le code modifié lors de la mise à jour. Afin d'implémenter le code modifié, vous devez placer une copie du fichier avec la classe requise dans le répertoire bitrix/php_interface/retailcrm.

Le plugin a la possibilité de personnaliser les fichiers suivants :

RestNormalizer.php
Enregistreur.php
Client.php
RCrmActions.php
RetailCrmUser.php
RetailCrmICML.php
RetailCrmInventories.php
RetailCrmPrix.php
RetailCrmCollector.php
RetailCrmUa.php
RetailCrmEvent.php
RetailCrmHistory_v4.php
RetailCrmHistory_v5.php
RetailCrmOrder_v4.php
RetailCrmOrder_v5.php
ApiClient_v4.php
ApiClient_v5.php

Pour personnaliser les fichiers dont les noms incluent la version de l'API utilisée, les fichiers sont créés avec un nom sans spécifier la version, par exemple - RetailCrmHistory.php.

Après avoir créé une copie du fichier avec la classe dans le répertoire bitrix/php_interface/retailcrm, le module utilisera une classe personnalisée ; vous pourrez apporter des modifications à ses méthodes.

Enregistrement d'une boutique en ligne dans le système

Avant l'installation, enregistrez votre boutique en ligne dans votre instance du système (section Administration > Boutiques par exemple dans la version démo) :

Installation de la solution dans 1C-Bitrix

  • Cliquez sur « Installer » sur la page de la solution dans la Marketplace et saisissez l'adresse de votre boutique en ligne :

  • Téléchargez le module via le système de mise à jour 1C-Bitrix :

  • Commencez à installer le module :

L'assistant d'installation se lancera.

Assistant d'installation. Étape 1

À l'étape 1.1, vous devez indiquer l'adresse de votre système (par exemple, https://test.retailcrm.ru) et la clé API que vous avez générée plus tôt dans le système :

Important! S'il n'y a qu'un seul magasin dans Bitrix, l'étape 1. Sites est ignorée.

Assistant d'installation. Étape 1. Sites Web

À l'étape 1.Sites, vous devez définir la correspondance entre vos magasins dans 1C-Bitrix et le système.

Important! Tous vos magasins dans le système doivent avoir une clé API commune.

Assistant d'installation. Étape 2

Dans la deuxième étape, vous devez indiquer la correspondance entre les valeurs de la boutique en ligne et les répertoires système. Le module lui-même tente d'établir une correspondance pour les statuts typiques. Si le module n'a pas réussi à le faire, vous devez spécifier vous-même la correspondance :

Vérifiez si le système dispose des valeurs de répertoire nécessaires correspondant aux répertoires de la boutique en ligne. S'il n'y en a pas assez, ajoutez-les dans la section Administration sans fermer la page de l'assistant d'installation :

Après cela, actualisez la page de l'assistant : les nouvelles valeurs du répertoire doivent être chargées.

Assistant d'installation. Étape 3

Dans la troisième étape, le module vous permet de définir la correspondance entre les champs de 1C-Bitrix et le système.

Important! S'il existe un formulaire " retour" ou commandes " en 1 clic ", et ces données ne rentrent pas dans les commandes Bitrix standard, alors elles ne sont pas extraites dans le système.

De plus, si vous travaillez avec entités juridiques, vous devez remplir tous les champs comme indiqué dans la capture d'écran ci-dessous.

Assistant d'installation. Étape 4

Dans la quatrième étape, le module vous permet de télécharger les commandes précédemment passées dans le système. Le déchargement peut prendre un certain temps (1000 commandes sont déchargées en 5 minutes environ). La progression du processus de téléchargement sera indiquée par une barre de progression.

Si nécessaire, vous pouvez suspendre le téléchargement et le reprendre après un certain temps.

Après avoir téléchargé les commandes précédemment passées, vous pourrez voir les rapports analytiques dans le panneau KPI. Nous vous recommandons d'effectuer cette étape.

Assistant d'installation. Étape 5

Dans la cinquième étape, le téléchargement du catalogue de produits est configuré. Pour ce faire, vous devez compléter les points suivants.

1. Sélection des blocs d'informations et des propriétés

Les blocs d'informations sélectionnés seront téléchargés dans le système. Un choix vous sera proposé uniquement parmi les blocs d'informations contenant des produits ou comportant des blocs d'informations liés à des offres commerciales. Parallèlement à la sélection des blocs d'informations, vous pouvez sélectionner les propriétés suivantes : article, fabricant, couleur, poids, taille - pour cela, vous devez spécifier la propriété du bloc d'informations, qui est responsable du stockage de la propriété correspondante. La sélection d'une propriété est facultative.

2. Chemin du fichier

Un fichier au format sera généré au chemin spécifié, qui contiendra la structure des répertoires. Le chemin par défaut est - "/bitrix/catalog_export/retailcrm.xml". Si vous modifiez le chemin, vous devrez effectuer une configuration similaire dans le système.

3. Paramétrage du nombre d'offres à l'export

Dans les paramètres d'export du catalogue, il y a un champ « Nombre maximum d'offres commerciales pour un produit », où vous devez saisir le nombre maximum d'offres commerciales qu'un produit peut avoir (s'il y en a plus de 50). Par défaut, le module calcule un maximum de 50 offres commerciales pour un produit. S'il y a moins de 50 offres commerciales par produit dans le magasin, ce paramètre peut être ignoré. S'il y a plus d'offres commerciales et que le réglage est précisé, il est recommandé de transférer l'agent en couronnes s'il travaille sur des hits.

4. Sélection de la fréquence de déchargement

Vous aurez le choix entre trois options :

1. Non- lorsque vous sélectionnez cet élément, le téléchargement périodique du catalogue ne sera pas automatiquement configuré et vous devrez télécharger le catalogue vous-même à chaque fois.

Cette option peut être utile si le catalogue de produits de votre boutique en ligne change très rarement ou si vous souhaitez configurer les paramètres de téléchargement ultérieurement.

2. Cron- la sélection de cet élément entraînera la création automatique d'un profil spécial qui sera lié au service Cron du serveur sur lequel fonctionne le site de la boutique en ligne.

L'utilitaire cron s'exécute dans arrière-plan et effectue des tâches spécifiées à des heures spécifiées.

La sélection de cet élément peut être utile si le catalogue contient un élément très volumineux ( plus de 10 000 produits). Pour cet élément, vous devez préciser le nom du profil d'export spécial.

3. Agent. Dans ce cas, un profil spécial sera également créé qui se connectera à la technologie « Agents » dans 1C-Bitrix, et le téléchargement aura lieu automatiquement une fois par jour.

Un agent est une fonction PHP qui s'exécute à une certaine fréquence. Au début de chaque chargement de page, le système vérifie automatiquement s'il y a un agent qui doit être lancé et, si nécessaire, l'exécute. Il n'est pas recommandé de créer des agents pour des téléchargements fastidieux - il est préférable d'utiliser cron.

Cette option est préférable si le répertoire contient moins de 10 000 produits, le téléchargement se produit assez rapidement, et cela n'affectera en rien la vitesse du site Web de la boutique en ligne.

Dans le cas d'une large plage ( plus de 10 000 produits), est nécessaire personnalisation supplémentaire Agent sur Cron. Pour cet élément, vous devez également préciser le nom du profil d'exportation spécial.

4. Indication de déchargement instantané

Suite à la définition de l'indicateur « Décharger maintenant », la structure des répertoires sera déchargée dans le fichier ci-dessus, immédiatement après l'installation du module.

Après avoir téléchargé le catalogue dans un fichier du système, vous devez accéder à l'onglet Administration -> Magasin -> Nom du magasin -> "Catalogue" et cocher la case "Télécharger le catalogue depuis ICML maintenant". Dans ce cas, le téléchargement du fichier et son traitement commencent presque instantanément.

5. Spécification d'un nom de profil

Après avoir correctement configuré le téléchargement du catalogue de produits, un nouveau type d'exportation système apparaîtra dans la section Store > Paramètres > Exportation de données ; si un téléchargement périodique est spécifié lors de l'installation, un profil d'exportation apparaîtra également.

Note:
Pour auto-configuration Lors du téléchargement, il est possible de créer votre propre profil d'exportation.

Fin de l'assistant d'installation

A la fin de l'installation, 2 agents seront créés : un agent télécharge l'historique des commandes de Bitrix vers le système, le deuxième agent génère un catalogue. Si le téléchargement des commandes est configuré pour un agent, les commandes sont téléchargées sur le système au moment où l'historique est appelé. Dans d'autres cas, les commandes sont déchargées en fonction d'un événement.

Déchargement du service de livraison lors de l'échange 1C-Bitrix - système

Si vous disposez de services de livraison automatisés connectés à 1C-Bitrix, tels que eDost, qui ont de nombreux profils : Poste russe, EMS, DHL et bien d'autres, alors dans le système, vous pouvez profiter de la possibilité de télécharger ce type de service de livraison.

Les méthodes de livraison doivent être configurées côté système. Si le module système a été installé avant de connecter le service de livraison à Bitrix, les méthodes de livraison manquantes devront être saisies manuellement dans le système. Si le module a été installé après avoir connecté le service de livraison, alors les modes de livraison seront installés automatiquement, ainsi que le service se déchargeant. Autrement dit, pour chaque commande, les frais de livraison seront téléchargés.

Côté 1C-Bitrix, vous devez effectuer les paramétrages suivants si le module système a été installé après avoir connecté le service de livraison au système 1C-Bitrix :

Aller à Administration > Paramètres, allez dans l'onglet "Paramètres du répertoire".

Configurer la correspondance des modes de livraison (préconfigurés côté système). Ensuite, cliquez sur le bouton « Télécharger les services de livraison ».

Configuration de la fréquence de téléchargement 1C-Bitrix - système

Lors de la mise à jour du catalogue produits, deux points peuvent être soulignés :

Génération de catalogue (au format yml/icml) côté client et

Le système télécharge le catalogue toutes les trois heures. Le chemin d'accès au fichier à télécharger est défini dans les paramètres du magasin - vous devez accéder à la section Administration > Boutiques > Sélectionner une boutique > Onglet Catalogue.

Après avoir installé le module système dans 1C-Bitrix, un profil de téléchargement est créé. Pour voir, il faut aller sur Bureau > Store > Paramètres > Exportation de données. La capture d'écran montre deux options :

Défaut,

Téléchargement du répertoire système.

Si vous sélectionnez la deuxième option, cliquer dessus ouvrira les options de téléchargement.

Si Agent est sélectionné comme option de fréquence, pour afficher la liste des agents, vous devez accéder à Bureau > Paramètres > Paramètres du produit > Agents.

Si vous cliquez sur « Modifier » ou « Ajouter nouveau », vous pouvez attribuer ou modifier la fréquence d'exécution de la tâche de génération.

Fréquence de synchronisation des données lors de l'échange 1C-Bitrix - système

Le module système vous permet de télécharger un catalogue de produits sur votre système, ainsi que d'effectuer un échange bidirectionnel régulier de commandes et de clients.

En téléchargeant en temps opportun les données du catalogue, vos responsables système disposeront d'informations à jour sur la disponibilité des produits. Une situation dans laquelle un produit est commandé et, après un certain temps, il s'avère qu'il est en rupture de stock, ne se produira pas.

L'échange de commandes est un processus de synchronisation des données lorsque les commandes sont téléchargées dans les deux sens :

De 1C-Bitrix au système :

  • Si le téléchargement basé sur les événements est activé, lorsqu'une commande est créée ou modifiée dans le système 1C-Bitrix, elle sera immédiatement téléchargée sur le système. Si un agent de déchargement est sélectionné, la commande sera téléchargée dans le système dans un délai de 15 minutes (il n'est pas recommandé d'utiliser ce mécanisme sans raisons impérieuses, car dans ce cas les commandes arriveront avec du retard et les mises à jour de ces commandes ne seront pas transférées au système).
  • Lorsqu'un utilisateur change, les données de base seront également immédiatement téléchargées dans le système.

Du système à 1C-Bitrix :

  • Si vous créez une commande dans le système pour un nouvel utilisateur, la commande sera téléchargée sur 1C-Bitrix et créée Nouvel utilisateur dans la plage de 1 à 15 minutes.
  • Si vous modifiez l'adresse, les frais de livraison ou le statut dans le système sur la page de commande, toutes ces modifications seront téléchargées sur 1C-Bitrix dans les 15 minutes.
  • Si vous modifiez les remises sur les produits dans le système et modifiez la quantité de produits, cela changera dans 1C-Bitrix dans un intervalle de 1 à 15 minutes.

Changements dans le module d'intégration

Version 2.0

  • Le module d'intégration version V2.0 est conçu pour intégrer 1C-Bitrix avec la version du module « Boutique en ligne (vente) » > 16 qui y est installé.
  • Désormais, le module fonctionne via l'API V4.
  • Le module d'intégration utilise désormais le nouveau noyau 1C-Bitrix D7.
  • Désormais, les modifications concernant le client (nom complet, e-mail, téléphone) sont également envoyées au site Web depuis le système.
  • Dans les paramètres du module d'intégration dans la section « Autres paramètres », il est devenu possible de traduire les numéros de commande du système vers 1C-Bitrix. Autrement dit, si vous créez manuellement une commande dans le système avec le numéro, par exemple 12345R, une commande avec le même numéro sera créée dans 1C-Bitrix.
  • Étant donné que dans la version > 16 du module "Boutique en ligne (vente)", les développeurs de Bitrix ont abandonné l'application de remises sur l'ensemble de la commande et ont laissé les remises uniquement sur les produits, le système, pour l'instant, n'a pas non plus la possibilité d'utiliser des remises sur le commande entière. Vous pouvez définir des remises uniquement pour des articles de commande spécifiques.

Version 2.1

  • Ajout d'unités de mesure dans l'export du catalogue.

Version 2.2

  • Le module prend désormais en charge plusieurs versions d'API avec un choix.
  • Prise en charge de l'API V5.
  • Ajout de la possibilité de décharger les soldes par entrepôt.
  • Ajout de la possibilité de télécharger les types de prix.
  • Ajout de l'intégration de base de Daemon Collector.
  • Ajout de l'intégration avec Universal Analytics.
  • La logique des fonctions intégrées de modification des données a été améliorée.
  • Ajout de la fonction intégrée retailCrmApiResult.
  • Ajout d'une version de déclenchement de l'historique des modifications.

Version 2.4

  • Ajout d'un chèque dans le processeur pour enregistrer le paiement d'une nouvelle commande.
  • Ajout d'un paramètre pour le nombre d'offres commerciales à l'export.
  • Conversion du prix d'achat ajoutée.
  • Modification des fichiers de traduction.
  • Ajout d'une vérification lors du déchargement des modifications du système pour les propriétés de la commande.
  • Ajout du téléchargement de la TVA.
  • Correction de l'obtention d'une liste de types de prix à télécharger. Tous les types disponibles dans Bitrix sont disponibles pour la sélection.

Autres réglages

Paramètres de commande

Transmettre les numéros de commande créés dans le centre de traitement central au magasin

Lorsqu'une commande est créée dans le système, elle génère son propre numéro unique selon les règles spécifiées. Lorsque ce paramètre est défini dans le module, le numéro d'une telle commande sera transmis au magasin lors de la synchronisation inverse.

Déchargement des commandes

  • Par événement- lorsque vous enregistrez la commande, les données sont introduites dans le système ;
  • Agent- les nouvelles commandes sont envoyées avant de demander l'historique des modifications au système.

Version de l'API cliente

Vous pouvez maintenant sélectionner la version de l'API avec laquelle le module fonctionnera. Le choix dépend de la version du système. Il est recommandé de sélectionner la dernière version.

Activer le déchargement des soldes par entrepôt (disponible si des entrepôts existent)

Vous pouvez désormais décharger périodiquement les soldes des entrepôts du site vers les entrepôts système. Pour ce faire, vous avez besoin de :

  • comparer les entrepôts du site avec les entrepôts du système ;
  • indiquer les magasins du système dans lesquels les soldes seront chargés ;
  • sélectionnez les blocs d'informations avec les marchandises nécessaires au chargement des soldes (vous devez sélectionner celles qui sont indiquées dans l'exportation du catalogue du système).

La mise en ligne est effectuée par l'agent avec une fréquence de 1 heure (par défaut).

Veuillez noter que pour charger les soldes dans le système, les options doivent être activées.

Activer le téléchargement des types de prix pour les produits (disponible uniquement s'il existe plusieurs types de prix)

Vous pouvez désormais télécharger périodiquement des types de prix supplémentaires du magasin vers le système. Pour ce faire, vous avez besoin de :

  • comparer les types de prix du site avec les types de prix du système ;
  • indiquer les magasins du système dans lesquels des types de prix supplémentaires seront chargés ;
  • sélectionnez les blocs d'informations avec les produits qui nécessitent le chargement de types de prix supplémentaires (vous devez sélectionner ceux qui sont spécifiés dans l'exportation du catalogue pour le système).

La mise en ligne est effectuée par l'agent toutes les 24 heures (par défaut).

Activer le collecteur de démons

Vous pouvez maintenant ajouter le démon collecteur au site Web à partir de l'interface des paramètres. Pour ce faire, vous devez spécifier la clé appropriée pour le site souhaité. La clé peut être trouvée dans le système.

Activer l'intégration UA

Vous pouvez désormais activer l'intégration avec Universal Analytics à partir de l'interface des paramètres (fonctionne correctement avec le composant de commande standard). Pour chaque site auquel vous souhaitez ajouter un suivi, vous devez renseigner l'ID de suivi et l'index des paramètres personnalisés.

Où $order est le tableau généré des données de commande à envoyer au système et $arFields est un tableau de champs de commande sur le site Web. function retailCrmBeforeOrderSave($order) ( //Vos modifications renvoient $order; //ou renvoie false; puis les modifications du système pour cette commande seront ignorées)

Où $order est un tableau avec les données de commande modifiées reçues du système.

fonction retailCrmAfterOrderSave

retailCrmAfterOrderSave - une fonction exécutée immédiatement après l'enregistrement sur le site Web des modifications apportées aux données de commande reçues de l'historique du système.

function retailCrmAfterOrderSave($order) ( //Vos modifications reviennent ; )

Où $order est un tableau avec les données de commande modifiées reçues du système.

Fonction retailCrmApiResult

retailCrmApiResult - une fonction exécutée immédiatement après avoir reçu une réponse de l'API système.

function retailCrmApiResult($methodApi, $res, $code) ( //Vos modifications renvoient ; )

Où $methodApi est le nom de la méthode API, $res est le résultat de la requête vrai/faux (demande réussie ou non), $code est le code d'état de la réponse de l'API.

Veuillez noter que des erreurs dans le code lors de l'utilisation de cette fonction peuvent perturber la synchronisation du site et du système.

Si les outils listés ci-dessus ne suffisent pas pour une raison quelconque, vous pouvez apporter les modifications requises directement au code du module sans risquer de perdre ces modifications lors de la mise à jour du module. Pour ce faire, vous devez copier le fichier avec la classe requise dans le répertoire /bitrix/php_interface/retailcrm/ et y apporter des modifications. Ce mécanisme prend en charge le changement de classe pour travailler avec les clients, les commandes, les événements, l'exportation de catalogue et d'autres mécanismes auxiliaires.


Signet Tâches personnalisées est destiné à ceux qui travailleront directement avec le produit, c'est-à-dire aux employés des entreprises utilisant notre logiciel.

L'onglet Tâches administratives est destiné à ceux qui administreront la version boîte. "Bitrix24".

Signet Documentation destiné aux développeurs de projets basés sur la version boîte "Bitrix24".

Tâches personnalisées

Tâches administratives

Pour les développeurs

La documentation du développeur est une description de l'API du système. La documentation utilisateur est une description des composants et des paramètres du système.

La documentation est disponible en ligne et sous forme de fichier au format chm. Il est recommandé d'utiliser la version en ligne car elle est plus à jour. Les fichiers chm sont mis à jour périodiquement et peuvent ne pas contenir d'informations sur les dernières versions.

Attention! Si vous ne voyez pas le contenu du fichier de format .chm, alors la raison est les paramètres de sécurité système opérateur. Dans les propriétés du fichier, vous devez débloquer la visualisation du fichier. Lire la suite dansFAQ

La documentation est une information de référence. Il ne suffit pas qu'un développeur novice travaille avec le système. En maîtrisant les principes de la programmation en Cadre Bitrix Un cours spécial vous aidera à :

Il n'y a pas si longtemps, notre société a reçu une assez grande boutique en ligne sur 1C-Bitrix pour la maintenance et la modification. Le projet a été mis en exploitation commerciale il y a quelques mois, mais il a en même temps rencontré un certain nombre de problèmes sérieux. De plus, le client prévoyait de terminer les tâches de finalisation de la nouvelle fonctionnalité le plus rapidement possible. On m'a confié la tâche d'organiser travail efficace selon le projet avec un temps d'arrêt minimal du site et une satisfaction maximale des besoins du client.

Donnée initiale:

  • Il y a une boutique en ligne sur 1C-Bitrix
  • Le projet a plusieurs années, mais il y a seulement quelques mois le site a été transféré vers 1C-Bitrix
  • Participation 10 à 15 000 personnes par jour
  • Le catalogue du magasin contient environ 12 000 articles
  • Les temps d'arrêt et les pannes de site sont inacceptables
  • Le projet a été développé par une autre entreprise en six mois :
    1. Il existe un cahier des charges technique pour environ 100 fiches, correspondant à environ 40 % des travaux réalisés.
    2. Aucune documentation du projet
    3. Manque de compréhension des raisons pour lesquelles les développeurs précédents ont utilisé des solutions architecturales spécifiques.

Développement logiciel En général, et sur des projets web en particulier, je travaille sur des projets web depuis environ 8 ans. Durant cette période, je suis tombé sur des projets de complexité variable et, à première vue, la tâche ne me paraissait pas trop difficile. Lors de la mise en œuvre de projets dans notre entreprise, la méthodologie SCRUM est généralement utilisée. J'ai commencé à m'éloigner d'elle.

Tout d'abord, j'ai eu accès code source projet. Analysé superficiellement. Convenu avec le client sur la liste des tâches prioritaires. J'ai fait un plan de développement pour 3 développeurs et, comme disait Gagarine, c'est parti !

Problème n°1 – les développeurs sont responsables de tout

Comme c’est souvent le cas, tout le monde est responsable, sauf le client. Le concepteur a fait une mise en page qui pèse trop, l'hébergeur a fourni un serveur qui fonctionne lentement, les développeurs ont fait un site Web qui est tout le temps bogué et en panne, les gestionnaires ont effectué certaines tâches que nous n'avions pas demandées après le passage de ancienne version site sur 1C-Bitrix, il y a eu une forte diminution du trafic de recherche, etc. La situation n’est pas claire. D’une part, la responsabilité principale devrait bien entendu incomber à la société de développement. Il fallait transmettre au client les conséquences de toutes les actions avec le chantier et préparer le résultat. Lors de la réalisation des travaux, proposer une architecture holistique futur système et un plan de développement à suivre jusqu'à ce que les étapes soient franchies. Effectuez des tests approfondis de la fonctionnalité et soumettez le travail. D'un autre côté, je suis souvent confronté à une situation où le client sait tout mieux lui-même, car sa mère a déjà peint et est donc meilleur designer, et son fils de 7 ans connaît bien l'optimisation SEO, car il passe tout son temps sur l'ordinateur à jouer à GTA.

Il ne nous appartient pas de juger qui est coupable et qui a raison. Dans ce cas, l’entrepreneur précédent était une entreprise assez connue et fiable et je ne peux rien dire de négatif sur son développement. Et le client, objectivement, se soucie de son produit et essaie de l'améliorer. Je ne sais pas comment cela s'est produit, j'ai moi-même trouvé une explication dans la quantité insuffisante d'analyses fournies par l'entrepreneur au client.

Par conséquent:

  • Le projet n’a pas été mené à sa conclusion logique. De nombreuses tâches sont abandonnées à mi-chemin
  • Le projet n'est pas documenté. Le fonctionnement de certaines fonctionnalités n’est pas évident. Lors du développement d'une nouvelle fonctionnalité, il s'avère que la fonctionnalité qui fonctionnait auparavant et dont le nouveau développeur ne soupçonnait pas l'existence a cessé de fonctionner.
  • Une partie du code écrit par l'interprète précédent doit être réécrite à partir de zéro
  • L'architecture prévue du projet n'est pas claire pour le nouvel entrepreneur au cours des premières semaines/mois de travail. L'amélioration de la fonctionnalité d'un module entraîne la perte de fonctionnalité d'un module qui n'y est en aucun cas lié.
  • Le client est nerveux, l'artiste est nerveux, les visiteurs ne sont pas contents, la fréquentation diminue, les ventes chutent

Je ne vois qu'une seule solution au problème : nettoyer progressivement et systématiquement tous les modules du site un par un pour amener le produit à l'état souhaité. Certaines erreurs ont été incluses dans des tâches distinctes et complétées immédiatement ; d'autres ont été corrigées parallèlement au développement de nouvelles fonctionnalités. Le résultat est qu’à chaque mise à jour, après avoir rapidement éliminé les bugs, le site devient meilleur et plus stable.

Problème n°2 – développement parallèle.

Conformément à la politique de licence 1C-Bitrix, chaque licence de site Web vous permet d'utiliser 2 copies du système. L'un comme site de production, le second comme site de développement. Le problème est que le développement est effectué en permanence par plusieurs développeurs, dans mon cas trois. Dans le cas du développement classique, tout est simple. Chaque développeur travaille sur son propre module. Ensuite, des tests fonctionnels de chaque module sont effectués, toutes les améliorations sont fusionnées dans le référentiel d'un système de contrôle de version, puis tout est testé ensemble (test d'intégration). Si le résultat est normal, la version test est présentée au client. Une fois la version test acceptée, le serveur de production est mis à jour. Conformément à la méthodologie SCRUM, j'ai déterminé que je mettrais en ligne les nouvelles versions sur le site de production une fois par semaine. En conséquence, il y a 3 à 4 jours pour le développement de base. 1 journée pour les tests et corrections de bugs et une demi-journée pour la mise à jour du serveur de production. Les délais, bien sûr, fluctuent, mais j'ai essayé de respecter strictement la règle « sortie tous les jeudis ».

La première chose que j'ai remarquée, c'est que dans 1C-Bitrix, il existe des situations dans lesquelles le même fichier est utilisé simultanément dans différentes fonctionnalités à différentes extrémités du site. La solution la plus simple et la plus évidente consiste à utiliser un système de contrôle de version, dans mon cas, SVN, que j'utilise dans tous les autres projets. Mais pour utiliser le contrôle de version, il faut que chaque développeur dispose de sa propre version du code, qu'il édite puis fusionne dans le référentiel commun.

Et le permis ? Contacté soutien technique 1C-Bitrix. J'ai reçu une offre d'achat supplémentaire. licences de développement. Pour le moins, je n’étais pas content, mais je n’ai reçu aucune autre offre. J'ai trouvé une solution assez rapidement. J'ai décidé d'utiliser des clés NFR. Heureusement, le statut de partenaire le permet. En conséquence, j'ai créé 5 installations de boutique en ligne :

  • Serveur de production
  • Serveur de tests
  • 3 serveurs de développement (un par développeur)

Au fil du temps, je suis allé encore plus loin. Il existe également une installation séparée pour le testeur. Il s'est avéré qu'avec ma chance, le client se connecte toujours au serveur de test au moment où quelque chose y est mis à jour. La piste de bugs contient de nombreuses tâches inutiles déjà terminées, et le client a l'impression que nous faisons mal notre travail.

Actuellement, j'utilise le schéma suivant :

  • Chaque développeur utilise uniquement sa copie locale pour son travail
  • Au moment convenu, toutes les améliorations réalisées sont fusionnées dans une branche commune du référentiel
  • Le contrôle qualité prend la version fusionnée pour les tests
  • Après avoir testé et corrigé les erreurs, le serveur de démonstration est mis à jour pour le client
  • Après vérification et acceptation par le client, les améliorations sont transférées sur le serveur de production.

Parmi les inconvénients évidents de cette approche, je voudrais souligner le faible niveau d'implication du client dans le développement. Le résultat n'est visible par le client qu'au stade final. Cette approche est applicable si vous disposez d'un bon analyste qui commet rarement des erreurs et est en contact permanent avec le client. Sinon, de nombreuses tâches devront être refaites à partir de zéro.

Alors que je construisais le circuit, j'ai rencontré un autre problème. Le projet occupe environ 80 Go d'espace disque. Sans cache ni fichiers temporaires - environ 60. Au début, j'ai essayé de supprimer les images et les vidéos du contrôle de version - cela n'a pas fonctionné. Les informations sur le site changent constamment. Vous devez tester en utilisant les données actuelles. La première validation du site dans le référentiel m'a pris plus de 2 jours en morceaux. La première extraction vers le dossier de développement prend plusieurs heures (serveur SVN en réseau local développement). Si, à Dieu ne plaise, vous effectuez accidentellement une mise à jour complète du dossier du projet, vous pouvez partir fumer, déjeuner, jouer au ping-pong ou au curling. La validation uniquement des fichiers ou dossiers sélectionnés est assez rapide. Solution : J'ai terminé la tâche de téléchargement d'une douzaine de fichiers modifiés à la fois.

Problème n°3 – mise à jour du serveur de production et collaboration avec le client

Le problème est le plus important, le plus complexe et non entièrement résolu. Après tout, si d'autres problèmes concernent le travail interne du projet, alors la réputation et les revenus du client, et, par conséquent, mes revenus, dépendent du travail du site.

Les lois de Murphy fonctionnent très bien ici :

  • Si quelque chose ne fonctionne pas bien sur le serveur de test, cela tombera définitivement en panne sur le serveur de production.
  • Si quelque chose fonctionne parfaitement sur le serveur de test, cela échouera toujours sur le serveur de production.
  • Si un bug sur le site n'existe que pendant 5 secondes, l'un des visiteurs le trouvera certainement et en parlera certainement dans les avis ou dans le formulaire de commentaires.
  • Si le site ne fonctionne pas pendant 1 minute lors d'une mise à jour, c'est à ce moment-là que le propriétaire de l'entreprise le montrera à son ami ou concurrent (et ce malgré l'accord sur le moment et la procédure de mise à jour).
Bien sûr, j’exagère, mais chaque blague comporte une part d’humour. La charge minimale sur le site est de 4h à 6h. Bien sûr, il serait préférable de mettre à jour à ce moment-là, mais je n’en ai vraiment pas envie.

Dans le cas de la plupart des applications Web, il existe une structure claire pour diviser l'application en couches et la mise à jour du site peut être divisée en 2 parties :

  • Mise à jour des codes
  • Mise à jour de la base de données à l'aide de scripts SQL

Dans le cas de 1C-Bitrix, tout est un peu plus compliqué. Premièrement, il y a beaucoup de fichiers. J'en ai plus d'un million dans mon projet. Une mise à jour typique à partir du référentiel ne prend pas moins de 20 à 30 minutes. Vous pouvez, bien sûr, mettre à jour uniquement les fichiers modifiés, mais alors tout l'intérêt du référentiel est perdu. Deuxièmement, et c'est beaucoup plus triste, souvent lors de la mise à jour, vous devez effectuer des modifications et des paramètres manuels via le panneau d'administration. Et cela est toujours lent, vous devez vous rappeler tous les changements qui doivent être effectués, il y a une forte probabilité de commettre une erreur accidentellement. Vous pouvez bien entendu écrire un script SQL qui apportera toutes les modifications nécessaires à la base de données. Bien entendu, dans les cas les plus simples, c’est exactement ce que nous faisons. Mais dans la plupart des cas, l'écriture et le débogage d'un tel script prennent plus de temps que le développement lui-même et beaucoup plus de temps que l'exécution manuelle de toutes les actions avec des tests ultérieurs.

Je n'ai pas encore trouvé de bonne solution au problème. Nous mettons maintenant à jour manuellement les paramètres de la base de données. Pour minimiser les erreurs, une liste de contrôle est compilée avec une liste de ce qui doit être fait lors de la mise à jour. Nous essayons d'effectuer la mise à jour avec le plus grand soin et la plus grande précision possible. Après la mise à jour, toute l'équipe vérifie les principales fonctionnalités du serveur de production et effectue des tests supplémentaires. Le nombre d'erreurs a été minimisé, mais il n'a pas encore été possible d'éliminer complètement les bugs et les temps d'arrêt lors de la mise à jour.

La deuxième chose que j'ai rencontrée est collaboration avec le client. Parce que Le projet est vaste, une trentaine de personnes y travaillent en permanence. Gestionnaires de contenu, directeurs commerciaux, optimiseurs de référencement, spécialistes du marketing et bien d'autres. Naturellement, chacun apporte des modifications aux pages du site et aux paramètres des modules. La première décision a été de retirer au client le droit de modifier le code du programme du site. La décision était tout à fait correcte, mais elle n’a fait qu’empirer. Si auparavant le client supposait qu'il pouvait également se rendre sur le site et casser accidentellement quelque chose, tous les problèmes commençaient désormais à incomber uniquement à nous. Qu'est-ce que cela a à voir avec ça. Même si le gestionnaire de contenu a modifié le texte de la page de manière tordue et n'a pas fermé certaines balises, le développeur est toujours à blâmer. La solution s’est avérée assez simple. La place de marché dispose d'un module gratuit pour le contrôle de version des pages. Cela n’a pas résolu le problème, quelqu’un va encore gâcher quelque chose de temps en temps, mais il est désormais possible de voir à tout moment qui a changé ce qu’il a changé et pourquoi tout s’est cassé. Le résultat, bien sûr, n'est pas de la glace, mais cela m'épargne beaucoup de nerfs.

De plus, nous avons décidé qu'avant chaque mise à jour du serveur de test, nous y apporterions une copie du serveur de production. Cela prend également beaucoup de temps. Archivez le projet, transférez-le sur un autre serveur, décompressez-le. Tout cela prend plusieurs heures. Mais les nouvelles améliorations sont testées pratiquement dans des conditions de combat. Si les paramètres des serveurs de test et de production sont identiques, la différence de fonctionnement sera minime et le nombre d'erreurs sera considérablement réduit. L'expérience a montré qu'en une semaine, le serveur de production peut tellement changer que certaines des nouvelles fonctionnalités qui fonctionnent sans problème sur une copie vieille d'une semaine peuvent ne pas fonctionner du tout sur une nouvelle copie.

Problème n°4 – « faites-le pour moi de toute urgence, c'est une tâche de 5 minutes »

Le problème ne concerne pas tant 1C-Bitrix, mais le raffinement et le support des projets de travail. Souvent, le client a envie de faire une petite chose, mais de toute urgence et immédiatement sur le site de production. Le résultat est toujours le même : rien de bon n’en sort. Dans le meilleur des cas, cette modification sera simplement oubliée lors de la prochaine version ; dans le pire des cas, le serveur plantera simplement et devra être restauré à partir d'une sauvegarde pendant plusieurs heures.

Je n’ai trouvé qu’une seule solution : ne jamais suivre l’exemple du client au détriment de la fiabilité et de la sécurité. Quelle que soit la demande du client, le développeur sera toujours à blâmer. Comme me l’a dit mon ancien patron : « Je ne vous ai pas demandé de faire quelque chose de mal. »

Et puisque nous avons abordé le sujet des sauvegardes, je tiens à le noter. La sauvegarde à l'aide de 1C-Bitrick est bien sûr bonne et pratique, mais très lente. Si vous avez un besoin urgent de restaurer 1 à 2 fichiers ou plusieurs valeurs dans la base de données, vous devez attendre que les 60 Go soient décompressés. Le schéma suivant me semble le plus efficace :

  • Il devrait y avoir une sauvegarde quotidienne des fichiers et des bases de données sous la forme d'une archive sur source externe données.
  • Nous effectuons toujours une sauvegarde immédiatement avant la mise à jour dans l'une des 2 options suivantes :
    1. Option légère – Copiez l'intégralité du dossier du projet dans un dossier adjacent sur le serveur. Nous enregistrons la base de données sous forme de dump dans un fichier séparé. Nous n'archivons rien. Au cas où vous auriez besoin de restaurer une valeur dans la base de données ou dans l'un des fichiers, tout sera à portée de main et facilement accessible
    2. Option forte - similaire à la précédente, seulement nous copions la base de données vers une autre base de données Données MySQL. Cela permettra, en cas de crash complet, de corriger le dossier racine du site dans le fichier hosts en 1 à 2 minutes, et le projet commencera à fonctionner à partir d'un dossier voisin avec une copie de la base de données.

Conclusion

Merci à tous ceux qui ont lu jusqu'au bout. J'espère que mon expérience vous sera utile. Je serai heureux de recevoir des suggestions sur de meilleures façons de résoudre les problèmes soulevés dans les commentaires ou dans un message personnel. J'ai maintenant essayé d'exprimer les principaux problèmes liés à la finalisation et au soutien de projets déjà lancés avec des exigences de fiabilité élevées. Si le matériel s'avère intéressant, je prévois d'écrire une suite sur les fonctionnalités de l'architecture 1C-Bitrix qui distinguent le développement d'un site sur Bitrix du développement d'autres projets Web.

Informations sur le travail avec peuvent être trouvés dans les tutoriels et la documentation. Les formations sont conçues pour maîtriser les méthodes de travail dans produit logiciel, et documentation - pour maîtriser les principes de personnalisation du CMS.

Lorsque vous travaillez avec "1C-Bitrix : Gestion de site" les problèmes se posent sous la forme de problèmes pratiques spécifiques. Nous avons rassemblé dans des sujets spécialisés différentes pages des formations pour vous permettre de trouver plus facilement des réponses à vos questions.



Centres de formation Poser une question Forum



Signet Gestionnaires de contenu est destiné à ceux qui travailleront directement avec le produit, c'est-à-dire aux gestionnaires de contenu dirigeant des projets créés sur notre produit logiciel.

Signet Administrateurs destiné à ceux qui administreront "1C-Bitrix : Gestion de site".

Signet Pour les développeurs conçu pour les développeurs de projets basés sur "1C-Bitrix : Gestion de site".

Gestionnaires de contenu

Vous pouvez importer le cours sur votre site Web Gestionnaire de contenu de ces archives. Cours sans questions pour les tests.
Version du cours datée du 5 juin 2015.

Administrateurs

Pour les développeurs

La documentation du développeur est une description de l'API du système. La documentation utilisateur est une description des composants et des paramètres du système.

La documentation est disponible en ligne et sous forme de fichier au format chm. Il est recommandé d'utiliser la version en ligne car elle est plus à jour. Les fichiers au format chm sont mis à jour périodiquement et peuvent ne pas contenir d'informations sur derniers changements dans le système d'aide.

Attention! Si vous ne voyez pas le contenu du fichier de format .chm, la raison en est les paramètres de sécurité du système d'exploitation. Dans les propriétés du fichier, vous devez débloquer la visualisation du fichier. Lire la suite dansFAQ

La documentation est une information de référence. Il ne suffit pas qu'un développeur novice travaille avec le système. En maîtrisant les principes de la programmation en Cadre Bitrix Un cours spécial vous aidera à :


Haut