BPEL - Guida rapida

SOA o Service Oriented Architecture è un approccio architettonico che utilizza la tecnologia per presentare i processi aziendali come servizi riutilizzabili.

È incentrato sul business e consente la trasformazione dei processi a nuovi livelli di integrazione, visualizzazione, monitoraggio e ottimizzazione.
Non è una tecnologia, è un concetto e una strategia per utilizzare le tecnologie per costruire soluzioni di automazione aziendale.

Vedremo ora cos'è BPEL e come aiuta nella SOA.

Cos'è BPEL?

Business Process Engineering Language è una tecnologia utilizzata per creare programmi in architettura SOA.

Aggiunta di un componente del servizio di elaborazione BPEL

Segui questi passaggi per aggiungere un componente BPEL Process Service:

Dal Navigatore applicazioni, seleziona File> Nuovo> Applicazioni> Applicazione SOA.
Verrà avviata la procedura guidata Crea applicazione SOA.
Nella finestra di dialogo Nome applicazione, inserisci il nome di un'applicazione nel campo Nome applicazione.
Nel campo Directory, immettere un percorso di directory in cui creare l'applicazione e il progetto compositi SOA.
Fare clic su Avanti.
Nella finestra di dialogo Nome progetto, inserisci un nome nel campo Nome progetto.
Fare clic su Avanti.
Nella finestra di dialogo Impostazioni SOA del progetto, selezionare Composito con il processo BPEL.
Fare clic su Fine.

File nel BPEL Composite

Il composito BPEL contiene i seguenti file:

composite.xml - Questo file descrive l'intero assemblaggio composito di servizi, componenti di servizio, riferimenti e cavi.
.bpel - Questo file contiene la serie di attività aggiunte al processo.
.componentType - Questo file descrive i servizi e i riferimenti per il componente del servizio del processo BPEL.
.wsdl - Questo file definisce i messaggi di input e output per questo flusso di processo BPEL, l'interfaccia e le operazioni client supportate e altre funzionalità.

Concetti utilizzati nel processo BPL

In questa sezione impareremo i diversi concetti coinvolti nel processo BPL.

Orchestrazione

Un processo centrale (che può essere un altro servizio Web) assume il controllo dei servizi Web coinvolti.
Coordina l'esecuzione di diverse operazioni sui servizi web coinvolti nell'operazione.
I servizi Web coinvolti non "sanno" (e non hanno bisogno di sapere) di essere coinvolti in un processo di composizione e che stanno prendendo parte a un processo aziendale di livello superiore.
Solo il coordinatore centrale dell'orchestrazione è consapevole di questo obiettivo, quindi l'orchestrazione è centralizzata con definizioni esplicite delle operazioni e l'ordine di invocazione dei servizi Web.

Coreografia

Non si basa su un coordinatore centrale.
Ogni servizio Web coinvolto nella coreografia sa esattamente quando eseguire le proprie operazioni e con chi interagire.
Ogni servizio Web coinvolto nella coreografia sa esattamente quando eseguire le proprie operazioni e con chi interagire.
Tutti i partecipanti alla coreografia devono essere consapevoli del processo aziendale, delle operazioni da eseguire, dei messaggi da scambiare e della tempistica degli scambi di messaggi.

In questo capitolo apprenderemo le diverse attività che costituiscono gli elementi costitutivi Gli elementi costitutivi di un componente del servizio di processo BPEL.

Oracle BPEL Designer include una serie di attività da trascinare in un componente del servizio del processo BPEL e fare doppio clic su un'attività per definirne gli attributi e i valori delle proprietà.

Assegna attività

Un'attività di assegnazione consente di manipolare i dati, come la copia del contenuto di una variabile in un'altra.

Richiama attività

Un'attività invoke consente di richiamare un servizio (identificato dal suo collegamento partner) e specificare un'operazione da eseguire per questo servizio.

Ricevi attività

Un'attività di ricezione attende un messaggio di risposta di callback asincrono da un servizio.

Cerchiamo di saperne di più sull'attività Invoke nella nostra sezione successiva.

Richiama attività

L'attività invoke consente di specificare un'operazione che deve essere invocata per il servizio (identificata dal suo collegamento partner). L'operazione può essere unidirezionale o richiesta-risposta su una porta fornita dal servizio. Le variabili possono essere create automaticamente in un'attività invoke. Un'attività invoke richiama un servizio sincrono o avvia un servizio Web asincrono.

L'attività invoke apre una porta nel processo per inviare e ricevere dati. Questa porta può essere ulteriormente utilizzata per inviare i dati richiesti e ricevere una risposta. Per i callback sincroni, è necessaria solo una porta per entrambe le funzioni di invio e ricezione.

