Recentemente, per qualche motivo, ho notato un aumento degli errori in Automation Studio, il che mi ha dato più occasioni per approfondire quanto tempo richieda effettivamente l’elaborazione di ciascuna attività.
In precedenza avevo condiviso la seguente query SQL per verificare orario di inizio, orario di fine e durata di elaborazione di ogni attività in Automation Studio.
SELECT TOP 10000
AutomationName AS [AutomationName],
ActivityName AS [ActivityName],
ActivityInstanceStep,
CONVERT(VARCHAR(19), DATEADD(HH, 9, ActivityInstanceStartTime_UTC), 120) AS [ActivityInstanceStartTime],
CONVERT(VARCHAR(19), DATEADD(HH, 9, ActivityInstanceEndTime_UTC), 120) AS [ActivityInstanceEndTime],
FORMAT(DATEDIFF(S, ActivityInstanceStartTime_UTC, ActivityInstanceEndTime_UTC) / 60, '00') + ':' +
FORMAT(DATEDIFF(S, ActivityInstanceStartTime_UTC, ActivityInstanceEndTime_UTC) % 60, '00') AS [Duration]
FROM
_automationactivityinstance
WHERE
AutomationName = 'XXXXXXXXXXXXXXX'
AND DATEADD(HH, 9, ActivityInstanceStartTime_UTC)
BETWEEN '2026-08-23 00:00:00' AND '2026-08-24 00:00:00'
ORDER BY
CONVERT(INT, LEFT(ActivityInstanceStep, CHARINDEX('.', ActivityInstanceStep) - 1)) ASC,
CONVERT(INT, SUBSTRING(
ActivityInstanceStep,
CHARINDEX('.', ActivityInstanceStep) + 1,
LEN(ActivityInstanceStep)
)) ASC,
ActivityName ASC,
ActivityInstanceStartTime_UTC ASC
Con questa query SQL è possibile controllare tutte le attività presenti in ciascuno step di un’Automation e verificare quanto tempo richiede ogni processo.
Tuttavia, ogni volta che serve un’indagine di questo tipo, ripetere operazioni come:
- Trovare questa SQL
- Incollarla in Query Studio
- Copiare e incollare il nome dell’Automation
- Modificare l’intervallo di date
può risultare un po’ tedioso.
Mi sono quindi chiesto se esistesse un modo più semplice per verificare rapidamente i tempi di elaborazione di Automation Studio, e ho creato una piccola app custom che funziona interamente all’interno di Marketing Cloud Engagement.
L’ho semplicemente chiamata “Automation Activity Viewer”.
- La versione di prova può essere implementata in circa 5 minuti.
- Anche la versione con autenticazione tramite login richiede circa 30 minuti.

Se vuoi prima capire come funziona, ti consiglio di creare la versione di prova senza autenticazione su CloudPages e provarla.
Se dopo averla usata pensi “questo strumento è utile”, potrai passare alla versione con autenticazione tramite login.
Importante
Se l’autenticazione non è configurata, chiunque conosca l’URL della CloudPage può accedere alla pagina. Questo significa che le informazioni visualizzate sulla pagina, come i nomi delle Automation, potrebbero essere visibili anche a utenti non autorizzati.
La versione di prova dovrebbe quindi essere utilizzata solo per test. Una volta terminati i test, rendi non disponibile la CloudPage oppure eliminala.
Versione di prova
Implementare la versione di prova è estremamente semplice.
Basta incollare lo script fornito in un blocco HTML su CloudPages.


Una volta salvata e pubblicata la CloudPage, la versione di prova è pronta all’uso.
Che ne pensi?
Se ti piace, il passo successivo è creare una versione visibile solo dopo il login.
Aggiungere l’autenticazione tramite login
Per l’autenticazione dell’app utilizzeremo una tecnica introdotta da Mateusz Dąbrowski, Salesforce MVP polacco.

MCE Cloud Page Apps | Mateusz Dąbrowski
https://medium.com/media/ea89b60fe5383b6f64701040375c4635/href
Iniziamo l’implementazione seguendo questi passaggi.
Creare le Data Extension per i log di audit
Nell’articolo di Mateusz, il primo passaggio consiste nel creare due Data Extension per il logging di audit.
La prima è:
- AUTHENTICATION_DATA_EXTENSION
e la seconda è:
- ERROR_DATA_EXTENSION
Ho creato degli script che semplificano la creazione di queste Data Extension. Inserisci ciascuno script in una Script Activity in Automation Studio ed eseguili una sola volta.
AUTHENTICATION_DATA_EXTENSION


*Dopo aver creato la Data Extension, impostare il valore predefinito di createdDate su Current Date.
ERROR_DATA_EXTENSION


*Dopo aver creato la Data Extension, impostare il valore predefinito di errorDate su Current Date.
A questo punto dovresti avere due Data Extension per i log di audit create nella cartella Data Extensions di primo livello.

Generare un URL CloudPages
Successivamente, crea una nuova CloudPage per generare un URL CloudPages.
Quando apri l’editor di CloudPages, puoi semplicemente salvare la pagina senza inserire nulla. A questo punto ci serve solo l’URL della CloudPage.

Dopo averla salvata, copia l’URL della CloudPage.

Configurare un Installed Package
Successivamente, vai su Installed Packages nel Setup di Marketing Cloud e crea un nuovo package.
- Esempio di nome del package: Automation Activity Viewer

Configureremo due componenti. Clicca su Add Component.

Per primo, seleziona API Integration.

Successivamente, seleziona Web App.

