The file reader is very simple example of component to read in files. If you have not done so already please have a read of A brief history of Iguana to understand the design philosophy here.
| Expand | ||
|---|---|---|
| ||
 There are three parameters:
| ||
| Expand | ||
| ||
The component behaves very simply. After a file is read and consumed by pushing the contents into a queue it is deleted. The component logs this activity to the logsThere is only one field to configure - the SourceDir. This is the directory that the component feeds from.  |
| Expand | ||
|---|---|---|
| ||
😅 No lol - it’s not is it. In the first version of this component we did have more configuration fields on it. But taking a step back and thinking from an operations perspective it seemed like the most important field was the source directory. If I am an operations person, then this is what I need to look at if there is a problem. Everything else just seemed like noise. |
| Expand | ||
|---|---|---|
| ||
The file matching logic is deliberately isolated in it’s own file which we can see here: https://bitbucket.org/interfaceware/fromfile/src/main/MatchRules.lua Why do we put this logic in it’s own file? It’s applying a concept call Separation of Concerns. We simplify code and make it easy to understand by separating it into its own file. Looking the code you can see that this code will only match files with the extensions hl7, log and txt. If you need to change it then you have a very simple obvious place to go. |
| Expand | ||
|---|---|---|
| ||
It’s not really intended to be all things to everyone. It is however a very simple starting point to open up and customize to what you really need. You can see the source code for it right here: https://bitbucket.org/interfaceware/fromfile/src/main/main.lua It’s deliberately simple to make the code non intimidating to alter and customize. |
...