Ora che abbiamo affrontato la fase di elaborazione degli eventi e abbiamo analizzato tutti i concetti di base relativi all’impostazione di B1iF, abbiamo deciso di fare un passo avanti. per “supervisionare” adeguatamente questi eventi, passiamo alla parte più intrigante del nostro progetto: ricevere il payload in uscita (XML) inviato con l’HTTPCall Atom e invocare il nostro WebHook che poi innesca il nostro flusso di lavoro.

Suppongo che abbiate già un abbonamento attivo ad Azure; in caso contrario, è giunto il momento di farlo.

Fasi del flusso di lavoro dell’applicazione logica:

Fase 1) La nostra applicazione logica deve avere un trigger, che nel nostro caso sarà il connettore “Quando viene ricevuta una richiesta HTTP“:

Ricordiamo che tutto ciò che vogliamo è sottoscrivere un endpoint di servizio, registrando un URL di
URL di callback.
TQuesto URL verrà generato una volta che l’applicazione logica viene salvata per la prima volta e sarà
unico
 a questo flusso di lavoro.

 

Fase 2) Se ricordate, l’HTTPCall Atom di B1iF serve a chiamare il nostro flusso di lavoro (usando l’URL di callback di cui sopra ) inviando un corpo XML, quindi useremo l’espressione “triggerBody()” per recuperare ciò che il nostro trigger deve consegnare.

Ma non è sufficiente, perché vorremmo convertire il corpo XML in arrivo in una struttura più “leggera” con cui possiamo lavorare facilmente: JSON (JavaScript Object Notation).

In effetti, B1iF mantiene i propri schemi di trasformazione XSL per quasi tutti i tipi di output richiesti dal sistema ricevente, quindi possiamo assicurarci di effettuare la conversione anche prima di trasmettere il payload all’atomo finale in uscita.

Ciò comporterebbe ulteriori passaggi per preparare l’output in modo che il nostro WebHook riceva un corpo JSON invece di un corpo XML. Per mantenere le cose semplici, ho deciso di usare un metodo più veloce e di eseguire la conversione dall’interno dell’applicazione Logic.

  • Per saperne di più sugli schemi di trasformazione XSL, accedere alla versione 1.X di B1iF, navigare in
    Aiuto ->

    Documenti
    e cercare “Schemi”. Potrei scrivere un blog successivo su come gestire i vari tipi di schema durante le trasformazioni XSL.

 

Quindi, il nostro 2seconda fase del flusso di lavoro Il secondo passo del flusso di lavoro prevede un’azione “Compose” che converte il corpo in un elemento JSON:

 

Passo 3) Se eseguissimo il flusso di lavoro fino alla sua seconda azione, otterremmo il seguente risultato:

Possiamo notare chiaramente che il valore che stiamo cercando di ottenere (New Business Partner Code, ricordate?) si “nasconde” all’interno dell’oggetto JSON appena creato e dobbiamo estrarlo da lì

Passo 4) Creeremo quindi una seconda azione “Compose” e useremo l’espressione “Outputs()” per navigare nel nostro JSON:

Questa azione recupererà il codice BP e ne memorizzerà il valore

Potrebbe trattarsi di un ordine di vendita con articoli, di una fattura o di un nuovo articolo creato/aggiornato: dipende dallo scenario aziendale.

L’importante è che ora possiate tenerlo e usarlo per fare tutto ciò che vi serve in base alle vostre esigenze:

  1. È possibile attivare un processo di approvazione
  2. È possibile generare un ordine d’acquisto sulla base di un ordine di vendita.
  3. È possibile inviare una quotazione a un cliente per un articolo appena creato.

Tutti questi risultati possono essere ottenuti utilizzando il SAP Business One Service Layer dall’interno della Logic App.

 

L’azione finale, nel mio caso, sarebbe quella di inviare un’e-mail a me stesso utilizzando il comando “
Invia un’e-mail (V2)”
 e utilizzare l’output dell’azione “Compose” come corpo dell’e-mail:

Il nostro flusso finale sarà simile al seguente:

E poi arriva l’e-mail stessa:

Ancora una volta, dobbiamo salvare la nostra applicazione logica in modo che venga generato l’URL di callback:

 

Una volta copiato l’URL, possiamo tornare a B1iF e completare l’operazione: scomponiamo l’URL nei seguenti campi:

  1. destProtocol- https
  2. destHost: il nome del nostro host Azure
  3. destPort- 443
  4. destPath: la stringa URL rimanente
  5. Metodo: di solito è un “POST” per questo scenario.


Osservazioni conclusive:

Nonostante il fatto che il nostro scenario non fosse troppo complesso, siamo stati in grado di dare un’occhiata a come gli eventi integrati di SAP Business One possano essere recuperati e poi utilizzati per attivare altri flussi di business utilizzando sia il framework di integrazione che la tecnologia serverless come i flussi di lavoro di Azure Logic Apps.

I vantaggi immediati che ne derivano sono:

  • Riduzione di DevOps
  • Time To Market più veloce (= un cliente più felice, che ci aiuta anche a gestire meglio le nostre risorse interne)
  • Costi ridotti

Azure Logic Apps è con noi da un po’ di tempo, ma con la versione attuale non c’è praticamente nulla che non si possa realizzare quando si costruisce un’integrazione con il nostro ERP e si gestiscono le nostre API.

Il fatto di poter saltare un processo relativamente lungo (noioso e anche piuttosto costoso) di iscrizione alla piattaforma SAP BTP e di impostazione dell’Event Mesh/Grid per lavorare con essa, ci apre una vasta finestra di opportunità per lanciare flussi di lavoro aziendali che si basano solo su eventi reali provenienti dal nostro ERP, in tempo reale, piuttosto che ripetutamente. e controllare i nostri endpoint per vedere se i nostri endpoint per vedere se abbiamo dei dati su cui lavorare.