

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Specifiche della definizione del flusso di lavoro WDL
<a name="workflow-languages-wdl"></a>

I seguenti argomenti forniscono dettagli sui tipi e le direttive disponibili per le definizioni dei flussi di lavoro WDL in. HealthOmics

**Topics**
+ [Conversione implicita dei tipi in WDL lenient](#workflow-wdl-type-conversion)
+ [Definizione dello spazio dei nomi in input.json](#workflow-wdl-namespace-defn)
+ [Tipi primitivi in WDL](#workflow-wdl-primitive-types)
+ [Tipi complessi in WDL](#workflow-wdl-complex-types)
+ [Direttive in WDL](#workflow-wdl-directives)
+ [Metadati delle attività in WDL](#workflow-wdl-task-metadata)
+ [Esempio di definizione del flusso di lavoro WDL](#wdl-example)

## Conversione implicita dei tipi in WDL lenient
<a name="workflow-wdl-type-conversion"></a>

HealthOmics supporta la conversione implicita dei tipi nel file input.json e nella definizione del flusso di lavoro. Per utilizzare il tipo di casting implicito, specificate il motore di workflow come WDL clemente quando create il flusso di lavoro. WDL lenient è progettato per gestire i flussi di lavoro migrati da Cromwell. Supporta le direttive Cromwell dei clienti e alcune logiche non conformi.

[WDL lenient supporta la conversione dei tipi per i seguenti elementi nell'elenco delle eccezioni limitate di WDL:](https://github.com/openwdl/wdl/blob/wdl-1.2/SPEC.md#-limited-exceptions)
+ Float to Int, dove la coercizione non comporta alcuna perdita di precisione (ad esempio 1,0 mappato a 1).
+ String to Int/Float, dove la coercizione non comporta alcuna perdita di precisione.
+ Mappa [W, X] su Array [Pair [Y, Z]], nel caso in cui W sia coercibile con Y e X sia coercibile con Z.
+ Array [Pair [W, X] to Map [Y, Z], nel caso in cui W sia coercibile con Y e X sia coercibile con Z (ad esempio 1,0 mappato a 1).

Per utilizzare il type casting implicito, specificate il motore di workflow come WDL\$1LENIENT quando create il workflow o la versione del workflow.

**Nella console, il parametro del motore di workflow è denominato Language.** Nell'API, il parametro del motore di workflow è denominato **engine**. Per ulteriori informazioni, consulta [Creare un flusso di lavoro privato](create-private-workflow.md) o [Creare una versione del flusso di lavoro](workflows-version-create.md).

## Definizione dello spazio dei nomi in input.json
<a name="workflow-wdl-namespace-defn"></a>

HealthOmics supporta variabili completamente qualificate in input.json. Ad esempio, se dichiarate due variabili di input denominate number1 e number2 nel flusso di lavoro: **SumWorkflow**

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

 Puoi usarle come variabili complete in input.json: 

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

## Tipi primitivi in WDL
<a name="workflow-wdl-primitive-types"></a>

La tabella seguente mostra come gli input in WDL vengono mappati ai tipi primitivi corrispondenti. HealthOmics fornisce un supporto limitato per la coercizione dei tipi, quindi consigliamo di impostare tipi espliciti. 


**tipi primitivi**  

| Tipo WDL | Tipo JSON | Esempio WDL | Esempio di chiave e valore JSON | Note | 
| --- | --- | --- | --- | --- | 
| Boolean | boolean | Boolean b | "b": true | Il valore deve essere minuscolo e senza virgolette. | 
| Int | integer | Int i | "i": 7 | Deve essere senza virgolette. | 
| Float | number | Float f | "f": 42.2 | Deve essere non quotato. | 
| String | string | String s | "s": "characters" | Le stringhe JSON che sono un URI devono essere mappate su un file WDL per essere importate. | 
| File | string | File f | "f": "s3://amzn-s3-demo-bucket1/path/to/file" | Amazon S3 e HealthOmics lo storage URIs vengono importati purché il ruolo IAM fornito per il flusso di lavoro abbia accesso in lettura a questi oggetti. Non sono supportati altri schemi URI (come file://https://, eftp://). L'URI deve specificare un oggetto. Non può essere una directory, il che significa che non può terminare con un/. | 
| Directory | string | Directory d | "d": "s3://bucket/path/" | Il Directory tipo non è incluso in WDL 1.0 o 1.1, quindi sarà necessario aggiungerlo version development all'intestazione del file WDL. L'URI deve essere un URI Amazon S3 e deve avere un prefisso che termina con un '/'. Tutti i contenuti della directory verranno copiati in modo ricorsivo nel flusso di lavoro come singolo download. DirectoryDeve contenere solo file relativi al flusso di lavoro. | 

## Tipi complessi in WDL
<a name="workflow-wdl-complex-types"></a>

La tabella seguente mostra come gli input in WDL vengono mappati ai tipi JSON complessi corrispondenti. I tipi complessi in WDL sono strutture di dati composte da tipi primitivi. Le strutture di dati, come gli elenchi, verranno convertite in matrici.


**Tipi complessi**  

| Tipo WDL | Tipo JSON | Esempio WDL | Esempio di chiave e valore JSON | Note | 
| --- | --- | --- | --- | --- | 
| Array | array | Array[Int] nums | “nums": [1, 2, 3] | I membri dell'array devono seguire il formato del tipo di array WDL. | 
| Pair | object | Pair[String, Int] str\$1to\$1i | “str\$1to\$1i": \$1"left": "0", "right": 1\$1 | Ogni valore della coppia deve utilizzare il formato JSON del tipo WDL corrispondente. | 
| Map | object | Map[Int, String] int\$1to\$1string | "int\$1to\$1string": \$1 2: "hello", 1: "goodbye" \$1 | Ogni voce nella mappa deve utilizzare il formato JSON del tipo WDL corrispondente. | 
| 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>  | I nomi dei membri della struttura devono corrispondere esattamente ai nomi delle chiavi degli oggetti JSON. Ogni valore deve utilizzare il formato JSON del tipo WDL corrispondente. | 
| Object | N/D | N/D | N/D | Il Object tipo WDL è obsoleto e deve essere sostituito da Struct in tutti i casi. | 

## Direttive in WDL
<a name="workflow-wdl-directives"></a>

HealthOmics supporta le seguenti direttive in tutte le versioni WDL che supportano. HealthOmics 

### Configura le risorse della GPU
<a name="workflow-wdl-directive-gpu"></a>

HealthOmics supporta gli attributi di runtime **acceleratorType** e **acceleratorCount** con tutte le istanze [GPU](https://docs.aws.amazon.com/omics/latest/dev/task-accelerators.html) supportate. HealthOmics supporta anche gli alias denominati **gpuType** and**gpuCount**, che hanno le stesse funzionalità delle controparti con acceleratore. Se la definizione WDL contiene entrambe le direttive, HealthOmics utilizza i valori dell'acceleratore.

L'esempio seguente mostra come utilizzare queste direttive:

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

### Configurare la ripetizione delle attività per gli errori di servizio
<a name="workflow-wdl-task-retry"></a>

HealthOmics supporta fino a due tentativi per un'operazione non riuscita a causa di errori di servizio (codici di stato HTTP 5XX). È possibile configurare il numero massimo di tentativi (1 o 2) e disattivare i tentativi per errori di servizio. Per impostazione predefinita, HealthOmics tenta un massimo di due nuovi tentativi. 

L'esempio seguente imposta `preemptible` la disattivazione dei nuovi tentativi per errori di servizio:

```
{
  preemptible: 0 
}
```

Per ulteriori informazioni sui nuovi tentativi di attività in HealthOmics, vedere. [Ritentativi di attività](monitoring-runs.md#run-status-task-retries)

### Configurare un nuovo tentativo di operazione in caso di esaurimento della memoria
<a name="workflow-wdl-retries"></a>

HealthOmics supporta nuovi tentativi per un'operazione che non è riuscita perché la memoria è esaurita (codice di uscita del contenitore 137, codice di stato HTTP 4XX). HealthOmics raddoppia la quantità di memoria per ogni nuovo tentativo.

Per impostazione predefinita, HealthOmics non riprova per questo tipo di errore. Utilizzate la `maxRetries` direttiva per specificare il numero massimo di tentativi.

L'esempio seguente è `maxRetries` impostato su 3, in modo che HealthOmics tenti un massimo di quattro tentativi di completare l'operazione (il tentativo iniziale più tre tentativi):

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

**Nota**  
Per riprovare l'operazione se la memoria non è sufficiente, è necessario GNU findutils 4.2.3\$1. Il contenitore di immagini predefinito include questo pacchetto. HealthOmics Se specificate un'immagine personalizzata nella definizione WDL, assicuratevi che l'immagine includa GNU findutils 4.2.3\$1.

### Configura i codici di restituzione
<a name="workflow-wdl-directive-returnCodes"></a>

L'attributo **ReturnCodes** fornisce un meccanismo per specificare un codice di ritorno, o un set di codici di ritorno, che indica l'esecuzione corretta di un'attività. Il motore WDL rispetta i codici restituiti specificati nella sezione **runtime** della definizione WDL e imposta lo stato delle attività di conseguenza. 

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

HealthOmics **supporta anche un alias denominato **continueOnReturnCode**, che ha le stesse funzionalità di ReturnCodes.** **Se si specificano entrambi gli attributi, HealthOmics utilizza il valore ReturnCodes.**

## Metadati delle attività in WDL
<a name="workflow-wdl-task-metadata"></a>

HealthOmics supporta le seguenti opzioni di metadati per le attività WDL.

### Disattiva la memorizzazione nella cache a livello di attività con l'attributo volatile
<a name="workflow-wdl-volatile-attribute"></a>

L'attributo **volatile** consente di disabilitare la memorizzazione nella cache delle chiamate per attività specifiche nel flusso di lavoro WDL. Quando un'attività è contrassegnata come volatile, verrà sempre eseguita e non utilizzerà mai i risultati memorizzati nella cache, anche quando la memorizzazione nella cache è abilitata per l'esecuzione.

Aggiungi l'attributo **volatile** alla **meta-sezione della definizione** dell'attività:

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

## Esempio di definizione del flusso di lavoro WDL
<a name="wdl-example"></a>

Gli esempi seguenti mostrano le definizioni di workflow private per la conversione da `CRAM` a `BAM` in WDL. Il `BAM` flusso di lavoro `CRAM` to definisce due attività e utilizza gli strumenti del `genomes-in-the-cloud` contenitore, illustrato nell'esempio e disponibile pubblicamente. 

L'esempio seguente mostra come includere il contenitore Amazon ECR come parametro. Ciò consente di HealthOmics verificare le autorizzazioni di accesso al contenitore prima che inizi l'esecuzione.

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

L'esempio seguente mostra come specificare quali file utilizzare nell'esecuzione, quando i file si trovano in un bucket 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"
}
```

Se desideri specificare file da un archivio di sequenze, indicalo come mostrato nell'esempio seguente, utilizzando l'URI per l'archivio delle sequenze.

```
{
    "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"
}
```

È quindi possibile definire il flusso di lavoro in WDL come illustrato nell'esempio seguente. 

```
 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}"
    }
}
```