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.

Spécificités de la définition du flux de travail Nextflow

HealthOmics prend en charge Nextflow DSL1 et DSL2. Pour en savoir plus, consultez Prise en charge de la version 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 les valeurs fournis par le JSON d'entrée sont disponibles dans la carte des paramètres (params) du flux de travail.

Utiliser les plugins nf-schema et nf-validation

HealthOmics fournit le support suivant pour les plugins Nextflow :

Spécifier les URI de stockage

Lorsqu'un Amazon S3 ou un HealthOmics URI est utilisé pour créer un fichier Nextflow ou un objet de chemin, il met l'objet correspondant à la disposition du flux de travail, tant que l'accès en lecture est 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.

HealthOmics prend partiellement en charge l'utilisation de modèles globulaires dans les URI Amazon S3 ou les URI HealthOmics de stockage. Utilisez les 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, voirNextflow Gestion du modèle Glob dans les entrées Amazon S3.

Directives Nextflow

Vous configurez les directives Nextflow dans le fichier de configuration Nextflow ou dans la définition du flux de travail. 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 :

Stratégie de nouvelle tentative de tâche utilisant ErrorStrategy

Utilisez la errorStrategy directive pour définir la stratégie à adopter en cas d'erreurs de tâches. Par défaut, lorsqu'une tâche revient avec une indication d'erreur (état de sortie différent de zéro), elle s'arrête et HealthOmics met fin à l'exécution complète. Si vous le définissez surretry, errorStrategy HealthOmics tente une nouvelle tentative pour exécuter la tâche qui a échoué. Pour augmenter le nombre de nouvelles tentatives, consultezTentatives de nouvelle tentative de tâche à l'aide de MaxRetries.

process {
    label 'my_label'
    errorStrategy 'retry'

    script:
    """
    your-command-here
    """
}   

Pour plus d'informations sur la façon dont HealthOmics les nouvelles tentatives de tâches sont gérées au cours d'une exécution, consultezNouvelles tentatives de tâches.

Tentatives de nouvelle tentative de tâche à l'aide de MaxRetries

Par défaut, HealthOmics ne tente aucune nouvelle tentative pour une tâche ayant é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 des sélecteurs de nom ou 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 5.xx 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 pour exécuter une tâche qui a échoué.

Vous pouvez configurer omicsRetryOn5xx pour désactiver la nouvelle tentative de tâche en cas d'erreur de service. Pour plus d'informations sur la nouvelle tentative de tâche HealthOmics, consultezNouvelles tentatives de tâches.

L'exemple suivant configure omicsRetryOn5xx la configuration globale pour désactiver la nouvelle tentative de tâche.

process {
    omicsRetryOn5xx = false
}     

L'exemple suivant montre comment configurer 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 des sélecteurs de nom ou d'étiquette.

process {
    withLabel: 'my_label' {
        omicsRetryOn5xx = false
    }

    withName: 'myTask' {
        omicsRetryOn5xx = false
    }
}   

Durée de la tâche à l'aide de la directive time

HealthOmics fournit un quota ajustable (voirHealthOmics quotas de service) 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 de nouveaux flux de travail, la définition de la durée maximale des tâches vous permet de détecter les tâches incontrôlables et les tâches de longue haleine.

Pour plus d'informations sur la directive temporelle Nextflow, consultez la directive temporelle dans la référence Nextflow.

HealthOmics fournit le support suivant pour la directive temporelle Nextflow :

Spécifiez la durée du délai d'expiration à l'aide d'une ou de plusieurs des unités suivantes : ms sm,h, oud.

L'exemple suivant montre comment spécifier la configuration globale dans le fichier de configuration Nextflow. Il définit un délai d'attente 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'attente 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 à la tâche pour my_label 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 des sélecteurs de nom ou d'étiquette. Cet exemple définit une valeur de délai d'expiration globale de 30 minutes pour les tâches. Il définit une valeur de 2 heures pour la tâche myTask et une valeur de 3 heures pour les tâches avec étiquettemy_label. Pour les tâches qui correspondent au sélecteur, ces valeurs ont priorité sur la valeur globale et 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 démarrez 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 Nextflow.

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 sur la ligne de commande. Les profils ultérieurs remplacent les profils 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 :

