È passato un po’ di tempo da quando ho implementato il mio primo scenario event-driven in SAP Business One. Da quando ho iniziato, mi sono imbattuto in un “oceano” di possibilità/piattaforme/servizi che offrono più o meno lo stesso approccio su come raggiungere questo obiettivo, ognuno dei quali ha i suoi pro e contro.

Non c’è dubbio che il settore sia ben sviluppato e possa offrire numerosi modi di fare le cose, e io sono un po’ troppo “zelante” quando si tratta di imparare nuove tecnologie (dopo tutto, è il nostro pane e burro). Ma ogni volta che mi siedo a scrivere un progetto, cerco di attenermi all’approccio “One-Stop”, dove la scelta di riutilizzare strumenti e servizi integrati nell’applicazione B1 stessa sarebbe probabilmente in cima alla mia lista.

Questi strumenti sono sempre stati disponibili e sono cresciuti nel corso degli anni e non solo non sono stati deprezzati, ma hanno anche ampliato le loro capacità e prestazioni.

Non fraintendetemi: ritengo che la piattaforma SAP BTP, ad esempio, offra infinite possibilità quando si tratta di consumare servizi Web REST in grado di interagire con i nostri sistemi SAP e consenta anche di riutilizzare alcuni dei connettori più potenti per integrarsi con altri sistemi SAP / non SAP, nonché di estendere le nostre applicazioni e processi aziendali. Il SAP BTP utilizza anche servizi all’avanguardia come gli strumenti AI Builders e Fiori Apps. Lo scopo non è quindi quello di abbattere il SAP BTP, che si è giustamente guadagnato il suo posto, ma semplicemente di affermare che il SAP BTP non è l’unico gioco in città.

Tuttavia, chi ha provato a navigare in questo oceano di dati esposti sulla piattaforma SAP BTP probabilmente si è reso conto che il BTP è molto orientato a S4/HANA e non è specificamente pensato per gli sviluppatori di SAP Business One.

Inoltre, il BTP presenta alcune evidenti carenze:

1. Una configurazione lunga e noiosa: l’aggiunta di un abbonamento/istanza/entitlement vi costerà tempo e, nella maggior parte dei casi, non lo farete al primo tentativo.
2. I livelli di prezzo non sono adatti alle PMI. Finché si utilizza l’abbonamento “Free” per gli ambienti non produttivi, si dovrebbe essere a posto, ma una volta che si passa ai livelli di abbonamento “Pay-As-You-Go” e si entra in produzione, nella maggior parte dei casi, diventerebbe un “overkill” per qualsiasi progetto basato sulle PMI e anche piuttosto costoso.
3. Non ha una consapevolezza incorporata degli oggetti B1. Possiamo usarla e chiamarla come faremmo con qualsiasi altra API per renderla “consapevole” di ciò che stiamo cercando di ottenere.

Come possiamo implementare uno scenario di inoltro eventi e utilizzare le informazioni ottenute per attivare/costruire altre soluzioni relative a B1 senza complicare eccessivamente le cose?

In genere, è necessario eseguire le seguenti operazioni:

1. Configurare un’istanza SAP Event Mesh su BTP
2. Avere un’applicazione SAP CAP per gestire gli eventi in BTP (di solito utilizzata per la costruzione di un’impresa).
   servizi e applicazioni di livello aziendale
   -servizi e applicazioni di livello enterprise, il che, ancora una volta, è un “gioco da ragazzi” quando si tratta di SAP B1)
3. Avremmo bisogno di codificare un passaggio ausiliario per recuperare il token al fine di autenticarci contro l’istanza SAP Event Mesh sulla SAP BTP Platform.

La panoramica architettonica si presenta come segue:

E se vi dicessi che possiamo saltare la parte in cui ci abboniamo al BTP e passare direttamente al nostro framework di integrazione B1 (B1If) per consumare quegli eventi e utilizzarli ulteriormente per estendere il comportamento della nostra applicazione B1 utilizzando Microsoft Azure?

Supponendo che B1iF sia stato installato e configurato correttamente nel vostro ambiente, siete già a buon punto.

