

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 définition du flux de travail WDL
<a name="workflow-languages-wdl"></a>

Les rubriques suivantes fournissent des informations détaillées sur les types et les directives disponibles pour les définitions de flux de travail WDL dans HealthOmics.

**Topics**
+ [Conversion de type implicite dans WDL Lenient](#workflow-wdl-type-conversion)
+ [Définition de l'espace de noms dans input.json](#workflow-wdl-namespace-defn)
+ [Types primitifs dans WDL](#workflow-wdl-primitive-types)
+ [Types complexes dans WDL](#workflow-wdl-complex-types)
+ [Directives dans WDL](#workflow-wdl-directives)
+ [Métadonnées des tâches dans WDL](#workflow-wdl-task-metadata)
+ [Exemple de définition de flux de travail WDL](#wdl-example)

## Conversion de type implicite dans WDL Lenient
<a name="workflow-wdl-type-conversion"></a>

HealthOmics prend en charge la conversion de type implicite dans le fichier input.json et dans la définition du flux de travail. Pour utiliser le casting de type implicite, spécifiez le moteur de flux de travail comme WDL indulgent lorsque vous créez le flux de travail. WDL Lenient inclut toutes les fonctionnalités WDL standard ainsi que des comportements de compatibilité supplémentaires conçus pour les flux de travail migrés depuis Cromwell. Il prend en charge les directives Cromwell du client et certaines logiques non conformes.

[WDL Lenient prend en charge la conversion de type pour les éléments suivants de la liste des exceptions limitées de WDL :](https://github.com/openwdl/wdl/blob/wdl-1.1/SPEC.md#-limited-exceptions)
+ Float jusqu'à Int, où la coercition n'entraîne aucune perte de précision (par exemple, 1,0 correspond à 1).
+ Chaîne to Int/Float, où la coercition n'entraîne aucune perte de précision.
+ Associez [W, X] à Array [Pair [Y, Z]], dans le cas où W est coercible à Y et X est coercible à Z.
+ Array [Pair [W, X]] to Map [Y, Z], dans le cas où W est coercible à Y et X est coercible à Z (par exemple, 1.0 correspond à 1).

Pour utiliser le casting de type implicite, spécifiez le moteur de flux de travail sous la forme WDL\_LENIENT lorsque vous créez le flux de travail ou la version du flux de travail.

Dans la console, le paramètre du moteur de flux de travail s'appelle **Language**. Dans l'API, le paramètre du moteur de flux de travail est nommé **moteur**. Pour plus d’informations, consultez [Création d'un flux de travail privé](create-private-workflow.md) ou [Création d'une version de flux de travail](workflows-version-create.md).

## Définition de l'espace de noms dans input.json
<a name="workflow-wdl-namespace-defn"></a>

HealthOmics prend en charge les variables entièrement qualifiées dans input.json. Par exemple, si vous déclarez deux variables d'entrée nommées numéro1 et numéro2 dans le flux de travail : **SumWorkflow**

```
workflow SumWorkflow {
  input {
    Int number1
    Int number2
  }
}
```

 Vous pouvez les utiliser comme variables entièrement qualifiées dans input.json : 

```
{
    "SumWorkflow.number1": 15,
    "SumWorkflow.number2": 27
}
```

## Types primitifs dans WDL
<a name="workflow-wdl-primitive-types"></a>

Le tableau suivant montre comment les entrées de WDL correspondent aux types primitifs correspondants. HealthOmics fournit une prise en charge limitée de la coercition de type. Nous vous recommandons donc de définir des types explicites. 


**Types primitifs**  

| Type WDL | Type JSON | Exemple WDL | Exemple de clé et de valeur JSON | Remarques | 
| --- | --- | --- | --- | --- | 
| Boolean | boolean | Boolean b | "b": true | La valeur doit être en minuscules et sans guillemets. | 
| Int | integer | Int i | "i": 7 | Ne doit pas être entre guillemets. | 
| Float | number | Float f | "f": 42.2 | Ne doit pas être entre guillemets. | 
| String | string | String s | "s": "characters" | Les chaînes JSON qui sont des URI doivent être mappées à un fichier WDL pour être importées. | 
| File | string | File f | "f": "s3://amzn-s3-demo-bucket1/path/to/file" | Amazon S3 et les URI HealthOmics de stockage sont importés tant que le rôle IAM fourni pour le flux de travail dispose d'un accès en lecture à ces objets. Aucun autre schéma d'URI n'est pris en charge (tel que file://https://, etftp://). L'URI doit spécifier un objet. Il ne peut pas s'agir d'un répertoire, ce qui signifie qu'il ne peut pas se terminer par un/. | 
| Directory | string | Directory d | "d": "s3://bucket/path/" | Le Directory type n'est pas inclus dans WDL 1.0 ou 1.1, vous devrez donc l'ajouter version development à l'en-tête du fichier WDL. L'URI doit être un URI Amazon S3 avec un préfixe se terminant par un «/». Tout le contenu du répertoire sera copié de manière récursive dans le flux de travail sous forme de téléchargement unique. Le ne Directory doit contenir que des fichiers liés au flux de travail. | 

## Types complexes dans WDL
<a name="workflow-wdl-complex-types"></a>

Le tableau suivant montre comment les entrées de WDL correspondent aux types JSON complexes correspondants. Les types complexes dans WDL sont des structures de données composées de types primitifs. Les structures de données telles que les listes seront converties en tableaux.


**Types complexes**  

| Type WDL | Type JSON | Exemple WDL | Exemple de clé et de valeur JSON | Remarques | 
| --- | --- | --- | --- | --- | 
| Array | array | Array[Int] nums | “nums": [1, 2, 3] | Les membres du tableau doivent suivre le format du type de tableau WDL. | 
| Pair | object | Pair[String, Int] str\_to\_i | “str\_to\_i": {"left": "0", "right": 1} | Chaque valeur de la paire doit utiliser le format JSON du type WDL correspondant. Les noms de clés de chaîne dans les représentations JSON WDL Pair sont comparés sans distinction majuscules/majuscules. Par exemple, {"left » : « 0", « right » : 1} et {"LEFT » : « 0", « Right » : 1} sont traités comme équivalents lors de la désérialisation dans un type Pair. | 
| Map | object | Map[Int, String] int\_to\_string | "int\_to\_string": { 2: "hello", 1: "goodbye" } | Chaque entrée de la carte doit utiliser le format JSON du type WDL correspondant. | 
| Struct | object | <pre>struct SampleBamAndIndex { <br />  String sample_name <br />  File bam <br />  File bam_index <br />} SampleBamAndIndex b_and_i</pre>  |  <pre>"b_and_i": { <br />   "sample_name": "NA12878", <br />   "bam": "s3://amzn-s3-demo-bucket1/NA12878.bam", <br />   "bam_index": "s3://amzn-s3-demo-bucket1/NA12878.bam.bai" <br />}           </pre>  | Les noms des membres de la structure doivent correspondre exactement aux noms des clés d'objet JSON. Chaque valeur doit utiliser le format JSON du type WDL correspondant. | 
| Object | N/A | N/A | N/A | Le Object type WDL est obsolète et doit être remplacé par Struct dans tous les cas. | 

## Directives dans WDL
<a name="workflow-wdl-directives"></a>

HealthOmics prend en charge les directives suivantes dans toutes les versions de WDL prises HealthOmics en charge.

### Configuration des ressources GPU
<a name="workflow-wdl-directive-gpu"></a>

HealthOmics prend en charge les attributs d'exécution **acceleratorType** et **acceleratorCount** avec toutes les [instances de GPU](https://docs.aws.amazon.com/omics/latest/dev/task-accelerators.html) prises en charge. HealthOmics prend également en charge les alias nommés **gpuType** et**gpuCount**, qui ont les mêmes fonctionnalités que leurs homologues accélérateurs. Si la définition WDL contient les deux directives, HealthOmics utilise les valeurs de l'accélérateur.

L'exemple suivant montre comment utiliser ces directives :

```
runtime {
    gpuCount: 2
    gpuType: "nvidia-tesla-t4"
}
```

### Configurer une nouvelle tentative de tâche pour les erreurs de service
<a name="workflow-wdl-task-retry"></a>

HealthOmics prend en charge jusqu'à deux tentatives pour une tâche qui a échoué en raison d'erreurs de service (codes d'état HTTP 5XX). Vous pouvez configurer le nombre maximum de tentatives (1 ou 2) et vous pouvez désactiver les tentatives en cas d'erreur de service. Par défaut, deux HealthOmics tentatives au maximum sont tentées. 

L'exemple suivant permet `preemptible` de désactiver les tentatives en cas d'erreur de service :

```
{
  preemptible: 0 
}
```

Pour plus d'informations sur les nouvelles tentatives de tâches HealthOmics, consultez[Nouvelles tentatives de tâches](monitoring-runs.md#run-status-task-retries).

### Configurer une nouvelle tentative de tâche en cas de mémoire insuffisante
<a name="workflow-wdl-retries"></a>

HealthOmics prend en charge les nouvelles tentatives pour une tâche qui a échoué en raison d'un manque de mémoire (code de sortie du conteneur 137, code d'état HTTP 4XX). HealthOmics double la quantité de mémoire à chaque nouvelle tentative.

Par défaut, HealthOmics ne réessaie pas pour ce type d'échec. Utilisez la `maxRetries` directive pour spécifier le nombre maximal de tentatives.

L'exemple suivant définit `maxRetries` la valeur 3, de sorte que quatre HealthOmics tentatives au maximum sont tentées pour terminer la tâche (la première tentative plus trois nouvelles tentatives) :

```
runtime {
    maxRetries: 3
}
```

**Note**  
Une nouvelle tentative de tâche en cas de mémoire insuffisante nécessite GNU findutils 4.2.3\+. Le conteneur HealthOmics d'images par défaut inclut ce package. Si vous spécifiez une image personnalisée dans votre définition WDL, assurez-vous qu'elle inclut GNU findutils 4.2.3\+.

### Configurer les codes de retour
<a name="workflow-wdl-directive-returnCodes"></a>

L'attribut **ReturnCodes** fournit un mécanisme permettant de spécifier un code de retour, ou un ensemble de codes de retour, indiquant l'exécution réussie d'une tâche. Le moteur WDL respecte les codes de retour que vous spécifiez dans la section **d'exécution** de la définition WDL et définit le statut des tâches en conséquence. 

```
runtime {
    returnCodes: 1
}
```

HealthOmics prend également en charge un alias nommé **continue OnReturnCode**, qui possède les mêmes fonctionnalités que **ReturnCodes**. Si vous spécifiez les deux attributs, HealthOmics utilise la valeur **ReturnCodes**.

## Métadonnées des tâches dans WDL
<a name="workflow-wdl-task-metadata"></a>

HealthOmics prend en charge les options de métadonnées suivantes pour les tâches WDL.

### Désactiver la mise en cache au niveau des tâches avec l'attribut volatile
<a name="workflow-wdl-volatile-attribute"></a>

L'attribut **volatile** vous permet de désactiver la mise en cache des appels pour des tâches spécifiques de votre flux de travail WDL. Lorsqu'une tâche est marquée comme volatile, elle s'exécute toujours et n'utilise jamais les résultats mis en cache, même lorsque la mise en cache est activée pour l'exécution.

Ajoutez l'attribut **volatile** à la **méta-section** de votre définition de tâche :

```
task my_volatile_task {
    meta {
        volatile: true
    }
    
    input {
        String input_file
    }
    
    command {
        echo "Processing ${input_file}" > output.txt
    }
    
    output {
        File result = "output.txt"
    }
}
```

## Exemple de définition de flux de travail WDL
<a name="wdl-example"></a>

Les exemples suivants présentent des définitions de flux de travail privés pour la conversion de `CRAM` vers `BAM` dans WDL. Le `BAM` flux `CRAM` de travail to définit deux tâches et utilise les outils du `genomes-in-the-cloud` conteneur, qui est illustré dans l'exemple et est accessible au public. 

L'exemple suivant montre comment inclure le conteneur Amazon ECR en tant que paramètre. Cela permet HealthOmics de vérifier les autorisations d'accès à votre conteneur avant qu'il ne commence l'exécution.

```
{
   ...
   "gotc_docker":"<account_id>.dkr.ecr.<region>.amazonaws.com/genomes-in-the-cloud:2.4.7-1603303710"
}
```

L'exemple suivant montre comment spécifier les fichiers à utiliser lors de votre exécution, lorsque les fichiers se trouvent dans un compartiment Amazon S3.

```
{
    "input_cram": "s3://amzn-s3-demo-bucket1/inputs/NA12878.cram",
    "ref_dict": "s3://amzn-s3-demo-bucket1/inputs/Homo_sapiens_assembly38.dict",
    "ref_fasta": "s3://amzn-s3-demo-bucket1/inputs/Homo_sapiens_assembly38.fasta",
    "ref_fasta_index": "s3://amzn-s3-demo-bucket1/inputs/Homo_sapiens_assembly38.fasta.fai",
    "sample_name": "NA12878"
}
```

Si vous souhaitez spécifier des fichiers à partir d'un magasin de séquences, indiquez-le comme indiqué dans l'exemple suivant, en utilisant l'URI du magasin de séquences.

```
{
    "input_cram": "omics://429915189008.storage.us-west-2.amazonaws.com/111122223333/readSet/4500843795/source1",
    "ref_dict": "s3://amzn-s3-demo-bucket1/inputs/Homo_sapiens_assembly38.dict",
    "ref_fasta": "s3://amzn-s3-demo-bucket1/inputs/Homo_sapiens_assembly38.fasta",
    "ref_fasta_index": "s3://amzn-s3-demo-bucket1/inputs/Homo_sapiens_assembly38.fasta.fai",
    "sample_name": "NA12878"
}
```

Vous pouvez ensuite définir votre flux de travail dans WDL comme indiqué dans l'exemple suivant. 

```
 version 1.0
workflow CramToBamFlow {
    input {
        File ref_fasta
        File ref_fasta_index
        File ref_dict
        File input_cram
        String sample_name
        String gotc_docker = "<account>.dkr.ecr.us-west-2.amazonaws.com/genomes-in-the-
cloud:latest"
    }
    #Converts CRAM to SAM to BAM and makes BAI.
    call CramToBamTask{
         input:
            ref_fasta = ref_fasta,
            ref_fasta_index = ref_fasta_index,
            ref_dict = ref_dict,
            input_cram = input_cram,
            sample_name = sample_name,
            docker_image = gotc_docker,
     }
     #Validates Bam.
     call ValidateSamFile{
        input:
           input_bam = CramToBamTask.outputBam,
           docker_image = gotc_docker,
     }
     #Outputs Bam, Bai, and validation report to the FireCloud data model.
     output {
         File outputBam = CramToBamTask.outputBam
         File outputBai = CramToBamTask.outputBai
         File validation_report = ValidateSamFile.report
      }
}
#Task definitions.
task CramToBamTask {
    input {
       # Command parameters
       File ref_fasta
       File ref_fasta_index
       File ref_dict
       File input_cram
       String sample_name
       # Runtime parameters
       String docker_image
    }
   #Calls samtools view to do the conversion.
   command {
       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
    }
    
    #Runtime attributes:
    runtime {
        docker: docker_image
    }

    #Outputs a BAM and BAI with the same sample name
     output {
         File outputBam = "~{sample_name}.bam"
         File outputBai = "~{sample_name}.bai"
    }
}

#Validates BAM output to ensure it wasn't corrupted during the file conversion.
task ValidateSamFile {
   input {
      File input_bam
      Int machine_mem_size = 4
      String docker_image
   }
   String output_name = basename(input_bam, ".bam") + ".validation_report"
   Int command_mem_size = machine_mem_size - 1
   command {
       java -Xmx~{command_mem_size}G -jar /usr/gitc/picard.jar \
       ValidateSamFile \
       INPUT=~{input_bam} \
       OUTPUT=~{output_name} \
       MODE=SUMMARY \
       IS_BISULFITE_SEQUENCED=false
    }
    runtime {
    docker: docker_image
    }
   #A text file is generated that lists errors or warnings that apply.
    output {
        File report = "~{output_name}"
    }
}
```