input:
path input_file
val name
val threshold
output:
path 'results.txt', emit: results
script:
"""
my_tool --name ${name} --threshold ${threshold} ${input_file}
"""
}
workflow MY_WORKFLOW {
my_task(
params.input_file,
params.name,
params.threshold
)
}
workflow {
MY_WORKFLOW()
}
```
------
#### [ CWL ]
```
cwlVersion: v1.2
class: Workflow
requirements:
InlineJavascriptRequirement: {}
inputs:
input_file: File
name: string
threshold: int
outputs:
result:
type: ...
outputSource: ...
steps:
my_task:
run:
class: CommandLineTool
baseCommand: my_tool
requirements:
...
inputs:
name:
type: string
inputBinding:
prefix: "--name"
threshold:
type: int
inputBinding:
prefix: "--threshold"
input_file:
type: File
inputBinding: {}
outputs:
results:
type: File
outputBinding:
glob: results.txt
```
------
# Archivos de plantillas de parámetros para HealthOmics flujos de trabajo
Las plantillas de parámetros definen los parámetros de entrada de un flujo de trabajo. Puede definir los parámetros de entrada para que su flujo de trabajo sea más flexible y versátil. Por ejemplo, puede definir un parámetro para la ubicación en Amazon S3 de los archivos del genoma de referencia. Las plantillas de parámetros se pueden proporcionar a través de un servicio de repositorio basado en Git o de su unidad local. A continuación, los usuarios pueden ejecutar el flujo de trabajo utilizando varios conjuntos de datos.
Puede crear la plantilla de parámetros para su flujo de trabajo o HealthOmics puede generar la plantilla de parámetros automáticamente.
La plantilla de parámetros es un archivo JSON. En el archivo, cada parámetro de entrada es un objeto con nombre que debe coincidir con el nombre de la entrada del flujo de trabajo. Cuando se inicia una ejecución, si no se proporcionan valores para todos los parámetros necesarios, se produce un error en la ejecución.
El objeto de parámetro de entrada incluye los siguientes atributos:
+ **description**— Este atributo obligatorio es una cadena que la consola muestra en la página de **inicio de la ejecución**. Esta descripción también se conserva como metadatos de ejecución.
+ **optional**— Este atributo opcional indica si el parámetro de entrada es opcional. Si no especifica el **optional** campo, el parámetro de entrada es obligatorio.
En el siguiente ejemplo de plantilla de parámetros se muestra cómo especificar los parámetros de entrada.
```
{
"myRequiredParameter1": {
"description": "this parameter is required",
},
"myRequiredParameter2": {
"description": "this parameter is also required",
"optional": false
},
"myOptionalParameter": {
"description": "this parameter is optional",
"optional": true
}
}
```
## Generación de plantillas de parámetros
HealthOmics genera la plantilla de parámetros analizando la definición del flujo de trabajo para detectar los parámetros de entrada. Si proporciona un archivo de plantilla de parámetros para un flujo de trabajo, los parámetros del archivo anulan los parámetros detectados en la definición del flujo de trabajo.
Existen pequeñas diferencias entre la lógica de análisis de los motores CWL, WDL y Nextflow, como se describe en las siguientes secciones.
**Topics**
+ [Detección de parámetros para CWL](#parameter-parsing-cwl)
+ [Detección de parámetros para WDL](#parameter-parsing-wdl)
+ [Detección de parámetros para Nextflow](#parameter-parsing-nextflow)
### Detección de parámetros para CWL
En el motor de flujo de trabajo CWL, la lógica de análisis hace las siguientes suposiciones:
+ Todos los tipos admitidos que admiten valores NULL se marcan como parámetros de entrada opcionales.
+ Todos los tipos admitidos que no sean nulos se marcan como parámetros de entrada obligatorios.
+ Todos los parámetros con valores predeterminados se marcan como parámetros de entrada opcionales.
+ Las descripciones se extraen de la `label` sección de la definición del `main` flujo de trabajo. Si no `label` se especifica, la descripción estará en blanco (una cadena vacía).
En las tablas siguientes se muestran ejemplos de interpolación de CWL. Para cada ejemplo, el nombre del parámetro es. `x` Si el parámetro es obligatorio, debe proporcionar un valor para el parámetro. Si el parámetro es opcional, no es necesario que proporcione un valor.
En esta tabla se muestran ejemplos de interpolación de CWL para tipos primitivos.
| Input | Ejemplo de entrada/salida | Obligatorio |
| --- | --- | --- |
| x:
type: int
| 1 o 2 o... | Sí |
| x:
type: int
default: 2
| El valor predeterminado es 2. La entrada válida es 1 o 2 o... | No |
| x:
type: int?
| La entrada válida es Ninguna o 1 o 2 o... | No |
| x:
type: int?
default: 2
| El valor predeterminado es 2. La entrada válida es Ninguna o 1 o 2 o... | No |
La siguiente tabla muestra ejemplos de interpolación de CWL para tipos complejos. Un tipo complejo es una colección de tipos primitivos.
| Input | Ejemplo de entrada/salida | Obligatorio |
| --- | --- | --- |
| x:
type: array
items: int
| [] o [1,2,3] | Sí |
| x:
type: array?
items: int
| Ninguno o [] o [1,2,3] | No |
| x:
type: array
items: int?
| [] o [Ninguno, 3, Ninguno] | Sí |
| x:
type: array?
items: int?
| [Ninguno] o Ninguno o [1,2,3] o [Ninguno, 3] pero no [] | No |
### Detección de parámetros para WDL
En el motor de flujo de trabajo de la WDL, la lógica de análisis hace las siguientes suposiciones:
+ Todos los tipos admitidos que admiten valores NULL se marcan como parámetros de entrada opcionales.
+ Para los tipos admitidos que no admiten valores nulos:
+ Cualquier variable de entrada con asignación de literales o expresiones se marca como parámetro opcional. Por ejemplo:
```
Int x = 2
Float f0 = 1.0 + f1
```
+ Si no se ha asignado ningún valor o expresión a los parámetros de entrada, se marcarán como parámetros obligatorios.
+ Las descripciones se `parameter_meta` extraen de la definición del `main` flujo de trabajo. Si no `parameter_meta` se especifica, la descripción aparecerá en blanco (una cadena vacía). Para obtener más información, consulte la especificación WDL para los [metadatos de los parámetros](https://github.com/openwdl/wdl/blob/wdl-1.2/SPEC.md#metadata-sections).
En las tablas siguientes se muestran ejemplos de interpolación de la WDL. Para cada ejemplo, el nombre del parámetro es. `x` Si el parámetro es obligatorio, debe proporcionar un valor para el parámetro. Si el parámetro es opcional, no es necesario que proporcione un valor.
En esta tabla se muestran ejemplos de interpolación de WDL para tipos primitivos.
| Input | Ejemplo de entrada/salida | Obligatorio |
| --- | --- | --- |
| Int x | 1 o 2 o... | Sí |
| Int x = 2 | 2 | No |
| Int x = 1\$12 | 3 | No |
| Int x = y\$1z | y\$1z | No |
| ¿Int? x | Ninguno o 1 o 2 o... | Sí |
| ¿Int? x = 2 | Ninguno o 2 | No |
| ¿Int? x = 1\$12 | Ninguno o 3 | No |
| ¿Int? x = y\$1z | Ninguno o y\$1z | No |
La siguiente tabla muestra ejemplos de interpolación de WDL para tipos complejos. Un tipo complejo es un conjunto de tipos primitivos.
| Input | Ejemplo de entrada/salida | Obligatorio |
| --- | --- | --- |
| Array [Int] x | [1,2,3] o [] | Sí |
| Matriz [Int] \$1 x | [1], pero no [] | Sí |
| ¿Matriz [Int]? x | Ninguno o [] o [1,2,3] | No |
| Matriz [Int?] x | [] o [Ninguno, 3, Ninguno] | Sí |
| Matriz [Int?] =? x | [Ninguno] o Ninguno o [1,2,3] o [Ninguno, 3] pero no [] | No |
| Ejemplo de estructura \$1String a, Int y\$1 más adelante en las entradas: Sample mySample | String a = mySample.a
Int y = mySample.y
| Sí |
| Ejemplo de estructura \$1String a, Int y\$1 más adelante en las entradas: ¿Ejemplo? ¿Mi muestra | if (defined(mySample)) {
String a = mySample.a
Int y = mySample.y
} | No |
### Detección de parámetros para Nextflow
En el caso de Nextflow, HealthOmics genera la plantilla de parámetros analizando el archivo. `nextflow_schema.json` Si la definición del flujo de trabajo no incluye un archivo de esquema, HealthOmics analiza el archivo de definición del flujo de trabajo principal.
**Topics**
+ [Analizar el archivo de esquema](#parameter-parsing-nextflow-schema)
+ [Analizando el archivo principal](#parameter-parsing-nextflow-main)
+ [Parámetros anidados](#parameter-parsing-nextflow-nested)
+ [Ejemplos de interpolación de Nextflow](#parameter-parsing-nextflow-examples)
#### Analizar el archivo de esquema
Para que el análisis funcione correctamente, asegúrese de que el archivo de esquema cumpla los siguientes requisitos:
+ El archivo de esquema recibe un nombre `nextflow_schema.json` y se encuentra en el mismo directorio que el archivo de flujo de trabajo principal.
+ El archivo de esquema es un JSON válido, tal como se define en cualquiera de los siguientes esquemas:
+ [esquema json. org/draft/2020-12/schema](https://json-schema.org/draft/2020-12/schema).
+ [esquema json. org/draft-07/schema](https://json-schema.org/draft-07/schema).
HealthOmics analiza el `nextflow_schema.json` archivo para generar la plantilla de parámetros:
+ Extrae todo **properties** lo que está definido en el esquema.
+ Incluye la propiedad **description** si está disponible para la propiedad.
+ Identifica si cada parámetro es opcional u obligatorio, en función del **required** campo de la propiedad.
El siguiente ejemplo muestra un archivo de definición y el archivo de parámetros generado.
```
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"type": "object",
"$defs": {
"input_options": {
"title": "Input options",
"type": "object",
"required": ["input_file"],
"properties": {
"input_file": {
"type": "string",
"format": "file-path",
"pattern": "^s3://[a-z0-9.-]{3,63}(?:/\\S*)?$",
"description": "description for input_file"
},
"input_num": {
"type": "integer",
"default": 42,
"description": "description for input_num"
}
}
},
"output_options": {
"title": "Output options",
"type": "object",
"required": ["output_dir"],
"properties": {
"output_dir": {
"type": "string",
"format": "file-path",
"description": "description for output_dir",
}
}
}
},
"properties": {
"ungrouped_input_bool": {
"type": "boolean",
"default": true
}
},
"required": ["ungrouped_input_bool"],
"allOf": [
{ "$ref": "#/$defs/input_options" },
{ "$ref": "#/$defs/output_options" }
]
}
```
La plantilla de parámetros generada:
```
{
"input_file": {
"description": "description for input_file",
"optional": False
},
"input_num": {
"description": "description for input_num",
"optional": True
},
"output_dir": {
"description": "description for output_dir",
"optional": False
},
"ungrouped_input_bool": {
"description": None,
"optional": False
}
}
```
#### Analizando el archivo principal
Si la definición del flujo de trabajo no incluye un `nextflow_schema.json` archivo, HealthOmics analiza el archivo de definición del flujo de trabajo principal.
HealthOmics analiza las `params` expresiones que se encuentran en el archivo principal de definición del flujo de trabajo y en el `nextflow.config` archivo. Todas `params` las que tengan valores predeterminados se marcan como opcionales.
Para que el análisis funcione correctamente, tenga en cuenta los siguientes requisitos:
+ HealthOmics analiza solo el archivo de definición del flujo de trabajo principal. Para garantizar que se capturen todos los parámetros, le recomendamos que los conecte todos los **params** submódulos y flujos de trabajo importados.
+ El archivo de configuración es opcional. Si define uno, asígnele un nombre `nextflow.config` y colóquelo en el mismo directorio que el archivo de definición del flujo de trabajo principal.
El siguiente ejemplo muestra un archivo de definición y la plantilla de parámetros generada.
```
params.input_file = "default.txt"
params.threads = 4
params.memory = "8GB"
workflow {
if (params.version) {
println "Using version: ${params.version}"
}
}
```
La plantilla de parámetros generada:
```
{
"input_file": {
"description": None,
"optional": True
},
"threads": {
"description": None,
"optional": True
},
"memory": {
"description": None,
"optional": True
},
"version": {
"description": None,
"optional": False
}
}
```
Para los valores predeterminados que se definen en nextflow.config, HealthOmics recopila `params` las asignaciones y los parámetros declarados en ellos`params {}`, como se muestra en el siguiente ejemplo. En las sentencias de asignación, `params` debe aparecer en el lado izquierdo de la sentencia.
```
params.alpha = "alpha"
params.beta = "beta"
params {
gamma = "gamma"
delta = "delta"
}
env {
// ignored, as this assignment isn't in the params block
VERSION = "TEST"
}
// ignored, as params is not on the left side
interpolated_image = "${params.cli_image}"
```
La plantilla de parámetros generada:
```
{
// other params in your main workflow defintion
"alpha": {
"description": None,
"optional": True
},
"beta": {
"description": None,
"optional": True
},
"gamma": {
"description": None,
"optional": True
},
"delta": {
"description": None,
"optional": True
}
}
```
#### Parámetros anidados
Ambos `nextflow.config` permiten `nextflow_schema.json` parámetros anidados. Sin embargo, la plantilla de HealthOmics parámetros solo requiere los parámetros de nivel superior. Si su flujo de trabajo utiliza un parámetro anidado, debe proporcionar un objeto JSON como entrada para ese parámetro.
##### Parámetros anidados en archivos de esquema
HealthOmics omite los anidados **params** al analizar un archivo. `nextflow_schema.json` Por ejemplo, si define el siguiente archivo: `nextflow_schema.json`
```
{
"properties": {
"input": {
"properties": {
"input_file": { ... },
"input_num": { ... }
}
},
"input_bool": { ... }
}
}
```
HealthOmics ignora `input_file` y `input_num` cuando genera la plantilla de parámetros:
```
{
"input": {
"description": None,
"optional": True
},
"input_bool": {
"description": None,
"optional": True
}
}
```
Al ejecutar este flujo de trabajo, HealthOmics espera un `input.json` archivo similar al siguiente:
```
{
"input": {
"input_file": "s3://bucket/obj",
"input_num": 2
},
"input_bool": false
}
```
##### Parámetros anidados en los archivos de configuración
HealthOmics no recopila los anidados **params** en un `nextflow.config` archivo y los omite durante el análisis. Por ejemplo, si define el siguiente archivo: `nextflow.config`
```
params.alpha = "alpha"
params.nested.beta = "beta"
params {
gamma = "gamma"
group {
delta = "delta"
}
}
```
HealthOmics ignora `params.nested.beta` y `params.group.delta` cuando genera la plantilla de parámetros:
```
{
"alpha": {
"description": None,
"optional": True
},
"gamma": {
"description": None,
"optional": True
}
}
```
#### Ejemplos de interpolación de Nextflow
La siguiente tabla muestra ejemplos de interpolación de Nextflow para los parámetros del archivo principal.
| Parámetros | Obligatorio |
| --- | --- |
| params.input\$1file | Sí |
| params.input\$1file = "s3://bucket/data.json» | No |
| params.nested.input\$1file | N/A |
| params.nested.input\$1file = "s3://bucket/data.json» | N/A |
La siguiente tabla muestra ejemplos de interpolación de Nextflow para los parámetros del archivo. `nextflow.config`
| Parámetros | Obligatorio |
| --- | --- |
| params.input_file = "s3://bucket/data.json"
| No |
| params {
input_file = "s3://bucket/data.json"
} | No |
| params {
nested {
input_file = "s3://bucket/data.json"
}
} | N/A |
| input_file = params.input_file
| N/A |
# Imágenes de contenedores para flujos de trabajo privados
HealthOmics admite imágenes de contenedores alojadas en repositorios privados de Amazon ECR. Puede crear imágenes de contenedores y subirlas al repositorio privado. También puede usar su registro privado de Amazon ECR como caché de extracción para sincronizar el contenido de los registros anteriores.
Su repositorio de Amazon ECR debe residir en la misma AWS región que la cuenta que llama al servicio. La imagen del contenedor Cuenta de AWS puede ser propiedad de otra persona, siempre que el repositorio de imágenes de origen proporcione los permisos adecuados. Para obtener más información, consulte [Políticas de acceso multicuenta a Amazon ECR](permissions-ecr.md#permissions-cross-account).
Le recomendamos que defina la imagen del contenedor de Amazon ECR URIs como parámetros de su flujo de trabajo para poder verificar el acceso antes de que comience la ejecución. También facilita la ejecución de un flujo de trabajo en una nueva región al cambiar el parámetro de región.
**nota**
HealthOmics no admite contenedores ARM ni admite el acceso a repositorios públicos.
Para obtener información sobre la configuración de los permisos de IAM para acceder HealthOmics a Amazon ECR, consulte. [HealthOmics Permisos de recursos](permissions-resource.md)
**Topics**
+ [Sincronización con registros de contenedores de terceros](#ecr-pull-through)
+ [Consideraciones generales sobre las imágenes de contenedores de Amazon ECR](#ecr-considerations)
+ [Variables de entorno para los HealthOmics flujos de trabajo](#ecr-env-vars)
+ [Uso de Java en imágenes de contenedores de Amazon ECR](#ecr-java-considerations)
+ [Añadir entradas de tareas a una imagen de contenedor de Amazon ECR](#ecr-tasks)
## Sincronización con registros de contenedores de terceros
Puede utilizar las reglas de caché de extracción de Amazon ECR para sincronizar los repositorios de un registro ascendente compatible con sus repositorios privados de Amazon ECR. Para obtener más información, consulte [Sincronizar un registro ascendente](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache.html) en la Guía del *usuario de Amazon ECR.*
La memoria caché extraíble crea automáticamente el repositorio de imágenes en su registro privado al crear la memoria caché y se sincroniza automáticamente con la imagen almacenada en caché cuando se producen cambios en la imagen original.
HealthOmics admite la caché extraíble para los siguientes registros ascendentes:
+ Amazon ECR Public
+ Registro de imágenes de contenedores de Kubernetes
+ Quay
+ Docker Hub
+ Para Microsoft Azure Container Registry
+ GitHub Registro de contenedores
+ GitLab Registro de contenedores
HealthOmics no admite la extracción de caché para un repositorio privado upstream de Amazon ECR.
Entre las ventajas de utilizar la memoria caché de extracción de Amazon ECR se incluyen las siguientes:
1. Evita tener que migrar manualmente las imágenes del contenedor a Amazon ECR o sincronizar las actualizaciones del repositorio de terceros.
1. Los flujos de trabajo acceden a las imágenes de contenedores sincronizadas de su repositorio privado, lo que resulta más fiable que descargar contenido en tiempo de ejecución desde un registro público.
1. Como las cachés de extracción de Amazon ECR utilizan una estructura de URI predecible, el HealthOmics servicio puede mapear automáticamente el URI privado de Amazon ECR con el URI del registro anterior. No es necesario que actualice ni sustituya los valores de URI en la definición del flujo de trabajo.
**Topics**
+ [Configuración de la memoria caché de extracción](#ecr-pull-through-configure)
+ [Asignaciones de registro](#ecr-pull-through-registry-mapping)
+ [Mapeos de imágenes](#ecr-pull-through-mapping-format)
### Configuración de la memoria caché de extracción
Amazon ECR proporciona un registro para usted Cuenta de AWS en cada región. Asegúrese de crear la configuración de Amazon ECR en la misma región en la que planea ejecutar el flujo de trabajo.
En las siguientes secciones se describen las tareas de configuración de la memoria caché extraíble.
**Topics**
+ [Cree una regla de extracción de caché](#create-ecr-ptc)
+ [Permisos de registro para el registro inicial](#reg-ecr-ptc)
+ [Plantillas de creación de repositorios](#repo-create-templates-ptc)
+ [Creación de un flujo de trabajo](#reg-mapping-ecr-ptc)
#### Cree una regla de extracción de caché
Cree una regla de caché de extracción de Amazon ECR para cada registro ascendente que contenga imágenes que desee almacenar en caché. Una regla especifica un mapeo entre un registro ascendente y el repositorio privado de Amazon ECR.
En el caso de un registro previo que requiera autenticación, debe proporcionar sus credenciales mediante AWS Secrets Manager.
**nota**
No modifique una regla de extracción de caché mientras una ejecución activa utilice el repositorio privado. La ejecución podría fallar o, lo que es más grave, provocar que tu canalización utilice imágenes inesperadas.
Para obtener más información, consulte [Creación de una regla de extracción de caché](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache-creating-rule.html) en la *Guía del usuario de Amazon Elastic Container Registry*.
##### Cree una regla de extracción de caché mediante la consola
Para configurar la memoria caché de extracción, siga estos pasos con la consola Amazon ECR:
1. Abra la consola de Amazon ECR: https://console.aws.amazon.com /ecr
1. En el menú de la izquierda, en **Registro privado**, expanda **Características y configuración y**, a continuación, seleccione **Extraer** caché.
1. En la página **de extracción de caché**, selecciona **Añadir regla**.
1. **En el panel de **registro inicial**, selecciona el registro inicial para sincronizarlo con tu registro privado y, a continuación, selecciona Siguiente.**
1. Si el registro principal requiere autenticación, la consola abre una nueva página en la que puede especificar el secreto de SageMaker IA que contiene sus credenciales. Elija **Siguiente**.
1. En **Especificar espacios de nombres**, en el panel de espacios de **nombres de Cache**, elige si quieres crear los repositorios privados con un prefijo de repositorio específico o sin prefijo. **Si opta por usar un prefijo, especifique el nombre del prefijo en el prefijo del repositorio de caché.**
1. En el panel del espacio de **nombres de Upstream**, elija si desea extraer datos de los repositorios ascendentes con un prefijo de repositorio específico o sin prefijo. **Si opta por utilizar un prefijo, especifique el nombre del prefijo en el prefijo del repositorio de Upstream.**
El panel de **ejemplos del espacio de nombres** muestra un ejemplo de solicitud de cambios, una URL anterior y la URL del repositorio de caché que se ha creado.
1. Elija **Siguiente**.
1. Revisa la configuración y selecciona **Crear para crear** la regla.
Para obtener más información, consulte [Crear una regla de extracción de memoria caché (consola AWS de administración)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache-creating-rule.html#pull-through-cache-creating-rule-console).
##### Cree una regla de extracción de caché mediante la CLI
Utilice el **create-pull-through-cache-rule** comando Amazon ECR para crear una regla de extracción de caché. En el caso de los registros anteriores que requieren autenticación, almacene las credenciales en un secreto de Secrets Manager.
En las siguientes secciones se proporcionan ejemplos de cada registro ascendente compatible.
##### Para Amazon ECR Public
En el siguiente ejemplo se crea una regla de caché de extracción para el registro público de Amazon ECR. Especifica un prefijo de repositorio `ecr-public`, lo que da como resultado que cada repositorio se cree mediante la regla de caché de extracción para tener el esquema de nomenclatura de `ecr-public/upstream-repository-name`.
```
aws ecr create-pull-through-cache-rule \
--ecr-repository-prefix ecr-public \
--upstream-registry-url public.ecr.aws \
--region us-east-1
```
##### Para el registro de contenedores de Kubernetes
En el siguiente ejemplo se crea una regla de extracción de caché para el registro público de Kubernetes. Especifica un prefijo de repositorio `kubernetes`, lo que da como resultado que cada repositorio se cree mediante la regla de caché de extracción para tener el esquema de nomenclatura de `kubernetes/upstream-repository-name`.
```
aws ecr create-pull-through-cache-rule \
--ecr-repository-prefix kubernetes \
--upstream-registry-url registry.k8s.io \
--region us-east-1
```
##### Para Quay
El siguiente ejemplo crea una regla de extracción de caché para el registro público de Quay. Especifica un prefijo de repositorio `quay`, lo que da como resultado que cada repositorio se cree mediante la regla de caché de extracción para tener el esquema de nomenclatura de `quay/upstream-repository-name`.
```
aws ecr create-pull-through-cache-rule \
--ecr-repository-prefix quay \
--upstream-registry-url quay.io \
--region us-east-1
```
##### Para Docker Hub
El siguiente ejemplo crea una regla de caché de extracción para el registro de Docker Hub. Especifica un prefijo de repositorio `docker-hub`, lo que da como resultado que cada repositorio se cree mediante la regla de caché de extracción para tener el esquema de nomenclatura de `docker-hub/upstream-repository-name`. Debe especificar el nombre de recurso de Amazon (ARN) completo del secreto que contiene las credenciales de Docker Hub.
```
aws ecr create-pull-through-cache-rule \
--ecr-repository-prefix docker-hub \
--upstream-registry-url registry-1.docker.io \
--credential-arn arn:aws:secretsmanager:us-east-1:111122223333:secret:ecr-pullthroughcache/example1234 \
--region us-east-1
```
##### Para GitHub Container Registry
En el siguiente ejemplo, se crea una regla de extracción de caché para el GitHub Container Registry. Especifica un prefijo de repositorio `github`, lo que da como resultado que cada repositorio se cree mediante la regla de caché de extracción para tener el esquema de nomenclatura de `github/upstream-repository-name`. Debe especificar el nombre de recurso de Amazon (ARN) completo del secreto que contiene sus credenciales de GitHub Container Registry.
```
aws ecr create-pull-through-cache-rule \
--ecr-repository-prefix github \
--upstream-registry-url ghcr.io \
--credential-arn arn:aws:secretsmanager:us-east-1:111122223333:secret:ecr-pullthroughcache/example1234 \
--region us-east-1
```
##### Para Microsoft Azure Container Registry
El siguiente ejemplo crea una regla de caché de extracción para el Microsoft Azure Container Registry. Especifica un prefijo de repositorio `azure`, lo que da como resultado que cada repositorio se cree mediante la regla de caché de extracción para tener el esquema de nomenclatura de `azure/upstream-repository-name`. Debe especificar el nombre de recurso de Amazon (ARN) completo del secreto que contiene las credenciales de Microsoft Azure Container Registry.
```
aws ecr create-pull-through-cache-rule \
--ecr-repository-prefix azure \
--upstream-registry-url myregistry.azurecr.io \
--credential-arn arn:aws:secretsmanager:us-east-1:111122223333:secret:ecr-pullthroughcache/example1234 \
--region us-east-1
```
##### Para GitLab Container Registry
En el siguiente ejemplo, se crea una regla de extracción de caché para el GitLab Container Registry. Especifica un prefijo de repositorio `gitlab`, lo que da como resultado que cada repositorio se cree mediante la regla de caché de extracción para tener el esquema de nomenclatura de `gitlab/upstream-repository-name`. Debe especificar el nombre de recurso de Amazon (ARN) completo del secreto que contiene sus credenciales de GitLab Container Registry.
```
aws ecr create-pull-through-cache-rule \
--ecr-repository-prefix gitlab \
--upstream-registry-url registry.gitlab.com \
--credential-arn arn:aws:secretsmanager:us-east-1:111122223333:secret:ecr-pullthroughcache/example1234 \
--region us-east-1
```
Para obtener más información, consulte [Crear una regla de extracción de caché (CLI)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache-creating-rule.html#pull-through-cache-creating-rule-cli) en la *Guía del usuario de Amazon ECR.*
Puede usar el comando **get-run-task** CLI para recuperar información sobre la imagen del contenedor utilizada para una tarea específica:
```
aws omics get-run-task --id 1234567 --task-id
```
El resultado incluye la siguiente información sobre la imagen del contenedor:
```
"imageDetails": {
"image": "string",
"imageDigest": "string",
"sourceImage": "string",
...
}
```
#### Permisos de registro para el registro inicial
Utilice los permisos de registro HealthOmics para poder utilizar la caché de extracción y extraer las imágenes del contenedor al registro privado de Amazon ECR. Añada una política de registro de Amazon ECR al registro que proporcione los contenedores utilizados en las ejecuciones.
La siguiente política otorga permiso al HealthOmics servicio para crear repositorios con los prefijos de caché de extracción especificados e iniciar extracciones ascendentes en estos repositorios.
1. En la consola Amazon ECR, abra el menú de la izquierda, en **Registro privado**, expanda **Permisos de registro** y, a continuación, seleccione **Generar declaración**.
1. En la parte superior derecha, selecciona JSON. Introduce una política similar a la siguiente:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowPTCinRegPermissions",
"Effect": "Allow",
"Principal": {
"Service": "omics.amazonaws.com"
},
"Action": [
"ecr:CreateRepository",
"ecr:BatchImportUpstreamImage"
],
"Resource": [
"arn:aws:ecr:us-east-1:123456789012:repository/ecr-public/*",
"arn:aws:ecr:us-east-1:123456789012:repository/docker-hub/*"
]
}
]
}
```
------
#### Plantillas de creación de repositorios
Para utilizar el almacenamiento en caché mediante extracción HealthOmics, el repositorio de Amazon ECR debe tener una plantilla de creación de repositorios. La plantilla define los ajustes de configuración para cuando usted o Amazon ECR creen un repositorio privado para un registro principal.
Cada plantilla contiene un prefijo de espacio de nombres de repositorio, que Amazon ECR utiliza para hacer coincidir los nuevos repositorios con una plantilla específica. Las plantillas especifican la configuración de todos los ajustes del repositorio, incluidas las políticas de acceso basadas en los recursos, la inmutabilidad de las etiquetas, el cifrado y las políticas de ciclo de vida.
Para obtener más información, consulte las [plantillas de creación de repositorios](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-creation-templates.html) en la *Guía del usuario de Amazon Elastic Container Registry*.
Cómo crear una plantilla de creación de repositorios:
1. En la consola de Amazon ECR, abra el menú de la izquierda, en **Registro privado**, expanda **Características y configuración y**, a continuación, seleccione **Plantillas de creación de repositorios**.
1. Seleccione **Crear plantilla**.
1. En **Detalles de la plantilla**, selecciona **Extraer caché**.
1. Elige si quieres aplicar esta plantilla a un prefijo específico o a todos los repositorios que no coincidan con otra plantilla.
**Si eliges **un prefijo específico, introduce el valor del prefijo** del espacio de nombres en Prefix.** Especificó este prefijo al crear la regla de PTC.
1. Elija **Siguiente**.
1. En la página **Añadir configuración de creación de repositorios**, introduzca los permisos **del repositorio**. Utilice uno de los ejemplos de declaraciones de política o introduzca uno similar al ejemplo siguiente:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "PTCRepoCreationTemplate",
"Effect": "Allow",
"Principal": {
"Service": "omics.amazonaws.com"
},
"Action": [
"ecr:BatchGetImage",
"ecr:GetDownloadUrlForLayer"
],
"Resource": "*"
}
]
}
```
------
1. Si lo desea, puede añadir la configuración del repositorio, como la política del ciclo de vida y las etiquetas. Amazon ECR aplica estas reglas a todas las imágenes de contenedores creadas para la caché de extracción que utilizan el prefijo especificado.
1. Elija **Siguiente**.
1. **Revise la configuración y seleccione Siguiente.**
#### Creación de un flujo de trabajo
Al crear un nuevo flujo de trabajo o una nueva versión del flujo de trabajo, revise las asignaciones del registro y actualícelas si es necesario. Para obtener más información, consulte [Crear un flujo de trabajo privado](create-private-workflow.md).
### Asignaciones de registro
Defina las asignaciones de registro para mapear entre los prefijos de su registro privado de Amazon ECR y los nombres de registro anteriores.
Para obtener más información sobre las asignaciones de registro de Amazon ECR, consulte [Creación de una regla de extracción de caché en Amazon](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache-creating-rule.html) ECR.
El siguiente ejemplo muestra las asignaciones de registro a Docker Hub, Quay y Amazon ECR Public.
```
{
"registryMappings": [
{
"upstreamRegistryUrl": "registry-1.docker.io",
"ecrRepositoryPrefix": "docker-hub"
},
{
"upstreamRegistryUrl": "quay.io",
"ecrRepositoryPrefix": "quay"
},
{
"upstreamRegistryUrl": "public.ecr.aws",
"ecrRepositoryPrefix": "ecr-public"
}
]
}
```
### Mapeos de imágenes
Defina las asignaciones de imágenes para mapearlas entre los nombres de las imágenes tal como se definen en sus flujos de trabajo privados de Amazon ECR y los nombres de las imágenes en el registro principal.
Puede utilizar las asignaciones de imágenes con registros que admitan la extracción de memoria caché. También puedes usar mapeos de imágenes con registros anteriores en los que no se HealthOmics admite la extracción de memoria caché. Tienes que sincronizar manualmente el registro original con tu repositorio privado.
Para obtener más información sobre las asignaciones de imágenes de Amazon ECR, consulte [Creación de una regla de extracción de caché en Amazon](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache-creating-rule.html) ECR.
El siguiente ejemplo muestra las asignaciones de imágenes privadas de Amazon ECR a una imagen genómica pública y a la imagen más reciente de Ubuntu.
```
{
"imageMappings": [
{
"sourceImage": "public.ecr.aws/aws-genomics/broadinstitute/gatk:4.6.0.2",
"destinationImage": "123456789012.dkr.ecr.us-east-1.amazonaws.com/broadinstitute/gatk:4.6.0.2"
},
{
"sourceImage": "ubuntu:latest",
"destinationImage": "123456789012.dkr.ecr.us-east-1.amazonaws.com/custom/ubuntu:latest",
}
]
}
```
## Consideraciones generales sobre las imágenes de contenedores de Amazon ECR
+ Arquitectura
HealthOmics admite contenedores x86\$164. Si su máquina local está basada en ARM, como Apple Mac, utilice un comando como el siguiente para crear una imagen de contenedor x86\$164:
```
docker build --platform amd64 -t my_tool:latest .
```
+ Punto de entrada y carcasa
HealthOmics Los motores de flujo de trabajo inyectan scripts bash como una sustitución de comandos en las imágenes del contenedor utilizadas en las tareas del flujo de trabajo. Por lo tanto, las imágenes de los contenedores deben crearse sin un PUNTO DE ENTRADA específico, de modo que el shell bash sea el predeterminado.
+ Rutas montadas
Un sistema de archivos compartido se monta en las tareas del contenedor en /tmp. Se anularán todos los datos o herramientas integrados en la imagen del contenedor en esta ubicación.
La definición del flujo de trabajo está disponible para las tareas mediante un montaje de solo lectura en /mnt/workflow.
+ Tamaño de imagen
Consulte los tamaños máximos [HealthOmics cuotas de tamaño fijas en el flujo de trabajo](fixed-quotas.md#fixed-quotas-workflows) de imagen del contenedor.
## Variables de entorno para los HealthOmics flujos de trabajo
HealthOmics proporciona variables de entorno que contienen información sobre el flujo de trabajo que se ejecuta en el contenedor. Puede utilizar los valores de estas variables en la lógica de las tareas del flujo de trabajo.
Todas las variables HealthOmics del flujo de trabajo comienzan con el `AWS_WORKFLOW_` prefijo. Este prefijo es un prefijo de variable de entorno protegido. No utilice este prefijo para sus propias variables en los contenedores de flujo de trabajo.
HealthOmics proporciona las siguientes variables de entorno de flujo de trabajo:
**AWS\$1REGION**
Esta variable es la región en la que se ejecuta el contenedor.
**AWS\$1WORKFLOW\$1EJECUTAR**
Esta variable es el nombre de la ejecución actual.
**AWS\$1WORKFLOW\$1RUN\$1ID**
Esta variable es el identificador de ejecución de la ejecución actual.
**AWS\$1WORKFLOW\$1RUN\$1UUID**
Esta variable es el UUID de ejecución de la ejecución actual.
**AWS\$1WORKFLOW\$1TAREA**
Esta variable es el nombre de la tarea actual.
**AWS\$1WORKFLOW\$1TASK\$1ID**
Esta variable es el identificador de la tarea actual.
**AWS\$1WORKFLOW\$1TASK\$1UUID**
Esta variable es el UUID de la tarea actual.
El siguiente ejemplo muestra los valores típicos de cada variable de entorno:
```
AWS Region: us-east-1
Workflow Run: arn:aws:omics:us-east-1:123456789012:run/6470304
Workflow Run ID: 6470304
Workflow Run UUID: f4d9ed47-192e-760e-f3a8-13afedbd4937
Workflow Task: arn:aws:omics:us-east-1:123456789012:task/4192063
Workflow Task ID: 4192063
Workflow Task UUID: f0c9ed49-652c-4a38-7646-60ad835e0a2e
```
## Uso de Java en imágenes de contenedores de Amazon ECR
Si una tarea de flujo de trabajo utiliza una aplicación Java como GATK, tenga en cuenta los siguientes requisitos de memoria para el contenedor:
+ Las aplicaciones Java utilizan memoria de pila y memoria de pila. De forma predeterminada, la memoria de pila máxima es un porcentaje de la memoria total disponible en el contenedor. Este valor predeterminado depende de la distribución específica de la JVM y de la versión de la JVM, así que consulte la documentación correspondiente a su JVM o establezca explícitamente el máximo de memoria de pila mediante las opciones de la línea de comandos de Java (como `-Xmx`).
+ No establezcas que la memoria de pila máxima sea el 100% de la asignación de memoria del contenedor, ya que la pila de JVM también requiere memoria. También se necesita memoria para el recolector de elementos no utilizados de la JVM y para cualquier otro proceso del sistema operativo que se ejecute en el contenedor.
+ Algunas aplicaciones Java, como GATK, pueden utilizar invocaciones de métodos nativos u otras optimizaciones, como los archivos de mapeo de memoria. Estas técnicas requieren asignaciones de memoria que se realicen «fuera del montón», que no están controladas por el parámetro de pila máxima de la JVM.
Si sabe (o sospecha) que su aplicación Java asigna memoria fuera del montón, asegúrese de que la asignación de la memoria a las tareas incluya los requisitos de memoria fuera del montón.
Si estas asignaciones fuera del montón provocan que el contenedor se quede sin memoria, normalmente no aparecerá ningún **OutOfMemory** error de Java, ya que la JVM no controla esta memoria.
## Añadir entradas de tareas a una imagen de contenedor de Amazon ECR
Añada todos los ejecutables, bibliotecas y scripts necesarios para ejecutar una tarea de flujo de trabajo a la imagen de Amazon ECR que se utiliza para ejecutar la tarea.
Se recomienda evitar el uso de scripts, archivos binarios y bibliotecas externos a la imagen del contenedor de tareas. Esto es especialmente importante cuando se utilizan `nf-core` flujos de trabajo que utilizan un `bin` directorio como parte del paquete de flujo de trabajo. Si bien este directorio estará disponible para la tarea de flujo de trabajo, se monta como un directorio de solo lectura. Los recursos necesarios de este directorio deben copiarse en la imagen de la tarea y estar disponibles en tiempo de ejecución o al crear la imagen del contenedor utilizada para la tarea.
Consulte [HealthOmics cuotas de tamaño fijas en el flujo de trabajo](fixed-quotas.md#fixed-quotas-workflows) el tamaño máximo de la imagen del contenedor que HealthOmics admite.
# HealthOmics Archivos README de flujo de trabajo
Puede cargar un archivo README.md que contenga instrucciones, diagramas e información esencial para su flujo de trabajo. Cada versión del flujo de trabajo admite un archivo README, que puede actualizar en cualquier momento.
**Los requisitos de README incluyen:**
+ El archivo README debe estar en formato markdown (.md)
+ Tamaño máximo de archivo: 500 KiB
**Topics**
+ [Utilice un archivo README existente](#workflows-add-readme)
+ [Condiciones de renderizado](#workflows-rendering-readme)
## Utilice un archivo README existente
READMEs los archivos exportados desde los repositorios de Git contienen enlaces relativos que normalmente no funcionan fuera del repositorio. HealthOmics La integración de Git los convierte automáticamente en enlaces absolutos para una representación adecuada en la consola, lo que elimina la necesidad de actualizar manualmente las URL.
En el caso de READMEs importar desde Amazon S3 o unidades locales, las imágenes y los enlaces deben ser públicas URLs o tener sus rutas relativas actualizadas para que se representen correctamente.
**nota**
Las imágenes deben estar alojadas públicamente para poder mostrarse en la HealthOmics consola. Las imágenes almacenadas en GitHub Enterprise Server GitLab Self-Managed los repositorios no se pueden renderizar.
## Condiciones de renderizado
La HealthOmics consola interpola imágenes y enlaces de acceso público mediante rutas absolutas. Para renderizar URLs desde repositorios privados, el usuario debe tener acceso al repositorio. Nuestros GitHub Enterprise Server GitLab Self-Managed repositorios, que utilizan dominios personalizados, HealthOmics no pueden resolver los enlaces relativos ni renderizar las imágenes almacenadas en estos repositorios privados.
En la siguiente tabla se muestran los elementos de marcado compatibles con la vista README de la AWS consola.
| Elemento | AWS consola |
| --- | --- |
| Alertas | Sí, pero sin iconos |
| Insignias | Sí |
| Formato de texto básico | Sí |
| [Bloques de código](https://www.markdownguide.org/basic-syntax/#code-blocks) | Sí, pero no tiene la funcionalidad de [resaltar la sintaxis](https://www.markdownguide.org/extended-syntax/#syntax-highlighting) ni de copiar |
| Secciones plegables | Sí |
| [Encabezados](https://www.markdownguide.org/basic-syntax/#headings) | Sí |
| [Formatos de imagen](https://www.markdownguide.org/basic-syntax/#images-1) | Sí |
| [Imagen (en la que se puede hacer clic)](https://www.markdownguide.org/basic-syntax/#linking-images) | Sí |
| [Saltos de línea](https://www.markdownguide.org/basic-syntax/#line-breaks) | Sí |
| Diagrama de sirena | Solo puede abrir un gráfico, mover la posición del gráfico y copiar código |
| Cuotas | Sí |
| [https://www.markdownguide.org/extended-syntax/#subscript](https://www.markdownguide.org/extended-syntax/#subscript) | Sí |
| [Tablas](https://www.markdownguide.org/extended-syntax/#tables) | Sí, pero no admite la alineación del texto |
| Alineación de texto | Sí |
### Uso de imagen y enlace URLs
En función del proveedor de fuentes, estructura tu base URLs para las páginas e imágenes en los siguientes formatos.
+ `{username}`: El nombre de usuario en el que está alojado el repositorio.
+ `{repo}`: el nombre del repositorio.
+ `{ref}`: La referencia de origen (rama, etiqueta e ID de confirmación).
+ `{path}`: la ruta del archivo a la página o imagen del repositorio.
| Proveedor de fuentes | URL de la página | URL de la imagen |
| --- | --- | --- |
| GitHub | https://github.com/\$1username\$1/\$1repo\$1/blob/\$1ref\$1/\$1path\$1 | `https://github.com/{username}/{repo}/blob/{ref}/{path}?raw=true` `https://raw.githubusercontent.com/{username}/{repo}/{ref}/{path}` |
| GitLab | https://gitlab.com/\$1username\$1/\$1repo\$1/-/blob/\$1ref\$1/\$1path\$1 | https://gitlab.com/\$1username\$1/\$1repo\$1/-/raw/\$1ref\$1/\$1path\$1 |
| Bitbucket | https://bitbucket.org/\$1username\$1/\$1repo\$1/src/\$1ref\$1/\$1path\$1 | https://bitbucket.org/\$1username\$1/\$1repo\$1/raw/\$1ref\$1/\$1path\$1 |
GitHubGitLab, y Bitbucket admiten tanto páginas como imágenes URLs que enlazan a un repositorio público. En la siguiente tabla, se muestra la compatibilidad de cada proveedor de fuentes con la representación de imágenes y enlaces URLs en repositorios privados.
| Soporte para repositorios privados | Proveedor de fuentes | URL de la página | URL de la imagen |
| --- | --- | --- | --- |
| GitHub | Solo con acceso al repositorio | No |
| GitLab | Solo con acceso al repositorio | No |
| Bitbucket | Solo con acceso al repositorio | No |
# Solicitud de licencias de Sentieon para flujos de trabajo privados
Si su flujo de trabajo privado utiliza el software Sentieon, necesitará una licencia de Senieon. Siga estos pasos para solicitar y configurar una licencia para el software Sentieon:
+ Solicite una licencia de Sentieon
+ Envíe un correo electrónico al grupo de soporte de Sentieon (support@sentieon.com) para solicitar una licencia de software.
+ Introduce tu AWS seudónimo de Canonical en el correo electrónico.
+ [Sigue estas instrucciones para encontrar tu seudónimo de AWS Canonical.](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-identifiers.html#FindCanonicalId)
+ Actualiza tu rol HealthOmics de servicio para concederle acceso al proxy del servidor de licencias de Sentieon y al depósito Omics de Sentieon en tu región. El siguiente ejemplo permite el acceso a. `us-east-1` Si es necesario, sustituya este texto por su región.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObjectAcl",
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::omics-ap-us-east-1/*",
"arn:aws:s3:::sentieon-omics-license-us-east-1/*"
]
}
]
}
```
------
+ Genere un caso de AWS soporte para acceder al proxy del servidor de licencias de Sentieon.
+ Para crear un caso de soporte, vaya a [support.console.aws.amazon.com](https://support.console.aws.amazon.com).
+ Indique su región y su Cuenta de AWS región en el caso de soporte. Su cuenta se añade a la lista de permitidos para el proxy del servidor de licencias.
+ Cree su flujo de trabajo privado utilizando el contenedor Sentieon y el script de licencia Sentieon.
+ Para obtener instrucciones adicionales sobre el uso de las herramientas de Sentieon en flujos de trabajo privados, consulte [Sentieon-Amazon-Omics](https://github.com/Sentieon/sentieon-amazon-omics) en. GitHub
+ La versión 202112.07 y superior del software Sentieon son compatibles con el servidor proxy de licencias. HealthOmics Para utilizar las versiones del software Sentieon anteriores a la 202112.07, póngase en contacto con el servicio de asistencia de Sentieon.
# Lentes de flujo de trabajo en HealthOmics
Tras crear un flujo de trabajo, le recomendamos que ejecute un filtro en el flujo de trabajo antes de iniciar la primera ejecución. El linter detecta errores que pueden provocar un error en la ejecución.
En el caso de WDL, ejecuta HealthOmics automáticamente un linter al crear el flujo de trabajo. El resultado del linter está disponible en el `statusMessage` campo de la respuesta. **get-workflow** Utilice el siguiente comando CLI para recuperar la salida de estado (utilice el ID de flujo de trabajo del flujo de trabajo de WDL que creó):
```
aws omics get-workflow
—id 123456
—query 'statusMessage'
```
HealthOmics proporciona linters que puede ejecutar en la definición del flujo de trabajo antes de crearlo. Ejecuta estos linters en las canalizaciones existentes a las que vayas a migrar. HealthOmics
+ **WDL**— Una imagen pública de Amazon ECR para ejecutar un linter de [WDL](https://gallery.ecr.aws/aws-genomics/healthomics-linter).
+ **Nextflow**— Una imagen pública de Amazon ECR para ejecutar [las reglas de Linter para]( https://gallery.ecr.aws/aws-genomics/linter-rules-for-nextflow) Nextflow. Puede acceder al código fuente de este linter desde. [GitHub](https://github.com/awslabs/linter-rules-for-nextflow)
+ **CWL**— no disponible
# HealthOmics operaciones de flujo de trabajo
Para crear un flujo de trabajo privado, necesitas:
+ **Workflow definition file:**Un archivo de definición de flujo de trabajo escrito en WDLNextflow, oCWL. La definición del flujo de trabajo especifica las entradas y salidas de las ejecuciones que utilizan el flujo de trabajo. También incluye especificaciones para las ejecuciones y tareas de ejecución del flujo de trabajo, incluidos los requisitos de procesamiento y memoria. El archivo de definición del flujo de trabajo debe estar en `.zip` formato. Para obtener más información, consulte [Archivos de definición de flujo](workflow-definition-files.md) de trabajo en HealthOmics.
+ Puede usar [Amazon Q CLI](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/what-is.html) para crear y validar sus archivos de definición de flujo de trabajo en WDL, Nextflow y CWL. Para obtener más información, consulte [Ejemplos de instrucciones para Amazon Q CLI](getting-started.md#omics-q-prompts) y el tutorial sobre [HealthOmics IA generativa de Agentic](https://github.com/aws-samples/aws-healthomics-tutorials/tree/main/generative-ai) en. GitHub
+ **(Optional) Parameter template file:**Un archivo de plantilla de parámetros escrito en. JSON Cree el archivo para definir los parámetros de ejecución o HealthOmics genere la plantilla de parámetros automáticamente. Para obtener más información, consulte [Archivos de plantillas de parámetros para HealthOmics flujos de trabajo](parameter-templates.md).
+ **Amazon ECR container images:**Cree repositorios privados de Amazon ECR para cada contenedor utilizado en el flujo de trabajo. Cree imágenes de contenedores para el flujo de trabajo y guárdelas en un repositorio privado, o sincronice el contenido de un registro anterior compatible con su repositorio privado de ECR.
+ **(Optional) Sentieon licenses:**Solicita una Sentieon licencia para usar el Sentieon software en flujos de trabajo privados.
Para archivos de definición de flujo de trabajo de más de 4 MiB (comprimidos), elija una de estas opciones durante la creación del flujo de trabajo:
+ Cárguelo en una carpeta de Amazon Simple Storage Service y especifique la ubicación.
+ Cargue en un repositorio externo (tamaño máximo de 1 GiB) y especifique los detalles del repositorio.
Tras crear un flujo de trabajo, puede actualizar la siguiente información del flujo de trabajo con la `UpdateWorkflow` operación:
+ Name
+ Description (Descripción)
+ Tipo de almacenamiento predeterminado
+ Capacidad de almacenamiento predeterminada (con ID de flujo de trabajo)
+ Archivo README.md
Para cambiar otra información del flujo de trabajo, cree un nuevo flujo de trabajo o versión del flujo de trabajo.
Utilice el control de versiones del flujo de trabajo para organizar y estructurar sus flujos de trabajo. Las versiones también le ayudan a gestionar la introducción de actualizaciones iterativas del flujo de trabajo. Para obtener más información acerca de las versiones, consulte [Crear una versión de flujo de trabajo](workflows-version-create.md).
**Topics**
+ [Crear un flujo de trabajo privado](create-private-workflow.md)
+ [Actualizar un flujo de trabajo privado](update-private-workflow.md)
+ [Eliminar un flujo de trabajo privado](delete-private-workflow.md)
+ [Compruebe el estado del flujo de trabajo](using-get-workflow.md)
+ [Hacer referencia a los archivos del genoma a partir de una definición de flujo de trabajo](create-ref-files.md)
# Crear un flujo de trabajo privado
Cree un flujo de trabajo mediante la HealthOmics consola, los comandos AWS CLI o uno de los AWS SDKs.
**nota**
No incluya ninguna información de identificación personal (PII) en los nombres de los flujos de trabajo. Estos nombres están visibles en CloudWatch los registros.
Al crear un flujo de trabajo, HealthOmics asigna un identificador único universal (UUID) al flujo de trabajo. El UUID del flujo de trabajo es un identificador único global (GUID) que es único en todos los flujos de trabajo y versiones del flujo de trabajo. Para la procedencia de los datos, le recomendamos que utilice el UUID del flujo de trabajo para identificar los flujos de trabajo de forma exclusiva.
Si sus tareas de flujo de trabajo utilizan herramientas externas (ejecutables, bibliotecas o scripts), cree estas herramientas en una imagen contenedora. Dispone de las siguientes opciones para alojar la imagen del contenedor:
+ Aloje la imagen del contenedor en el registro privado del ECR. Requisitos previos para esta opción:
+ Cree un repositorio privado de ECR o elija uno existente.
+ Configure la política de recursos de ECR como se describe en. [Permisos de Amazon ECR](permissions-ecr.md)
+ Sube la imagen de tu contenedor al repositorio privado.
+ Sincronice la imagen del contenedor con el contenido de un registro de terceros compatible. Requisitos previos para esta opción:
+ En el registro privado del ECR, configure una regla de extracción de memoria caché para cada registro ascendente. Para obtener más información, consulte [Mapeos de imágenes](workflows-ecr.md#ecr-pull-through-mapping-format).
+ Configure la política de recursos de ECR como se describe en. [Permisos de Amazon ECR](permissions-ecr.md)
+ Cree plantillas de creación de repositorios. La plantilla define la configuración para cuando Amazon ECR cree el repositorio privado para un registro ascendente.
+ Cree asignaciones de prefijos para reasignar las referencias de las imágenes del contenedor en la definición del flujo de trabajo a los espacios de nombres de la caché de ECR.
Al crear un flujo de trabajo, se proporciona una definición de flujo de trabajo que contiene información sobre el flujo de trabajo, las ejecuciones y las tareas. HealthOmics puede recuperar la definición del flujo de trabajo como un archivo.zip almacenado localmente o en un bucket de Amazon S3, o desde un repositorio compatible basado en Git.
**Topics**
+ [Crear un flujo de trabajo mediante la consola](#console-create-workflows)
+ [Creación de un flujo de trabajo mediante la CLI](#api-create-workflows)
+ [Crear un flujo de trabajo mediante un SDK](#sdk-create-workflows)
## Crear un flujo de trabajo mediante la consola
**Pasos para crear un flujo de trabajo**
1. Abra la [consola de HealthOmics ](https://console.aws.amazon.com/omics/).
1. Si es necesario, abra el panel de navegación izquierdo (≡). Elija **Flujos de trabajo privados**.
1. En la página **Flujos de trabajo privados**, selecciona **Crear flujo de trabajo**.
1. En la página **Definir flujo** de trabajo, proporciona la siguiente información:
1. **Nombre del flujo** de trabajo: nombre distintivo de este flujo de trabajo. Recomendamos configurar los nombres de los flujos de trabajo para organizar las ejecuciones en la AWS HealthOmics consola y en CloudWatch los registros.
1. **Descripción** (opcional): descripción de este flujo de trabajo.
1. En el panel **de definición del flujo** de trabajo, proporcione la siguiente información:
1. **Idioma del flujo** de trabajo (opcional): seleccione el idioma de especificación del flujo de trabajo. De lo contrario, HealthOmics determina el idioma a partir de la definición del flujo de trabajo.
1. Para **la fuente de definición de flujo** de trabajo, elija importar la carpeta de definición desde un repositorio basado en Git, una ubicación de Amazon S3 o desde una unidad local.
1. Para **importar desde un servicio de repositorio**:
**nota**
HealthOmics admite repositorios públicos y privados paraGitHub,GitLab, BitbucketGitHub self-managed,GitLab self-managed.
1. Elija una **conexión** para conectar sus AWS recursos al repositorio externo. Para crear una conexión, consulte[Conéctese con repositorios de código externos](setting-up-new.md#setting-up-omics-repository).
**nota**
Los clientes de la TLV región deben crear una conexión en la región IAD (us-east-1) para crear un flujo de trabajo.
1. En ID de **repositorio completo, introduce tu ID** de repositorio como nombre de usuario/nombre de repositorio. Comprueba que tienes acceso a los archivos de este repositorio.
1. En **Referencia de origen** (opcional), introduce una referencia de origen del repositorio (rama, etiqueta o ID de confirmación). HealthOmics usa la rama predeterminada si no se especifica ninguna referencia a la fuente.
1. En **Excluir patrones de archivos**, introduzca los patrones de archivo para excluir carpetas, archivos o extensiones específicos. Esto ayuda a administrar el tamaño de los datos al importar archivos del repositorio. Hay un máximo de 50 patrones y los patrones deben seguir la sintaxis del [patrón global](https://fossil-scm.org/home/doc/tip/www/globs.md). Por ejemplo:
1. `tests/`
1. `*.jpeg`
1. `large_data.zip`
1. Para **seleccionar la carpeta de definiciones de S3**:
1. Introduzca la ubicación de Amazon S3 que contiene la carpeta comprimida de definiciones de flujos de trabajo. El bucket de Amazon S3 debe estar en la misma región que el flujo de trabajo.
1. Si su cuenta no es propietaria del depósito de Amazon S3, introduzca el ID de AWS cuenta del propietario del depósito en el ID de **cuenta del propietario del depósito de S3**. Esta información es necesaria para HealthOmics poder verificar la propiedad del bucket.
1. Para **seleccionar la carpeta de definiciones de una fuente local**:
1. Introduzca la ubicación de la unidad local de la carpeta comprimida de definiciones de flujo de trabajo.
1. **Ruta principal del archivo de definición del flujo** de trabajo (opcional): introduzca la ruta del archivo desde la carpeta o el repositorio de definiciones de flujo de trabajo comprimido hasta el `main` archivo. Este parámetro no es necesario si solo hay un archivo en la carpeta de definición del flujo de trabajo o si el archivo principal se denomina «principal».
1. En el panel del **archivo README** (opcional), seleccione la **fuente del archivo README** y proporcione la siguiente información:
+ Para **Importar desde un servicio de repositorio**, en la **ruta del archivo README**, introduzca la ruta al archivo README del repositorio.
+ En **Seleccione un archivo de S3**, en el **archivo README de S3**, introduzca el URI de Amazon S3 para el archivo README.
+ En **Seleccionar un archivo de una fuente local**: en **README (opcional)**, **elija Elegir archivo para seleccionar el archivo** marcado (.md) que desea cargar.
1. En el panel de **configuración del almacenamiento de ejecución predeterminado**, proporciona el tipo de almacenamiento de ejecución predeterminado y la capacidad para las ejecuciones que utilizan este flujo de trabajo:
1. **Tipo de almacenamiento de ejecución**: elija si desea utilizar el almacenamiento estático o dinámico como predeterminado para el almacenamiento de ejecución temporal. El valor predeterminado es el almacenamiento estático.
1. **Capacidad de almacenamiento de ejecución** (opcional): para el tipo de almacenamiento de ejecución estático, puede introducir la cantidad predeterminada de almacenamiento de ejecución necesaria para este flujo de trabajo. El valor predeterminado de este parámetro es 1200 GiB. Puede anular estos valores predeterminados al iniciar una ejecución.
1. **Etiquetas** (opcional): puedes asociar hasta 50 etiquetas a este flujo de trabajo.
1. Elija **Siguiente**.
1. En la página **Añadir parámetros de flujo** de trabajo (opcional), seleccione la **fuente de parámetros**:
1. Para **analizar desde un archivo de definición de flujo** de trabajo, HealthOmics analizará automáticamente los parámetros del flujo de trabajo del archivo de definición del flujo de trabajo.
1. Para **Proporcionar una plantilla de parámetros desde el repositorio de Git**, usa la ruta al archivo de plantillas de parámetros de tu repositorio.
1. Para **seleccionar un archivo JSON de una fuente local**, sube un JSON archivo de una fuente local que especifique los parámetros.
1. En **Introducir manualmente los parámetros del flujo** de trabajo, introduzca manualmente los nombres y las descripciones de los parámetros.
1. En el panel de **vista previa de los parámetros**, puede revisar o cambiar los parámetros de esta versión del flujo de trabajo. Si restaura el JSON archivo, perderá los cambios locales que haya realizado.
1. Elija **Siguiente**.
1. En la página de **reasignación de URI del contenedor**, en el panel **Reglas de mapeo**, puede definir las reglas de mapeo de URI para su flujo de trabajo.
En **Fuente del archivo de mapeo**, selecciona una de las siguientes opciones:
+ **Ninguna**: no se requieren reglas de mapeo.
+ **Seleccione el archivo JSON de S3**: especifique la ubicación en S3 para el archivo de mapeo.
+ **Seleccione el archivo JSON de una fuente local**: especifique la ubicación del archivo de mapeo en su dispositivo local.
+ **Introduzca los mapeos manualmente****: introduzca los mapeos de registro y los mapeos de imágenes en el panel de mapeos.**
1. La consola **muestra** el panel de mapeos. Si elige un archivo fuente de mapeo, la consola muestra los valores del archivo.
1. En **las asignaciones del registro**, puede editar las asignaciones o añadir asignaciones (máximo 20 asignaciones del registro).
Cada mapeo de registro contiene los siguientes campos:
+ **URL del registro ascendente**: el URI del registro ascendente.
+ **Prefijo del repositorio ECR: el prefijo** del repositorio que se utilizará en el repositorio privado de Amazon ECR.
+ (Opcional) Prefijo del **repositorio ascendente: el prefijo** del repositorio en el registro ascendente.
+ (Opcional) ID de **cuenta ECR: ID** de cuenta de la cuenta propietaria de la imagen del contenedor ascendente.
1. En los **mapeos de imágenes**, puede editar los mapeos de imágenes o añadir mapeos (máximo 100 mapeos de imágenes).
Cada mapeo de imágenes contiene los siguientes campos:
+ **Imagen de origen**: especifica el URI de la imagen de origen en el registro original.
+ **Imagen de destino**: especifica el URI de la imagen correspondiente en el registro privado de Amazon ECR.
1. Elija **Siguiente**.
1. Revise la configuración del flujo de trabajo y, a continuación, seleccione **Crear flujo de trabajo**.
## Creación de un flujo de trabajo mediante la CLI
Si los archivos de flujo de trabajo y el archivo de plantilla de parámetros están en su máquina local, puede crear un flujo de trabajo mediante el siguiente comando CLI.
```
aws omics create-workflow \
--name "my_workflow" \
--definition-zip fileb://my-definition.zip \
--parameter-template file://my-parameter-template.json
```
La `create-workflow` operación devuelve la siguiente respuesta:
```
{
"arn": "arn:aws:omics:us-west-2:....",
"id": "1234567",
"status": "CREATING",
"tags": {
"resourceArn": "arn:aws:omics:us-west-2:...."
},
"uuid": "64c9a39e-8302-cc45-0262-2ea7116d854f"
}
```
### Parámetros opcionales que se deben usar al crear un flujo de trabajo
Puede especificar cualquiera de los parámetros opcionales al crear un flujo de trabajo. Para obtener información sobre la sintaxis, consulte [CreateWorkflow](https://docs.aws.amazon.com/omics/latest/api/API_CreateWorkflow.html)la referencia de la HealthOmics API de AWS.
**Topics**
+ [Especifique la ubicación de Amazon S3 de la definición del flujo de trabajo](#create-defn-uri-parameter)
+ [Usa la definición de flujo de trabajo de un repositorio basado en Git](#create-defn-uri-git)
+ [Especifique un archivo readme](#specify-readme-file)
+ [**main**Especifique el archivo de definición](#create-main-parameter)
+ [Especifique el tipo de almacenamiento de ejecución](#create-run-storage-parameter)
+ [Especifique la configuración de la GPU](#create-accelerator-parameter)
+ [Configure los parámetros de mapeo de la memoria caché extraíble](#create-prefix-mapping-parameters)
#### Especifique la ubicación de Amazon S3 de la definición del flujo de trabajo
Si el archivo de definición de flujo de trabajo se encuentra en una carpeta de Amazon S3, especifique la ubicación mediante el `definition-uri` parámetro, como se muestra en el siguiente ejemplo. Si su cuenta no es propietaria del bucket de Amazon S3, proporcione el Cuenta de AWS ID del propietario.
```
aws omics create-workflow \
--name Test \
--definition-uri s3://omics-bucket/workflow-definition/ \
--owner-id 123456789012
...
```
#### Usa la definición de flujo de trabajo de un repositorio basado en Git
Para usar la definición de flujo de trabajo de un repositorio compatible basado en Git, usa el `definition-repository` parámetro en tu solicitud. No proporciones ningún otro `definition` parámetro, ya que una solicitud falla si incluye más de una fuente de entrada.
El `definition-respository` parámetro contiene los siguientes campos:
+ **connectionArn**— ARN de la conexión de código que conecta los recursos de AWS al repositorio externo.
+ **fullRepositoryId**— Introduzca el ID del repositorio como`owner-name/repo-name`. Compruebe que tiene acceso a los archivos de este repositorio.
+ **sourceReference**(Opcional): introduzca un tipo de referencia de repositorio (BRANCH, TAG o COMMIT) y un valor.
HealthOmics usa la última confirmación de la rama predeterminada si no especificas una referencia de origen.
+ **excludeFilePatterns**(Opcional): introduce los patrones de los archivos para excluir carpetas, archivos o extensiones específicos. Esto ayuda a administrar el tamaño de los datos al importar archivos del repositorio. Proporcione un máximo de 50 patrones. Los patrones deben seguir la sintaxis del patrón [global.](https://fossil-scm.org/home/doc/tip/www/globs.md) Por ejemplo:
+ `tests/`
+ `*.jpeg`
+ `large_data.zip`
Al especificar la definición del flujo de trabajo desde un repositorio basado en Git, utilícela `parameter-template-path` para especificar el archivo de plantilla de parámetros. Si no proporciona este parámetro, HealthOmics crea el flujo de trabajo sin una plantilla de parámetros.
El siguiente ejemplo muestra los parámetros relacionados con el contenido de un repositorio privado basado en Git:
```
aws omics create-workflow \
--name custom-variant \
--description "Custom variant calling pipeline" \
--engine "WDL" \
--definition-repository '{
"connectionArn": "arn:aws:codeconnections:us-east-1:123456789012:connection/abcd1234-5678-90ab-cdef-1234567890ab",
"fullRepositoryId": "myorg/my-genomics-workflows",
"sourceReference": {
"type": "BRANCH",
"value": "main"
},
"excludeFilePatterns": ["tests/**", "*.log"]
}' \
--main "workflows/variant-calling/main.wdl" \
--parameter-template-path "parameters/variant-calling-params.json" \
--readme-path "docs/variant-calling-README.md" \
--storage-type "DYNAMIC" \
```
Para ver más ejemplos, consulte la entrada del blog [Cómo crear HealthOmics flujos de trabajo de AWS a partir del contenido de Git](https://repost.aws/articles/ARCEN7AjhaRSmteczRoc_QsA/how-to-create-an-aws-healthomics-workflows-from-content-in-git).
#### Especifique un archivo readme
Puede especificar la ubicación del archivo README mediante uno de los siguientes parámetros:
+ **readme-markdown**— Entrada de cadena o un archivo en su máquina local.
+ **readme-uri**— El URI de un archivo almacenado en S3.
+ **readme-path **— La ruta al archivo README del repositorio.
**Utilice readme-path solo junto con definition-respository.** Si no especificas ningún parámetro README, HealthOmics importa el archivo README.md de nivel raíz en el repositorio (si existe).
Los siguientes ejemplos muestran cómo especificar la ubicación del archivo README mediante readme-path y readme-uri.
```
# Using README from repository
aws omics create-workflow \
--name "documented-workflow" \
--definition-repository '...' \
--readme-path "docs/workflow-guide.md"
# Using README from S3
aws omics create-workflow \
--name "s3-readme-workflow" \
--definition-repository '...' \
--readme-uri "s3://my-bucket/workflow-docs/readme.md"
```
Para obtener más información, consulte [HealthOmics Archivos README de flujo de trabajo](workflows-readme.md).
#### **main**Especifique el archivo de definición
Si incluye varios archivos de definición del flujo de trabajo, utilice el `main` parámetro para especificar el archivo de definición principal del flujo de trabajo.
```
aws omics create-workflow \
--name Test \
--main multi_workflow/workflow2.wdl \
...
```
#### Especifique el tipo de almacenamiento de ejecución
Puede especificar el tipo de almacenamiento de ejecución predeterminado (DINÁMICO o ESTÁTICO) y la capacidad de almacenamiento de ejecución (necesaria para el almacenamiento estático). Para obtener más información sobre los tipos de almacenamiento de ejecución, consulte[Ejecute tipos de almacenamiento en HealthOmics flujos de trabajo](workflows-run-types.md).
```
aws omics create-workflow \
--name my_workflow \
--definition-zip fileb://my-definition.zip \
--parameter-template file://my-parameter-template.json \
--storage-type 'STATIC' \
--storage-capacity 1200 \
```
#### Especifique la configuración de la GPU
Usa el parámetro accelerators para crear un flujo de trabajo que se ejecute en una instancia de procesamiento acelerado. En el siguiente ejemplo, se muestra cómo utilizar el parámetro. `accelerators` La configuración de la GPU se especifica en la definición del flujo de trabajo. Consulte [Instancias de computación acelerada](memory-and-compute-tasks.md#workflow-task-accelerated-computing-instances).
```
aws omics create-workflow --name workflow name \
--definition-uri s3://amzn-s3-demo-bucket1/GPUWorkflow.zip \
--accelerators GPU
```
#### Configure los parámetros de mapeo de la memoria caché extraíble
Si utiliza la función de mapeo de caché extraíble de Amazon ECR, puede anular los mapeos predeterminados. Para obtener más información sobre los parámetros de configuración del contenedor, consulte. [Imágenes de contenedores para flujos de trabajo privados](workflows-ecr.md)
En el siguiente ejemplo, el archivo `mappings.json` contiene este contenido:
```
{
"registryMappings": [
{
"upstreamRegistryUrl": "registry-1.docker.io",
"ecrRepositoryPrefix": "docker-hub"
},
{
"upstreamRegistryUrl": "quay.io",
"ecrRepositoryPrefix": "quay",
"accountId": "123412341234"
},
{
"upstreamRegistryUrl": "public.ecr.aws",
"ecrRepositoryPrefix": "ecr-public"
}
],
"imageMappings": [{
"sourceImage": "docker.io/library/ubuntu:latest",
"destinationImage": "healthomics-docker-2/custom/ubuntu:latest",
"accountId": "123412341234"
},
{
"sourceImage": "nvcr.io/nvidia/k8s/dcgm-exporter",
"destinationImage": "healthomics-nvidia/k8s/dcgm-exporter"
}
]
}
```
Especifique los parámetros de mapeo en el comando create-workflow:
```
aws omics create-workflow \
...
--container-registry-map-file file://mappings.json
...
```
También puede especificar la ubicación en S3 del archivo de parámetros de mapeo:
```
aws omics create-workflow \
...
--container-registry-map-uri s3://amzn-s3-demo-bucket1/test.zip
...
```
## Crear un flujo de trabajo mediante un SDK
Puede crear un flujo de trabajo mediante uno de los SDKs. El siguiente ejemplo muestra cómo crear un flujo de trabajo mediante el SDK de Python.
```
import boto3
omics = boto3.client('omics')
with open('definition.zip', 'rb') as f:
definition = f.read()
response = omics.create_workflow(
name='my_workflow',
definitionZip=definition,
parameterTemplate={ ... }
)
```
# Actualizar un flujo de trabajo privado
Puede actualizar un flujo de trabajo mediante la HealthOmics consola, los comandos AWS CLI o uno de los AWS SDKs.
**nota**
No incluya ninguna información de identificación personal (PII) en los nombres de los flujos de trabajo. Estos nombres están visibles en CloudWatch los registros.
**Topics**
+ [Actualización de un flujo de trabajo mediante la consola](#console-update-workflows)
+ [Actualización de un flujo de trabajo mediante la CLI](#api-update-workflows)
+ [Actualizar un flujo de trabajo mediante un SDK](#sdk-update-workflows)
## Actualización de un flujo de trabajo mediante la consola
**Pasos para actualizar un flujo de trabajo**
1. Abra la [consola de HealthOmics ](https://console.aws.amazon.com/omics/).
1. Si es necesario, abra el panel de navegación izquierdo (≡). Elija **Flujos de trabajo privados**.
1. En la página **Flujos de trabajo privados**, elija el flujo de trabajo que desee actualizar.
1. En la página **de flujo de trabajo**:
+ Si el flujo de trabajo tiene versiones, asegúrese de seleccionar la **versión predeterminada**.
+ Elija **Editar seleccionado** en la lista de **acciones**.
1. En la página **Editar flujo** de trabajo, puede cambiar cualquiera de los siguientes valores:
+ **Nombre del flujo de trabajo**.
+ **Descripción del flujo** de trabajo.
+ El **tipo de almacenamiento de ejecución** predeterminado para el flujo de trabajo.
+ La **capacidad de almacenamiento de ejecución** predeterminada (si el tipo de almacenamiento de ejecución es almacenamiento estático). Para obtener más información sobre la configuración de almacenamiento de ejecución predeterminada, consulte[Crear un flujo de trabajo mediante la consola](create-private-workflow.md#console-create-workflows).
1. Seleccione **Guardar cambios** para aplicar los cambios.
## Actualización de un flujo de trabajo mediante la CLI
Como se muestra en el siguiente ejemplo, puede actualizar el nombre y la descripción del flujo de trabajo. También puede cambiar el tipo de almacenamiento de ejecución predeterminado (ESTÁTICO o DINÁMICO) y la capacidad de almacenamiento de ejecución (para el tipo de almacenamiento estático). Para obtener más información sobre los tipos de almacenamiento de ejecución, consulte[Ejecute tipos de almacenamiento en HealthOmics flujos de trabajo](workflows-run-types.md).
```
aws omics update-workflow \
--id 1234567 \
--name my_workflow \
--description "updated workflow" \
--storage-type 'STATIC' \
--storage-capacity 1200
```
No recibes una respuesta a la `update-workflow` solicitud.
## Actualizar un flujo de trabajo mediante un SDK
Puede actualizar un flujo de trabajo mediante uno de los SDKs.
El siguiente ejemplo muestra cómo actualizar un flujo de trabajo mediante el SDK de Python.
```
import boto3
omics = boto3.client('omics')
response = omics.update_workflow(
name='my_workflow',
description='updated workflow'
)
```
# Eliminar un flujo de trabajo privado
Cuando ya no necesite un flujo de trabajo, puede eliminarlo mediante la HealthOmics consola, los comandos AWS CLI o uno de los AWS SDKs. Puede eliminar un flujo de trabajo que cumpla los siguientes criterios:
+ Su estado es ACTIVO o FALLIDO.
+ No tiene acciones activas.
+ Has eliminado todas las versiones del flujo de trabajo.
La eliminación de un flujo de trabajo no afecta a las ejecuciones en curso que estén utilizando el flujo de trabajo.
**Topics**
+ [Eliminar un flujo de trabajo mediante la consola](#console-delete-workflows)
+ [Eliminar un flujo de trabajo mediante la CLI](#api-delete-workflows)
+ [Eliminar un flujo de trabajo mediante un SDK](#sdk-delete-workflows)
## Eliminar un flujo de trabajo mediante la consola
**Para eliminar un flujo de trabajo**
1. Abra la [consola de HealthOmics ](https://console.aws.amazon.com/omics/).
1. Si es necesario, abra el panel de navegación izquierdo (≡). Elija **Flujos de trabajo privados**.
1. En la página **Flujos de trabajo privados**, elija el flujo de trabajo que desee eliminar.
1. En la página **de flujo** de trabajo, elija **Eliminar lo seleccionado** en la lista de **acciones**.
1. En el modal **Eliminar flujo** de trabajo, introduce «confirmar» para confirmar la eliminación.
1. Elija **Eliminar**.
## Eliminar un flujo de trabajo mediante la CLI
El siguiente ejemplo muestra cómo se puede utilizar el AWS CLI comando para eliminar un flujo de trabajo. Para ejecutar el ejemplo, sustituya el `workflow id` identificador por el ID del flujo de trabajo que desee eliminar.
```
aws omics delete-workflow
--id workflow id
```
HealthOmics no envía una respuesta a la `delete-workflow` solicitud.
## Eliminar un flujo de trabajo mediante un SDK
Puede eliminar un flujo de trabajo mediante uno de los SDKs.
El siguiente ejemplo muestra cómo eliminar un flujo de trabajo mediante el SDK de Python.
```
import boto3
omics = boto3.client('omics')
response = omics.delete_workflow(
id='1234567'
)
```
# Compruebe el estado del flujo de trabajo
Tras crear el flujo de trabajo, puede verificar el estado y ver otros detalles del flujo de trabajo mediante **get-workflow**, como se muestra.
```
aws omics get-workflow --id 1234567
```
La respuesta incluye los detalles del flujo de trabajo, incluido el estado, como se muestra.
```
{
"arn": "arn:aws:omics:us-west-2:....",
"creationTime": "2022-07-06T00:27:05.542459"
"id": "1234567",
"engine": "WDL",
"status": "ACTIVE",
"type": "PRIVATE",
"main": "workflow-crambam.wdl",
"name": "workflow_name",
"storageType": "STATIC",
"storageCapacity": "1200",
"uuid": "64c9a39e-8302-cc45-0262-2ea7116d854f"
}
```
Puede iniciar una ejecución con este flujo de trabajo una vez que el estado pase a`ACTIVE`.
# Hacer referencia a los archivos del genoma a partir de una definición de flujo de trabajo
Se puede hacer HealthOmics referencia a un objeto de almacén de referencia con un URI como el siguiente. Usa el tuyo propio `account ID` `reference store ID` y `reference ID` donde se indique.
```
omics://account ID.storage.us-west-2.amazonaws.com/reference store id/reference/id
```
Algunos flujos de trabajo requerirán tanto `SOURCE` los `INDEX` archivos como los del genoma de referencia. El URI anterior es la forma abreviada predeterminada y, de forma predeterminada, será el archivo FUENTE. Para especificar cualquiera de los archivos, puede utilizar el formulario URI largo, de la siguiente manera.
```
omics://account ID.storage.us-west-2.amazonaws.com/reference store id/reference/id/source
omics://account ID.storage.us-west-2.amazonaws.com/reference store id/reference/id/index
```
El uso de un conjunto de lecturas secuenciales tendría un patrón similar, como se muestra.
```
aws omics create-workflow \
--name workflow name \
--main sample workflow.wdl \
--definition-uri omics://account ID.storage.us-west-2.amazonaws.com/sequence_store_id/readSet/id \
--parameter-template file://parameters_sample_description.json
```
Algunos conjuntos de lecturas, como los basados en FASTQ, pueden contener lecturas emparejadas. En los siguientes ejemplos, se denominan SOURCE1 y SOURCE2. Los formatos como BAM y CRAM solo tendrán un SOURCE1 archivo. Algunos conjuntos de lectura contendrán archivos de índice, como archivos `bai` o`crai`. El URI anterior es la forma abreviada predeterminada y se utilizará de forma predeterminada en el SOURCE1 archivo. Para especificar el archivo o índice exacto, puede utilizar el formulario URI largo, de la siguiente manera.
```
omics://123456789012.storage.us-west-2.amazonaws.com//readSet//source1
omics://123456789012.storage.us-west-2.amazonaws.com//readSet//source2
omics://123456789012.storage.us-west-2.amazonaws.com//readSet//index
```
El siguiente es un ejemplo de un archivo JSON de entrada que usa dos Omics Storage URIs.
```
{
"input_fasta": "omics://123456789012.storage.us-west-2.amazonaws.com//reference/",
"input_cram": "omics://123456789012.storage.us-west-2.amazonaws.com//readSet/"
}
```
Haga referencia al archivo JSON de entrada en el AWS CLI agregándolo `--inputs file://` a su solicitud de **inicio y ejecución**.