Integrazione dei file system locali con SAP Business One e Microsoft Azure – Parte 1

Siamo tutti consapevoli della rapidità con cui la tecnologia si evolve.

Ogni giorno emergono nuovi strumenti e servizi che ci offrono più contenuti che probabilmente possiamo consumare.

Questa “tendenza”, in realtà, non è una tendenza, ma il modo abituale in cui le cose si manifestano. Se rimaniamo concentrati su ciò che stiamo cercando di ottenere, possiamo anche trarre grandi benefici da quelle “rivoluzioni” in cui continuiamo a imbatterci.

Tuttavia, la maggior parte di noi (compreso il sottoscritto) non abbandona mai completamente il vecchio “approccio legacy” che, in qualche modo, ha dato il tono e ha gettato le basi, per anni, per molti dei nuovi approcci che utilizziamo oggi.

L’unica vera domanda è: come possiamo sfruttare il progresso e combinare approcci più nuovi e avanzati con approcci tradizionali per facilitare le nostre attività organizzative e accelerare i processi in modo da diventare più efficienti nello svolgimento del nostro lavoro?

Lo scenario

Per esempio, immaginiamo che la vostra azienda abbia un’enorme quantità di numeri di pezzi immagazzinati in un magazzino e che, di fatto, il vostro responsabile dell’inventario debba eseguire un MRP Recommendation Report settimanale utilizzando il modulo MRP di SAP Business One.

Tuttavia, anche se non tratterò i concetti di MRP in questo blog (forse vale la pena che lo faccia presto…), chi di voi utilizza effettivamente il modulo MRP sa già che per ottenere una affidabile Rapporto di raccomandazione MRPè assolutamente necessario che le previsioni MRP siano manutenzione regolare in SAP Business One, soprattutto quando le previsioni di vendita cambiano continuamente.

Potenzialmente, il controllore dell’inventario dovrebbe tornare al MRP Forecast all’interno di SAP Business One e modificare i valori previsti per ciascuna delle SKU/località di stoccaggio.

L’utilizzo di alcuni degli Expert Tools offerti da SAP Business One potrebbe aiutarvi a raggiungerli più rapidamente. Tuttavia, questi strumenti sono progettati in modo tale da richiedere una profonda conoscenza degli schemi delle tabelle di SAP Business One e possono causare gravi danni se gestiti male.

E per rendere le cose un po’ più interessanti, aggiungerò un altro livello di complessità allo scenario aziendale: supponiamo che i valori previsionali NON vengano generati in SAP Business One, ma estratti in un “Flat File” (*.CSV) da altri sistemi SAP/Non-SAP, come SAP-ECC o persino un sistema SAP S/4HANA o forse un’interfaccia web che state utilizzando. Supponiamo che il controllore dell’inventario desideri semplicemente rilasciare il file di output nel suo file system locale, sapendo che un processo automatizzato si occuperà di questo in background, inserendo i valori nel posto giusto in SAP Business One, assicurandosi che il suo Rapporto sulle raccomandazioni MRP sta prendendo in considerazione le ultime modifiche apportate ai valori di vendita previsti e può continuare la sua giornata completando altri compiti.

Sembra complicato? Beh, non è un “gioco da ragazzi”, ma è sicuramente fattibile con gli strumenti che Microsoft Azure e la straordinaria Power Platform ci offrono.

Come si può ottenere questo risultato

La prima cosa da capire è che il nostro file system locale (On-Premises Data Source) deve essere in grado di “parlare” con Azure e quest’ultimo deve essere in grado di “ascoltare” la nostra struttura di cartelle locale.

Questo può essere ottenuto installando e configurando il “Data Gateway On-Premises” sul computer locale.

Il gateway di dati in sede funge da “ponte”.

Fornisce un trasferimento rapido e sicuro dei dati tra i dati on-premises, cioè quelli che non si trovano nel cloud, e diversi servizi cloud di Microsoft su Azure, per i quali Microsoft ha predisposto dei connettori.

