Relier votre logiciel métier à SAP Business One par le Service Layer

Service Layer, DI API, Integration Framework : par où passer ?

Pour une nouvelle intégration, la porte d'entrée est le Service Layer, que SAP présente comme un serveur d'applications donnant un accès web aux services et aux objets de SAP Business One. Les modules de formation officiels de SAP (SAP Learning) décrivent trois outils qui ne répondent pas au même besoin :

Le Service Layer fonctionne avec les deux bases de données de SAP Business One, SAP HANA et Microsoft SQL Server, et tourne sous SUSE Linux Enterprise comme sous Windows depuis la version 10.0 PL01. Il s'appuie sur le serveur Apache comme répartiteur de charge, pour assurer la haute disponibilité de l'accès aux données. SAP Business One lui-même se déploie sur site ou dans le cloud.

Que peut faire un programme par le Service Layer ?

Un programme peut créer, lire, modifier et supprimer les objets de gestion de SAP Business One, y compris les objets définis par l'utilisateur, selon une logique identique pour tous. La formation SAP Learning prend l'exemple de la commande client :

• création d'une commande par un POST sur Orders, avec une réponse 201 ;
• modification d'une quantité par un PATCH sur la commande, avec une réponse 204 ;
• création de la facture à partir de la commande, par un POST sur Invoices dont la ligne référence la commande d'origine ;
• clôture de la commande par l'action Close ;
• refus de supprimer un article qui a déjà des transactions liées, avec une erreur 400 explicite.

Pour la lecture, le Service Layer accepte les options de requête OData : choix des champs ($select), filtres ($filter), données liées dans la même réponse ($expand), agrégats ($apply), par exemple le total des commandes regroupé par client. Les listes arrivent par paquets de 20 documents par défaut, taille réglable dans la configuration du Service Layer, avec un lien odata.nextLink vers la suite. Pour un besoin de reporting que les objets ne couvrent pas, l'entité SQLQueries exécute des requêtes SQL enregistrées et paramétrées, dans le respect d'une liste de tables autorisées et d'autorisations accordées requête par requête dans le client SAP Business One.

Session, lots et performances : ce que SAP recommande

L'accès commence par une ouverture de session : un POST sur Login avec le nom de la base société (CompanyDB, sensible à la casse), l'utilisateur et le mot de passe. La réponse renvoie un identifiant de session ; les cookies de session et de routage (ROUTEID) accompagnent ensuite chaque requête, et un appel Logout ferme la session. Le Service Layer accepte aussi OAuth 2.0 et OpenID Connect, avec un fournisseur d'identité comme SAP IAS et une application cliente enregistrée.

Les bonnes pratiques publiées par SAP Learning sont concrètes :

• réutiliser les sessions au lieu d'enchaîner connexions et déconnexions ;
• ne récupérer que les données nécessaires au traitement ;
• regrouper les écritures courtes dans un lot $batch : dans un ensemble de modifications (change set), un échec annule tout l'ensemble, qui ne peut contenir aucune lecture ;
• activer la session persistante (sticky session) pour les traitements lourds, la désactiver en cas de forte concurrence ;
• planifier les traitements de masse aux heures où les utilisateurs sont peu actifs ;
• ne laisser les journaux de débogage actifs que le temps d'un diagnostic.

Cinq flux à brancher sur SAP Business One

1. Portail de commande professionnel. Un distributeur ouvre à ses clients un portail qui affiche stock et prix nets. Le portail lit les articles, puis crée la commande client par le Service Layer ; l'ADV la traite dans SAP Business One sans ressaisie. Voir notre page sur l'application de prise de commande.
2. Vente comptoir en un seul lot. Pour une vente réglée sur place, la commande et la facture qui la référence partent dans le même ensemble de modifications : soit les deux documents existent, soit aucun.
3. Visite commerciale préparée. Avant un rendez-vous, l'application mobile du commercial itinérant lit les dernières commandes du client avec leurs lignes en une seule requête ($expand), même sur une connexion faible.
4. Chiffre d'affaires du matin. Chaque matin, un service calcule par agrégat le chiffre d'affaires par client et l'affiche dans un tableau de bord de pilotage, sans export de fichier.
5. Vue de reporting spécifique. Une requête SQL enregistrée dans SQLQueries, avec paramètres, fournit à un outil externe une vue que les objets standard n'exposent pas, avec des droits accordés requête par requête.

Les difficultés propres à SAP Business One

• Les changements côté SAP. Les modules SAP Learning consultés décrivent des échanges lancés par le programme appelant. Pour suivre les nouveaux documents, on interroge le Service Layer à intervalles réguliers, ou l'on étudie avec l'intégrateur SAP ce que l'Integration Framework peut prendre en charge.
• Le serveur et son administrateur. Le port du Service Layer, les certificats, la taille des pages et les mises à jour se règlent côté serveur : l'intégrateur ou le service informatique qui gère SAP Business One est associé dès le cadrage.
• Le compte technique. L'intégration se connecte avec un utilisateur SAP Business One : son type de licence et ses autorisations se vérifient avec votre revendeur avant le développement.
• Les champs utilisateur. Les champs et objets ajoutés à votre base font partie du contrat d'échange : ils sont listés et figés au cadrage.
• Les doublons et la reprise. Le service garde la correspondance entre ses identifiants et les numéros de documents SAP, rejoue ce qui a échoué et journalise chaque requête, pour éliminer les doubles saisies sans en créer d'autres.
• Les données personnelles. Contacts et partenaires contiennent des données personnelles : seuls les champs utiles circulent, et le flux est inscrit au registre des traitements.

Connecteur, Integration Framework ou développement : comment trancher ?

La réponse dépend du nombre d'outils en jeu et de la finesse des règles. Si votre logiciel du marché propose déjà une liaison avec SAP Business One, essayez-la d'abord. Si votre intégrateur SAP maîtrise l'Integration Framework et que l'échange se résume à transférer des documents entre deux systèmes, cette voie reste dans l'univers SAP. Le développement sur mesure se justifie quand une application spécifique (portail, application mobile, logiciel d'atelier) doit lire et écrire en temps réel, avec ses propres écrans et règles. Et si SAP Business One ne colle plus à vos processus, la question change de nature : voir les alternatives à SAP Business One.

Ce que YMHB Web livre sur une intégration SAP Business One

YMHB Web développe le service d'intégration, et souvent l'application qui l'utilise, en travaillant sur une copie de la base société mise à disposition avec votre intégrateur. Vous recevez :

• le code source, déposé chez vous et documenté, qui vous appartient au paiement intégral ;
• la liste des entités, champs et requêtes SQL utilisés, avec le sens de chaque flux ;
• le journal des échanges et les alertes en cas d'échecs répétés ;
• la procédure à suivre lors d'une mise à jour de SAP Business One.

Le principe de ces composants est détaillé sur notre page API et microservices.