Monitoraggio della soluzione Gestione dei processi di business con BAM
La soluzione consente di monitorare i passaggi dell'elaborazione degli ordini utilizzando l'API di Monitoraggio attività di business (BAM). La struttura del processo di business suddivide le attività in più fasi. Le attività possono comunque essere ricombinate per creare la sensazione di un processo continuo. BAM fornisce inoltre dati aggregati per indicare il tempo impiegato dai diversi sistemi back-end, il numero di ordini completati e altre informazioni simili.
Come la soluzione orientata al servizio, usa il nuovo oggetto OrchestrationEventStream . Per una discussione sull'oggetto OrchestrationEventStream, vedere "What Is the OrchestrationEventStream Object" in Monitoraggio della soluzione orientata al servizio con BAM.
Per informazioni generali su BAM, vedere Uso del monitoraggio attività aziendali. Per informazioni sull'editor del profilo di rilevamento (TPE), vedere Editor profilo di rilevamento.
Wrapping dell'oggetto OrchestrationEventStream
Analogamente alla soluzione orientata al servizio, la soluzione di gestione dei processi aziendali esegue il wrapping dell'oggetto OrchestrationEventStream . Inoltre, come nella soluzione orientata ai servizi, tutti i metodi sono statici e pertanto le orchestrazioni non devono creare istanze degli oggetti per utilizzare i metodi. Ciò significa anche che non è necessario che gli oggetti utilizzati per il rilevamento vengano serializzati e salvati (non è necessario che siano serializzabili) se il motore disidrata un'orchestrazione. La soluzione di gestione dei processi aziendali, tuttavia, esegue il wrapping di OrchestrationEventStream con diversi oggetti derivati da un singolo oggetto astratto.
La classe astratta è BasicActivity. Sebbene sia astratta, questa classe non funge effettivamente da modello per le classi derivate, bensì fornisce, tramite i propri metodi statici, un set di metodi disponibili senza qualifica in una classe derivata. Ciò consente di utilizzare quattro implementazioni predefinite dei metodi. I quattro metodi statici sono : CreateActivityId, BeginActivity, UpdateActivity e EndActivity.
La classe esegue l'overload del metodo BeginActivity . Una versione accetta un nome di attività come singolo argomento, crea un GUID da utilizzare come identificatore dell'attività e quindi chiama la propria versione che accetta un nome di attività e un identificatore di attività e quindi restituisce l'identificatore dell'attività. La versione con argomento singolo è utile nei casi in cui è possibile che un ordine non disponga di un identificatore univoco.
Il metodo CreateActivityId accetta una stringa e un identificatore univoco, ad esempio l'identificatore della richiesta e restituisce una stringa concatenandoli con un carattere di sottolineatura. In questo modo fornisce un identificatore univoco dell'attività che viene ampiamente utilizzato nelle classi derivate. I metodi BeginActivity, UpdateActivity e EndActivity chiamano i metodi BeginActiviy, UpdateActivity e EndActivity di OrchestrationEventStream.
La soluzione deriva classi da BasicActivity per il broker ordini (CustomerOrderRequest), order manager (OrderManager) e le fasi di elaborazione (ServiceOrderRequest). Ciascuna delle classi corrisponde a un'attività. Ogni classe fornisce una stringa per il nome dell'attività da usare in CreateActivityId per creare l'identificatore di attività e metodi specializzati per le attività cardine.
Poiché il broker di ordini invia l'ordine e in un secondo momento riceve una risposta, include un metodo per ripristinare l'identificatore dell'attività assegnato all'identificatore della richiesta dell'ordine. Ciò consente al processo di business di continuare il rilevamento degli elementi finali dell'elaborazione dell'ordine.
Nota
Se si inviano ordini tramite questa funzionalità anziché tramite l'applicazione Web del servizio clienti, è necessario aggiungere un identificatore univoco per ogni richiesta.
Vedere anche
Sviluppo di una soluzione di gestione dei processi aziendali