In sintesi
Chi deve collegare un sistema esterno a SAP Business One — un e-commerce, un gestionale satellite, un tool di BI — si trova davanti a tre tecnologie con scopi diversi: Service Layer, DI API e B1IF. Non sono intercambiabili, e la scelta sbagliata non si vede al momento del preventivo: si vede sei mesi dopo, in manutenzione. Questo articolo spiega cosa fa ciascuna, quando ha senso l’una e quando l’altra, e quali errori architetturali si ripetono più spesso.
Le tre famiglie di integrazione con SAP B1
Prima di scegliere, serve chiarezza su cosa sono davvero queste tecnologie: non sono tre modi diversi di fare la stessa cosa, ma tre strumenti pensati per contesti diversi.
Service Layer
Il Service Layer è l’API REST/OData di SAP B1: espone risorse (ordini, articoli, business partner, giacenze) su HTTP, con autenticazione a sessione. È pensato per essere chiamato da remoto — un’app mobile, un frontend web, un sistema esterno che vive fuori dalla rete del cliente — e non richiede componenti installati sulla macchina che lo chiama. È la tecnologia più adatta quando il chiamante non è nella stessa rete Windows del server SAP B1.
DI API
La DI API (Data Interface API) è una libreria COM/.NET che gira sulla stessa macchina o nella stessa rete del client SAP B1: dà accesso più diretto alla business logic interna di B1 (validazioni, numerazione documenti, alcuni comportamenti non esposti dal Service Layer). Il vincolo è geografico e architetturale insieme: non è pensata per essere invocata da remoto come un’API pubblica, ma per girare vicino all’installazione B1, tipicamente in servizi Windows locali o add-on client-side.
B1IF
Il B1IF (B1 Integration Framework) non è un’API da chiamare, ma un motore di orchestrazione a scenari: definisci flussi che intercettano eventi in SAP Business One (o in sistemi esterni) e li trasformano/instradano verso altre destinazioni, senza scrivere codice custom per ogni passaggio. È lo strumento giusto quando serve orchestrare più step (validazione, trasformazione, instradamento) e si preferisce configurare scenari piuttosto che mantenere codice ad hoc per ognuno.
Come si sceglie
La domanda giusta non è “quale API è più potente”, ma quattro domande concrete su dove vive il chiamante e come deve comportarsi l’integrazione:
- Dove vive chi chiama? Se è un’app mobile, un frontend web o un sistema esterno fuori dalla rete del cliente, il Service Layer è quasi sempre la scelta corretta. Se è un servizio o un add-on che gira già sulla stessa macchina o rete Windows di SAP B1, la DI API diventa un’opzione valida.
- Serve realtime o va bene batch/eventi? Chiamate sincrone puntuali (crea un ordine, leggi una giacenza) sono il caso naturale del Service Layer o della DI API. Se invece serve reagire a eventi e instradare/trasformare dati verso più destinazioni, il B1IF evita di scrivere codice custom per ogni scenario.
- Quanto profondo deve essere l’accesso alla business logic B1? Alcuni comportamenti interni (validazioni specifiche, numerazione documenti in certi contesti) sono più accessibili via DI API che via Service Layer.
- Chi mantiene l’integrazione nel tempo? Un’integrazione fatta con lo strumento sbagliato non si vede il giorno del go-live — si vede quando va estesa o quando cambia un requisito, e a quel punto costa riscriverla.
Tabella comparativa
| Dimensione | Service Layer | DI API | B1IF |
|---|---|---|---|
| Protocollo | REST / OData su HTTP | Libreria COM/.NET nativa | Motore a scenari, non un’API |
| Dove può girare il chiamante | Da remoto, fuori dalla rete del cliente | Stessa macchina/rete Windows del client SAP B1 | Server B1IF, tipicamente vicino a SAP B1 |
| Tipo di accesso | Risorse REST (ordini, articoli, BP) | Accesso diretto alla business logic B1 | Orchestrazione di eventi/trasformazioni |
| Caso d’uso tipico | App mobile, integrazioni web esterne | Add-On locali, servizi Windows vicini a B1 | Instradamento multi-destinazione, flussi a step |
| Complessità di manutenzione | Bassa se il chiamante resta stateless | Cresce se il servizio deve girare su più macchine | Configurazione a scenari, meno codice custom |
Errori architetturali comuni
Alcuni pattern sbagliati si ripetono in modo quasi identico progetto dopo progetto:
- Usare la DI API per un caso che doveva essere Service Layer. Un’integrazione web o mobile costruita sopra la DI API finisce per richiedere un componente server-side dedicato solo per “avvicinarsi” a SAP B1 — complessità evitabile scegliendo il Service Layer da subito.
- Sincrono quando serviva asincrono. Chiamare il Service Layer in modo sincrono per ogni singolo evento, quando in realtà serve orchestrare più passaggi o gestire retry, porta a integrazioni fragili: è il caso in cui B1IF o una coda applicativa avrebbero retto meglio.
- Duplicare la fonte di verità invece di leggere/scrivere direttamente SAP B1. Costruire un secondo database che replica anagrafiche e giacenze “per comodità” introduce un problema di allineamento che prima o poi si paga — lo stesso principio vale sia per le integrazioni custom che per i prodotti mobile (ne parliamo anche nell’articolo sulla tentata vendita su SAP Business One).
- Ignorare i limiti di sessione della Service Layer su volumi alti. Le sessioni Service Layer hanno un comportamento e un ciclo di vita da gestire esplicitamente: un’integrazione che non li considera nel disegno rischia errori intermittenti sotto carico. (I valori esatti di limite dipendono dalla versione e dalla configurazione SAP B1: vanno verificati caso per caso, non stimati a priori.)
Domande frequenti
Posso usare Service Layer e DI API insieme nello stesso progetto?
Sì. Non sono alternative esclusive: capita che un’integrazione usi il Service Layer per le chiamate da remoto e un componente locale basato su DI API per operazioni specifiche che richiedono accesso più diretto alla business logic. La chiave è essere espliciti su quale tecnologia risponde a quale esigenza, non mescolarle per abitudine.
Serve B1IF se ho già uno sviluppatore che scrive integrazioni custom?
Dipende da quanti scenari di orchestrazione servono e quanto cambiano nel tempo. Se i flussi sono pochi e stabili, il codice custom può bastare. Se i flussi crescono (più destinazioni, più trasformazioni, più eventi da intercettare), B1IF riduce la quantità di codice da mantenere a ogni nuovo scenario.
Il Service Layer funziona anche fuori dalla rete del cliente?
Sì, è pensato esattamente per questo: è un’API REST accessibile da remoto, con autenticazione a sessione. È il motivo per cui è la scelta naturale per app mobile e integrazioni web che non vivono nella stessa rete del server SAP B1.
Quale tecnologia usa MTF nei suoi prodotti mobile?
MTF.Sales.Suite, MTF.Warehouse e MTF.TMS integrano SAP Business One nativamente tramite il Service Layer: è la scelta coerente per prodotti che devono funzionare da dispositivi mobili fuori dalla rete del cliente, con SAP B1 come unica fonte di verità.
Cosa fa MTF qui
MTF è Silver Partner SAP e implementa e integra SAP Business One per le PMI italiane dal 2017. Nella consulenza disegniamo architetture di integrazione su Service Layer, DI API e B1IF in base al progetto reale — non a uno schema fisso — e nei nostri prodotti mobile (MTF.Sales.Suite, MTF.Warehouse, MTF.TMS) usiamo il Service Layer come integrazione nativa con SAP B1.
Se stai valutando come integrare un sistema con SAP Business One, scopri i servizi SAP Business One di MTF o parliamo del tuo caso specifico.