Axelor couvre des processus transverses (CRM, ventes, achats, finance, stock, workflow), ce qui en fait une très bonne base ERP mais aussi un terrain d’intégration exigeant. Les flux deviennent vite interdépendants, et les connecteurs “ad hoc” créent de la dette opérationnelle.
Notre SDK Axelor sous Symfony a été conçu pour standardiser auth, mapping, gestion des erreurs, résilience et observabilité. L’objectif est d’éviter les implémentations dispersées et d’assurer une qualité constante d’un projet à l’autre.
Vue globale: Intégration API.
Les APIs Axelor sont flexibles, mais la difficulté réelle se situe dans la cohérence métier entre modules. Les règles de validation, les états documentaires et les dépendances référentielles doivent être explicités avant de pousser des flux en production.
Les points sensibles incluent généralement: cohérence clients/tiers, taxes et arrondis, transitions d’état, et synchronisation des écritures liées aux opérations commerciales.
En pratique, la densité fonctionnelle d’Axelor impose de traiter les flux comme des transactions métier complètes: un simple changement de statut commercial peut impacter le stock, la facturation et la comptabilité analytique. Le SDK doit donc embarquer une lecture claire des dépendances inter-modules, et pas seulement exposer des wrappers HTTP.
Nous formalisons systématiquement les préconditions/postconditions de chaque opération: document source requis, statut attendu, droits applicatifs, données minimales, et effets de bord potentiels. Cette formalisation réduit fortement les incidents de type “payload valide mais comportement métier inattendu”.
En complément, nous séparons clairement ce qui relève du contrat API (champs obligatoires, types, cardinalité, statuts autorisés) de ce qui relève de conventions d’implémentation (naming interne, mapping d’énumérations, règles de retry). Cette séparation évite de figer des choix techniques côté client là où seule la sémantique métier doit rester stable.
Le SDK est structuré en couches: `AxelorAuthProvider`, `AxelorHttpClient`, `AxelorDomainAdapters`, `AxelorErrorMapper`, `AxelorTelemetry`. Symfony fournit le cadre pour DI, configuration par environnement et policies transverses.
Les adapters sont orientés domaines: `CustomerAdapter`, `ProductAdapter`, `SalesAdapter`, `PurchaseAdapter`, `InvoiceAdapter`, `AccountingAdapter`, `StockAdapter`. Cette découpe réduit les régressions quand un endpoint évolue.
Côté implémentation Symfony, nous utilisons des policies explicites par type de flux (lecture lourde, écriture sensible, action de transition), avec timeout/réessais dédiés. Cela évite une configuration unique trop grossière qui ne respecte pas les exigences différentes des opérations Axelor.
final class AxelorSalesAdapter
{
public function __construct(
private AxelorHttpClient $client,
private AxelorErrorMapper $errors
) {}
public function createOrder(array $payload, string $idempotencyKey): array
{
return $this->client->post(
'/api/sales-order',
$payload,
headers: ['X-Idempotency-Key' => $idempotencyKey]
);
}
}Le point important ici n’est pas la syntaxe, mais le contrat: chaque écriture sensible est appelée via une API dédiée, avec clé d’idempotence et mapping d’erreurs métier centralisé.
# Extrait de configuration par politique de flux (illustratif)
axelor_sdk:
http:
base_uri: '%env(AXELOR_API_BASE_URI)%'
timeout:
read_seconds: 10
write_seconds: 20
retries:
read_max: 2
write_max: 1
backoff_ms: [200, 700]
circuit_breaker:
failure_threshold: 5
open_seconds: 30Ces réglages sont volontairement distincts entre lecture et écriture. En ERP, un retry mal calibré sur une écriture peut provoquer des doublons coûteux; l’approche la plus sûre reste idempotence + validation post-write.
Exemples illustratifs, à adapter au modèle Axelor du projet.
Les payloads ci-dessous sont illustratifs et servent à montrer une approche d’industrialisation. Le contractuel se définit toujours à partir de l’instance Axelor ciblée, de ses modules activés et des personnalisations (champs, workflows, règles de validation).
{
"externalId": "CLI-003219",
"name": "ACME Services",
"email": "compta@acme.fr",
"phone": "+33 1 53 40 20 10",
"address": {
"line1": "40 rue des Ateliers",
"zipCode": "75012",
"city": "Paris",
"country": "FR"
},
"vatNumber": "FR88123456789"
}POST /api/partners/upsert HTTP/1.1
Host: [AXELOR_HOST]
Authorization: Bearer [ACCESS_TOKEN]
Content-Type: application/json
X-Correlation-Id: b5fd7f2d-59df-4696-8cd8-c833ea54e4fd
X-Idempotency-Key: 6e5d7e7e-5cc8-4a7d-a64d-7e11ff78f3c2Point de vigilance: le couple `externalId + société` doit être unique. Sans cette contrainte, les moteurs de synchronisation multi-entités créent facilement des doublons “silencieux”.
{
"orderNumber": "WEB-2026-005010",
"customerExternalId": "CLI-003219",
"orderDate": "2026-02-19",
"currency": "EUR",
"lines": [
{"sku": "SKU-12001", "qty": 5, "unitPriceExclTax": 29.90, "taxCode": "TVA20"}
]
}{
"status": "CREATED",
"erpDocumentId": "SO-2026-000451",
"correlationId": "b5fd7f2d-59df-4696-8cd8-c833ea54e4fd",
"warnings": []
}En production, nous imposons une vérification immédiate des arrondis HT/TTC après création. Les divergences de quelques centimes, non traitées en amont, génèrent ensuite des écarts de lettrage en comptabilité.
{
"invoiceNumber": "FAC-2026-001320",
"sourceOrder": "WEB-2026-005010",
"invoiceDate": "2026-02-19",
"lines": [
{"sku": "SKU-12001", "qty": 5, "unitPriceExclTax": 29.90, "taxCode": "TVA20"}
]
}Après écriture, le SDK relit systématiquement statut, totaux et références internes pour garantir la cohérence.
Nous vérifions aussi les dimensions financières attendues (centre, axe analytique, journal), car ce sont souvent ces champs qui génèrent des rejets tardifs en clôture si la validation est trop permissive.
public function assertInvoiceConsistency(array $invoice): void
{
Assertion::keyExists($invoice, 'invoiceNumber');
Assertion::keyExists($invoice, 'totalExclTax');
Assertion::keyExists($invoice, 'totalInclTax');
Assertion::greaterOrEqualThan($invoice['totalInclTax'], $invoice['totalExclTax']);
// Vérifie présence des dimensions comptables attendues
Assertion::keyExists($invoice, 'ledger');
Assertion::keyExists($invoice, 'analyticAxis');
}Séquence type: validation payload, upsert référentiels, création documentaire, propagation des statuts, génération des écritures associées, relecture de contrôle avant ack final.
Les étapes sont rejouables indépendamment pour éviter les duplications lors d’un incident partiel.
Sur les environnements multi-sociétés, nous isolons les files de traitement par contexte société/devises pour empêcher les contaminations de flux. Cette règle simple évite des incidents très coûteux de routage documentaire inter-entités.
Queue naming recommandée:
- erp.axelor.sales.[company_code].[currency]
- erp.axelor.purchase.[company_code].[currency]
- erp.axelor.accounting.[company_code]
Clé de partition:
- company_code + fiscal_periodCette granularité facilite aussi la reprise: on peut redémarrer une file ou une période fiscale sans impacter le reste du run.
Le SDK applique retries bornés, timeout par type d’opération et clés d’idempotence métier sur les écritures sensibles. Les erreurs sont classées (technique, contrat, métier) pour orienter la bonne stratégie de reprise.
Cette approche réduit les incidents silencieux et facilite la remédiation côté run.
Matrice de traitement appliquée: erreur technique transitoire -> retry borné + backoff; erreur de contrat (payload/champ) -> rejet immédiat + ticket correction; erreur métier bloquante (statut/référentiel) -> mise en quarantaine + reprise guidée.
enum AxelorErrorClass: string
{
case TECHNICAL = 'technical';
case CONTRACT = 'contract';
case BUSINESS = 'business';
}
final class RetryPolicyDecider
{
public function shouldRetry(AxelorErrorClass $class): bool
{
return $class === AxelorErrorClass::TECHNICAL;
}
}Nous évitons les retries “aveugles”: une erreur de contrat rejouée en boucle augmente la charge, masque la cause racine et retarde la correction fonctionnelle.
Couverture standard: tests unitaires (mappers/validators), intégration API (nominaux et dégradés), non-régression sur scénarios critiques (annulation, correction stock, reprise post-timeout).
Référence utile: Tests API, stratégie et bonnes pratiques.
Les scénarios les plus rentables à tester en priorité sont ceux qui mélangent modules: commande partiellement livrée, facture partielle, annulation tardive, correction de stock post-facturation. C’est là que les intégrations fragiles exposent leurs limites.
Matrice de test minimale:
1) Nominal: création client -> commande -> facture -> écriture comptable
2) Dégradé réseau: timeout sur création commande + reprise idempotente
3) Dégradé contrat: champ fiscal manquant -> rejet contrôlé + message actionnable
4) Dégradé métier: statut non autorisé -> quarantaine + reprise opérateur
5) Non-régression: réexécution d'un lot déjà traité -> aucun doublonCes tests sont exécutés en CI avec jeux de données figés. Nous ajoutons des campagnes hebdomadaires de tests de long run (batch volumétrique) pour mesurer dérives de latence et stabilité mémoire.
Postman est utilisé pour qualifier endpoints, partager collections de recette et rejouer les scénarios. Les mocks couvrent les cas limites avant validation sur environnement Axelor cible.
Voir: Postman pour industrialiser vos tests API.
En phase de cadrage, nous livrons généralement un pack outillage: collection Postman versionnée, environnement par cible (dev/recette/prod), exemples d’assertions, et documentation de correspondance entre champs externes et objets Axelor.
{
"name": "axelor-sdk-sales-create-order",
"event": [
{
"listen": "test",
"script": {
"exec": [
"pm.response.to.have.status(200);",
"pm.expect(pm.response.json().status).to.eql('CREATED');",
"pm.expect(pm.response.responseTime).to.be.below(1500);"
]
}
}
]
}Chaque flux est corrélé (trace id), journalisé (endpoint, durée, statut, retries) et supervisé sur latence, taux d’échec, backlog et délai de reprise.
Complément: Observabilité et runbooks API.
Au-delà des métriques techniques, nous suivons aussi des KPI de qualité métier: taux de reprises manuelles, délai moyen de correction fonctionnelle, et volume d’écarts entre systèmes. Ces indicateurs aident à piloter la roadmap d’amélioration continue du connecteur.
Jeu de métriques recommandé:
- api_call_duration_ms{endpoint,operation}
- api_error_total{class,endpoint}
- integration_backlog_size{queue}
- replay_total{reason}
- business_reconciliation_gap_total{module}Chaque alerte est reliée à un runbook court: cause probable, vérifications immédiates, action de reprise et seuil d’escalade. Ce format réduit le temps moyen de résolution sur incident.
Vue d’ensemble: Présentation des SDK API ERP développés par Dawap.
SDK API ERP Microsoft Dynamics 365
Sur Axelor, la robustesse d’une intégration dépend de la qualité du cadre global: contrat de données explicite, gestion d’erreurs actionnable, tests réalistes et observabilité continue.
Le cadrage initial doit couvrir quatre axes: périmètre métier priorisé, contrat API versionné, validation nominaux + dégradés, et exploitation avec runbooks/ownership.
Nous recommandons également un cadrage explicite des responsabilités: qui valide les règles métier, qui opère les reprises, qui arbitre les évolutions de contrat. Sans ownership clair, le coût opérationnel augmente rapidement malgré une bonne qualité technique initiale.
Enfin, un projet Axelor performant est un projet qui pense “vie du connecteur” dès le départ: versionning des schémas, compatibilité ascendante, plan de migration et budget de maintenance. C’est ce qui transforme une intégration ponctuelle en actif logiciel durable.
Pour approfondir: Intégration API ERP Axelor et notre offre Intégration API.
Nous accompagnons les équipes produit et techniques dans la conception, l’intégration et l’industrialisation d’APIs. Notre mission : construire des architectures robustes, sécurisées et évolutives, alignées sur vos enjeux métier et votre croissance.
Vous préférez échanger ? Planifier un rendez-vous
Les flux Odoo exigent une lecture fine de JSON-RPC, des modèles métier et des règles de transition documentaires. Ce guide détaille comment Dawap structure un SDK Symfony pour synchroniser clients, commandes, factures et stocks avec idempotence, retries maîtrisés et traçabilité run.
SAP implique des contraintes élevées sur la volumétrie, la cohérence des données et la robustesse des workflows critiques. Nous y détaillons notre SDK Symfony pour orchestrer les flux logistiques et financiers avec contrôle d'état strict, résilience réseau et supervision orientée production.
Dynamics 365 nécessite des échanges API REST sécurisés et cohérents sur plusieurs domaines métier simultanément. Ce guide explique notre SDK Symfony pour synchroniser ventes, clients, stocks et finance, tout en conservant une observabilité fine et une gestion d'incidents pilotable.
Les projets Divalto demandent de concilier contraintes terrain, flux commerciaux et exigences logistiques. L'article présente notre SDK Symfony avec mappings versionnés, stratégie de retry adaptée et normalisation des échanges pour stabiliser les opérations au quotidien.
Nous accompagnons les équipes produit et techniques dans la conception, l’intégration et l’industrialisation d’APIs. Notre mission : construire des architectures robustes, sécurisées et évolutives, alignées sur vos enjeux métier et votre croissance.
Vous préférez échanger ? Planifier un rendez-vous