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.
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.
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.
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.
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.
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.
(c) Copyright IBM Corporation 2005, 2006.
This information center is powered by Eclipse technology (http://www.eclipse.org)