Vi consiglio vivamente di prendere in considerazione i seguenti passi per assicurarvi di soddisfare pienamente tutti i prerequisiti:

• Impostazione dell’ambiente di sviluppo B1iF.
• Comprendere le basi del B1iF e la panoramica tecnica.
• Impostazione della configurazione SLD dell’azienda.
• Configurare la connettività al Service Layer B1 (non vogliamo affidarci esclusivamente alla DI-API, che è la “vecchia generazione” di API di estensione per il consumo di dati e servizi di SAP Business One).

** Se si riscontrano problemi con la configurazione del B1iF, non esitate a contattarmi e sarò lieto di fornirvi indicazioni e supporto**.

Infine, vogliamo impostare il nostro mittente di eventi B1iF in modo che inizi ad emettere eventi.

Le migliori pratiche di B1iF ci impongono di aderire a quanto segue:

1)Assicurarsi di accedere a Integration Framework 2.0 anziché 1.0:

Questo comporta diversi vantaggi fondamentali:

• Oltre al quadro di integrazione, tutti i modelli di programmazione possono essere eseguiti contemporaneamente in parallelo.
• Ottimizzato per il cloud computing
• Multi-tenancy incorporata – Maggiore flessibilità nelle implementazioni di scenario
• Costruito per soddisfare tutti gli sviluppatori di integrazione
  • Maggiore flessibilità
  • Maggiore controllo e trasparenza nello sviluppo dei contenuti di integrazione
• Gli sviluppatori “classici” si sentono più a loro agio grazie al nuovo IDE basato su browser
• Fino a 10 volte più veloce: viene eseguito direttamente sulla piattaforma di integrazione.
• Non sostituisce l’attuale modello di programmazione Non è richiesta la migrazione dei pacchetti di scenario esistenti, a meno che non si voglia utilizzare la multi-tenancy in ambienti cloud.

2. Assicurarsi che tutte le connessioni SLD siano corrette:

L’interruzione di una di queste connessioni compromette il processo e impedisce la comunicazione con il server HANA o il Service Layer in un secondo momento, quindi è bene assicurarsi che siano tutte chiare e, in caso contrario, riconfigurare le stringhe di connessione.

3) Assicurarsi di filtrare gli eventi B1i navigando su Manutenzione -> B1 Event Filter e selezionando “B1i User Filter Switched On” (Filtro utente B1i attivato ), in modo da eliminare tutti gli eventi di sistema che non si desidera ascoltare.

Si noti che è possibile includere questa configurazione anche nella versione 1.X, accedendovi direttamente dalla versione 2.0 (in Strumenti ->Versione 1) e navigando fino alla Procedura guidata mittente eventi.

Qui è necessario includere anche gli ID degli oggetti B1 per tutti gli oggetti per i quali si desidera ottenere gli eventi

L’elenco completo degli oggetti B1 è disponibile alla fine di questa discussione.

In alternativa, è possibile recuperare questo valore direttamente dall’applicazione B1 lanciando il Query Generator e selezionando la colonna “<table_name>”.” ObjType”:

4) Il passo più importante è verificare che i VOSTRI eventi NON vengano filtrati, bensì trasmessi a B1 Event Monitor quando si attiva lo scenario.

Nel mio caso, ho semplicemente creato un Business Partner e aggiornato la visualizzazione per vedere che B1iF era in grado di catturare l’evento:

Nota: l’esecuzione del test avrà successo solo se ci si assicura di aggiungere un nuovo deployment al “Deployment Panel” dello scenario e di assegnare un sistema Sender/Receiver valido dall’SLD; questo riquadro è la nuova (e interessante!) funzione della versione 2.0 che consente di avere un’unica panoramica di tutti gli artefatti dello scenario.

Una volta accertato che il nostro Event Sender elabora correttamente gli eventi, possiamo procedere con la costruzione del nostro scenario in BizFlow.

Ora, è importante comprendere appieno ciò che stiamo cercando di ottenere:

