This will use the "featureCounts" tool from the "subread" package.
-# Writing the tool wrapper
+### 1. File header
-1. Create a new file "featureCounts.cwl"
+Create a new file "featureCounts.cwl"
-2. Start with this header
+Start with this header
```
cwlVersion: v1.2
class: CommandLineTool
```
-3. Command line tool inputs
+### 2. Command line tool inputs
A CommandLineTool describes a single invocation of a command line program.
counts_input_bam: File
```
-4. Specifying the program to run
+### 3. Specifying the program to run
Give the name of the program to run in `baseCommand`.
baseCommand: featureCounts
```
-5. Command arguments
+### 4. Command arguments
The easiest way to describe the command line is with an `arguments`
section. This takes a comma-separated list of command line arguments.
$(inputs.counts_input_bam)]
```
-6. Outputs section
+### 5. Outputs section
In CWL, you must explicitly identify the outputs of a program. This
associates output parameters with specific files, and enables the
glob: featurecounts.tsv
```
-7. Running in a container
+### 6. Running in a container
In order to run the tool, it needs to be installed.
Using software containers, a tool can be pre-installed into a
dockerPull: quay.io/biocontainers/subread:1.5.0p3--0
```
-8. Running a tool on its own
+### 7. Running a tool on its own
When creating a tool wrapper, it is helpful to run it on its own to test it.
cwl-runner featureCounts.cwl featureCounts.yaml
```
-9. Adding it to the workflow
+### 8. Adding it to the workflow
Now that we have confirmed that it works, we can add it to our workflow.
We add it to `steps`, connecting the output of samtools to
Analyzing a single sample is great, but in the real world you probably
have a batch of samples that you need to analyze and then compare.
-1. Subworkflows
+### 1. Subworkflows
In addition to running command line tools, a workflow step can also
execute another workflow.
If you run this workflow, you will get exactly the same results as
before, we've just wrapped the inner workflow with an outer workflow.
-2. Scattering
+### 2. Scattering
The wrapper lets us do something useful. We can modify the outer
workflow to accept a list of files, and then invoke the inner workflow
ScatterFeatureRequirement: {}
```
-3. Running with list inputs
+### 3. Running with list inputs
The `fq` parameter needs to be a list. You write a list in yaml by
starting each list item with a dash. Example `main-input.yaml`
Now you can run the workflow the same way as in Lesson 2.
-4. Combining results
+### 4. Combining results
Each instance of the alignment workflow produces its own featureCounts
file. However, to be able to compare results easily, we need them a
# Expressions
-1. Expressions on step inputs
+### 1. Expressions on step inputs
You might have noticed that the output bam files are all named
`Aligned.sortedByCoord.out.bam`. This happens because because when we
separate the leading part of our filename from the "Aligned.bam"
extension that will be added by STAR.
-2. Organizing output files into Directories
+### 2. Organizing output files into Directories
You probably noticed that all the output files appear in the same
directory. You might prefer that each file appears in its own
type: File
outputSource: featureCounts/featurecounts
```
-
-3. Other uses for expressions
-
-- Creating configuration files on the fly.