Il diagramma seguente illustra il funzionamento del Data Gateway On-Premises e consente di vedere l’architettura sottostante:

Quindi, il primo passo è scaricare e installare il Gateway On-Premises. Tenete presente che Microsoft rilascia ogni mese un nuovo aggiornamento per i gateway di dati.

Microsoft fornisce una documentazione abbastanza ordinata su come installare e configurare il Gateway, quindi non mi dilungherò in una descrizione passo-passo. Ma tratteremo le basi e anche alcune delle MIE migliori pratiche mentre lavoravo ad alcune delle mie soluzioni.

Tutta la documentazione è disponibile qui:

• Che cos’è un Data Gateway On-Premises?
• Architettura del gateway di dati on-Premises
• Installare un gateway di dati in sede

Alcune buone pratiche per l’installazione dell’istanza Gateway sul computer locale:

1. Utilizzare una chiave di ripristino: non si sa mai quando l’opzione di ripristino può essere utile e, invece di ricreare l’istanza, è possibile recuperarla abbastanza facilmente.

2. Assicurarsi di creare un’istanza gateway anche su Azure.

3. Se il Gateway è stato configurato correttamente, si dovrebbe poter vedere che la risorsa è disponibile per l’utente:

4. Al termine dell’installazione, il Gateway On-Premise avrà il proprio nome di servizio predefinito (account):

L’account deve essere modificato in modo da puntare all’utente locale del computer in cui è stato installato il Gateway, preferibilmente un account di amministratore.

Nota importante: non utilizzare l’account Administrator locale, che deve essere disattivato e sostituito con un account alternativo che sia membro del gruppo admins locale del server. L’account dell’amministratore locale è il primo a essere preso di mira dagli hacker in caso di violazione dei dati.

Una volta premuto “Cambia account”, si aprirà una finestra di dialogo che suggerisce di riavviare il Gateway, in modo da reimpostare le sue credenziali:

Ora avete due opzioni:

• La prima cosa da fare è aprire il Prompt dei comandi e digitare “WHOAMI” per ottenere l’utente locale sulla macchina
• Il modo più sicuro è quello di navigare nelle Proprietà del sistema e prendere il “Nome dispositivo”, che è fondamentalmente il “nome del computer” che funge da “nome di dominio locale”:

Se tutto è andato bene, si dovrebbe essere in grado di accedere al nuovo nome del servizio e vedere le modifiche applicate:

5. Si noti che la macchina deve rimanere sempre connessa a Internet se si intende utilizzarla come fonte di dati che “parla” costantemente con Azure e scambia informazioni.

Se esiste la possibilità che questa istanza Gateway diventi indisponibile a un certo punto, si potrebbe prendere in considerazione l’aggiunta di questa istanza Gateway a un “cluster” quando è richiesta l’alta disponibilità.

6. Il nome utente utilizzato per installare il Data Gateway On-Premise deve essere un utente della macchina locale; ciò significa che non è possibile utilizzare utenti del cloud (come Azure AD, M365) per attivare il flusso, anche se l’utente è quello utilizzato per accedere alla macchina. Consiglio di attivare “Amministratore” o di impostare un altro utente locale con privilegi di amministrazione.

Ora che abbiamo impostato la connessione tra il nostro file system locale e Azure, possiamo passare alla fase successiva: la creazione della logica necessaria per consentire l’aggiornamento dei valori di previsione MRP in SAP Business One.

In questo caso, l’approccio migliore sarebbe quello di creare un’applicazione Logic che “ascolti” la cartella locale mappata (ne parleremo presto), in modo che ogni volta che un nuovo file viene inserito in quella cartella, il nostro flusso venga attivato.

Questo approccio, che prevede la reazione agli eventi anziché il polling periodico della cartella, garantisce un minor numero di esecuzioni e quindi un minor costo basato sul consumo (soprattutto se si utilizzano le App logiche “a consumo” e non quelle “standard”). Azure Logic Apps offre un’intera serie di connettori integrati per gestire il nostro file system locale.