Inserisci l’URL della CloudPage copiato in precedenza e clicca su Save. Non è necessario configurare alcuno scope.

In precedenza era possibile visualizzare il Client Secret di una Web App in qualsiasi momento. Ora invece viene mostrato solo in questa fase, quindi assicurati di salvarlo in un posto sicuro.

Dopo aver copiato il Client Secret, copia anche il Client ID della Web App. Quindi clicca nuovamente su Add Component per creare il secondo componente.

Questa volta seleziona Marketing Cloud App.

Inserisci il nome dell’app e inserisci l’URL della CloudPage copiato in precedenza in entrambi i campi Endpoint. Va bene usare lo stesso URL per entrambi. Quindi salva la configurazione.
- Esempio di nome dell’app: Automation Activity Viewer

La configurazione dell’Installed Package è ora completa.
Configurare il codice in CloudPages
Infine, ritorna alla CloudPage dove hai generato precedentemente l’URL e incolla il codice fornito.
Dovrai sostituire quattro valori:
var APP_URL = "YOUR_CLOUDPAGE_URL"; var WEB_APP_CLIENT_ID = "YOUR_WEB_APP_CLIENT_ID"; var WEB_APP_CLIENT_SECRET = "YOUR_WEB_APP_CLIENT_SECRET"; var CLIENT_BASE = "YOUR_TSSD";
- URL CloudPages: l’URL della CloudPage salvato precedentemente
- Client ID: generato nell’Installed Package
- Client Secret: generato nell’Installed Package
- Client Base: verifica il valore come descritto di seguito
Ad esempio, se il tuo URI è:
- https://mc123abc456def.auth.marketingcloudapis.com/
allora il valore di CLIENT_BASE è: mc123abc456def

Una volta salvata e pubblicata la CloudPage, il lavoro è completato.
Verificare l’app
L’app apparirà come tab in AppExchange: trovala e clicca su di essa.

Se vedi una schermata come la seguente, la configurazione è andata a buon fine.

Se si verifica un errore, controlla che i quattro valori inseriti manualmente siano corretti:
var APP_URL = "YOUR_CLOUDPAGE_URL"; var WEB_APP_CLIENT_ID = "YOUR_WEB_APP_CLIENT_ID"; var WEB_APP_CLIENT_SECRET = "YOUR_WEB_APP_CLIENT_SECRET"; var CLIENT_BASE = "YOUR_TSSD";
- URL CloudPages: l’URL della CloudPage salvato precedentemente
- Client ID: generato nell’Installed Package
- Client Secret: generato nell’Installed Package
- Client Base: verifica il valore come descritto di seguito
Ad esempio, se il tuo URI è:
- https://mc123abc456def.auth.marketingcloudapis.com/
allora il valore di CLIENT_BASE è: mc123abc456def
Consumo di chiamate API
Ogni volta che si costruisce un’app di questo tipo, una domanda che sorge inevitabilmente è quante chiamate API vengono utilizzate.
Con l’implementazione attuale, assumendo che non si verifichi paginazione, il numero approssimativo di chiamate SOAP API (WSProxy) necessarie per una singola ricerca è:
- Circa 5 + (numero di esecuzioni dell’Automation nel periodo selezionato × 2)
Per esempio, se l’Automation è stata eseguita una sola volta nel periodo selezionato:
- Circa 7 chiamate API
Se è stata eseguita 5 volte, ad esempio cercando cinque giorni di storico esecuzioni:
- Circa 15 chiamate API
Se è stata eseguita 30 volte:
- Circa 65 chiamate API
Questi numeri sono solo stime.
Se viene restituito un numero elevato di risultati e si verifica paginazione durante un’operazione Retrieve di WSProxy, il numero effettivo di chiamate API potrebbe essere superiore.
Un punto importante riguarda la funzionalità di filtro.
Nell’implementazione attuale, cliccando su Apply Filter la pagina esegue nuovamente un POST e ripete la ricerca stessa.
Pertanto, ad esempio, se stai cercando uno storico di esecuzioni che contiene 30 run dell’Automation:
- Ricerca iniziale: circa 65 chiamate
- Apply Filter: circa 65 chiamate
D’altra parte, Export CSV non genera alcuna chiamata SOAP API aggiuntiva.
I dati CSV vengono generati quando la pagina stessa viene creata, ed Export CSV si limita a scaricare i dati già generati.
Per la versione con autenticazione, oltre alle chiamate SOAP API, durante il login iniziale si verificano le seguenti chiamate HTTP API:
- /v2/token → 1 chiamata HTTP API
- /v2/userinfo → 1 chiamata HTTP API
Queste chiamate fanno parte del processo di autenticazione e normalmente non si verificano ad ogni ricerca eseguita.
Conclusione
Anche se questo strumento venisse utilizzato in modo scorretto, è improbabile che causi immediatamente un problema serio. Tuttavia, presta attenzione a non lasciare pubblicamente accessibile una CloudPage senza autenticazione tramite login.
Soprattutto quando lo utilizzi in un ambiente reale, assicurati di considerare i requisiti di sicurezza e operativi, e valuta l’implementazione in base al tuo specifico ambiente e caso d’uso.
È tutto per questo articolo.
Resta collegato per altri consigli su Salesforce Marketing Cloud! 😎
Nobuyuki Watanabe
Tradotto e adattato da SFMC Tips #340 : Understand Automation Processing Times: Automation Activity Viewer di Nobuyuki Watanabe (@marketingcloudtips), pubblicato originariamente su Medium. Traduzione autorizzata dall’autore.