Nell‘articolo precedente è stato illustrato come creare un processo BPEL tramite lo strumento JDeveloper. Il processo creato eseguiva l‘echo della stringa in input verso il chiamante. Ma i processi di business spesso svolgono operazioni molto più complesse e strutturate, e il linguaggio BPEL mette a disposizione diversi costrutti per implementare questo tipo di attività. Le tre operazioni che è possibile effettuare con BPEL riguardano la gestione delle comunicazioni asincrone, l‘intercettazione e la gestione degli errori, la gestione dei flussi di lavoro.

Gestione delle comunicazioni asincrone

BPEL permette di gestire le comunicazioni asincrone tra vari Web Service. Come è stato anticipato nel primo articolo della serie, una chiamata asincrona permette di effettuare una invoke verso un partner senza la necessità di allocare risorse condivise. La gestione delle chiamate asincrone viene effettuata implicitamente, ossia non specificando, nell’attività di invoke, il parametro di risposta della chiamata.
Come esempio, si può analizzare il seguente scenario: si ha un processo BPEL che effettua determinate operazioni; durante l’elaborazione, il processo ha però la necessità di chiamare in maniera asincrona un web service esterno per delegare ad esso lo svolgimento di alcune operazioni. Avendo effettuato una chiamata asincrona, il controllo di flusso rimane nel processo BPEL, che continua quindi la sua elaborazione. Ma cosa avviene nel caso in cui il processo BPEL ha necessità di conoscere l’esito dell’elaborazione del web service contattato precedentemente in maniera asincrona? Una “richiamata” del web service verso il processo BPEL deve necessariamente colloquiare con la medesima istanza del processo che ha effettuato la chiamata. Risulta quindi evidente la necessità di impostare una relazione tra i messaggi scambiati e le istanze dei processi in corso che hanno generato quei messaggi. Per far sì che questo accada, si può agire in due modi:

1. Associare una chiave univoca al processo stesso quando questo ha inizio;
2. Associare a un application data un’unica chiave di istanza.

La tecnologia BPEL mette a disposizione dei costrutti per implementare la seconda soluzione, sfruttando quindi i campi all’interno dell’application data per identificare univocamente le istanze dei processi. I campi utilizzati sono detti properties: una property è un costrutto appartenente al WSDL extension element che presenta un nome e un tipo:

Per assegnare il valore della property si deve far riferimento al messaggio WSDL di richiesta, ossia al messaggio di input del processo: nel WSDL, infatti, viene definito un oggetto propertyAlias, che rappresenta la relazione tra la property stessa e i valori contenuti nel messaggio. Per poter valorizzare questa proprietà, il propertyAlias specifica la property a cui fa riferimento, il messaggio da analizzare, la parte di esso, e la query XPATH per raggiungere il valore desiderato all’interno del messaggio. 

propertyName="instance:ID"
messageType="RequestMessage"
part="payload"
query="//instanceID"
/>

L’associazione di queste due proprietà costituisce quindi una chiave univoca che identifica una particolare istanza del processo attivo, e prende il nome di correlation set.

Prima di poter utilizzare il correlation set, l’insieme delle properties a cui fa riferimento deve essere inizializzato: in una conversazione multi-partner, colui che inizia lo scambio di messaggi, e che quindi crea i valori delle properties, viene detto initiator.

È importante notare che questo costrutto rappresenta la chiave identificativa di un’istanza, quindi ha la necessità di essere immutabile durante tutto il corso del processo: questo è il motivo per cui ad ogni altra attività che fa riferimento a un determinato correlation set non è permesso modificare nessuna delle proprietà associate ad esso.

Esiste il caso particolare in cui il correlation set deve essere impostato alla creazione dell’istanza del processo: questo può avvenire inserendo una porzione di codice nella prima attività, quella di receive della chiamata esterna, impostando chiaramente l’inizializzazione a true. 

Una volta identificato univocamente il processo, quindi, è possibile realizzare una conversazione asincrona bilaterale tra il processo BPEL e i suoi partner.

La natura stessa della “conversazione” prevede che i due partecipanti dialoghino tra loro. Per questo motivo, da un lato il web service deve poter richiamare il processo, mentre il processo deve possedere un’interfaccia verso il chamante, e attendere la chiamata di risposta dell’elaborazione.

Per permettere all’istanza di attendere la richiamata del web service, il linguaggio BPEL mette a disposizione un costrutto particolare, detto PICK. Questa attività, considerata una variante della receive, attende sostanzialmente l’arrivo della risposta dall’esterno: 

La durata dell’attesa può essere configurata in due modi diversi:

specificando il numero di messaggi da attendere prima della riattivazione dell’istanza BPEL;
specificando un timeout temporale, espresso per durata o puntualmente, ossia indicando una data precisa di scadenza, come mostrato in figura 2.

Il codice seguente mostra come viene implementata l’attività di pick.

operation="initiate"
variable="OnMessage_initiate_InputVariable">


