Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Caractéristiques de la définition du flux de travail Nextflow
HealthOmics est compatible avec Nextflow DSL1 et DSL2. Pour en savoir plus, consultez [Prise en charge de la version Nextflow](workflows-lang-versions.md#workflows-lang-versions-nextflow).
Nextflow DSL2 est basé sur le langage de programmation Groovy. Les paramètres sont donc dynamiques et la coercition de type est possible en utilisant les mêmes règles que Groovy. Les paramètres et valeurs fournis par le JSON d'entrée sont disponibles dans la carte parameters (`params`) du flux de travail.
**Topics**
+ [Utiliser les plugins nf-schema et nf-validation](#schema-and-validation-plugins-nextflow)
+ [Spécifier les URI de stockage](#storage-uris-nextflow)
+ [Directives Nextflow](#workflow-nexflow-directives)
+ [Utiliser les profils Nextflow](#nextflow-profiles)
+ [Exporter le contenu au niveau du flux de travail](#exporting-workflow-content-nextflow)
+ [Exporter le contenu de la tâche](#exporting-task-content-nextflow)
+ [Spécifiez la version de syntaxe Nextflow](#nextflow-syntax-version)
+ [Notes de mise à jour de Nextflow v26.04](#nextflow-v26-release-notes)
## Utiliser les plugins nf-schema et nf-validation
**Note**
Résumé de la HealthOmics prise en charge des plugins :
v22.04 — aucun support pour les plugins
v23.10 — prend en charge et `nf-schema` `nf-validation`
v24.10 — prend en charge `nf-schema`
v25.10, v26.04 — prend en charge`nf-schema`,, et `nf-core-utils` `nf-fgbio` `nf-prov`
HealthOmics fournit le support suivant pour les plugins Nextflow :
+ Pour Nextflow v23.10, HealthOmics préinstalle le plugin nf-validation @1 .1.1.
+ Pour Nextflow v23.10 et v24.10, HealthOmics préinstalle le plugin nf-schema @2 .3.0.
+ Pour Nextflow v25.10, HealthOmics préinstalle les plugins nf-schema @2 .6.1, nf-core-utils @0 .4.0, nf-prov @1 .7.0 et nf-fgbio @1 .0.1.
+ Pour Nextflow v26.04, HealthOmics préinstalle les plugins nf-schema @2 .7.2, nf-core-utils @0 .4.0, nf-prov @1 .7.0 et nf-fgbio @1 .0.1.
+ Vous ne pouvez pas récupérer de plug-ins supplémentaires lors de l'exécution d'un flux de travail. HealthOmics ignore toutes les autres versions du plugin que vous spécifiez dans le `nextflow.config` fichier.
+ Pour Nextflow v24 et versions supérieures, `nf-schema` il s'agit de la nouvelle version du plugin obsolète`nf-validation`. Pour plus d'informations, consultez [nf-schema](https://github.com/nextflow-io/nf-schema) dans le référentiel GitHub Nextflow.
## Spécifier les URI de stockage
Lorsqu'un Amazon S3 ou un HealthOmics URI est utilisé pour créer un fichier ou un objet de chemin Nextflow, l'objet correspondant est mis à la disposition du flux de travail, à condition que l'accès en lecture soit accordé. L'utilisation de préfixes ou de répertoires est autorisée pour les URI Amazon S3. Pour obtenir des exemples, consultez [Formats de paramètres d'entrée Amazon S3](workflows-run-inputs.md#s3-run-input-formats).
HealthOmics prend partiellement en charge l'utilisation de modèles globaux dans les URI Amazon S3 ou les URI HealthOmics de stockage. Utilisez des modèles Glob dans la définition du flux de travail pour la création de `path` `file` canaux. Pour le comportement attendu et les cas exacts, voir[Nextflow Gestion du modèle Glob dans les entrées Amazon S3](workflows-run-inputs.md#wd-nextflow-s3-formats).
## Directives Nextflow
Vous configurez les directives Nextflow dans le fichier de configuration ou la définition du flux de travail Nextflow. La liste suivante indique l'ordre de priorité HealthOmics utilisé pour appliquer les paramètres de configuration, de la priorité la plus faible à la plus élevée :
1. Configuration globale dans le fichier de configuration.
1. Section des tâches de la définition du flux de travail.
1. Task-specific sélecteurs dans le fichier de configuration.
**Topics**
+ [`Stratégie de nouvelle tentative de tâche à l'aide d'ErrorStrategy`](#workflow-nextflow-errorStrategy)
+ [`Tentatives de nouvelle tentative de tâche à l'aide de MaxRetries`](#workflow-nexflow-task-retry)
+ [Désactiver la nouvelle tentative de tâche à l'aide d'`omics 5xx RetryOn`](#workflow-nextflow-retry-5xx)
+ [Durée de la tâche selon la directive `time`](#time-directive-nextflow)
### `Stratégie de nouvelle tentative de tâche à l'aide d'ErrorStrategy`
Utilisez la `errorStrategy` directive pour définir la stratégie à adopter en cas d'erreur dans les tâches. Par défaut, lorsqu'une tâche revient avec une indication d'erreur (un statut de sortie différent de zéro), la tâche s'arrête et HealthOmics met fin à l'exécution complète. Si vous définissez cette `errorStrategy` option`retry`, HealthOmics tente une nouvelle tentative de la tâche qui a échoué. Pour augmenter le nombre de tentatives, voir[`Tentatives de nouvelle tentative de tâche à l'aide de MaxRetries`](#workflow-nexflow-task-retry).
```
process {
label 'my_label'
errorStrategy 'retry'
script:
"""
your-command-here
"""
}
```
Pour plus d'informations sur le mode HealthOmics de gestion des nouvelles tentatives de tâches lors d'une exécution, consultez[Nouvelles tentatives de tâches](monitoring-runs.md#run-status-task-retries).
### `Tentatives de nouvelle tentative de tâche à l'aide de MaxRetries`
Par défaut, HealthOmics ne tente aucune nouvelle tentative d'une tâche qui a échoué, ou tente une nouvelle tentative si vous configurez. `errorStrategy` Pour augmenter le nombre maximum de tentatives, définissez `retry` et configurez le nombre maximum de tentatives `errorStrategy` à l'aide de la `maxRetries` directive.
L'exemple suivant définit le nombre maximum de tentatives à 3 dans la configuration globale.
```
process {
errorStrategy = 'retry'
maxRetries = 3
}
```
L'exemple suivant montre comment définir `maxRetries` dans la section des tâches de la définition du flux de travail.
```
process myTask {
label 'my_label'
errorStrategy 'retry'
maxRetries 3
script:
"""
your-command-here
"""
}
```
L'exemple suivant montre comment spécifier une configuration spécifique à une tâche dans le fichier de configuration Nextflow, en fonction du nom ou des sélecteurs d'étiquette.
```
process {
withLabel: 'my_label' {
errorStrategy = 'retry'
maxRetries = 3
}
withName: 'myTask' {
errorStrategy = 'retry'
maxRetries = 3
}
}
```
### Désactiver la nouvelle tentative de tâche à l'aide d'`omics 5xx RetryOn`
Pour Nextflow v23 et versions ultérieures, HealthOmics prend en charge les nouvelles tentatives de tâche si la tâche a échoué en raison d'erreurs de service (codes d'état HTTP 5XX). Par défaut, HealthOmics tente jusqu'à deux tentatives d'une tâche qui a échoué.
Vous pouvez configurer `omicsRetryOn5xx` pour désactiver la rétentative de tâche en cas d'erreur de service. Pour plus d'informations sur la nouvelle tentative d'une tâche HealthOmics, consultez[Nouvelles tentatives de tâches](monitoring-runs.md#run-status-task-retries).
L'exemple suivant permet de configurer `omicsRetryOn5xx` la configuration globale pour désactiver la nouvelle tentative de tâche.
```
process {
omicsRetryOn5xx = false
}
```
L'exemple suivant montre comment procéder à la configuration `omicsRetryOn5xx` dans la section des tâches de la définition du flux de travail.
```
process myTask {
label 'my_label'
omicsRetryOn5xx = false
script:
"""
your-command-here
"""
}
```
L'exemple suivant montre comment définir `omicsRetryOn5xx` une configuration spécifique à une tâche dans le fichier de configuration Nextflow, en fonction du nom ou des sélecteurs d'étiquette.
```
process {
withLabel: 'my_label' {
omicsRetryOn5xx = false
}
withName: 'myTask' {
omicsRetryOn5xx = false
}
}
```
### Durée de la tâche selon la directive `time`
HealthOmics fournit un quota ajustable (voir[HealthOmics quotas de service](service-quotas.md)) pour spécifier la durée maximale d'une course. Pour les flux de travail Nextflow v23 et versions ultérieures, vous pouvez également spécifier la durée maximale des tâches à l'aide de la directive Nextflow. `time`
Lors du développement d'un nouveau flux de travail, la définition de la durée maximale des tâches vous permet de détecter les tâches intempestives et les tâches de longue durée.
Pour plus d'informations sur la directive temporelle Nextflow, voir [directive time dans la](https://www.nextflow.io/docs/latest/reference/process.html#process-time) référence Nextflow.
HealthOmics fournit le support suivant pour la directive temporelle Nextflow :
1. HealthOmics prend en charge une granularité d'une minute pour la directive horaire. Vous pouvez spécifier une valeur comprise entre 60 secondes et la durée maximale d'exécution.
1. Si vous entrez une valeur inférieure à 60, HealthOmics arrondissez-la à 60 secondes. Pour les valeurs supérieures à 60, HealthOmics arrondissez à la minute inférieure la plus proche.
1. Si le flux de travail prend en charge les nouvelles tentatives pour une tâche, HealthOmics réessayez la tâche si le délai imparti est expiré.
1. Si le délai d'expiration d'une tâche (ou si la dernière tentative expire), elle est HealthOmics annulée. Cette opération peut avoir une durée d'une à deux minutes.
1. En cas d'expiration de la tâche, HealthOmics définit l'exécution et le statut de la tâche sur Échec, et annule les autres tâches en cours d'exécution (pour les tâches en cours d'exécution, en attente ou en cours d'exécution). HealthOmics exporte les sorties des tâches qu'il a terminées avant le délai d'expiration vers l'emplacement de sortie S3 que vous avez désigné.
1. Le temps passé par une tâche en attente n'est pas pris en compte dans la durée de la tâche.
1. Si l'exécution fait partie d'un groupe d'exécution et que le groupe d'exécution expire avant le délai imparti, l'exécution et la tâche passent au statut d'échec.
Spécifiez la durée du délai d'expiration en utilisant une ou plusieurs des unités suivantes :`ms`,`s`, `m``h`, ou`d`.
L'exemple suivant montre comment spécifier une configuration globale dans le fichier de configuration Nextflow. Il définit un délai d'expiration global de 1 heure et 30 minutes.
```
process {
time = '1h30m'
}
```
L'exemple suivant montre comment spécifier une directive temporelle dans la section des tâches de la définition du flux de travail. Cet exemple définit un délai d'expiration de 3 jours, 5 heures et 4 minutes. Cette valeur a priorité sur la valeur globale du fichier de configuration, mais pas sur une directive temporelle spécifique à une tâche `my_label` dans le fichier de configuration.
```
process myTask {
label 'my_label'
time '3d5h4m'
script:
"""
your-command-here
"""
}
```
L'exemple suivant montre comment spécifier des directives temporelles spécifiques à une tâche dans le fichier de configuration Nextflow, en fonction du nom ou des sélecteurs d'étiquette. Cet exemple définit un délai d'expiration global de la tâche de 30 minutes. Il définit une valeur de 2 heures pour la tâche `myTask` et une valeur de 3 heures pour les tâches avec étiquette`my_label`. Pour les tâches correspondant au sélecteur, ces valeurs ont priorité sur la valeur globale et sur la valeur de la définition du flux de travail.
```
process {
time = '30m'
withLabel: 'my_label' {
time = '3h'
}
withName: 'myTask' {
time = '2h'
}
}
```
## Utiliser les profils Nextflow
Les profils Nextflow sont des ensembles nommés de paramètres de configuration que vous pouvez sélectionner lors de l'exécution. Définissez les profils dans le `profiles` bloc de votre `nextflow.config` fichier :
```
profiles {
standard {
process.cpus = 2
process.memory = '4 GB'
}
production {
process.cpus = 16
process.memory = '64 GB'
params.input = 's3://bucket/production-data.bam'
}
}
```
Lorsque vous lancez une exécution, spécifiez un ou plusieurs profils à l'aide du `engineSettings` paramètre. HealthOmics passe le `-profile` drapeau au moteur Nextflow. Pour de plus amples informations, veuillez consulter [Spécifier les paramètres du moteur](starting-a-run.md#start-run-api-engine-settings).
```
aws omics start-run \
--workflow-id {{workflow-id}} \
--role-arn {{role-arn}} \
--output-uri s3://{{bucket}}/{{prefix}}/ \
--engine-settings '{"profile": "production"}'
```
Lorsque plusieurs profils sont spécifiés (par exemple,`"test,docker"`), Nextflow les applique dans l'ordre dans lequel ils sont spécifiés dans la ligne de commande. Les profils ultérieurs remplacent les précédents en cas de conflit de paramètres. Pour les versions de Nextflow inférieures à 26, les profils sont appliqués dans l'ordre dans lequel ils sont définis dans le fichier de configuration plutôt que dans l'ordre de la ligne de commande.
Notez ce qui suit :
+ La prise en charge des profils est disponible pour toutes les versions de Nextflow HealthOmics prises en charge.
+ Les profils peuvent contenir des paramètres, des directives de processus, `includeConfig` des instructions et des remplacements de manifestes (y compris`manifest.nextflowVersion`).
+ Les paramètres d'exécution explicites ont priorité sur les valeurs de paramètres définies par le profil.
+ Si vous spécifiez un profil inexistant, HealthOmics renvoie une erreur de validation.
+ Les profils doivent être définis dans le fichier zip de définition du flux de travail. HealthOmics ne permet pas de récupérer les définitions de profil à partir de sources externes.
+ Si vous ne spécifiez pas de profil, l'exécution utilise le `standard` profil s'il est défini sous profils dans la définition du flux de travail. Dans le cas contraire, l'exécution utilise la configuration par défaut (niveau supérieur).
+ Lorsque vous utilisez des profils, nous vous recommandons d'épingler la version Nextflow dans la définition de votre flux de travail afin de garantir un comportement cohérent `manifest.nextflowVersion` de l'application de profil d'une exécution à l'autre.
## Exporter le contenu au niveau du flux de travail
Pour Nextflow v25.10 et versions ultérieures, vous pouvez exporter des fichiers produits en dehors de tâches individuelles, tels que des rapports de provenance ou des DAG de pipeline. Pour exporter ces fichiers, écrivez-les dans`/mnt/workflow/output/`. HealthOmics exporte les fichiers placés dans ce répertoire vers le `output/` préfixe de l'emplacement de sortie Amazon S3 de votre exécution.
L'exemple suivant montre comment configurer le `nf-prov` plugin pour y écrire un rapport de provenance`/mnt/workflow/output/`.
```
prov {
formats {
bco {
file = "/mnt/workflow/output/pipeline_info/manifest.bco.json"
}
}
}
```
Vous pouvez également transmettre ce chemin en tant que paramètre dans le JSON d'entrée de votre exécution. Cette approche est courante avec les flux de travail nf-core qui utilisent. `params.outdir`
```
{
"outdir": "/mnt/workflow/output/"
}
```
## Exporter le contenu de la tâche
Pour les flux de travail écrits dans Nextflow, définissez une directive **PublishDir** pour exporter le contenu des tâches vers votre compartiment Amazon S3 de sortie. Comme indiqué dans l'exemple suivant, définissez la valeur **PublishDir sur**. `/mnt/workflow/pubdir` Pour exporter des fichiers vers Amazon S3, les fichiers doivent se trouver dans ce répertoire.
```
nextflow.enable.dsl=2
workflow {
CramToBamTask(params.ref_fasta, params.ref_fasta_index, params.ref_dict, params.input_cram, params.sample_name)
ValidateSamFile(CramToBamTask.out.outputBam)
}
process CramToBamTask {
container ".dkr.ecr.us-west-2.amazonaws.com/genomes-in-the-cloud"
publishDir "/mnt/workflow/pubdir"
input:
path ref_fasta
path ref_fasta_index
path ref_dict
path input_cram
val sample_name
output:
path "${sample_name}.bam", emit: outputBam
path "${sample_name}.bai", emit: outputBai
script:
"""
set -eo pipefail
samtools view -h -T $ref_fasta $input_cram |
samtools view -b -o ${sample_name}.bam -
samtools index -b ${sample_name}.bam
mv ${sample_name}.bam.bai ${sample_name}.bai
"""
}
process ValidateSamFile {
container ".dkr.ecr.us-west-2.amazonaws.com/genomes-in-the-cloud"
publishDir "/mnt/workflow/pubdir"
input:
file input_bam
output:
path "validation_report"
script:
"""
java -Xmx3G -jar /usr/gitc/picard.jar \
ValidateSamFile \
INPUT=${input_bam} \
OUTPUT=validation_report \
MODE=SUMMARY \
IS_BISULFITE_SEQUENCED=false
"""
}
```
Pour Nextflow v25.10 et versions ultérieures, comme alternative à`publishDir`, vous pouvez utiliser les sorties du flux de travail pour exporter le contenu des tâches. L'exemple suivant montre comment définir un `output` bloc de flux de travail qui exporte les résultats des tâches vers Amazon S3.
```
process myTask {
input:
val data
output:
path 'result.txt'
script:
"""
echo ${data} > result.txt
"""
}
workflow {
main:
output_file = myTask('hello')
publish:
results = output_file
}
output {
results {
path '.'
}
}
```
Pour plus d'informations sur les sorties de flux de travail, consultez la section [Sorties de flux](https://www.nextflow.io/docs/latest/workflow.html#workflow-output-def) de travail dans la documentation de Nextflow.
## Spécifiez la version de syntaxe Nextflow
Nextflow v26.04.0 utilise l'analyseur syntaxique strict (v2) par défaut. Il s'agit d'un changement radical pour les flux de travail écrits à l'aide de l'ancienne syntaxe (v1), qui est la syntaxe par défaut dans Nextflow v25.10.0 et versions antérieures. Pour plus d'informations sur la syntaxe v2, consultez la section [Syntaxe stricte](https://docs.seqera.io/nextflow/strict-syntax) dans la documentation de Seqera Nextflow.
Pour exécuter un flux de travail créé par rapport à l'ancien analyseur (v1), définissez ce `engineSettings.syntaxVersion` qui suit `v1` dans la **StartRun** demande :
```
{
"engineSettings": {
"syntaxVersion": "v1"
}
}
```
Pour Nextflow v25.10.0 et versions antérieures, l'analyseur v2 n'est HealthOmics pas pris en charge.
## Notes de mise à jour de Nextflow v26.04
Les tableaux suivants résument la HealthOmics prise en charge des nouvelles fonctionnalités, améliorations et dépréciations publiées dans la version 26.04 de Nextflow.
### Nouvelles fonctionnalités et améliorations
| Fonctionnalité | De la version | HealthOmics soutien | Remarques |
| --- | --- | --- | --- |
| Analyseur syntaxique strict (par défaut) | 26,04 | Oui | Activé par défaut à partir de la version 26.04. L'ancien analyseur est disponible syntaxVersion: "v1" dans les paramètres du moteur. |
| Types d'enregistrement | 26,04 | Oui | Pour plus d'informations, consultez la section [Records](https://docs.seqera.io/nextflow/script#records) dans la documentation de Seqera Nextflow. |
| Résumés des résultats du flux de travail | 26,04 | Oui | Imprime un résumé des résultats du flux de travail à la fin de l'exécution. Format de sortie configurable via outputFormat les paramètres du moteur. Pour de plus amples informations, veuillez consulter [Spécifier les paramètres du moteur](starting-a-run.md#start-run-api-engine-settings). |
| Mode de journalisation de l'agent | 26,04 | Oui | Configurable via agentMode les paramètres du moteur. Pour de plus amples informations, veuillez consulter [Spécifier les paramètres du moteur](starting-a-run.md#start-run-api-engine-settings). |
| Système de modules (Nextflow Registry) | 26,04 | Non | HealthOmics les flux de travail s'exécutent dans un réseau isolé sans accès Internet sortant. Vous pouvez inclure des modules directement dans le zip de votre flux de travail. |
| Typage statique (aperçu) | 26,04 | Non | HealthOmics ne prend pas en charge les fonctionnalités de prévisualisation. |
| Auto-load paramètres de collection à partir de fichiers | 26,04 | Non | Nécessite une saisie statique (aperçu), qui n'est HealthOmics pas prise en charge. |
| Multi-revision vérification des pipelines | 26,04 | N/A | Non applicable HealthOmics n'utilise pas le Git-based pipeline checkout. |
### Obsolescence
| Article déconseillé | De la version | Impact | Action recommandée |
| --- | --- | --- | --- |
| Méthode listFiles() | 26,04 | Avertissement de dépréciation | Remplacez parlistDirectory(). |
| Indicateur nextflow.enable.strict | 26,04 | N'est plus nécessaire | Supprimer de la configuration. Le mode strict est désormais le mode par défaut. |
| manifest.defaultBranch | 26,04 | N'est plus nécessaire | Supprimer de la configuration. HealthOmics n'utilise pas le Git-based pipeline checkout et n'a jamais pris en charge cette option. |