Gestione del ciclo di vita e comportamento relativo alla versione dei processi secondari

Un processo avviato da un altro processo viene chiamato processo secondario. Il modo in cui il ciclo di vita dei processi secondari può essere gestito e il comportamento relativo alla versione dipendono dal modellamento di questi processi.

Per la modularità e il riutilizzo, è spesso opportuno applicare il concetto di programmazione di incapsulamento al modellamento del business, cioè implementare uno o più passi della logica business come processo separati e richiamare questo processo dal processo principale. Un processo secondario può anche avviare un altro processo. Questo può portare a una gerarchia arbitraria completa delle istanze del processo. Quando questi processi vengono distribuiti, tutte le maschere di processo nella relazione da processo a processo devono essere distribuiti nello stesso database Business Process Choreographer.

Gestione ciclo di vita

Un processo secondario può avere una relazione peer-to-peer o parent-child con il processo di richiamo. Questa relazione determina il comportamento di un processo secondario quando un'azione che gestisce il ciclo di vita viene richiamata per il processo di richiamo. Le azioni del ciclo di vita comprendono la sospensione, la ripresa, il termine, l'eliminazione e la compensazione. Le azioni che gestiscono il ciclo di vita del processo possono essere eseguite solo alle istanze del processo a livello superiore.

La relazione processo processo secondario è determinata dall'attributo di autonomia del processo secondario. Questo attributo può avere solo uno dei seguenti valori:
Peer
Un processo peer è considerato un processo di livello superiore. Un processo di livello superiore è un'istanza di processo che non è richiamata da un'altra istanza di processo o è richiamata da un'altra istanza di processo, ma dispone di autonomia peer. Se il processo secondario è parte di una relazione peer-to-peer, le azioni del ciclo di vita sull'istanza del processo di richiamo non vengono applicate all'istanza del processo secondario.

Tuttavia, i processi di lunga esecuzione con un'operazione di creazione che implementa un'interfaccia di sola andata, il valore dell'attributo di autonomia è impostato automaticamente su peer durante il runtime. Se l'attributo di autonomia è impostato su child, questo valore è ignorato al runtime.

Child
Se il processo secondario è parte di una relazione parent-child, le azioni del ciclo di vita sul processo parent vengono applicate all'istanza del processo secondario. Ad esempio, se l'istanza del processo parent viene sospesa, anche tutte le istanze del processo secondario con autonomia child.

Un microflusso viene sempre seguito come processo child. Tuttavia, se c'è un altro componente tra i due processi, si evita di stabilire una relazione parent-child, ad esempio, un componente mappa interfaccia che è collegato tra i componenti dei due processi.

Comportamento relativo alla versione

La versione di un processo che è utilizzato è determinata da se il processo è utilizzato in uno scenario bind anticipato o bind posticipato.
Bind anticipato
In uno scenario di bind anticipato, la decisione su quale versione del processo secondario è richiamata viene effettuata durante la distribuzione. Il processo di richiamo è indirizzato a un processo secondario dedicato, staticamente associato alla connessione SCA (Service Component Architecture). La versione del processo è ignorata.

Un esempio di un bind anticipato è un collegamento SCA. Ad esempio, se di collega un riferimento autonomo a un componente del processo, ogni richiamo del processo che utilizza questo riferimento viene destinato a una versione specifica rappresentata dal componente del processo.

Bind posticipato
Un uno scenario di bind posticipato, la decisione su quale maschera di processo secondario è richiamato avviene quando l'istanza del processo di richiamo necessita di richiamare il processo secondario. In questo caso, viene utilizzata la versione del processo secondario correntemente valida. Una versione più aggiornata di un processo secondario sostituisce tutte le versioni precedenti del processo. Le istanze del processo esistenti continuano ad essere eseguite con la maschera di processo al quale sono state associate quando sono state avviate. Questo porta alle categorie seguenti di maschere di processo:
  • Le maschere di processo non più correnti potrebbero essere ancora valide per le istanze del processo di lunga esecuzione esistenti
  • Le maschere di processo correnti vengono utilizzate per le nuove istanze del processo
  • Le maschere di processo che diventano valide in futuro secondo data e ora Valido da.

Per applicare un bind posticipato quando viene richiamato un processo secondario, il processo parent deve specificare il nome della maschera di processo secondario dalla quale il processo secondario valido deve essere selezionato come partner di riferimento. L'attributo Valido da del processo è utilizzato per determinare la maschera di processo secondario correntemente valida. Qualsiasi collegamento SCA è ignorato.

Un esempio di bind posticipato è quando un nuovo processo viene richiamato in Business Process Choreographer Explorer. L'istanza creta è sempre basata sulla versione più recente della maschera di processo con una data Valido da che non è nel futuro.

Quando viene creata una nuova versione di un modello di processo e il modello di processo esistente viene utilizzato in scenari di bind posticipato, è necessario evitare di effettuare modifiche che possano causare problemi di compatibilità quando la nuova versione del processo diventa valida e, ad esempio, un processo parent richiama un'istanza della nuova versione del processo secondario. Sono di seguito riportate modifiche incompatibili da evitare:
  • Modifica delle impostazioni di correlazione
  • Modifica di qualsiasi interfaccia utilizzata dal processo parent per comunicare con il processo secondario

(c) Copyright IBM Corporation 2005, 2006.
This information center is powered by Eclipse technology (http://www.eclipse.org)