Business Process

La definizione di modalità standard per descrivere processi di business ha lo scopo di garantire l’interoperabilità fra le organizzazioni. Concludere transazioni commerciali è più semplice se un’organizzazione può comprendere i processi di business di un’altra. La piattaforma ebXML descrive una modalità standard per la definizione di Processi di Business. Per raggiungere questo obiettivo, è stato definito lo Schema di Specifica dei Processi di Business (Business Process Specification Schema, BPSS) [13].

Lo schema supporta la specifica di Transazioni di Business e la loro combinazione all’interno delle Collaborazioni di Business. Ogni Transazione di Business può essere implementata usando uno tra i molti standard disponibili. Questi schemi controllano lo scambio dei Documenti e dei messaggi che i Partner Commerciali si scambiano per portare a termine la transazione di commercio elettronico desiderata.

I Business Process vengono definiti mediante dei modelli UML e successivamente espressi mediante una struttura XML detta Business Process Specification Schema. Questo schema fornisce la semantica per specificare le transazioni e le collaborazioni come una sequenza di azioni e di stati. Questo schema è estremamente flessibile e permette agli utenti di realizzare istanze specifiche a seconda delle necessità del particolare processo realizzato. Questa flessibilità è ottenuta mediante la definizione di Core Component. La versione XML del Business Process è mantenuta nel Registry e può quindi essere riutilizzato da altre aziende. L’architettura del Business Process è costituita da quattro componenti funzionali come mostra la Figura 29:

• Una versione UML del Business Process Specification Schema. • Una versione XML del Business Process Specification Schema. • Le regole di trasformazione da modello UML a modello XML. • La definizione dei segnali per la regolamentazione delle transazioni.

Figura 29 – Relazioni fra i componenti dell’architettura ebXML

Un Business Process definisce quindi l’ordine con cui vengono inviati i messaggi all’interno di una collaborazione B2B, ma non tiene conto di come vengono creati o elaborati i dati e i messaggi scambiati.

All’interno di una collaborazione B2B i partecipanti assumano dei ruoli ben precisi, a cui corrispondono transazioni prestabilite per lo scambio di documenti. Una collaborazione può essere binaria (tra due parti) o multiparte (tra tre o più parti). Quest’ultima può essere espressa come un insieme di collaborazioni binarie.

Una transazione consiste in uno o più flussi di comunicazione.

Il Business Transaction Choreography è la componente del Business Process che si occupa di descrive l’ordinamento delle transazioni durante le collaborazioni.

Un Business Process è costituito dalle seguenti componenti (Figura 30):

• Specifica della transazione

• Specifica del flusso dei documenti • Specifica della collaborazione binaria

• Specifica della coreografia per la collaborazione binaria

• Specifica della collaborazione multiparte utilizzando gli elementi della collaborazione

Figura 30 – Componenti di un Business Process

Di seguito vengono proposti una serie di esempi che descrivono singolarmente queste componenti.

Una transazione viene definita come nel seguente esempio:

<BusinessTransaction name= Create Order > <RequestingBusinessActivity name=

isNonRepudiationRequired= true timeToAcknowledgeReceipt= P2D timeToAcknowledgeAcceptance= P3D >

<DocumentEnvelope businessDocument= Purchase Order /> </RequestingBusinessActivity>

<RespondingBusinessActivity name= isNonRepudiationRequired= true timeToAcknowledgeReceipt= P5D >

<DocumentEnvelope isPositiveResponse= true businessDocument= PO Acknowledgement /> </RespondingBusinessActivity>

</BusinessTransaction>

La transazione “Create Order” è costituita da un’attività di richiesta contenente l’ordine di

Per definire il flusso dei documenti vengono prima descritti i Business Document e successivamente ne viene definito il flusso mediante la specifica di una transazione:

<BusinessDocument name= Purchase Order specificationLocation= someplace /> <BusinessDocument name= PO Acknowledgement specificationLocation= someplace /> <BusinessDocument name= PO Rejection specificationLocation= someplace />

<BusinessDocument name= Delivery Instructions specificationLocation=vsomeplace />

<BusinessTransaction name= Create Order > <RequestingBusinessActivity name= > <DocumentEnvelope

businessDocument= ebXML1.0/PO Acknowledgement > <Attachment name= DeliveryNotesv mimeType= XML

businessDocument= ebXML1.0/Delivery Instructions specification= isConfidential= true

isTamperProof= true isAuthenticated= true > </Attachment>

</DocumentEnvelope>

</RequestingBusinessActivity>

<RespondingBusinessActivity name= > <DocumentEnvelope

businessDocument= ebXML1.0/PO Acknowledgement > </DocumentEnvelope>

<DocumentEnvelope isPositiveResponse= false businessDocument= ebXML1.0/PO Rejection > </DocumentEnvelope>

</RespondingBusinessActivity> </BusinessTransaction>

Una collaborazione binaria avviene tra da due partner, che assumano i due ruoli di iniziatore e di risponditore ed è costituita da una serie di transazioni (Figura 31):

<BinaryCollaboration name= Product Fulfillment timeToPerform= P5D >

<Documentation>

timeToPerform = Period: 5 days from start of transaction </Documentation>

<InitiatingRole name= buyer /> <RespondingRole name= seller />

<BusinessTransactionActivity name= Create Order businessTransaction= Create Order

fromAuthorizedRole= buyer toAuthorizedRole= seller isLegallyBinding= true />

<BusinessTransactionActivity name= Notify shipment businessTransaction= Notify of advance shipment fromAuthorizedRole= buyer toAuthorizedRole= seller /> </BinaryCollaboration>

L’esempio mostra la collaborazione stabilita fra l’acquirente e il venditore definita mediante l’utilizzo di due transazioni di documenti.

Per specificare la coreografia e quindi l’ordine dei messaggi e gli stati del processo, basta aggiungere alla collaborazione appena descritta, dopo la definizione delle transazioni, il codice seguente:

<Start toBusinessState= Create Order /> <Transition fromBusinessState= Create Order toBusinessState= Notify shipment /> <Success fromBusinessState= Notify shipment conditionGuard= Success />

<Failure fromBusinessState= Notify shipment conditionGuard= BusinessFailure />

Figura 31 –Flusso di documenti e segnali all’interno di una collaborazione binaria tra due partner

Infine, le collaborazioni multipare possono essere descritte mediante la definizione di un insieme di ruoli che partecipano a due collaborazioni binarie.

<MultiPartyCollaboration name= DropShip > <BusinessPartnerRole name= Customer > <Performs initiatingRole=

‘//binaryCollaboration[@name= Firm Order ]/ InitiatingRole[@name= buyer ]’/>

</BusinessPartnerRole>

<BusinessPartnerRole name= Retailer > <Performs respondingRole=

‘//binaryCollaboration[@name= Firm Order ]/ RespondingRole[@name= seller ]’/>

<Performs initiatingRole=

‘//binaryCollaboration[@name= Product Fulfillment / InitiatingRole[@name= buyer ]’/>

</BusinessPartnerRole>

<BusinessPartnerRole name= DropShip Vendor > <Performs respondingRole=

‘//binaryCollaboration[@name= Product Fulfillment / RespondingRole[@name= seller ]’/>

</BusinessPartnerRole> </MultiPartyCollaboration>

L’esempio appena proposto definisce la presenza di tre partner: un cliente, un rivenditore ed un fornitore. Ad ognuno è associata una collaborazione binaria ed il ruolo occupato all’interno di essa.