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.

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.

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 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.

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, voirNextflow Gestion du modèle Glob dans les entrées Amazon S3.

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 :

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 optionretry, HealthOmics tente une nouvelle tentative de la tâche qui a échoué. Pour augmenter le nombre de tentatives, voirTentatives 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 le mode HealthOmics de gestion des nouvelles tentatives de tâches lors 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 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, consultezNouvelles tentatives de tâches.

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 (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 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 référence Nextflow.

HealthOmics fournit le support suivant pour la directive temporelle Nextflow :

Spécifiez la durée du délai d'expiration en utilisant une ou plusieurs des unités suivantes :ms,s, mh, oud.

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 étiquettemy_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.

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 :

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 "<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é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 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 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

Obsolescence