Esporta (0) Stampa
Espandi tutto

Concetti di utilità di pianificazione, terminologia e gerarchia di entità

Aggiornamento: gennaio 2015

La tabella seguente descrive le risorse principali esposte o usate dall'utilità di pianificazione API.

 

Risorsa Descrizione

Cloud service

A livello concettuale, un servizio cloud rappresenta un'applicazione. Una sottoscrizione può includere diversi servizi cloud.

Job collection

Una raccolta di processi contiene un gruppo di processi e gestisce le impostazioni, le quote e le limitazioni condivise dai processi all'interno della raccolta. Una raccolta di processi viene creata dal proprietario di una sottoscrizione e consente di raggruppare i processi in base ai limiti di uso o delle applicazioni. È vincolata a un'area. e consente inoltre di applicare quote per vincolare l'uso di tutti i processi all'interno della raccolta; le quote includono MaxJobs e MaxRecurrence.

Job

Un processo definisce una singola azione ricorrente, con strategie di esecuzione semplici o complesse. Le azioni possono includere richieste HTTP le richieste di code di archiviazione.

Job history

Una cronologia processo rappresenta i dettagli per l'esecuzione di un processo. Contiene operazioni riuscite, non riuscite e dettagli sulle risposte.

A livello generale, l'utilità di pianificazione e l'API di gestione del servizio espongono le operazioni sulle risorse indicate di seguito.

 

Capability Descrizione e indirizzo URI

Cloud service management

Supporto GET, PUT e DELETE per la creazione e la modifica di servizi cloud

https://management.core.windows.net/{subscriptionId}/cloudservices/{cloudServiceName}

Job collection management

Supporto GET, PUT e DELETE per la creazione e la modifica di raccolte di processi e dei processi al loro interno. Una raccolta di processi è un contenitore che esegue il mapping a quote e impostazioni condivise. Esempi di quote, descritti più avanti, sono rappresentati dal numero di processi e dall'intervallo minimo di ricorrenze

PUT e DELETE: https://management.core.windows.net/{subscriptionId}/cloudservices/{cloudServiceName}/resources/scheduler/jobcollections/{jobCollectionName}

GET: https://management.core.windows.net/{subscriptionId}/cloudservices/{cloudServiceName}/resources/scheduler/~/jobcollections/{jobCollectionName}

Job management

Supporto GET, PUT, POST, PATCH e DELETE per la creazione e la modifica di processi. Tutti i processi devono appartenere a una raccolta già esistente, pertanto non si verifica alcuna creazione implicita

https://management.core.windows.net/{subscriptionId}/cloudservices/{cloudServiceName}/resources/scheduler/~/jobcollections/{jobCollectionName}/jobs/{jobId}

Job history management

Supporto GET per recuperare 60 giorni della cronologia di esecuzione dei processi, ad esempio tempo trascorso e risultati. Aggiunge il supporto dei parametri delle stringhe di query per filtrare in base allo stato

https://management.core.windows.net/{subscriptionId}/cloudservices/{cloudServiceName}/resources/scheduler/~/jobcollections/{jobCollectionName}/jobs/{jobId}/history

Sono disponibili due tipi di processo: processi HTTP (inclusi i processi HTTPS che supportano SSL) e processi di accodamento di archiviazione. I processi HTTP sono ideali se si dispone di un endpoint di un carico di lavoro o un servizio esistente. I processi di accodamento di archiviazione consentono di inviare messaggi alle code di archiviazione, pertanto sono ideali per i carichi di lavoro che usano le code di archiviazione.

A livello base, un processo pianificato è costituito da diversi elementi:

  1. Azione da eseguire all'attivazione del timer del processo

  2. (Facoltativo) Ora di esecuzione del processo

  3. (Facoltativo) Tempi e frequenze di ripetizione del processo

  4. (Facoltativo) Azione da attivare in caso di esito negativo dell'azione primaria

A livello interno, un processo pianificato contiene inoltre dati forniti dal sistema, quali l'ora di esecuzione successiva pianificata.

Di seguito è indicato un esempio completo dell'utilità di pianificazione. Maggiori dettagli verranno forniti nelle sezioni successive.


{
    "startTime": "2012-08-04T00:00Z",               // optional
    "action": 
    {
        "type": "http",
        "retryPolicy": { "retryType":"none" },
        "request":
        {
            "uri": "http://contoso.com/foo",        // required
            "method": "PUT",                        // required
            "body": "Posting from a timer",         // optional
            "headers":                              // optional

            {
                "Content-Type": "application/json"
            },
        },
       "errorAction": 
       {
           "type": "http",
           "request":
           {
               "uri": "http://contoso.com/notifyError", 
               "method": "POST",                       
           },
       },
    },
    "recurrence":                                   // optional
    {
        "frequency": "week",                        // can be "year" "month" "day" "week" "minute"
        "interval": 1,                              // optional, how often to fire (default to 1)
        "schedule":                                 // optional (advanced scheduling specifics)
        {
            "weekDays": ["monday", "wednesday", "friday"],
            "hours": [10, 22]                      
        },
        "count": 10,                                 // optional (default to recur infinitely)
        "endTime": "2012-11-04",                     // optional (default to recur infinitely)
    },
    "state": "disabled",                           // enabled or disabled
    "status":                                       // controlled by Scheduler service
    {
        "lastExecutionTime": "2007-03-01T13:00:00Z", 
        "nextExecutionTime": "2007-03-01T14:00:00Z ", 
        "executionCount": 3,
         "failureCount": 0,
         "faultedCount": 0
    },
}