Per il nostro scenario, dovremmo iniziare con due:

• Il “trigger” – il connettore “ascolta” la nostra cartella locale – “Quando viene creato un file (solo proprietà)“.
• L'”azione” – il connettore recupera il contenuto effettivo del nostro file (contenuto delimitato da virgole) -” Ottieni il contenuto del file”.

Prima di poterli utilizzare, è necessario stabilire una connessione al nostro Data Gateway On-Premise:

Una volta autenticata la connessione, possiamo iniziare a usare sia il trigger che l’azione.

Il trigger, come suggerisce il nome, verrà attivato solo quando un nuovo file viene scaricato nella cartella locale che abbiamo mappato – questo file conterrà i valori di previsione che vorremmo aggiornare in SAP Business One.

La struttura del file, che cattura i valori di previsione, potrebbe potenzialmente essere la seguente:

Suggerisco inoltre, per le soluzioni produttive, di pensare a una convenzione di denominazione per questo file e di aggiungere una logica che verifichi che la convenzione di denominazione sia rispettata. In questo modo si eviterà di attivare il flusso ogni volta che qualcuno inserisce “qualche file” in questa cartella. Tratterò questa logica più avanti in questo blog.

Supponendo di aver effettuato l’accesso al gateway e di averlo abilitato, dovremmo essere in grado di rilasciare un file CSV nella cartella e verificare se l’applicazione Logic riconosce il nuovo evento.

Se è stato configurato correttamente, si dovrebbe vedere quanto segue in “Cronologia trigger” :

E poi per dare un’occhiata all’esecuzione di Logic App:

Come si può vedere, il contenuto del nostro file CSV è ora recuperato dall’azione “Get_file_content”.

Se, per qualche motivo, la creazione del nuovo file non viene riconosciuta dall’applicazione Logic, provare a controllare la sezione “Connessione API” dell’applicazione Logic per verificare che il percorso del file sia stato mappato correttamente e che siano state fornite tutte le credenziali necessarie per accedere al file system locale tramite il gateway:

Recap di Integrazione dei file system locali con SAP Business One e Microsoft Azure – Parte 1

• Abbiamo trattato alcuni concetti di base degli approcci “Legacy” e della necessità di integrare i file system locali con le nostre soluzioni per leggere/scrivere i dati da/verso il nostro sistema SAP Business One.
• Abbiamo proposto uno scenario aziendale in cui un gran numero di articoli deve essere aggiornato regolarmente in SAP Business One con un piccolo sforzo, mentre i dati di origine potrebbero essere un altro sistema di^terze parti SAP/Non-SAP.
• Abbiamo anche trattato i concetti di base su come installare e configurare il Data Gateway On-Premise per generare la connettività tra qualsiasi macchina locale e Azure Logic Apps.
• Abbiamo testato l’evento “creazione di un file” per verificare che la nostra applicazione logica potesse identificarlo e recuperare il contenuto del file.

Cosa aspettarsi nell’integrazione dei file system locali con SAP Business One e Microsoft Azure – Parte 2

• Aggiunta della convalida al nome del file per filtrare i file indesiderati che vengono rilasciati nella nostra cartella, attivando la nostra applicazione logica.
• Convertire il contenuto del file in un corpo JSON leggibile con il quale lavorare
• Conversione dei numeri della settimana in date che rappresentano il primo giorno lavorativo della settimana in cui è possibile mantenere una previsione per un articolo. Questo perché il Service Layer di SAP Business One può accettare solo date quando si invoca l’aggiornamento del Weekly Forecast, a differenza dell’interfaccia utente B1.
• Generare il payload per le previsioni e incorporare la generazione delle previsioni nella nostra soluzione.
• Copertura di alcuni concetti di gestione degli errori

Guardate la pagina del blog della SAP Business One Community per la seconda parte!