I Partner Link sono definiti come scambi di comunicazione tra tutte le parti con cui interagisce il Processo BPEL.

Sono i riferimenti alle implementazioni reali, attraverso le quali il processo BPEL interagisce con il mondo esterno.

Link partner richiamati

Questi sono collegamenti a servizi che vengono richiamati dal processo BPEL.

Link ai partner del cliente

Questi sono collegamenti a servizi che possono richiamare un processo BPEL.

Proprietà link partner

L'editor delle proprietà dei collegamenti ai partner consente di stabilire collegamenti ai partner per i processi BPEL. Con l'Editor delle proprietà del link del partner, puoi specificare quanto segue:

Name - Specifica il nome dell'elemento Invoke.
WSDL File - Indica il file WSDL associato al Partner Link.
Partner Link Type - Indica il tipo di collegamento del partner definito nel WSDL.
My Role - Indica il ruolo del processo aziendale stesso.
Partner Pole - Indica il ruolo del partner.
Documentation - Accesso nella finestra Proprietà.

I collegamenti dei partner sono definiti nel file .bpel.

Un BPEL può interagire con i servizi nei seguenti tre modi:

Servizi che invocano un processo BPEL
Servizi che vengono richiamati dal processo BPEL
Servizi che agiscono in entrambe le direzioni

In questo capitolo impareremo come creare un collegamento partner.

Segui i passaggi mostrati di seguito per creare un collegamento partner:

Nell'editor composito SOA, fare doppio clic sul componente del servizio del processo BPEL.
Facendo clic sul componente del servizio, viene visualizzato Oracle BPEL Designer.
Nella Component Palette, espandere BPEL Services.

Trascina un collegamento partner nella corsia da nuoto appropriata.
Completare i campi per questa finestra di dialogo come indicato sopra nelle proprietà del collegamento del partner.

Gli adattatori consentono di integrare il componente del servizio di elaborazione BPEL con l'accesso a file system, server FTP, tabelle di database, code di database, socket, Java Message Services (JMS), MQ e Oracle E-Business Suite. Questa procedura guidata consente di configurare i tipi di adattatori mostrati nella figura sottostante per l'utilizzo con il componente del servizio di processo BPEL -

Tipi di adattatori

L'immagine seguente mostra i diversi tipi di adattatore:

Accodamento avanzato (AQ)

Per l'interazione con una coda. AQ fornisce un meccanismo flessibile per la comunicazione bidirezionale e asincrona tra le applicazioni partecipanti.

Oracle Business Activity Monitoring (BAM)

Per la pubblicazione di dati su oggetti dati in un server Oracle BAM.

Banca dati

Per l'interazione con database Oracle e non Oracle tramite JDBC e Oracle Business Intelligence (che è un tipo di origine dati speciale).

FTP e file

