Exportar (0) Imprimir
Expandir todo

Jerarquía, conceptos y terminología de entidades de Scheduler

Actualizado: abril de 2014

En la tabla siguiente se describen los recursos principales expuestos o utilizados por la API de Scheduler:

 

Recurso Descripción

Cloud service

Conceptualmente, un servicio en la nube representa una aplicación. Una suscripción puede tener varios servicios en la nube.

Job collection

Una colección de trabajos contiene un grupo de trabajos y mantiene los valores, cuotas y aceleradores compartidos por los trabajos en la colección. Un propietario de la suscripción crea la colección de trabajos y agrupa los trabajos juntos en función del uso o de los límites de la aplicación. Está limitado a una región. También permite la aplicación de cuotas para restringir el uso de todos los trabajos de la colección; las cuotas incluyen MaxJobs y MaxRecurrence.

Job

Un trabajo define una única acción periódica, con estrategias simples o complejas para la ejecución. Las acciones pueden incluir solicitudes HTTP o solicitudes de cola de almacenamiento.

Job history

Un historial de trabajos representa los detalles de una ejecución de un trabajo. Contiene la información de error o de ejecución correcta, así como los detalles de la respuesta.

En un nivel superior, la API de Scheduler y de administración de servicios exponen las siguientes operaciones en los recursos:

 

Capacidad Descripción y dirección de URI

Cloud service management

GET, PUT y DELETE permiten la creación y modificación de servicios en la nube

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

Job collection management

GET, PUT y DELETE permiten la creación y modificación de las colecciones de trabajos y de los trabajos que contienen. Una colección de trabajos es un contenedor para trabajos, y se asigna a las cuotas y a los valores compartidos. Los ejemplos de cuotas, que se describen más adelante, son nº máximo de trabajos e intervalo menor de periodicidad

PUT y 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

GET, PUT, POST, PATCH y DELETE permiten la creación y modificación de trabajos. Todos los trabajos deben pertenecer a una colección de trabajos que ya existe, por lo que no hay ninguna creación implícita

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

Job history management

GET permite la captura de 60 días de historial de ejecución de trabajos, que incluye, por ejemplo, el tiempo transcurrido de trabajo y los resultados de la ejecución de trabajos. Agrega compatibilidad de parámetros de cadena de consulta con el filtrado basado en el estado

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

En un nivel básico, un trabajo programado tiene varias partes:

  1. La acción que se debe realizar cuando se activa el temporizador de trabajo

  2. (Opcional) La hora de ejecución del trabajo

  3. (Opcional) Cuándo y con qué frecuencia se debe repetir el trabajo

  4. (Opcional) Una acción que se activa si se produce un error en la acción principal

Internamente, un trabajo programado contiene también datos proporcionados por el sistema, como, por ejemplo, la siguiente hora de ejecución programada.

A continuación se muestra un ejemplo de trabajo de Scheduler completo. Los detalles se proporcionan en las secciones siguientes.


{
    "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
    },
}

Como se ve en el trabajo de Scheduler del ejemplo anterior, una definición de trabajo tiene varias partes:

  1. Hora de inicio (“startTime")

  2. Acción (“action"), que incluye la acción de error (“errorAction")

  3. Periodicidad (“recurrence")

  4. Estado (“state")

  5. Estado (“status")

  6. Directiva de reintentos (“retryPolicy”)

Examinemos cada una de ellas en detalle:

“startTime” es la hora de inicio y permite que el autor de la llamada especifique un ajuste de zona horaria en el cable en formato ISO-8601.

“action” es la acción que se invoca cada vez y describe un tipo de invocación del servicio. La acción es lo que se ejecutará en la programación especificada. Actualmente Scheduler admite las acciones HTTP y Cola de almacén.

La acción del ejemplo anterior es una acción HTTP. A continuación se muestra un ejemplo de una acción Cola de almacén:


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


“errorAction” es el controlador de errores, la acción que se invoca cuando se produce un error en la acción principal. Puede usar esta variable para llamar a un extremo de control de errores o enviar una notificación de usuario. Se puede utilizar para llegar a un extremo secundario en caso de que el primario no esté disponible (por ejemplo, en el caso de un desastre en el sitio del extremo) o se puede utilizar para notificar un extremo de control de errores. Al igual que la acción principal, la acción de error puede ser lógica sencilla o compuesta basada en otras acciones.

La periodicidad tiene varias partes:

  1. Frecuencia: puede ser minuto, hora, día, semana, mes o año

  2. Intervalo: el intervalo de frecuencia definido para la periodicidad

  3. Programación prescrita: especifique minutos, horas, días de la semana, meses y días del mes para la periodicidad

  4. Recuento: el recuento de repeticiones

  5. Hora de finalización: los trabajos se ejecutarán después de la hora de finalización especificada

Un trabajo es periódico si se ha especificado un objeto de periodicidad en la definición de JSON. Si se especifica el recuento y la hora de finalización, se respeta la regla de finalización que aparece en primer lugar.

El estado del trabajo es uno de los cuatro valores: habilitado, deshabilitado, finalizado o error. Puede usar PUT o PATCH con los trabajos para actualizarlos al estado habilitado o deshabilitado. Si un trabajo se ha completado o ha producido errores, se trata de un estado final que no se puede actualizar (aunque el trabajo todavía se puede eliminar con DELETE). El siguiente es un ejemplo de la propiedad state:


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

Los trabajos completados y con errores se eliminan después de 60 días.

Una vez iniciado un trabajo de Scheduler, se devolverá información sobre el estado actual del trabajo. El usuario no puede configurar este objeto, lo establece el sistema. Sin embargo, se incluye en el objeto de trabajo (en lugar de un recurso vinculado independiente) para que se pueda obtener el estado de un trabajo con facilidad.

El estado del trabajo incluye la hora de ejecución anterior (si existe), la hora de la siguiente ejecución programada (para los trabajos en curso) y el recuento de ejecución del trabajo.

Si se produce un error en un trabajo de Scheduler, es posible especificar una directiva de reintentos para determinar si se reintenta una acción y de qué manera. Esto viene determinado por el objeto retryType: está establecido en none si no hay ninguna directiva de reintentos, tal como se muestra más arriba. Establécelo en fixed si hay una directiva de reintentos.

Para establecer una directiva de reintentos, se pueden especificar configuraciones adicionales de dos valores: un intervalo de reintentos (retryInterval) y el número de reintentos (retryCount).

Intervalo de reintentos, especificado con el objeto retryInterval, es el intervalo entre los reintentos. Su valor predeterminado es un minuto, su valor mínimo es un minuto y su valor máximo es 18 meses. Está definido en el formato ISO 8601. De manera similar, el valor del número de reintentos está especificado con el objeto retryCount; es el número de veces que se realiza un reintento. Su valor predeterminado es 5 y su valor máximo es 20. retryInterval y retryCount son opcionales: se les asigna su valor predeterminado si retryType está establecido en fixed y no se especifican valores explícitamente.

Mostrar:
© 2014 Microsoft