Come illustrato nell'esempio precedente, la definizione di un processo è costituita da diversi elementi:

  1. Ora di inizio ("startTime")

  2. Azione ("action"), che include l'azione di errore ("errorAction")

  3. Ricorrenza ("recurrence")

  4. Stato ("state")

  5. Stato ("status")

  6. Criteri per l'esecuzione di nuovi tentativi ("retryPolicy")

Di seguito vengono descritti in dettaglio i singoli elementi.

"startTime" è l'ora di inizio e consente al chiamante di specificare una differenza di fuso orario in transito nel formato ISO 8601.

"action" è l'azione richiamata a ogni occorrenza e descrive un tipo di chiamata di servizio. "action" rappresenta l'azione che verrà eseguita nella pianificazione specificata. Attualmente l'utilità di pianificazione supporta azioni di code di archiviazione e HTTP.

L'azione nell'esempio precedente è un'azione di tipo HTTP. Di seguito è riportato un esempio di un'azione di coda di archiviazione.


{
        "type": "storageQueue",
        "queueMessage":
        {
            "storageAccount": "myStorageAccount",  // required
            "queueName": "myqueue",                // required
            "sasToken": "TOKEN",                   // required
            "message":                             // required
                "My message body",
        },
}


"errorAction" è il gestore degli errori, l'azione richiamata quando l'azione primaria non riesce. È possibile usare questa variabile per chiamare un endpoint di gestione degli errori o inviare una notifica all'utente, nonché per raggiungere un endpoint secondario nel caso in cui l'endpoint primario non sia disponibile (ad esempio, in caso di problemi nel sito dell'endpoint) oppure per inviare una notifica all'endpoint di gestione degli errori. Come nel caso dell'azione primaria, l'azione di errore può essere costituita da logica semplice o composta, in base ad altre azioni. Per informazioni su come creare un token di firma di accesso condiviso, vedere Creare e utilizzare una firma di accesso condiviso.

La ricorrenza è costituita da diversi elementi.

  1. Frequenza: valore tra minuto, ora, giorno, settimana, mese, anno

  2. Intervallo: intervallo alla frequenza specificata per la ricorrenza

  3. Pianificazione prescritta: specificare minuti, ore, giorni della settimana, mesi e giorni del mese della ricorrenza

  4. Conteggio: numero di occorrenze

  5. Fine: nessun processo verrà eseguito dopo l'ora di fine specificata

Un processo è ricorrente se nella definizione JSON è specificato un oggetto ricorrente. Se sono specificati entrambi i valori count ed endTime, verrà applicata la regola di completamento che si verificherà per prima.

Lo stato del processo può essere uno di quattro valori: enabled, disabled, completed o faulted. È possibile usare un'operazione PUT o PATCH per i processi in modo da aggiornarli nello stato enabled (abilitato) o disabled (disabilitato). Se un processo è in stato completed (completato) o faulted (con errori), è in uno stato finale e non può essere aggiornato (sebbene il processo possa comunque essere spostato in stato DELETED). Di seguito viene riportato un esempio di formato proprietà di stato.


    "state": "disabled", // enabled, disabled, completed, or faulted

I processi completati e con errori vengono eliminati dopo 60 giorni.

Una volta avviata un'utilità di pianificazione, verranno restituite informazioni sullo stato corrente del processo. Questo oggetto non può essere impostato dall'utente, ma solo dal sistema. Tuttavia, è incluso nell'oggetto processo (anziché in una risorsa collegata separata) in modo da consentire di ottenere agevolmente lo stato di un processo.

Lo stato del processo include l'ora dell'esecuzione precedente (se presente), l'ora della successiva esecuzione pianificata (per i processi in corso) e il conteggio di esecuzioni del processo.

Se un'utilità di pianificazione ha esito negativo, si possono specificare criteri per l'esecuzione di nuovi tentativi in modo da determinare se e come l'azione viene ripetuta. Ciò viene determinato dall'oggetto retryType che è impostato su none se non sono presenti criteri per l'esecuzione di nuovi tentativi, come illustrato sopra. Se è presente un criterio per l'esecuzione di nuovi tentativi, l'oggetto è impostato su fixed.

Per impostare un criterio per l'esecuzione di nuovi tentativi, si devono specificare due impostazioni aggiuntive dei valori: un intervallo tra i tentativi (retryInterval) e il numero di tentativi da eseguire (retryCount).

L'intervallo tra i tentativi, specificato con l'oggetto retryInterval, indica l'intervallo tra più tentativi. Il valore predefinito di questa impostazione è un minuto, il valore minimo è un minuto e quello massimo è 18 mesi. Questo valore è definito nel formato ISO 8601. In modo analogo, il valore del numero di tentativi viene specificato con l'oggetto retryCount, che rappresenta il numero di volte in cui un tentativo viene eseguito. Il valore predefinito è cinque e il valore massimo è 20. Gli oggetti retryInterval e retryCount sono facoltativi e restituiscono i rispettivi valori predefiniti se retryType è impostato su fixed e non sono presenti valori specificati in modo esplicito.

Vedere anche

Mostra:
© 2015 Microsoft