query="/client:BPELProcessRequest/client:input"/>
query="/client:BPELProcessResponse/client:result"/>






query="/client:BPELProcessRequest/client:input"/>
query="/client:BPELProcessResponse/client:result"/>

Come si può vedere dal listato, l’attività di pick prevede un flusso di lavoro quando si verifica il timeout specificato: questo viene implementato tramite il tag “onAlarm”.

Gestione delle eccezioni

Come tutti i prodotti software, anche un processo di BPEL può sollevare delle eccezioni durante l’elaborazione. Il linguaggio BPEL mette a disposizione degli oggetti detti fault handlers che hanno il compito di catturare e gestire le situazioni eccezionali, sia ricevute dall’esterno, che lanciate dal processo stesso.
Un caso tipico di ricezione di un errore esterno può essere fault sollevato dall’invocazione di un web service: i WSDL, infatti, prevedono dei tag particolari che consentono di rendere visibile il tipo di errore che può essere lanciato.

Internamente al processo, invece, si possono verificare due casi:

Il primo caso è quello di esplicito lancio di un fault dalla logica del processo: questa situazione può essere implementata attraverso l’attività throw, che dichiara un nome qualificato di un fault e può mettere a disposizione una variabile che associa i dati al fault stesso.

Il secondo caso è un fault sollevato a runtime: l’architettura BPEL consente di riconoscere a runtime delle situazioni che sollevano eccezione, come ad esempio un’assegnazione incompatibile tra tipi, variabili non inizializzate e messaggi correlati non validi. In questi casi l’istanza del processo lancia una fault standard BPEL.

Per la gestione di questi casi eccezionali, BPEL introduce il meccanismo dei fault handlers, che hanno il compito di catturare e gestire questo tipo di situazione. Quando viene sollevato un fault, questi oggetti terminano alcune attività in corso, come ad esempio la receive, invoke o reply; le attività a vita breve, come ad esempio un assign, non vengono interrotte volutamente, proprio perchè comunque termineranno a breve.
Sintatticamente, un fault handler viene implementato tramite gli elementi catch e catchAll: il primo consente di specificare il nome qualificato del fault ( come ad esempio quelli lanciati dai costrutti throw), mentre l’altro consente la cattura di ogni tipo di eccezione.

Gestione dei flussi di lavoro

BPEL mette a disposizione alcuni costrutti che permettono di gestione il flusso delle operazioni implementate.
Come in ogni processo di business, diverse azioni possono essere eseguite in sequenza o in parallelo: nel primo caso, le operazioni da svolgere devono essere racchiuse nel tag sequence, nel secondo il tag da utilizzare è il flow. Nell’esecuzione parallela, BPEL rende possibili alcuni punti di sincronizzazione dei diversi flussi attraverso la definizione di dipendenze temporali, implementate con i costrutti link, target e source.
È possibile gestire anche cicli di esecuzione e blocchi condizionali attraverso i costrutti while e switch, che vengono utilizzati come nei normali linguaggi di programmazione. È interessante notare come sia possibile utilizzare valori interni alle variabili, calcolati quindi a runtime, per il calcolo delle espressioni condizionali: questo aspetto rende il linguaggio BPEL del tutto simile alla maggior parte dei linguaggi imperativi e a oggetti.

Conclusioni

In questo articolo sono state presentate alcune situazioni particolari che possono essere gestite dall’architettura BPEL. Questo linguaggio presenta notevoli potenzialità e possibilità di espansione, come ad esempio l’integrazione di attività umane all’interno dei processi, la gestione delle mail e degli sms, e altre attività non analizzate in questa serie.

Riferimenti

[1] Oracle BPEL Process Manager
http://www.oracle.com/technology/products/ias/bpel/index.html

[2] S. Blanvalet, J. Bolie, M. Cardella, S. Carey, P. Chandran, Y. Coene, K. Geminiuc, M.B. Juric, T.H. Nguyen, A. Poduval, L. Pravin, J. Thomas, D. Todd, “BPEL Cookbook. Best Practices for SOA-based integration and composite applications development”, Packt Publishing Ltd, 2006

[3] Daniel Rubio, “BPEL: Web Services orchestration, hands-on with ActiveBPEL”, 2005

[4] B. Mathew, P. Sarang, M.B Juric, “Business Process Execution Languange for Web Service”, Packt Publishing Ltd, 2006

[5] Oracle BPEL Process Manager – Quick Start Tutorial

[6] Web Services Description Language (WSDL) 1.1, 2001
http://www.w3c.org/TR/2001/NOTE-wsdl-20010315

[7] SOAP (Simple Object Access Protocol) 1.1 Specification, 2000
http://www.w3c.org/TR/2000/NOTE-SOAP-20000508/

[8] Business Process Execution Language for Web Services (BPEL4WS) 1.1, 2003
http://www-106.ibm.com/developerworks/webservices/library/ws-bpel/

[9] Programming BPEL version 6.25.3
http://www.collaxa.com