Per lo scambio di file (lettura e scrittura) su file system locali e file system remoti (tramite l'uso del protocollo di trasferimento file (FTP)).

Java Messaging Service (JMS)

Per l'interazione con JMS. L'architettura JMS utilizza un'interfaccia client per molti server di messaggistica.

Message Queue (MQ)

Per lo scambio di messaggi con i sistemi di accodamento WebSphere MQ.

Applicazioni Oracle

Per l'interazione con il set di applicazioni aziendali integrate di Oracle Application.

Oracle B2B

Per sfogliare i metadati B2B nel repository del servizio metadati (MDS) e selezionare le definizioni dei documenti.

Prese

Per modellare protocolli standard o non standard per la comunicazione su socket TCP / IP.

Nome servizio adattatore

La finestra Nome servizio richiede di inserire un nome, quando il tipo di adattatore viene selezionato dal pallet. Per questo esempio,File Adapterè stato selezionato. Al termine della procedura guidata, un file WSDL con questo nome di servizio viene visualizzato nel Navigatore applicazioni per il componente del servizio del processo BPEL (per questo esempio, denominatoReadFile.wsdl). Il nome del servizio deve essere univoco all'interno del progetto. Questo file di configurazione include le impostazioni di configurazione dell'adattatore specificate con questa procedura guidata. Vengono creati anche altri file di configurazione (come file di intestazione e file specifici per l'adattatore). Questi file vengono visualizzati nel Navigatore applicazioni.

I monitor di processo BPEL in Oracle BPEL Designer possono essere configurati selezionando Monitor nella parte superiore di Oracle BPEL Designer.

In questa fase, è necessario configurare Oracle BAM Adapter.

Il processo BPEL del cliente invia un messaggio al processo BPEL del servizio e il processo BPEL del servizio non è tenuto a rispondere come mostrato nella figura seguente -

Il processo BPEL client richiede un collegamento partner valido e un'attività invoke.
Il processo BPEL del servizio necessita di un'attività di ricezione.
Come per tutte le attività dei partner, il file WSDL (Web Services Description Language) definisce l'interazione. Il file WSDL è come mostrato di seguito.

<wsdl:portType name = "BPELProcess">
   <wsdl:operation name = "process">
      <wsdl:input message = "client:BPELProcessRequestMessage" />
      <wsdl:output message = "client:BPELProcessResponseMessage"/>
   </wsdl:operation>
</wsdl:portType>

Il Processo BPEL del Cliente invia una richiesta al Processo BPEL del Servizio (d1 nella figura sotto) e riceve una risposta immediata (d2 nella figura sotto). Ad esempio, un utente richiede l'iscrizione a un modulo di domanda online per l'ammissione a un college e riceve immediatamente la conferma tramite posta elettronica che la sua richiesta è stata accettata.

Il processo BPEL client necessita di un'attività invoke. La porta sul lato client invia la richiesta e riceve la risposta.
Il processo BPEL del servizio richiede un'attività di ricezione per accettare la richiesta in arrivo e un'attività di risposta per restituire le informazioni richieste o un messaggio di errore (un errore; f1 nella figura seguente) definito nel WSDL.
Come per tutte le attività dei partner, il file WSDL (Web Services Description Language) definisce l'interazione. Il file WSDL è come mostrato di seguito.

WSDL File

<wsdl:portType name = "BPELProcess">
   <wsdl:operation name = "process">
      <wsdl:input message = "client:BPELProcessRequestMessage" />
      <wsdl:output message = "client:BPELProcessResponseMessage"/>
   </wsdl:operation>
</wsdl:portType>

Il Processo BPEL del Cliente invia una richiesta al Processo BPEL del Servizio (d1 nella figura sotto riportata) e attende fino a quando il servizio risponde (d2 nella figura sotto riportata).

Ad esempio, un utente richiede l'iscrizione a un modulo di domanda online per l'ammissione a un college e la richiesta non può essere confermata a meno che non venga accettata presso l'ufficio di ammissione.

Il processo BPEL client necessita di un'attività invoke per inviare la richiesta e un'attività di ricezione per ricevere la risposta.
Il processo BPEL del servizio richiede un'attività di ricezione per accettare la richiesta in arrivo e un'attività di invocazione per restituire le informazioni richieste o un errore.

Note - La differenza tra la risposta da un processo BPEL sincrono e asincrono è che il servizio sincrono utilizza un'attività di risposta per rispondere al client e un servizio asincrono utilizza un'attività invoke.
Come per tutte le attività dei partner, il file WSDL (Web Services Description Language) definisce l'interazione. Il file WSDL è come mostrato di seguito.

WSDL File

<wsdl:portType name = "BPELProcess">
   <wsdl:operation name = "process">
      <wsdl:input message = "client:BPELProcessRequestMessage"/>
   </wsdl:operation>
</wsdl:portType>

<wsdl:portType name = "BPELProcessCallback">
   <wsdl:operation name = "processResponse">
      <wsdl:input message = "client:BPELProcessResponseMessage"/>
   </wsdl:operation>
</wsdl:portType>

Il Processo BPEL del Cliente invia una richiesta al Processo BPEL del Servizio (d1 nella figura sottostante) e attende fino a quando il servizio non risponde o fino a quando non viene raggiunto un certo limite di tempo, a seconda di quale evento si verifica per primo. (d2 nella figura sotto).

Ad esempio, un utente richiede l'iscrizione a un modulo di domanda online per l'ammissione a un college e la richiesta viene annullata se l'utente non riceve una risposta di conferma entro un determinato periodo di tempo.

Il processo BPEL client necessita di un'attività invoke per inviare la richiesta e un'attività di prelievo con due rami: un file onMessage ramo e un onAlarmramo. Se la risposta arriva dopo la scadenza del limite di tempo, il messaggio va nella coda dei messaggi non recapitabili.

Il processo BPEL del servizio richiede un'attività di ricezione per accettare la richiesta in arrivo e un'attività di invocazione per restituire le informazioni richieste o un errore.

Come per tutte le attività dei partner, il file WSDL (Web Services Description Language) definisce l'interazione.

In questo capitolo impareremo le interazioni asincrone con un timer di notifica. Considera i seguenti punti relativi alle interazioni asincrone:

Il Processo BPEL del Cliente invia una richiesta al Processo BPEL del Servizio e attende una risposta, sebbene una notifica venga inviata allo scadere di un timer.
Il Processo BPEL del Cliente continua ad attendere la risposta dal Processo BPEL del Servizio anche dopo che il timer è scaduto.
Il processo BPEL client necessita di un'attività di ambito contenente un'attività invoke per inviare la richiesta e un'attività di ricezione per accettare la risposta. IlonAlarm il gestore dell'attività dell'ambito ha un limite di tempo e istruzioni su cosa fare quando scade il timer.
Ad esempio, attendi 60 secondi, quindi invia un avviso che indica che il processo sta impiegando più tempo del previsto.
Il processo BPEL del servizio richiede un'attività di ricezione per accettare la richiesta in arrivo e un'attività di invocazione per restituire le informazioni richieste o un errore.
Come per tutte le attività dei partner, il file WSDL (Web Services Description Language) definisce l'interazione.

In questo capitolo apprenderemo il concetto di una richiesta e risposte multiple.

Il Processo BPEL del cliente invia una singola richiesta al Processo BPEL del servizio e riceve in cambio più risposte.

Ad esempio, la richiesta può essere quella di ordinare un prodotto online e la prima risposta può essere il tempo di consegna stimato, la seconda una conferma di pagamento e la terza una notifica che il prodotto è stato spedito. In questo esempio, sono previsti il numero e il tipo di risposte.
Il processo BPEL client necessita di un'attività invoke per inviare la richiesta e un'attività in sequenza con tre attività di ricezione.
Il processo BPEL del servizio richiede un'attività di ricezione per accettare il messaggio dal client e un attributo di sequenza con tre attività di richiamo, una per ciascuna risposta.
Come per tutte le attività dei partner, il file WSDL (Web Services Description Language) definisce l'interazione.

In questo capitolo apprenderemo il concetto di una richiesta e una delle due possibili risposte.

Il Processo BPEL del Cliente invia una singola richiesta al Processo BPEL del Servizio e riceve una delle due possibili risposte.

Ad esempio, la richiesta può essere quella di ordinare un prodotto online e la prima risposta può essere un messaggio di disponibilità o un messaggio di esaurimento.
Il processo BPEL del cliente richiede quanto segue:

Un'attività invoke per inviare la richiesta.
Un'attività di prelievo con due rami: uno onMessage per la risposta in magazzino e istruzioni su cosa fare se viene ricevuto un messaggio in magazzino.
Un secondo onMessage per la risposta di esaurimento scorte e istruzioni su cosa fare se viene ricevuto un messaggio di esaurimento scorte.

Il processo BPEL del servizio richiede un'attività di ricezione per accettare il messaggio dal client e un'attività di cambio con due rami, uno con un'attività invoke che invia il messaggio in magazzino se l'articolo è disponibile e un secondo ramo con un invio di attività invoke il messaggio di esaurimento scorte se l'articolo non è disponibile.

Come per tutte le attività dei partner, il file WSDL (Web Services Description Language) definisce l'interazione.

In questo capitolo capiremo il concetto di una richiesta, una risposta obbligatoria e una risposta facoltativa.

Il Servizio BPEL del Cliente invia una singola richiesta al Processo BPEL del Servizio e riceve una o due risposte.
Qui la richiesta è ordinare un prodotto online. Se il prodotto è in ritardo, il servizio invia un messaggio per informare il cliente. In ogni caso, il servizio invia sempre una notifica quando l'articolo viene spedito.
Il servizio BPEL client necessita di un'attività di ambito contenente l'attività invoke per inviare la richiesta e un'attività di ricezione per accettare la risposta obbligatoria. Per il messaggio opzionale, ilonMessageil gestore dell'attività di ambito viene impostato insieme alle istruzioni su cosa fare se viene ricevuto il messaggio facoltativo (ad esempio, avvisare che il prodotto è stato ritardato). Il processo BPEL client attende di ricevere la risposta obbligatoria. Se la risposta obbligatoria viene ricevuta per prima, il processo BPEL prosegue senza attendere la risposta facoltativa.
Il processo BPEL del servizio richiede un'attività di ambito contenente l'attività di ricezione e un'attività di invocazione per inviare il messaggio di spedizione obbligatorio e onAlarm gestore per inviare il messaggio ritardato facoltativo se un timer scade (ad esempio, inviare il messaggio ritardato se l'articolo non viene spedito entro 24 ore).
Come per tutte le attività dei partner, il file WSDL (Web Services Description Language) definisce l'interazione.

Ora impareremo il concetto di elaborazione parziale in BPEL.

Il processo BPEL del cliente invia una richiesta al processo BPEL del servizio e riceve una risposta immediata, ma l'elaborazione continua sul lato del servizio.
Questo modello può anche includere più callback di ripresa, seguite da un'elaborazione a lungo termine.
Ad esempio, il cliente invia una richiesta per l'acquisto di un pacchetto vacanza e il servizio invia una risposta immediata confermando l'acquisto, quindi continua a prenotare l'hotel, il volo, l'auto a noleggio e così via.
Il processo BPEL client necessita di un'attività invoke per ogni richiesta e un'attività di ricezione per ogni risposta per transazioni asincrone, o solo un'attività invoke per ogni transazione sincrona.
Il processo BPEL del servizio richiede un'attività di ricezione per ogni richiesta dal client e un'attività di richiamo per ogni risposta. Una volta terminate le risposte, il Processo BPEL del servizio in quanto il servizio può continuare con la sua elaborazione, utilizzando le informazioni raccolte nella transazione per eseguire le attività necessarie senza ulteriori input da parte del cliente.
Come per tutte le attività dei partner, il file WSDL (Web Services Description Language) definisce l'interazione.

In questo capitolo apprenderemo le interazioni multiple delle applicazioni con BPEL.

Quando ci sono più di due applicazioni coinvolte in una transazione.
Questo modello di transazione da A a B a C ad A può gestire molte transazioni contemporaneamente. Pertanto, è necessario un meccanismo per tenere traccia di quale messaggio va e dove.
Questo può essere gestito utilizzando WS-Addressing o set di correlazione.

Abbiamo discusso in uno dei capitoli precedenti che il servizio Web sincrono è uno, che fornisce una risposta immediata a un'invocazione.

Nello screenshot mostrato di seguito, abbiamo creato un processo BPEL sincrono che ha un'attività di ricezione per accettare la richiesta dell'utente. L'attività di risposta invia contemporaneamente la risposta.

Come discusso in precedenza, il servizio Web asincrono è quello che invia una richiesta ad un altro servizio Web e attende la risposta.

Nello screenshot mostrato di seguito, abbiamo creato il processo BPEL asincrono che ha un'attività di ricezione per accettare la richiesta dell'utente. L'attività di assegnazione assegna inoltre valori ai diversi elementi nella richiesta.

Successivamente, l'attività invoke richiama l'applicazione HelloWorld che invia la risposta simultaneamente e che viene acquisita nell'attività di ricezione.

Inoltre, abbiamo l'attività di callback che infine genera output e invia la risposta in modo asincrono.

Se fai doppio clic sul file receiveInput o callbackClient, vedrai che ognuno di loro ha una sola variabile.

receiveInput → inputVariable
callbackClient → outputVariable

In questo capitolo, capiremo come funziona il flusso parallelo in BPEL.

Cos'è l'attività di flusso?

Un'attività di flusso contiene in genere molte attività di sequenza e ogni sequenza viene eseguita in parallelo. Un'attività di flusso può contenere anche altre attività.

Ad esempio, due callback asincroni vengono eseguiti in parallelo, in modo che un callback non debba attendere prima il completamento dell'altro. Ogni risposta viene memorizzata in una variabile globale diversa.

Nell'attività di flusso, il codice BPEL determina il numero di rami paralleli. Tuttavia, spesso il numero di rami richiesti è diverso a seconda delle informazioni disponibili.

Cos'è l'attività FlowN?

L'attività flowN crea più flussi uguali al valore di N, che viene definito in fase di esecuzione in base ai dati disponibili e alla logica all'interno del processo. C'è un incremento della variabile Indice ogni volta che viene creato un nuovo ramo, fino a quando la variabile Indice raggiunge il valore di N.

L'attività flowN esegue attività su un numero arbitrario di elementi di dati. Man mano che il numero di elementi cambia, il processo BPEL si adatta di conseguenza.

I rami creati da flowN svolgono le stesse attività, ma utilizzano dati diversi. Ogni ramo utilizza la variabile indice per cercare le variabili di input. La variabile index può essere utilizzata nell'espressione XPath per acquisire i dati specifici per quel ramo.

BPEL applica la logica per effettuare scelte attraverso la ramificazione condizionale. Le due diverse azioni basate sulla ramificazione condizionale sono mostrate di seguito:

Cambia attività

In questo metodo, imposti due o più rami, con ogni ramo sotto forma di un'espressione XPath. Se l'espressione è vera, il ramo viene eseguito. Se l'espressione è falsa, il processo BPEL passa alla condizione del ramo successivo, fino a quando non trova una condizione di ramo valida, incontra un altro ramo o esaurisce i rami. Se più di una condizione di ramo è vera, allora BPEL esegue il primo ramo vero.

Mentre l'attività

È possibile utilizzare un'attività while per creare un ciclo while per selezionare tra due azioni.

Per capire come utilizzare la gestione dei guasti, dobbiamo apprendere l'architettura di base di un Service Composite in Oracle SOA Suite.

Service components- Processi BPEL, Regola aziendale, Attività umana, Mediatore. Questi sono usati per costruire un'applicazione composita SOA.
Binding components - Stabilire una connessione tra un composito SOA e il mondo esterno.
Services - Fornisce un punto di ingresso per l'applicazione composita SOA.
Binding - Definisce i protocolli che comunicano con il servizio come SOAP / HTTP, adattatore JCA, ecc.
WSDL - Definisce la definizione del servizio di un servizio web.
References - Consente a un'applicazione composita SOA di inviare messaggi a servizi esterni
Wires - Consente la connessione tra i componenti del servizio.

Tipi di guasti

Vediamo ora i diversi tipi di guasti.

Difetti aziendali

Si verifica quando l'applicazione esegue l'attività THROW o un INVOKE riceve un errore come risposta. Il nome dell'errore è specificato dal componente del servizio del processo BPEL. Il gestore degli errori che utilizza il nome dell'errore e la variabile dell'errore rileva questo errore.

Errori di runtime

Questo viene lanciato dal sistema. Questi difetti sono associati aRunTimeFaultMessage e sono inclusi in

http://schemas.oracle.com/bpel/extensionnamespace.

Modalità di gestione dei guasti

In questa sezione apprenderemo i diversi modi di gestione dei guasti.

Lancia attività

L'attività di lancio genera esplicitamente l'errore. Il blocco catch rileva questo errore e le azioni corrispondenti vengono eseguite in tal modo.

Utilizzando l'attività di lancio, è possibile lanciare errori aziendali e all'interno dell'ambito creato, è possibile rilevare questo errore e reindirizzare al chiamante (consumatore) per agire.
Invece dell'approccio di cui sopra, lanci lo stesso errore catturato nell'attività di cattura dell'ambito creato. Nell'ambito principale, puoi rilevare questo errore utilizzando l'attività catchall.

Framework gestore degli errori (EHF)

I 2 file principali utilizzati in EHF sono:

Fault-Policy.xml
Fault-Bindings.xml

Ogni volta che il processo BPEL genera un errore, l'EHF controllerà se l'errore esiste nei file Fault-Bindings.xml. In tal caso, verrà eseguita l'azione nel file Fault-Policy.xml. Se l'azione non viene trovata, l'errore verrà lanciato e verrà gestito nel blocco catch.

Il framework di gestione dei guasti (Fault-Policy.xml e Fault-Bindings.xml) è mantenuto all'interno di un SOA Composite.

I gestori di errori come catch e catchall sono all'interno di un BPEL per rilevare tutti i difetti, ma fault policies will only be executed when an invoke activity fails.

In questo capitolo vedremo diversi scenari relativi al reinvio di un processo in errore.

Scenario A

Il codice BPEL utilizza una politica di errore e un errore viene gestito utilizzando l'attività "ora-intervento-umano". L'errore viene quindi contrassegnato come ripristinabile e lo stato dell'istanza viene impostato su "In esecuzione".

Scenario B

Il codice BPEL utilizza una policy di errore e un errore viene rilevato e rilanciato utilizzando l'azione "ora-rethrow-fault". L'errore viene quindi contrassegnato come ripristinabile e lo stato dell'istanza viene impostato su "Faulted"; a condizione che l'errore sia recuperabile (come l'URL non era disponibile).

Esistono diversi metodi per incorporare codice Java e Java EE nei processi BPEL. Di seguito sono riportati alcuni metodi importanti:

Avvolgi come servizio SOAP (Simple Object Access Protocol)
Incorpora frammenti di codice Java in un processo BPEL con il tag bpelx - exec
Usa una facciata XML per semplificare la manipolazione del DOM
Usa bpelx - esegui i metodi integrati
Usa il codice Java racchiuso in un'interfaccia di servizio

L'attività Java Embedding ci consente di aggiungere attività in un processo BPEL. Possiamo scrivere uno snippet Java utilizzando le librerie JDK standard, le API BPEL, le classi Java personalizzate e di terze parti incluse nei file JAR nei compositi SCA distribuiti (nella directory SCA-INF / lib) e le classi e le librerie Java disponibili sul Classpath per SOA Tempo di esecuzione della suite.

Java Embedding significa funzionalità nascoste al suo interno, in modo poco disaccoppiato. Il codice Java è difficile da mantenere. Incorporando Java in BPEL (basato su XML), iniziamo a mescolare la tecnologia, che richiede competenze diverse e un costoso XML per il marshalling e l'unmarshalling di oggetti Java.

I migliori casi d'uso per Java Embedding sembrano essere per la registrazione / traccia avanzata o per convalide / trasformazioni speciali. Tuttavia, non sostituire le funzionalità integrate del motore BPEL, nonché gli altri componenti in SOA Suite 11g e gli adattatori forniti con esso.

XPath viene utilizzato principalmente per manipolare XML nel processo BPEL. Ci sono alcune preziose funzioni Xpath che possono essere usate per manipolare XML. Vediamo le funzioni di seguito.

bpel: getVaribleData (varName, partName, xpathStr)

Può essere utilizzato per estrarre un insieme di elementi da una variabile, utilizzando un'espressione XPath.

<bpel:copy>
   <bpel:from>
   <![CDATA[count(bpel:getVariableData(‘$Variable','$partName')/ns:return)]]>
   </bpel:from>
      <bpel:to variable = "itemNumber">
   </bpel:to>
</bpel:copy>

bpel: getLinkStatus ()

Può essere utilizzato per valutare e restituire un valore booleano se un particolare collegamento è attivo o inattivo.

: getVariableProperty (stringa, stringa)

Ciò è utile per estrarre le proprietà nelle variabili.

: doXSLTTransform ()

Questo esegue le trasformazioni XSLT.

corda ()

Questo può essere usato per estrarre il contenuto del testo dagli elementi piuttosto usando / text ().

string-length ()

Questa funzione viene utilizzata per calcolare la lunghezza della stringa. Ma l'operatore! = Sembra non funzionare con l'output di questa funzione. Quindi puoi usare> o <piuttosto usare! =.

Valori booleani

È possibile assegnare valori booleani con la funzione booleana XPath.

<assign>
   <!-- copy from boolean expression function to the variable -->
   <copy>
      <from expression = "true()"/>
      <to variable = "output" part = "payload" query="/result/approved"/>
   </copy>
</assign>

Assegnazione di una data o di un'ora

È possibile assegnare il valore corrente di un campo data o ora utilizzando la funzione Oracle BPEL XPath getCurrentDate, getCurrentTime o getCurrentDateTime, rispettivamente.

<!-- execute the XPath extension function getCurrentDate() -->
<assign>
   <copy>
      <from expression = "xpath20:getCurrentDate()"/>
      <to variable = "output" part = "payload"
      query = "/invoice/invoiceDate"/>
   </copy>
</assign>

Concatenazione di stringhe

Anziché copiare il valore di una variabile di stringa (o di una parte o di un campo di variabile) in un'altra, è possibile prima eseguire la manipolazione delle stringhe, come concatenare più stringhe.

<assign>
   <!-- copy from XPath expression to the variable -->
   <copy>
      <from expression = "concat('Hello ',
      bpws:getVariableData('input', 'payload', '/p:name'))"/>
      <to variable = "output" part = "payload" query = "/p:result/p:message"/>
   </copy>
</assign>

Assegnazione di valori letterali di stringa

È possibile assegnare valori letterali stringa a una variabile in BPEL.

<assign>
   <!-- copy from string expression to the variable -->
   <copy>
      <from expression = "'GE'"/>
      <to variable = "output" part = "payload" query = "/p:result/p:symbol"/>
   </copy>
</assign>

Assegnazione di valori numerici

È possibile assegnare valori numerici nelle espressioni XPath.

<assign>
   <!-- copy from integer expression to the variable -->
   <copy>
      <from expression = "100"/>
      <to variable = "output" part = "payload" query = "/p:result/p:quantity"/>
   </copy>
</assign>

Note - Alcune funzioni XSLT sono state utilizzate per trasformare un documento XML.

La correlazione BPEL abbina i messaggi in entrata con un'istanza di processo specifica. Quando è necessario associare dati specifici a un'istanza specifica di un processo aziendale, si utilizza la correlazione.

Ad esempio, durante la creazione di un processo che verifica un numero di conto e controlla il limite di credito del conto. Una volta verificato, il processo effettua una chiamata a un altro sistema per controllare l'inventario e, se l'articolo è disponibile, genera un ordine di acquisto. Come fa l'ordine di acquisto a sapere quale conto deve essere addebitato? La risposta a questa domanda è la correlazione.

Insiemi di correlazione

I set di correlazione vengono utilizzati per identificare in modo univoco le istanze del processo. Fornisci a ciascun set di correlazione un nome univoco e quindi lo definisci da una o più proprietà. Ogni proprietà ha un nome e un tipo (ad esempio, stringa o numero intero).

Alias proprietà

È necessario definire l'alias di proprietà per ciascuna proprietà nel set di correlazioni. Un alias di proprietà è una mappatura che lega la proprietà ai valori di input o di output.

Punti importanti

Considera i seguenti punti importanti relativi a Correlation Sets and Message Aggregation -

Un processo che contiene più di un'attività di ricezione o prelievo deve avere un insieme di correlazioni.
I set di correlazione vengono inizializzati con i valori dei messaggi in entrata o in uscita del processo.
Se si dispone di gruppi di messaggi associati a un processo specifico, è possibile impostare uno o più set di correlazioni da gestire.

I servizi Web asincroni di solito impiegano molto tempo per restituire una risposta e, pertanto, un componente del servizio del processo BPEL deve essere in grado di scadere, o rinunciare ad aspettare, e continuare con il resto del flusso dopo un certo periodo di tempo. È possibile utilizzare l'attività di prelievo per configurare un flusso BPEL per attendere un periodo di tempo specificato o per continuare a svolgere i suoi compiti. Per impostare un periodo di scadenza per il tempo, è possibile utilizzare l'attività di attesa. Per gestire i messaggi, gli eventi possono essere utilizzati in particolare quando il processo aziendale è in attesa di richiamate dai servizi Web dei partner.

Eventi

BPEL supporta due tipi di eventi:

Eventi messaggio

Questi eventi vengono attivati dai messaggi in arrivo tramite il richiamo dell'operazione sui tipi di porta.

Eventi di allarme

Questi eventi sono legati al tempo e vengono attivati dopo una certa durata o in un momento specifico.

Spesso, però, è più utile aspettare più di un messaggio, di cui solo uno si verificherà.
Gli eventi di allarme sono utili quando si desidera che il processo attenda una richiamata per un determinato periodo di tempo, ad esempio 15 minuti.

Se non viene ricevuta alcuna richiamata, il flusso del processo continua come previsto.
Utile in architetture orientate ai servizi liberamente accoppiate, in cui non è possibile fare affidamento sul fatto che i servizi Web siano sempre disponibili.

Scegli attività

L'attività di prelievo ha 2 rami:

onMessage - il codice su questo ramo è uguale al codice per ricevere una risposta prima che fosse aggiunto un timeout.
onAlarm - questa condizione ha un codice per un timeout di un minuto.

Aspetta attività

L'attività di attesa consente a un processo di attendere per un determinato periodo di tempo o fino al raggiungimento di un limite di tempo. È necessario specificare esattamente uno dei criteri di scadenza.

Il processo BPEL può essere utilizzato per il servizio di notifica. Il processo può essere progettato per inviare quanto segue:

email
messaggio vocale
messaggistica istantanea (IM) o
notifiche del servizio di messaggi brevi (SMS)

Per i servizi sopra menzionati, è possibile configurare il canale per il messaggio in entrata e in uscita.

I sensori compositi all'interno di un'applicazione SOA offrono la possibilità di definire campi tracciabili sui messaggi e consentono di trovare un'istanza composita specifica cercando uno o più campi all'interno di un messaggio. Ad esempio, un sensore potrebbe essere definito per un numero d'ordine all'interno di un messaggio, permettendoci così di trovare l'istanza in cui si trova il numero d'ordine in questione.

I sensori compositi possono essere definiti all'interno di un'applicazione SOA in diversi componenti:

Componente di servizio (servizio esposto)
Componente di riferimento (riferimento esterno)
Mediatore o componente BPEL che si è iscritto a un evento aziendale (la pubblicazione di un evento non può avere un sensore)

Diversi modi per definire il sensore composito

Esistono diversi modi per definire un sensore composito:

Specificando una variabile esistente come sensore.
Da un'espressione con l'aiuto del generatore di espressioni.
Utilizzando le proprietà (ad esempio le proprietà dell'intestazione del messaggio).

Sensori in Enterprise Manager

La definizione di un sensore consente una rapida ricerca dei dati all'interno di un'istanza composita nella EM Console.

Nella dashboard di EM Console, un utente può cercare istanze per nome e valore del sensore.

Nella scheda "Istanze di flusso", è possibile selezionare i sensori dai menu a discesa e utilizzare valori simili a caratteri jolly per il valore del sensore.

Nuove attività sono state aggiunte nella 2.0 che hanno sostituito quelle nella 1.1.

<perOgni>

Questa attività aiuta a ripetere l'insieme di attività. L'attività sostituisce l'attività FlowN nella versione BPEL 1.1.

<repeatUntil>

Questa attività è utile se il corpo di un'attività deve essere eseguito almeno una volta. La condizione di espressione XPath nell'attività repeatUntil viene valutata al termine del corpo dell'attività.

<if> - <elseif> - <else>

Questa attività sostituisce l'attività di passaggio in BPEL 2.0. L'attività consente di definire il comportamento condizionale per attività specifiche per decidere tra due o più rami. Viene selezionata solo un'attività per l'esecuzione da un insieme di rami.

<compensateScope>

Questa attività aiuta a compensare l'ambito figlio specificato.

<rethrow>

Questa attività è stata aggiunta ai gestori di errori. Consente di rilanciare un errore originariamente catturato dal gestore degli errori che lo racchiude immediatamente.