Exporter du 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 plug-in pour é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 des tâches

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 "<account>.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 "<account>.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érieurespublishDir, 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 de travail dans la documentation Nextflow.

Générez des rapports d'exécution de Nextflow

Nextflow peut produire quatre rapports intégrés pour chaque exécution : un rapport d'exécution (report), un calendrier (timeline), un fichier de trace (trace) et un diagramme de flux de travail (dag). HealthOmics Pour exporter ces fichiers vers l'emplacement de sortie Amazon S3 de votre exécution, configurez chacun d'eux pour écrire sa sortie /mnt/workflow/output/ dans votre nextflow.config fichier :

report {
    enabled = true
    file = '/mnt/workflow/output/report.html'
    overwrite = true
}

timeline {
    enabled = true
    file = '/mnt/workflow/output/timeline.html'
    overwrite = true
}

trace {
    enabled = true
    file = '/mnt/workflow/output/trace.txt'
    overwrite = true
}

dag {
    enabled = true
    file = '/mnt/workflow/output/dag.html'
    overwrite = true
}

HealthOmics exporte les fichiers écrits sous /mnt/workflow/output/ le output/ préfixe de l'emplacement de sortie Amazon S3 de votre exécution. Pour plus d'informations sur ce chemin d'exportation, consultezExporter du contenu au niveau du flux de travail. Les rapports écrits à l'extérieur ne /mnt/workflow/output/ sont pas exportés vers l'emplacement de sortie Amazon S3 de votre exécution.

Spécifiez la version de la syntaxe Nextflow

Nextflow v26.04.0 utilise l'analyseur syntaxique strict (v2) par défaut. Il s'agit d'une modification majeure pour les flux de travail écrits à l'aide de la syntaxe héritée (v1), qui est la valeur 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 dans la documentation Seqera Nextflow.

Pour exécuter un flux de travail créé à partir de l'ancien analyseur (v1), définissez sur v1 dans engineSettings.syntaxVersion la StartRun demande :

{
  "engineSettings": {
    "syntaxVersion": "v1"
  }
}

Pour Nextflow v25.10.0 et versions antérieures, HealthOmics ne prend pas en charge l'analyseur v2.

Validation automatique de la syntaxe lors de la création du workflow

HealthOmics exécute automatiquement le linter DSL2 strict intégré à Nextflow (nf-lang/v2) lorsque vous créez ou mettez à jour un flux de travail DSL2 Nextflow. Ce linter fonctionne pendant CreateWorkflow et. CreateWorkflowVersion Elle s'applique à toutes les versions DSL2 prises en charge (v22.04, v23.10, v24.10, v25.10 et v26.04). Les flux de travail DSL1 ne sont pas linted.

Le filtre fonctionne en mode non bloquant. Les résultats de Lint n'empêchent pas le flux de travail de devenir ACTIF. Les résultats apparaissent sous forme de JSON structuré dans le statusMessage champ de la GetWorkflow réponse.

Pour plus d'informations sur le format de sortie Lint et sur la manière de traiter les résultats, consultezLe flux de travail s'affiche HealthOmics.

Utiliser efficacement le stockage Scratch dans Nextflow

scratchLa directive de Nextflow contrôle l'endroit où un processus écrit ses fichiers de travail temporaires. Lorsque le stockage éphémère est activé (scratchStorageMode: LOCAL), utilisez la scratch directive pour rediriger Scratch I/O vers le volume local rapide situé à. /tmp

Le tableau suivant décrit les valeurs de scratch directive prises en charge et leur comportement dans HealthOmics :

L'approche recommandée consiste à définir scratch true dans votre définition de processus, qui utilise automatiquement $TMPDIR et ne nécessite aucune configuration de chemin :

process my_process {
    scratch true
    disk '200 GB'
    script:
    """
    my-tool --input ${input} --output ${output}
    """
}

Pour plus d'informations sur le stockage éphémère et la disk directive, consultez. Stockage éphémère pour HealthOmics les tâches de flux de travail

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

Obsolescence