Vogliamo solo che B1iF inoltri ogni evento che soddisfa i nostri criteri di filtraggio a un flusso di lavoro esterno HTTP basato su WebHook, sotto forma di payload XML da cui possiamo analizzare e recuperare i dati.

Non c’è altro da fare!

Se vi chiedete “perché?”, la risposta è piuttosto semplice:

Con
Azure Logic Apps
e il connettore HTTP Webhook integrato, possiamo creare attività e flussi di lavoro automatizzati che si iscrivono a un endpoint di servizio registrando un URL di callback, attendono eventi specifici e vengono eseguiti in base a tali eventi, anziché controllare o eseguire regolarmente il polling dell’endpoint.

Questo è particolarmente utile e vantaggioso nei casi in cui i PaaS (Platforms as a Service) come Microsoft-Azure fanno pagare per ogni esecuzione.

Immaginate quante esecuzioni verranno attivate nell’arco di 24 ore quando un flusso di lavoro è programmato per essere eseguito ogni 15 minuti (96 esecuzioni) contro le 3 esecuzioni per i 3 nuovi Business Partner che avete creato quando il flusso di lavoro è solo attivata subito dopo l’aggiunta del record del Business Partner al database B1.

Ciò influisce direttamente sui consumi e, di conseguenza, sull’importo che vi verrà addebitato alla fine del mese.

Detto questo, nella prossima parte di questo blog tratterò il lato Logic App del nostro progetto.

Per prima cosa, mettiamo a punto il nostro scenario e le fasi dello scenario.

Il nostro diagramma BizFlow sarà relativamente semplice:

Si tratta di una tipica modalità di processo ‘asincrona’, in cui l’evento viene lanciato, recuperato e poi trasmesso all’Atomo in entrata, dove viene trasformato tramite un Atomo XSLT per essere utilizzato nell’Atomo HTTPCall.

Tenere presente che B1iF elabora sempre i dati internamente come XML, quindi, nel nostro caso, desideriamo semplicemente prendere la rappresentazione XML del nostro evento dal sistema mittente (Event Sender) e utilizzarla come parte del nostro corpo di chiamata HTTP.

Un buon modo per analizzare la struttura dei messaggi durante l’esecuzione è utilizzare il B1iF Debugger:

Il nostro Atom di trasformazione XSL dovrà essere adattato solo per recuperare il payload XML in entrata dell’evento B1, dove verrà aggiunta un’espressione XPATH al nostro Atom HTTPCall.

Torneremo al nostro HttpCall Atom dopo aver concluso la discussione sulle Logic App (WebHook) nella seconda parte di questo blog.

Riassumiamo ciò che abbiamo realizzato finora:

1. Abbiamo presentato il nostro argomento principale – Creazione e inoltro di eventi in SAP Business One.
2. Abbiamo analizzato alcuni dei modi più comuni per gestire gli eventi, illustrando i pro e i contro di ciascun approccio.
3. Abbiamo analizzato alcune impostazioni e configurazioni di base di SAP Business One Integration Framework.
4. Abbiamo trattato i nuovi miglioramenti della versione 2.0 di B1iF
5. Abbiamo avuto una panoramica dettagliata della configurazione di Event Sender e abbiamo imparato a impostare con successo i criteri di filtraggio per gli oggetti B1 per i quali desideriamo ottenere eventi
6. Abbiamo imparato a distribuire uno sviluppo tramite il “Deployment Panel” del nostro scenario e ad assegnare un sistema mittente/ricevente SLD.
7. Abbiamo discusso dei WebHook HTTP e abbiamo compreso come essi svolgano un ruolo significativo nel ridurre il numero di esecuzioni dei flussi di lavoro che alla fine influiscono sulla fatturazione.
8. Abbiamo analizzato le varie fasi dello scenario per ricevere un messaggio in entrata (evento), quindi elaborarlo e trasformarlo e prepararlo per l’HTTPCall Atom.

Unitevi a noi nella pagina del blog della SAP Business One Community per la seconda parte dell’implementazione di un meccanismo di inoltro degli eventi con SAP Business One B1iF e Microsoft Azure.

Elenco dei tipi di oggetti SAP Business One