Building block > Building block comuni > Building block di connessione database > Invio e convalida di eventi pre-azione, post-azione e in azione
Invio e convalida di eventi pre-azione, post-azione e in azione
Quando viene avviata un'azione di creazione, aggiornamento o eliminazione, l'oggetto dello strumento di convalida di pre-azione (PTC.DBConnection.PreActionValidator) viene chiamato prima che sia eseguito l'aggiornamento del database. Se la convalida ha esito positivo, il database viene aggiornato e viene chiamato l'oggetto del processore in azione (PTC.DBConnection.OnActionProcessor). Dopo un aggiornamento del database, l'oggetto dell'handler di post-azione (PTC.DBConnection.PostActionHandler) viene chiamato in un altro thread, senza influire sull'esecuzione dell'azione.
Il diagramma seguente mostra la progettazione generale dello strumento di convalida di pre-azione, del processore in azione e dell'handler di post-azione:
Diagramma della progettazione generale dello strumento di convalida di pre-azione e dell'handler di post-azione.
Il diagramma seguente mostra la sequenza dispatcher dello strumento di convalida di pre-azione, del processore in azione e dell'handler di post-azione in caso di esito positivo della convalida di pre-azione:
Diagramma che mostra la sequenza dispatcher dello strumento di convalida di pre-azione e dell'handler di post-azione in caso di esito positivo della convalida di pre-azione.
Se la convalida ha esito negativo, l'azione non viene completata e il database non viene aggiornato. Il diagramma riportato di seguito mostra la sequenza dispatcher in caso di esito negativo della convalida di pre-azione.
Diagramma che mostra la sequenza dispatcher in caso di esito negativo della convalida di pre-azione.
L'oggetto dello strumento di convalida di pre-azione (PTC.DBConnection.PreActionValidator) eredita il modello di oggetto dello strumento di convalida di pre-azione (PTC.DBConnection.PreActionValidator_TT). L'oggetto del processore in azione (PTC.DBConnection.OnActionProcessor) eredita il modello di oggetto del processore in azione (PTC.DBConnection.OnActionProcessor_TT). Analogamente, l'oggetto dell'handler di post-azione (PTC.DBConnection.PostActionHandler) eredita il modello di oggetto dell'handler di post-azione (PTC.DBConnection.PostActionHandler_TT). Tali modelli di oggetto implementano le thing shape necessarie per l'attivazione degli invii di eventi pre-azione, in azione e post-azione.
Quando si avvia un'azione di creazione, aggiornamento o eliminazione, viene attivato il servizio di pre-azione appropriato per lo strumento di convalida di pre-azione (PreCreateAction, PreUpdateAction o PreDeleteAction). Il servizio di pre-azione a sua volta esegue il servizio CallServices, che esamina le modifiche dei dati e legge la configurazione sullo strumento di convalida di pre-azione. Se è presente un servizio configurato per tale azione e data shape, CallServices invia i servizi di convalida appropriati. Se una parte della convalida non riesce, l'intera azione non viene completata.
Se la convalida di pre-azione ha esito positivo, il database viene aggiornato e i servizi in azione vengono attivati (OnCreateAction, OnDeleteAction, OnUpdateAction). Il servizio in azione esegue quindi il servizio CallServices, che legge la configurazione nel processore in azione. Se un servizio è configurato per la data shape e l'azione, viene inviato tale servizio in azione.
Se un'azione di creazione, aggiornamento o eliminazione viene completata, viene attivato l'handler di post-azione (PostCreateAction, PostUpdateAction o PostDeleteAction). Il servizio di post-azione esegue quindi il servizio CallServices, che legge la configurazione sull'handler di post-azione di default. Se un servizio è configurato per tali data shape e azione, viene inviato tale servizio di post-azione.
I servizi sono disponibili nello strumento di convalida di pre-azione e nell'handler di post-azione, che vengono eseguiti ogni volta che si crea o si aggiorna una definizione di lavorazione, un turno o un sito. Tali implementazioni possono essere utilizzate come modelli per l'implementazione dei propri servizi di pre-azione e post-azione personalizzati.
Esempio di servizi pre-azione
In questa sezione viene descritto come funzionano i servizi pre-azione utilizzando le azioni delle commesse come esempio.
I seguenti servizi sono disponibili nell'oggetto PTC.JobOrderImpl.Manager: JobOrderPreCreate, JobOrderPreUpdate, ValidateDispatchStatus e ValidateJobOrderSite.
Quando viene creata o aggiornata una commessa e viene specificato uno stato di esecuzione, lo stato di esecuzione viene convalidato prima di consentire il proseguimento dell'azione. A seconda dell'azione eseguita, viene richiamato il servizio JobOrderPreCreate o JobOrderPreUpdate. L'azione a sua volta chiama i servizi ValidateDispatchStatus e ValidateJobOrderSite. Se vengono create o aggiornate più commesse in una singola azione e lo stato di esecuzione specificato di una di esse non è valido, l'intera azione non viene completata. Impostare Livello di registrazione su Debug per visualizzare i dettagli dei servizi di convalida ed eventuali errori in Monitoraggio > ScriptLog. Fare riferimento al servizio ValidateJobOrderSite per un esempio che illustra come generare un'eccezione quando una convalida ha esito negativo.
Esempio di servizi in azione
I seguenti servizi sono disponibili nell'oggetto PTC.JobOrderImpl.Manager: OnCreateJobOrder, OnUpdateJobOrder, UpdateJobOrderExecutionResponsesForJobOrders.
Quando viene creata o aggiornata una commessa, viene chiamato il servizio OnCreateJobOrder o OnUpdateJobOrder, a seconda dell'azione eseguita. L'azione a sua volta chiama il servizio UpdateJobOrderExecutionResponsesForJobOrders.
Esempio di servizi post-azione
I seguenti servizi sono disponibili nell'oggetto PTC.SCA.SCO.DefaultProductionOrderManager: WorkDefinitionPostCreate, WorkDefinitionPostUpdate, LogWorkDefinitionExecutionStatusChange.
Dopo la creazione o l'aggiornamento di una definizione di lavorazione, viene chiamato il servizio WorkDefinitionPostCreate o WorkDefinitionPostUpdate, a seconda dell'azione eseguita. Tale azione richiama a sua volta il servizio LogWorkDefinitionExecutionStatusChange, che registra i seguenti dettagli sull'azione: l'agente responsabile per l'azione, l'UID della definizione di lavorazione creata o aggiornata, l'UID e il valore dello stato di esecuzione. Tali dettagli possono essere visualizzati in Monitoraggio > ScriptLog dopo aver impostato Livello di registrazione su Debug.
Aggiunta di servizi pre-azione, in azione e post-azione
Gli oggetti PTC.DBConnection.PreActionValidator, PTC.DBConnection.OnActionProcessor e PTC.DBConnection.PostActionHandler non sono modificabili.
Per aggiungere altri servizi pre-azione, in azione o post-azione, attenersi alla procedura riportata di seguito.
1. Per ulteriori servizi di pre-azione, duplicare l'oggetto PTC.DBConnection.PreActionValidator. Per ulteriori servizi in azione, duplicare l'oggetto PTC.DBConnection.OnActionProcessor. Per ulteriori servizi dell'handler di post-azione, duplicare l'oggetto PTC.DBConnection.PostActionHandler. Per questa procedura, si fa riferimento a questi oggetti duplicati come oggetto PTC.DBConnection.PreActionValidator_Duplicate, oggetto PTC.DBConnection.OnActionProcessor_Duplicate e oggetto PTC.DBConnection.PostActionHandler_Duplicate rispettivamente. Per ulteriori informazioni, vedere Duplicazione delle entità del building block.
2. Creare i servizi pre-azione, in azione e post-azione nell'oggetto manager per il building block a cui appartiene la data shape. Ad esempio, creare i servizi pre-azione, in azione e post-azione per le commesse nell'oggetto PTC.JobOrderImpl.Manager.
3. Aggiungere una nuova voce alla tabella di configurazione ActionConfigurationSettings nella pagina Configurazione dell'oggetto PTC.DBConnection.PreActionValidator_Duplicate, dell'oggetto PTC.DBConnection.OnActionProcessor_Duplicate o dell'oggetto PTC.DBConnection.PostActionHandler_Duplicate, a seconda del caso:
DataShapeName - Cercare e selezionare il nome della data shape per cui si applica questo servizio pre-azione, in azione o post-azione.
Action - Immettere l'azione: Create, Update o Delete. Il valore distingue tra maiuscole e minuscole e deve essere immesso esattamente come viene presentato qui.
ThingName - Cercare e selezionare il nome dell'oggetto manager in cui risiede il servizio, ad esempio PTC.JobOrderImpl.Manager.
ServiceName - Immettere il nome del servizio che deve essere inviato da CallServices. Se l'implementazione è costituita da più servizi, immettere il servizio iniziale che richiama gli altri. Il valore distingue tra maiuscole e minuscole e deve corrispondere esattamente al nome del servizio.
* 
Sebbene l'implementazione possa includere una serie di servizi, il servizio specificato nella tabella di configurazione ActionConfigurationSettings e inviato da CallServices deve includere un parametro di input denominato DataChanges. Questo parametro di input è una infotable della data shape PTC.DBConnection.DataChange.
4. Fare clic su Aggiungi, quindi fare clic su Salva per salvare le modifiche della configurazione.
5. Passare all'oggetto database configurato per il sistema, ad esempio PTC.DBConnection.MSSQLDatabase.
* 
È possibile trovare l'oggetto database configurato per il sistema nella tabella di configurazione DefaultDatabaseConfiguration della pagina Configurazione di PTC.DBConnection.Manager.
6. Nella pagina Configurazione dell'oggetto database, in DatabaseValidationConfigurationTable, aggiornare i campi PreActionValidator, PostActionHandler e OnActionProcessor in modo che puntino agli oggetti duplicati creati al passo 1.
7. Fare clic su Salva per salvare le modifiche alla configurazione dell'oggetto database.
È stato utile?